Detecting short pulses

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
Hello,

Suppose our application has to detect an incoming short pulse - faster than any of our clocks can sample reliably (or perhaps we don't even know the width of the incoming pulse).

My solution:

1. Drive the short signal (our_short_pulse) into a clock pin of a DFF (sadly wasting a BUFG).
2. Issue a detection flag (short_pulse_detected) to the slow clock domain.
3. Issue a reset signal to the detector (short_pulse_acknowledge).

Code: 
process (short_pulse_acknowledge , our_short_pulse) is
begin
if short_pulse_acknowledge = '1' then
  short_pulse_detected <= '1' ;
elsif rising edge ( our_short_pulse ) then
   short_pulse_detected <= '1' ;
end if ;
end process ;

So far, so good - I thought...
But than I found this interesting post:


What are the benefits of using the suggested method over my simple solution ?
 

The shown code is never resetting the DFF, so it can't be right.

I would use a toggle synchronizer for this and similar problems.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
The shown code is never resetting the DFF, so it can't be right
Click to expand...
.
Code: 
process (short_pulse_acknowledge , our_short_pulse) is
begin
if short_pulse_acknowledge = '1' then
  short_pulse_detected <= [COLOR="#FF0000"]'0'[/COLOR] ; -- '1' was a typo...
elsif rising edge ( our_short_pulse ) then
   short_pulse_detected <= '1' ;
end if ;
end process ;


I would use a toggle synchronizer for this and similar problems.
Click to expand...
Can you post an example please?
Correct me if I'm wrong, but a toggle synchronizer creates a long pulse from the sending clock domain. However, my example assumes that we don't have access to that domain. I.E: all our FPGA gets is a very short pulse.
 

Assuming that I'm thinking of the same circuit as FvM. I've used toggle synchronizers to do this, with the restriction that the pulses need to be at least far enough apart to resynchronize to the detecting clock domain.

The idea is to use a toggle flop, followed by edge detection in the detecting clock domain (both edges using XOR). Due to the synchronizer and the edge detect you'll need at least 3 detecting clocks of separation between pulses.

You also don't need to use a global buffer to clock the FF just add constraints to keep the FF near the I/O where the pulse input is located.

Something like this is what I've used in the past and perhaps is what FvM is suggesting.
Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10

reg toggle = 0;
always @ (posedge pulse_pin) begin
  toggle <= ~toggle;
end
reg [2:0] t_dly;
reg pulse_clk;
always @ (posedge clk) begin
  t_dly <= {t_dly[1:0], toggle};
  pulse_clk <= (t_dly[2:1] == 2'b01) ? 1'b1 : 1'b0;
end


- - - Updated - - -

Oh, yeah if you can't afford to miss pulses that may be way less than the 3 detecting clock cycles apart...

Use a 1-bit async FIFO with the write enable and data input set high and the pulse connected to the clock input.
On the read side as long as the empty flag is low you have a detected pulse in the FIFO. Of course now you have to use a clock buffer to distribute the pulse, but now you have the luxury of dealing with the pulses at the aggregate rate instead of a possible burst rate exceeding the toggle synchronizer's ability to detect.
 
This is somewhat similar to what I wrote in #3 - the difference is that I use an asynchronous reset from the receiving clock domain to clear the DFF.

Back to my question:
Do you see any benefits in using the solution proposed in this link:
https://www.doulos.com/knowhow/fpga/fastcounter/
 

Thanks to ads-ee for elaborating the toggle synchronizer principle.

A solution to acquire asynchronous pulses with higher rate is a gray counter with it's output synchronized to the slow domain. It can be understood as generalization of the toggle synchronizer.

I must confess that I didn't exactly understood the operation of the linked circuit, particularly the purpose of the set and clr clocks. Synchronization circuits with asynchronous FF operation are often considered as unreliable. I can confirm that it's easy to overlook hidden trapdoors.

A good overview of various synchronization circuits is given in a Sunburst paper http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf
 

Hi,

What if you see the "short pulse" as clock input?
And run a simple binary counter with it...
Then use the outputs of the counter.

***

The problem I see is that your "short pulses" are not defined...also there is no definition what you want to achieve.
If you just want to see the existance of any pulse you could just use an (unclocked) RS flip flop.
The "short pulse" sets the output.. you can read the state from a lower frequency clock domain...and reset it.
But for sure you may miss pulses

If you don't want to miss a single pulse, the things become difficult.
* You need to ensure, that the incoming pulse is long enough to safely trigger a flip flop
* and you need to be sure that the time between two (rising) edges is long enough to process (in any way) the pulse before.
Both is not defined ..

A good solution need good specifications first.

Klaus
 

What if you see the "short pulse" as clock input?
And run a simple binary counter with it...
Then use the outputs of the counter.
Click to expand...
The pulse signal has to be treated as clock in any case, constraints like minimal pulse width and maximum frequency must be kept.

The said toggle synchronizer can be understood as a single bit counter. If proceeding to multiple bits, you get a problem of transferring the counter values consistently to the asynchronous clock domain. Gray encoding is a popular method to achieve this.
 

FvM,

Anything wrong with what I proposed in #3 ?
 

Anything wrong with what I proposed in #3 ?
Click to expand...
No, if short_pulse_acknowledge is a synchronized copy of short_pulse_detected.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Keep in mind that there is a minimum pulse width spec for most FPGAs, and the various internals. The pulse detection can be done by using it as a clock or an async set/reset. The best place is likely to be within the IO. However, if the pulse is shorter than the minimum pulse width you may not have a reliable design.

Interestingly, the pulse width is not the same for all internals in the FPGA. For the Kintex7 (as an example), the shift registers and some IO registers are best, with general fabric registers being worst. The minimum width is actually pretty long for general purpose registers at near 1 nanosecond. For this reason, I would prefer to instantiate the primitive that I want in order to prevent an incorrect one from being inferred.

The other options would be to use an external pulse stretching circuit, or using a high speed serial IO input to oversample the input.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Keep in mind that there is a minimum pulse width spec for most FPGAs
Click to expand...
As with any other practical non-ideal IC...

BTW,
talking about minimum pulse width, given an FPGA - is it the same for clock and asynchronous reset ?
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…