UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Xilinx Employee
Xilinx Employee
16,469 Views
Registered: ‎03-24-2008

Re: How to set timing constraint in this case.

Mark,

 

The tools do not do "fake" analysis.  They do worst case analysis.  Assuming synchronous is worst case, the most conservative position.  Adopting accepted SDC methodology is the industry standard, and is taken from ASIC tools where the ramifications of mistaken assumptions can be millions of dollars in mask costs.  It is the right thing to do.  It is what Altera does and every commercial tool suite for both ASIC and FPGA (Synopsys, Cadence, Mentor, etc), all following Primetime which is the gold standard STA tool.

 

The position in Vivado is that it is better to report the timing path and force the user to explicitly override it than to go the other way around and assume silently that clocks are unrelated. 

 

We have been investing tremendously in improving the reporting and analysis capabilities to educate our customers of the importance of this aspect.  Please have a look at our clock interaction report, clock network report, and new for 2014.3 is report_cdc which reports on the clock domain crossings.  Our new Timing Constraint Wizard also is heavily geared to analyze your design netlist and guide you to the appropriate constraints, including for the clock groups.

Greg Daughtry
Vivado Product Marketing Director, Xilinx, Inc.
Xilinx Employee
Xilinx Employee
16,465 Views
Registered: ‎03-24-2008

Re: How to set timing constraint in this case.

Shihua,

 

There is no such thing as a "safe" clock based on its frequency.  Crossings from fast to slow or slow to fast or even 2 identical frequency clocks can never be assumed to be safe if they have no primary clock root, and you ALWAYS need to be concerned about metastability and synchronization logic.

 

There are of course several ways of designing clock crossings - but our primary recommendation is a synchronizer chain of 2 or greater flops, with identical control sets so they can be placed in the same slice, and marked with ASYNC_REG=TRUE.  This minimizes recovery time in the inevitable event of metastability and assures you with appropriate latency such that the last chain in the synchronizer remains stable with the correct value.  This also lowers the MTBF and improves reliability of the circuit/design.

 

We cannot and will not adjust the priority of set_max_delay over set_clock_group.  This goes against industry standard practices for SDC behavior, and is dangerous based on interoperability principles.

 

The only time you really need a datapthonly constraint is in a vector crossing that is grey coded, like our soft fifo.  The rest of the time - placing a datapath only constraint on an asynchronous signal crossing is unnecessary overhead - and should be avoided.  This is our recommendation as outlined in the UltraFast Design Methodology user guide.


@zhoushihua wrote:

 

I do not need take care about metastablity, sync logic... I only need caculate ratio of the cpm clock and sys clock. because in this picture if the signal 4 is not stable when the first counter equal to 4, it will stable in the next time counter equal to 4. So if the CPM clock fast enough. the data will be safe. 


 

Greg Daughtry
Vivado Product Marketing Director, Xilinx, Inc.
Scholar markcurry
Scholar
16,459 Views
Registered: ‎09-16-2009

Re: How to set timing constraint in this case.


@daughtry wrote:

Mark,

 

The tools do not do "fake" analysis.  They do worst case analysis.  Assuming synchronous is worst case, the most conservative position.  .


The tools is assuming a phase relationship where none exists.  The numbers spit out have no utility.  Call it what you want, but I call it fake.  In the best case this won't hurt you.  In the worst one can be fooled into thinking that all is well, when in fact, it is not.  (The tool failing to report any problems because the assumed ( "fake" ) phase relation ship meets timing).

 

Altera recommends async clock groups - as I am doing with Xilinx.  But as noted in these threads, I'm missing timing checks this way.  But I've got no choice.  Both the OP in this thread and myself have NO way to analyze these paths with current methodologies. 

 

Xilinx should lead by example here.  What about some of the suggestions in this thread of changing the priority of constraints, or adding a max_skew check?  Either one of these would solve the problem.

 

Regards,

 

Mark

 

 

0 Kudos
Scholar muravin
Scholar
16,456 Views
Registered: ‎11-21-2013

Re: How to set timing constraint in this case.

Greg,

 

I agree with your response to Mark.

 

(and I still think we could benefit from set_false_path -from $src_clk -to $dest_clk -except $list_of_path_we_care_about).

 

I read your response to Shihua, and maybe there is something I still don't understand (and if I indeed don't, I would like to), but I cannot agree on one thing. Sorry.

 

Based on my limited experience, I did try set_max_delay without the datapath_only, and my synthesis runtime ++ and timing score ++ probably because all the related clock edges, sooner or later "collide".

 

This is wrong.

 

What I believe Shihua should do, is to use set_max_delay -datapath_only $val, and not what myself and Mark chose to do, i.e. set_false_path, but for the entire clock-to-clock path not just async paths.

 

The experiment I made as mentioned in the earlier post, $val = 6-7 ns makes virtually no change on the runtime when all set_false_path are replaced by set_max_delay, as following.

 

Instead:

set_false_path -from [get_clocks gmii_gtx_txclkout] -to [get_clocks axi_bus_clk]

 

Shihua can use:

set_max_delay $val -from [get_clocks gmii_gtx_txclkout] -to [get_clocks axi_bus_clk] -datapath_only

 

Again, $val should be calculated based on the number of the sync stages minus some overhead. As long as it it something like 6-7 ns, there should be no impact on the runtime (although not sure how this works out in 90%+ FPGA utilization case).

 

Regards

Vlad

Vladislav Muravin
0 Kudos
Scholar markcurry
Scholar
16,427 Views
Registered: ‎09-16-2009

Re: How to set timing constraint in this case.

All,

 

FYI - Paul Zimmer has an excellant writeup from SNUG 2013, on how this exact problem is handled in ASIC land (Primetime).  The paper's available here (But you'll need a Solvnet Login to access):

 

"No Man's Land” Constraining async clock domain crossings

 

The basic premise is to indeed start with clocks defined properly in async clock groups.

 

Then, parallel versions of the CDC clocks are created with create_clock -add

 

These parallel versions of the clocks are then used to do the set_max_delay constraints. (This is greatly simplified, see the paper).

 

A large part of the paper is getting the tools to correctly NOT use the clock insertion delay - i.e. the Xilinx equivalent of -datapath only.  So we'd be ahead of the game there.

 

I've no idea if the methodology presented in the paper will work with Vivado.  I'll be looking into trying it soon.  

 

Shihua - if you have access to this paper, I'd suggest giving it a read and trying.

 

Regards,

 

Mark

0 Kudos
Scholar dwisehart
Scholar
16,424 Views
Registered: ‎06-23-2013

Re: How to set timing constraint in this case.

Paul Zimmer's paper is also available here without a Synopsis login:

http://www.zimmerdesignservices.com/no_mans_land_20130328.pdf

 

Daniel

 

0 Kudos
Historian
Historian
16,407 Views
Registered: ‎01-23-2009

Re: How to set timing constraint in this case.

FYI - Paul Zimmer has an excellant writeup from SNUG 2013, on how this exact problem is handled in ASIC land (Primetime).  The paper's available here (But you'll need a Solvnet Login to access):

 

[Edited]

 

A large portion of the solution presented here is trying to get the tools to not analyze the clock insertion delays for the CDC paths (since they are meaningless and effectively incorrect). It does this by declaring these two new clocks as ideal clocks. Ideal clocks are not supported in Vivado (at least I am pretty sure), since it really doesn't make sense in an FPGA - ideal clocks are used in the ASIC world before the clock trees have been inserted; in the FPGA world clock trees have already been inserted, so you never use ideal clocks.

 

But, the fact that we can't use ideal clocks is irrelevent. Xilinx (cleverly) added a command that allows us to create a constraint that is analyzed without clock tree delays; set_max_delay -datapath_only.

 

With the set_max_delay -datapath_only constraint, we can correctly constrain the path without the need to define these new "clock crossing clocks". So, what do these new clocks buy you? The short answer is - the thing that people here have been complaining about. With these new clocks, you can define the original clocks as asynchronous, and then have a set_max_delay -datapath_only on the CDC path (that will only use the new clocks). While I haven't tried this, I don't see any reason why it won't work in Vivado. 

 

One of the advantages the author is working toward is being able to constrain the paths based on clocks, rather than FFs. You can do this without the CDC clocks using set_max_delay -from <clka> -to <clkb> -datapath_only, but Greg  ( @daughtry ) advises against it due to potential run time issues. Again, you have to use the set_max_delay -datapath_only (instead of a regular set_max_delay as the author does), since I don't believe we can work with ideal clocks. Also this "advantage" is also a disadvantage - if you inadvertently have a path between the two domains that isn't covered by a clock crossing circuit, this constraint will cover it, masking a potential failure.

 

What else does it cost you? The addition of these new clocks immediately quadruples the number of paths in your design - since now every physical path has two starting clocks and two ending clocks. The additional constraints go about declaring most of these as false, so that, in the end, only one path remains for each physical path (between the regular clocks for all non-CDC paths and between the CDC clocks for all CDC paths). My concern, though, is that keeping track of all these false paths will have a negative impact on run time - maybe Greg can comment on whether this is true.

 

The other concern is that this is all going to be horribly confusing to someone who inherits this constraint file without full knowledge of this mechanism. While it makes sense (and is VERY clever - particularly in the Synopsys world that doesn't have access to the -datapath_only), it is using some pretty advanced knowledge of SDC - I think a lot of engineers (especially those who are newer to SDC) will have trouble following this. If you do choose to do this, I would highly recommend putting lots of comments into your constraint file, and even include a link to this paper (for the poor soul that is going to inherit your constraint file at some point down the road).

 

Avrum

Tags (2)
0 Kudos
Observer zhoushihua
Observer
16,170 Views
Registered: ‎04-24-2008

Re: How to set timing constraint in this case.

Thanks, I will read that document.

0 Kudos
Observer zhoushihua
Observer
16,169 Views
Registered: ‎04-24-2008

Re: How to set timing constraint in this case.

Thanks for the link.

0 Kudos
4,953 Views
Registered: ‎09-28-2017

Re: How to constrain clock crossing paths

HI Avrum

 

For <value> of set_max_delay constraints do we have to use max period of a clock or min period of clock. Why?

Please clarify.

 

Regards

Vinoddh


@avrumw wrote:

Using set_max_delay -datapath_only between two clocks tells the tool to ignore mechanism it usually uses to derive the requirement for the path, and instead use the requirement given in the set_max_delay. Therefore, this constraint is a different (but equally valid, or even better) way of telling the tool that the clocks are asynchronous. So, if you use a set_max_delay -datapath_only, you don't need to use a set_false_path or set_clock_groups on that path. So, if you have

 

set_max_delay <value> -from [get_clocks cpmclk] -to         [get_clocks {clka clkb clkc clkd clke}] -datapath_only

set_max_delay <value> -to       [get_clocks cpmclk] -from    [get_clocks {clka clkb clkc clkd clke}] -datapath_only

 

There is no additional need to do anything to make cpmclk "async" to all the rest.

 

If all the other clocks are really async, then you can do

set_clock_groups -asynchronous \

   -group [get_clocks clka] \

   -group [get_clocks clkb] \

   -group [get_clocks clkc] \

   -group [get_clocks clkd] \

   -group [get_clocks clke]

 

But (here is my standard word of caution) - declaring paths as false (which is what set_clock_groups does) is rarely the correct thing to do. If there are no paths between any pairs of these clocks, then you don't need any constraints - setting them as asyncrhonous doesn't do anything. If there are paths between them, then these paths must have clock crossing circuits. Except for the "single slow changing signal" clock crosser, almost all clock crossing circuits need constraints - setting them as false paths underconstrains the clock crossing circuit, which can result in system failure. For most circuits, you need a set_max_delay -datapath_only constraint on the path between the domains. The value of the max_delay depends on the clock crosser, but almost all of them have a requirement.

 

In my opinion, there are very few places where a set_false_path or set_clock_groups shoud be used...

 

Avrum


 

0 Kudos
Historian
Historian
3,274 Views
Registered: ‎01-23-2009

Re: How to constrain clock crossing paths

For <value> of set_max_delay constraints do we have to use max period of a clock or min period of clock. Why?

Please clarify.

 

I don't really understand your question. Normally a clock has only a single value for its period - this is neither a max nor a min.

 

In cases where the clock frequency is unknown (or can be one of several values) depending on system usage, then most of the time the fastest clock (smallest period) is the most demanding, and hence is what is used for constraints.

 

If you are talking about crossing between two clocks and are asking which period we use (the source or the destination, the maximum or the minimum), then the answer depends on the style of the clock domain crossing circuit. Depending on the structure being used, sometimes the right answer is the source clock, sometimes it is the destination clock and sometimes it is the minimum period of the two (the faster clock).

 

Avrum

0 Kudos
Historian
Historian
3,240 Views
Registered: ‎01-23-2009

Re: How to constrain clock crossing paths

To echo a small point in Avrum's excellent post: it would be very nice to have way to constrain skew.

 

(I know this thread is old, but it is worth updating...)

 

Now you can!

 

Xilinx introduced the set_bus_skew command in a "recent" version (some time in 2016). Now you can specify the maximum skew on a set of paths.

 

Since the set_bus_skew operates on a set of paths (rather than on individual paths), it does not run into the same "constraint priority" that has been discussed above - any constraints you have on individual paths (set_max_delay, set_false_path, set_clock_groups) will not affect the set_bus_skew command.

 

Avrum

Tags (1)