Detecting a pulse with minimum width

[M. Hamed]

I have an input signal that is required to be high for a certain
length in time before a halt request is issued to a processor. To
detect this signal, three solutions popped into my head.

1- A shift register with all bits ANDed together. The output is taken
from the AND gate and will not be high unless the signal has passed
completely through the pipeline without going to zero(except for any
glitches that wasn't captured by the first FF.

2- A shift register with the Reset line (active low) of all the FFs
tied to to the signal. The output is taken from the last FF. In such a
case the last FF will never be 1 unless the signal was high for the
whole period while passing through the entire pipeline. If it goes to
zero any time before that, then all FFs (and hence the last FF) will
be zero. This solution may be more elegant than the first since it
doesn't really matter how long the pipeline is, while in the first,
the more stages, the bigger the AND gate. It would also detect any
glitches on the signal.

3- Divide the master clock using a binary counter until the desired
time length is achieved, then use a variation of the previous two
schemes but with a much reduced shift register length.

Which solution would you choose? Are there any better approaches? I
would personally choose the third solution combined with the second,
since it means fewer FFs can be used for longer required times, and
any glitches will invalidate the pipeline.

Thank you!

 

[Brad Smallridge]

You haven't stated how long the signal needs to stay nor your
clock frequency. You are right about option 2 needing less
logic, never thought of that, and if you are working in Xilinx
then you may get a nice 16 to one compression in your register
use when the synthesizer packs your registers into an SRL16,
although I'm not sure you can reset all the internal flip-flops.

The most conventional solution is a counter that counts to your
desired time and triggers.

Brad Smallridge
AiVision

 

[M. Hamed]

You haven't stated how long the signal needs to stay nor your
clock frequency. You are right about option 2 needing less
logic, never thought of that, and if you are working in Xilinx
then you may get a nice 16 to one compression in your register
use when the synthesizer packs your registers into an SRL16,
although I'm not sure you can reset all the internal flip-flops.

The most conventional solution is a counter that counts to your
desired time and triggers.

Brad Smallridge
AiVision

My clock period is 10 ns, and the delay is 50 ns for now but longer
delay is anticipated.

IIRC, once I use async reset that automatically prohibits the
synthesizer from using SRL16. (Sorry I forgot to mention this is going
to a Xilinx Spartan3).

I think besides the counter, I need at least two extra FFs to make
sure the signal will pass through for the specified time.

Thanks.

 

[KJ]

My clock period is 10 ns, and the delay is 50 ns for now but longer
delay is anticipated.

A choice between 5 flops for the shift register and 4 for a counter (3 to
count, 1 presumably for the final reset out). It really doesn't matter much
does it?

Longer delays meaning another flop or two wouldn't do much to sway me one
way or the other, longer delays meaning maybe 10 clocks then I probably
would go the counter route.

Another consideration is whether this input is already synchronized to the
clock or not. If not, then you'll need to add synchronizing flops before
feeding it into the counter whereas the shift register approach inherently
has them (but you would need to lengthen the shift chain to guarantee the
50ns).

IIRC, once I use async reset that automatically prohibits the
synthesizer from using SRL16. (Sorry I forgot to mention this is going
to a Xilinx Spartan3).

Whether you use a sync or an async reset shouldn't matter, if the SRL15
likes sync resets then give it a sync reset.

I think besides the counter, I need at least two extra FFs to make
sure the signal will pass through for the specified time.

Not sure what you mean by this, but I'm guessing it might be having to do
with the input maybe being asynchronous to the clock. If that's the case,
then you need to synchronize with any approach and take that into account in
figuring out if you have your 50 ns or not.

Kevin Jennings