cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
3,273 Views
Registered: ‎04-11-2018

Async reset - min pulse width?

Jump to solution

I have a vu440, with high speed logic (600+mhz) generating async reset to a slower domain. The slow domain is guaranteed to have reset recovery/removal times met. Is there a min pulse width for the async reset? I don't see the pulse width in the data sheet.

thank you.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
4,162 Views
Registered: ‎11-03-2016

Re: Async reset - min pulse width?

Jump to solution

Hi,

While I was not able to recover the minimal requirement for reset pulse width on Ultrascale and Ultrascale+, you can get an estimate from previous generations (Both Spartan6 and Artix-7 have them listed in their datasheet although in different places in the doc). The minimal SR pulse width should be smaller than the smallest period achievable by the logic. I give no guarantee, but it would mess up a lot of designs relying on this otherwise.

Regards,

YL

View solution in original post

21 Replies
Highlighted
Teacher
Teacher
3,265 Views
Registered: ‎07-09-2009

Re: Async reset - min pulse width?

Jump to solution

a bit more detail / code would be good.

 

general, async resets are avoided inside an fpga,

      ok there are times thy are needed,

 

but a syncronous reset is the normal, sample the asyncronous reset to a clock, 

    and you have a reset that can be timmed

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Mentor
Mentor
3,253 Views
Registered: ‎02-24-2014

Re: Async reset - min pulse width?

Jump to solution

Scratch my previous reply..  checking the data sheet now.. 

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Highlighted
Visitor
Visitor
3,244 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

drjohn, the high speed domain consumes an event flag from the slow domain. The fast domain needs to re-arm the event flag in the slow domain, prior to the next clock in the slow domain. That is the reason for the min pulse width question, and why the reset must be asynchronous.

0 Kudos
Highlighted
Mentor
Mentor
3,241 Views
Registered: ‎02-24-2014

Re: Async reset - min pulse width?

Jump to solution

I am reasonably sure that a single clock cycle pulse from a 700 MHz clock domain will meet the minimum pulse width.   That's at least 1.4 ns.    Under 1 ns, I'm not sure.  But have you gotten any pulse width violations from Vivado when running this through timing analysis?    If not... assume you are good to go.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Guide
Guide
3,236 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

the high speed domain consumes an event flag from the slow domain. The fast domain needs to re-arm the event flag in the slow domain, prior to the next clock in the slow domain.

 

Depending on some conditions, this has the potential to be a very difficult thing to deal with. Let me ask two questions.

 

 - what is the frequency of the low speed clock

 - are the two clocks (high and low speed) synchronous - i.e. from the same MMCM with the same clock buffer (and in the same CLOCK_DELAY_GROUP)

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
3,233 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

Ok, I'll run with it as a single clock pulse. 

Still simulating at the moment, will run it through the tools very soon. I was curious if STA would detect the AR pulse width, but it seems highly unlikely without some guidance (if even possible). thanks

0 Kudos
Highlighted
Guide
Guide
3,221 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

I was curious if STA would detect the AR pulse width, but it seems highly unlikely without some guidance (if even possible).

 

While I am not certain, I doubt that the tool will "extract" the pulse width (based on the fact that it is driven from a clock on a faster domain) and use that as a pulse width check on the asynchronous clear.

 

I suspect that the tools only check recovery and removal times on the flip-flops. In your case, you will have to disable these checks since they will be clock crossing paths (hence not valid checks to perform).

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
3,220 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

avrumw, these are true async clocks, not related. The slow is 20mhz.

There are directed constraints to deal with recovery/removal. Functional timing guarantees the budget+ given in the constraints.

0 Kudos
Highlighted
Guide
Guide
3,205 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

So within one 20MHz clock

   - the rising edge of the 20MHz clock causes the "event" signal to rise

   - the event signal is brought to the high speed domain

       - this requires metastability resolution

          - at least 3 maybe 4 back to back flip-flops on the high speed domain with the ASYNC_REG property set

       - this requires a set_max_delay -datapath_only between the FF on the 20MHz domain and the FF on the high speed domain to limit the routing length (hence delay) between these two

   - the synchronized event is edge detected on the high speed domain

   - this edge detected event causes a one clock wide pulse on the high speed domain

   - this pulse is connected to the async clear of the flip-flop on the 20MHz domain

       - this requires another set_max_delay -datapath_only to limit the routing

       - the reset removal/recovery is "guaranteed" due to the fact that the round trip path from the original 20MHz clock to the async clear's removal is guaranteed to be (significantly) less than one 20MHz clock period, but significantly more than a handful of high speed clock periods

   - the next rising edge of the 20MHz clock can cause the event to rise again

 

Here is another question - is the "event" flip-flop on the 20MHz domain used for anything other than the path to the high speed domain - i.e. is there another 20MHz FF (either directly or through logic) that uses the output of this flip-flop (and this includes the event FF itself - does it have feedback from itself)? If so then the static timing behavior of any path that starts at the event FF is not "normal". The static timing analysis ensures that a path from a 20MHz FF to a 20MHz FF takes less than 50ns. But in the case of the event FF, part of this 50ns is taken by the trip to and back from the high speed domain. Therefore, these paths need to be artificially constrained to 50ns - (worst case round trip delay to the high speed domain) - (skew and uncertainty).

 

So, all this can be made to work (due to the VERY high ratio between the fast and slow domains), but it requires some fancy constraints.

 

But I wonder if there isn't a better way. What is "setting" the event register? Is it set every 20MHz clock? Is it set only on some 20MHz clocks? Is the asynchronous clear only required for the edge detect on the high speed domain?

 

I can see other solutions to all of these problems that don't require using the asynchronous clear; there are simpler (less asynchronous) mechanisms of having the high speed domain sample a condition on the low speed clock at a rate of once per low speed clock period...

 

Avrum

0 Kudos
Highlighted
Teacher
Teacher
3,084 Views
Registered: ‎07-09-2009

Re: Async reset - min pulse width?

Jump to solution

this is the classic clock domain crossing question.

 

look up CDC circuits. for instance this hit "crossing clock domain vhdl"

 

it all depends on the relative speeds / frequency of the pulses as to what you use, and multiple options are available in the tools.

 

 

what you dont want is an asynchronous reset 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Xilinx Employee
Xilinx Employee
4,163 Views
Registered: ‎11-03-2016

Re: Async reset - min pulse width?

Jump to solution

Hi,

While I was not able to recover the minimal requirement for reset pulse width on Ultrascale and Ultrascale+, you can get an estimate from previous generations (Both Spartan6 and Artix-7 have them listed in their datasheet although in different places in the doc). The minimal SR pulse width should be smaller than the smallest period achievable by the logic. I give no guarantee, but it would mess up a lot of designs relying on this otherwise.

Regards,

YL

View solution in original post

Highlighted
Visitor
Visitor
3,045 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

yes, reasonable that min pulse width >= min clock period. But not guaranteed, hence the question. :) The goal is to keep logic tight and lightweight as possible to ease timing closure @silicon limits. Would be nice to have this stated as such in the data sheet or CLB user guide. thank you for confirming.

0 Kudos
Highlighted
Teacher
Teacher
3,036 Views
Registered: ‎07-09-2009

Re: Async reset - min pulse width?

Jump to solution

Are you feeding the reset into the SR input of the FF.

 

look at the implemented design, not your equations.

 

You need to design your circuit such that you do not rely upon asynchronous rests, 

     

try this as some examples of the sort of thing you can do,

 

http://www.fpga4fun.com/CrossClockDomain.html

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Guide
Guide
3,030 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

But I wonder if there isn't a better way. What is "setting" the event register? Is it set every 20MHz clock? Is it set only on some 20MHz clocks? Is the asynchronous clear only required for the edge detect on the high speed domain?

 

I can see other solutions to all of these problems that don't require using the asynchronous clear; there are simpler (less asynchronous) mechanisms of having the high speed domain sample a condition on the low speed clock at a rate of once per low speed clock period...

 

You have multiple people telling you "don't use asynchronous resets this way". Why don't you respond to these questions - maybe we can point you to a less ugly solution to your problem...

 

And maybe the most specific question - is the high speed clock domain guaranteed to consume the "event" within one 20MHz clock period?

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
3,016 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

avrum, because the question is regarding pulse width requirements, not when or how to use async reset. That said, yes, this is a CDC and data is consumed once per 20mhz cycle. This is a simplified description, but the essence is there. The async reset is the cleanest solution in terms of managing convergence, STA and footprint.

 

0 Kudos
Highlighted
Guide
Guide
2,999 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

The async reset is the cleanest solution in terms of managing convergence, STA and footprint.

 

I would submit that there is a cleaner (less asynchonous) approach to the problem...

 

Start with a toggle flip-flop on the 20MHz domain

 

always @(posdege clk20)

   toggle_20 <= !toggle_20

 

Synchronize this to the clk_fast domain with a triple (or quadruple) synchronizer.

 

always @(posedge clk_fast)

begin

   toggle_20_meta1 <= toggle_20;

   toggle_20_meta2 <= toggle_20_meta1;

   toggle_20_meta3 <= toggle_20_meta2;

   toggle_20_clk_fast <= toggle_20_meta3;

end

 

Place ASYNC_REG attributes on all flip-flops of the synchronizer (meta1, meta2, meta3 and toggle_20_clk_fast) and, for safety put a set_max_delay -datapath_only (with a delay of the period of clk_fast) on the path between toggle_20_reg and the first metastability flip-flop (toggle_20_meta1_reg).

 

Do edge detection on toggle_20_clk_fast

 

always @(posedge clk_fast)

  toggle_20_clk_fast_s1 <= toggle_20_clk_fast;

 

assign do_sample = toggle_20_clk_fast_s1 ^ toggle_20_clk_fast;

 

Now the signal "do_sample" is a normal signal on the clk_fast domain, that is asserted for exactly one fast clock period, a "short time" (3-4 clk_fast cycles) after the rising edge of the clk_20. This means that any data on the clk_20 domain can be sampled onto the clk_fast domain with no synchronizer (since it is stable). A set_max_delay -datapath_only (with a period of clk_fast) should be used between any signal on the clk_20 domain that is sampled by a flip-flop on the clk_fast domain which is enabled by this "do_sample" signal.

 

This allows clean transfer from the slow domain to the fast domain without any nasty asynchronous logic...

 

Avrum

Highlighted
Teacher
Teacher
2,985 Views
Registered: ‎07-09-2009

Re: Async reset - min pulse width?

Jump to solution

@dbriddel

 

you are right , async reset is very simple and elegant,

 

 

But remember you are running without tool support,

     the tools only work on synchronous / related paths,

 

So to use an asynchronous function, its up to you to ensure correct function, in all situations , temperatures and voltages.

    These are the things the tools do for you in synchronous designs.

 

The essence is, one designs very conservatively when using asynchronous logic.

     you have to be very aware of glitches / runts / meta stability and ensure the thing can not under any of these conditions lock up or miss an event.

 

A few of us have done some interesting work on asynchronous. I've worked on an asynchronous processor, no clock involved, totaly data driven, 

 

 

BUT , 99.99999 percent of the time, 

    simplifying the logic to the minimum , and using clock domain crossing techniques is the safe way forward,

 

good luck with relying upon asynchronous pulse widths 

      

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Visitor
Visitor
2,896 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

for any CDC boundary it is critical to identify and constrain all paths between domains, and at higher clock speeds (>400mhz) the internal synchronizer logic as well. Underconstraining high speed convergence logic is a recipe for reduced MTBF. ASYNC_REG is not enough. RLOC and max_delays are necessary. Ultrascale does have hardened synchronizer primitives, but unfortunately I can't make use of these due to floorplanning requirements.

Highlighted
Guide
Guide
2,890 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

for any CDC boundary it is critical to identify and constrain all paths between domains, and at higher clock speeds (>400mhz) the internal synchronizer logic as well. Underconstraining high speed convergence logic is a recipe for reduced MTBF.

 

This is definitely true.

 

ASYNC_REG is not enough. RLOC and max_delays are necessary.

 

But I am not sure where you get this from...

 

First let's talk about ASYNC_REG. If the placer sees two flip-flops that are connected Q to D and they both have the ASYNC_REG property, then the placer will put these two flip-flops "as close together as possible". If there are multiple flip-flops in a chain with the property set, then this will apply to all flip-flops in the chain. This means that these flip-flops will be placed in the same slice if possible, or in adjacent slices if not possible. The only reasons that it would not be possible is if

  - the flip-flops do not share the same control set

     - but all FFs in a synchronizer chain should use the same control set

  - if the chain is larger than can be fit in one slice

     - in UltraScale the slice has 8 primary flip-flops (and 8 secondary flip-flops) so this is not likely to be the case

 

So, with the ASYNC_REG property, the flops will all be placed in the same slice. A LOC or RLOC constraint cannot do any better than this - so the ASYNC_REG should be sufficient.

 

While I haven't seen it explicitly stated, it is my (and probably Xilinx's) assumption that when routing between two FFs in the same slice the route will not enter the routing channels - it will stay local to the switch matrix beside the slice. As a result, the route is guaranteed to be as small as it can possibly be. If the flip-flops are only in adjacent slices (which shouldn't be the case, as discussed above), then they will enter the routing channel. If this is the case, then theoretically this route could be moved due to congestion. I don't know if the router has any special rules regarding these nets, but if one is worried about it, one could put set_max_delay commands on the paths between the synchronizer flip-flops; I used to do that before the ASYNC_REG property, but it is now my belief that they are unnecessary.

 

So, given this, why do you think the ASYNC_REG is not sufficient?

 

Avrum

Highlighted
Visitor
Visitor
2,265 Views
Registered: ‎04-11-2018

Re: Async reset - min pulse width?

Jump to solution

ASYNC_REG is the recommended attribute, however I have found it to be "best effort". The related flops are usually packed in same slice, but not always. For congested designs, logic can be shuffled around to achieve better timing and routability (as perceived  by the placer). I have also found route delays to be far from minimal, and this is THE critical item for synchronizer performance. It is not uncommon for route delays to consume a large portion of the clock period for high speed designs, which in turn quickly degrades MTBF. RPM'ing the synchronizer and applying max_delay ensures that every synchronizer instance is the highest quality. I have 1000's of synchronizer instances to deal with, so the RPM really helps QoR, while the max_delay is probably sufficient otherwise. If latency isn't an issue, or at slow/medium clock speeds, then ASYNC_REG alone will suffice. 

Highlighted
Guide
Guide
2,255 Views
Registered: ‎01-23-2009

Re: Async reset - min pulse width?

Jump to solution

I have also found route delays to be far from minimal, and this is THE critical item for synchronizer performance.

 

This is absolutely correct!

 

It is not uncommon for route delays to consume a large portion of the clock period for high speed designs, which in turn quickly degrades MTBF.

 

Given the above, if this is really the case then this is a BUG - plain and simple. If you can reproduce this should be submitted as a SR to fix. Xilinx is pretty serious about MTBF and the ASYNC_REG property is supposed to ensure that the tool does its very best to maximize MTBF. If this is not the case, then it needs to be fixed.

 

Avrum