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: 
Observer zhoushihua
Observer
31,500 Views
Registered: ‎04-24-2008

How to set timing constraint in this case.

My design have 5 different clock. clka, clkb, clkc, clkd and clke. All these clocks are async. I have another clock named cpmclk, which is running very fast to packing parellel signal to serail and transfer between FPGAs.

The path between cpmclk and clka, clkb...clke is async, but I need control the datapath delay to one cpmclk.

 

In the past (ISE), I can set all the clock clka, clkb...clke and cpmclk to async, and add a set_max_delay datapath_only between cpmclk and  clka, clkb...clke.

 

But in vivado the set_clock_groups have the higher priority, if I set them to async the set_max_delay constraint will be ignore by the tools.

 

How to set timing constraint in this case. Thanks.

 

BRs

Shihua

0 Kudos
41 Replies
Historian
Historian
31,488 Views
Registered: ‎01-23-2009

Re: How to constrain clock crossing paths

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
Scholar muravin
Scholar
31,485 Views
Registered: ‎11-21-2013

Re: How to set timing constraint in this case.

Avrum,

Can you please explain what do you mean by your word of caution? If VIVADO by default assumes all clocks are related, and if they are not, one has to tell this to the tool otherwise it will workd harder and give lots of timing violations etc. But both of us know that, so maybe I misunderstood the message you are trying to convey? And if I may ask, why do you think using false_path is rarely correct thing to do?

Thank you very much

Vlad

Vladislav Muravin
0 Kudos
Highlighted
Historian
Historian
31,470 Views
Registered: ‎01-23-2009

Re: How to constrain clock crossing paths

So, yes, Vivado assumes all clocks are related. And, yes, if they are not, in fact, related, then we need a timing exception to tell the tool that the normal "synchronous" timing checks on the path are not to be performed. There are three ways to do this

  - set_false_path

  - set_clock_groups (which is really the same as set_false_path between pairs of clocks)

  - set_max_delay -datapath_only

 

It is my argument that, in most cases, only the last one is correct.

 

Lets break this down into a couple of cases...

 

If two clocks are not related, but there are no paths between them, then no additional constraints are required; since no paths exist, the tools will not have any paths to optimize, so it becomes irrelevent whether the clocks are related or not. The "report_clock_interaction" command is perfect for identifying these.

 

If two clocks are not related, but paths exist between them, then there must be a clock crossing circuit between them. The clock crossing circuit allows data to be moved across the unrelated clock domain boundary in spite of the fact that no known phase relationship exists between the two clocks (and this includes clocks that are unrelated in either frequency or phase, since the net result is the same, there is no minimum guaranteed separation between the edges of the source and destination clock). This clock crossing circuit must accurately bring data across the boundary in spite of the fact that no phase relationship exists, and therefore must deal with

  - metastability, since you may well violate the setup/hold requirement of the capture FF in the destination domain

  - bus coherency (if the data being crossed is more than a single bit wide)

 

A lot of discussion on clock crossing revolves around metastability; when the D input of a FF changes too close to the active edge of the clock (and hence violates the setup or hold time), the FF may

   - keep its old state

   - transition to the new state

   - go metastable

       - once metastable, it will eventually resolve to either the old or new state, and the amount of time required for the metastability to resolve is probabilistic and (theoretically) unbounded

 

Metastability resolution circuits reduce the risk that a metastable signal will be used in the system in a way that causes a system failure; reduces it, but can never eliminate it entirely; asynchronous signals always cause some possibility  that your system will fail; the goal is to reduce the probability to low enough that your "Mean Time Between Failures (MTBF)" is sufficiently large to meet your systems goals. This is generally done with two (or more) back to back flip-flops; these flip-flops must have the ASYNC_REG property set on them, and should have set_max_delay constraints on them.

 

Bus coherency is different. If the data crossing the barrier is more than one bit wide, then the datum must be passed through accurately. If a bus changes from one datum (data_old) to a new datum (data_new) near a destination clock edge, then most clock crossing circuits must be designed in such a way to yield either of the two data (either data_old or data_new); it is impossible to know which one will get through, but it must be one or the other, and not some "other" datum. (Some clock crossers have a way of signalling "no data", when a reliable crossing cannot be done).

 

Bus coherency is actually the tougher problem. There are many approaches to crossing multiple-bit data. Lets take (common) problem of crossing a counting value from one domain into another (or more specifically, sampling the value of a counter in one domain using another domain). On any destination clock edge, the value of the counter in the source domain will be <cnt>. However, if we sample the value when it is transitioning between <cnt> and <cnt+1>, then the value received on the destination side must either be <cnt> or <cnt+1>.

 

We know this doesn't work with conventional binary counting sequences. If <cnt> = 4'b0111  (i.e. the decimal value 7), then what is received on the other side must either be 7 or 8. A simple metastability resolution circuit on each of the 4 bits won't get this; in this case, all 4 bits are transitioning, and hence each one may give

  - the old value

  - the new value

  - or go metastable

After metastability resolution each of the 4 bits (which are all transitioning), will resolve to either the old value or the new value. Thus, each will independently resolve to either a 0 or a 1, thus resulting in any value from 0000 to 1111 in the destination domain - this is a system failure, only 0111 or 1000 are correct.

 

One solution to this is to use a Gray code counter. Instead of counting in binary fashion (0000 0001 0010 0011 0010...) we count in a Gray code fashion, where each value in the counting sequence differs from the preceding one by only one bit change

    0000 = 0

    0001 = 1

    0011 = 2

    0010 = 3

    0110 =4

    0111 =5

    0101 =6

    0100 =7

    1100 =8

    1101 =9

    1111 =10

    1110 =11

    1010 =12

    1011 =13

    1001 =14

    1000 =15

Now, each transition from <cnt> to <cnt+1> has only one bit changing. If we sample around that point, only the one bit in question can be unknown, which guarantees that on the destination side we will get either the old value <cnt> or the new value <cnt+1>. Note that the "+" operator here is not done using 2s compliment addition, but with Gray code addition (a different logical function).

 

But, lets look at a potential problem. If we declare the clock crossing path false (with set_false_path or set_clock_groups) then there is no constraint on the path between the last FF in the source domain and the first FF in the destination domain. If we do this, the clock crosser can fail!

 

With no constraints (or false path constraints), the tool has no constraint on the path. Therefore, it can place the source and destination FF of the path anywhere on the die, and route them any way it wants. There is no limit on the propagation delay between the last FF on the source domain and the first FF on the destination domain.

 

Lets say the route for bit 1 is pretty short, but the route on bit 0 is very very long - lets say that it is more than one source clock period in length. To put real numbers on it, say the source clock is 10ns, the routing on bit 0 is 12ns and the routing on bit 1 is 1ns; remember, while this is unlikely, it is possible since there are no constraints on the path.

 

So lets look at the transition from 0 -> 1 -> 2

 

When the source counter transitions from 0->1 (lets call that time 0), bit 0 changes from a 0 to 1. It will take 12 ns for that to reach the sample FF on the destination domain. One clock later (at time 10ns), the counter transitions from 1->2; bit 0 will remain at a 1, but bit 1 will transition from a 0->1. It takes 1ns for that change to propagate to the capture FF, thus will arrive at  time 11.

 

In this case, what is at the input of the destination FFs between time 11 and time 12? The propagation of bit 1 has made it to the destination (so it is a 1), but the propagation of bit 0 has not yet (it will arrive at time 12), so it is still a 0. Thus the bus will be sampled as 0010. This is the code for the value 3! Thus, in the destination domain, it looks like our counter has gone 0 -> 3 -> 1 -> 2 -> 3 (assuming it is sampled fast enough). This is a system failure. 

 

So, how do we fix this. We need to constrain the clock crossing paths so that this is impossible. What we really need to do is ensure that the skew on the different bits of our Gray code bus is less than one source clock period. Even in Vivado, we cannot directly constrain skew. But, if we constrain the maximum delay on the path to be less than one source clock period, then we can (indirectly) constrain the skew. How do we do this

 

set_max_delay -from <source_FFs_on_source_domain> -to <destination_FFs_on_destination_domain> <value_less_than_source_clock_period> -datapath_only

 

Now, the skew is constrained, so the clock crosser can't fail.

 

Note: We can do this on the individual FFs on involved in the path, or we can do this on the clocks themselves. However, if we do a set_false_path between the clocks or a set_clock_groups on the clocks, then that constraint has the highest priority - even if we also do a set_max_delay on the FFs involved in the path, the set_clock_groups will override it, and the path will still be unconstrained.

 

This is a perfect example as to why set_false_path or set_clock_groups is incorrect for this path, but set_max_delay -datapath_only is correct.

 

Other clock crossers have similar (but different requirements). For example, if a clock crosser looks for a stable point to sample data by waiting until "just after a transition" on a bus that has infrequent transitions, then you end up with a skew requirement on the signal that crosses the clock domain which is signalling the change in the bus and the rest of the bits of the bus (hence it also needs a set_max_delay -datapath_only).

 

Furthermore, at the heart of any clock crossing FIFO is a Gray code clock crosser; this is used to cross the address from one domain to the other to calculate empty and full. Again, it needs a set_max_delay -datapath_only (unless it is the built-in FIFO, where the clock crosser is hardened).

 

This is what I mean by the set_false_path -from/to clocks or set_clock_groups rarely being the correct constraint. These do work if your only crossers on the domain are (or ever will be)

  - single bit slow changing signals or

  - clock crossing FIFOs using the built-in (hardened) FIFO

 

All other clock crossers will be underconstrained if you use set_clock_groups or set_false_path.

 

Avrum

Scholar muravin
Scholar
31,458 Views
Registered: ‎11-21-2013

Re: How to constrain clock crossing paths

Thank you for detailed answer. I understand now what you meant. I agree with you on the cause of the metastabilities as well as on the techniques to deal with this, and of course all the well-known clock domain crossings, bus transfers and coherency, FIFOs etc. We have a library of little modules that are designed to just deal with this.

 

My question was asked rather in the context of having a timing constraints that make the tool work more than it should. (which may not be as important as first of all one's making sure he/she has a proper education on *all* aspects of the CDC)

 

Say I have a clock domain such as 100 MHz that runs all the configuration that configures how my design would operate. And the rest of the design runs off completely different clock domain, which may or may not be related, and it is something like 333 MHz.

 

If I define a relationship between these clocks using the set_max_delay -datapath_only, the tool creates a completely different placement where the logic I don't care about its timing starts to be blended with the logic I do care about its timing and makes the tool work harder etc as it tries to put all the design together. I saw it on the floorplan.

 

If I tell the tool that these clocks are not related, and decouple them there is a completely different story. The non-related FFs are being thrown away, and runtime goes lower as the tool does not have to work more to do its job, TNS is 0 etc.

 

Again, I believe what you said is very important and as such, people should deal with the CDC situations. I guess what I want to emphasize is that, and again, this is said in the context of designers who *know* what they are doing, if there are constraints that may not have to exist, they should not exist.

 

For the Shihua, I believe that using set_false_paths followed by *correct* use of the set_max_delay for things like bus crossers and double-D oversamplers (which are exactly what Avrum mentioned), is another way to go. This is how we constrain our designs but perhaps there are designs where not using set_false_paths and just using set_max_delay would work better. Shihua can choose what's better for his application.

 

Thanks again for your response

Vlad

Vladislav Muravin
Historian
Historian
31,455 Views
Registered: ‎01-23-2009

Re: How to constrain clock crossing paths

Vlad,

 

Your example is a good one if it is designed correctly. This condition (where configuration registers are on a different clock domain from the datapath) happens "not infrequently". As long as you make sure that your data path is in reset (or some other mechanism to make sure it is not sensitive to configuration changes) when the configration registers are changed, then these can be declared as false paths. The are, in fact, really multicycle paths with very large multipliers (based on the minimum number of clocks between the last update of your configuration register and the re-enabling of your datapath), but it is pretty safe to call them false.

 

This is one of the few cases where a path between different domains does not have a clock crossing circuit (and is still correct). From the timing point of view on your datapath, the configuration inputs are considered "pseudo-static".

 

I will re-warn about one thing, though...

 

The set_false_path has an inherently higher priority than other path exceptions (including set_max_delay). So if you have FFA on CLKA and FFB on CLKB then

 

set_clock_groups -group CLKA -group CLKB

set_max_delay -from [get_cells FFA] -to [get_cells FFB] 5 -datapath_only

 

will not constrain the path between FFA and FFB. This path is included in the enumeration of both constraints, but the set_clock_groups has higher priority than the set_max_delay, so the path from FFA to FFB will remain a false_path. If the FFA to FFB path is part of your clock crosser then it will end up underconstrained.

 

Lets take your example. Most of the paths from the configiuration domain to the datapath domain are false. However, there is (at least) one that isn't; presumably one configuration bit controls the "enable" or "reset" to your datapath that ensures that it is idle when you change other configuration registers. This bit needs a clock crosser to bring it into the datapath domain. With a set_clock_groups, you cannot constrain it. (Although, this probably isn't a problem since it is a slow changing single bit signal, so is one of the clock crosser types that will work without a constraint).

 

Anyway, I hope you can see why I really discourage set_clock_groups or set_false_path -from <clock> -to <clock>; once these are done, no other constraints on paths between the domains will matter. Furthermore, you will not get any error or warning that the set_max_delay is not accomplishing anything. If paths are false (like yours), and the designer is sure of it, then he can declare them false - but I still recommend doing it by enumerating the FFs involved in the clock crossing; not by declaring the clocks false or unrelated.

 

Avrum

Scholar muravin
Scholar
31,448 Views
Registered: ‎11-21-2013

Re: How to constrain clock crossing paths

Oh well, I guess you are right 100%. Our example is that we make the designs not to care about these inter-clock domain stuff. And the way we use set_max_delay is slightly different in its purpose.

 

And, I'd add Xilinx should figure out a way to allow more flexibility on this topic (while properly educating the designers). One should be able to decouple 2 or more clock domains to timing-except 99% of the paths while still allowing the use of something equivalent to set_max_delay between maybe 1% of the path we may want to care about.

 

Regards Vlad

Vladislav Muravin
0 Kudos
Historian
Historian
31,446 Views
Registered: ‎01-23-2009

Re: How to constrain clock crossing paths

And, I'd add Xilinx should figure out a way to allow more flexibility on this topic (while properly educating the designers). One should be able to decouple 2 or more clock domains to timing-except 99% of the paths while still allowing the use of something equivalent to set_max_delay between maybe 1% of the path we may want to care about.

 

Unfortunately, this is not how SDC (as defined by Synopsys works) - the constraint priority stuff is part of the open standard SDC constraint system...

 

We are stuck with it!

 

Avrum

Scholar muravin
Scholar
31,444 Views
Registered: ‎11-21-2013

Re: How to constrain clock crossing paths

Let's look on the bright side: if this is our worst problem, we are the happiest ppk on this Earth :)
Vladislav Muravin
0 Kudos
Xilinx Employee
Xilinx Employee
31,388 Views
Registered: ‎03-24-2008

Re: How to constrain clock crossing paths

Avrum gave you some fantastic detail in his response and he is 100% correct.  I will add a tiny bit to this.  We are not really stuck w/ SDC technically speaking.  For example the datapath_only option to set_max_delay is after all an extension that we implemented that diverges from accepted SDC semantics.  We did that based on historical tools support from TRCE and customer requests.  I will point out however that ASIC designs, and our competitor who supports SDC have no such constraint.  Why is that?  The consequences of allowing a cross-clock domain violation into a $100M ASIC are far, far greater, and the tools cost a GREAT deal more than FPGA tools - surely there is a fancier/easier way to constrain these crossings if you the designer are absolutely certain you have designed your circuit correctly.

 

We could offer additional extensions - but it does not solve the root problem.  Frankly speaking it is not safe to do so - and that is why SDC and Vivado make the assumption that clocks are synchronous by default.  You as the designer must make sure there are no crossings for which you have not designed a proper synchronizing circuit to provide immunity from metastaiblity which will certainly happen in the crossing.  If you do that, all you need is the datapathonly to constraint the grey code interfaces - and you do not need the datapthonly constraint to not be overridden by set_clock_groups.

 

One final thought here.  The datapthonly constraint is extremely expensive computationally speaking in STA.  It is non-standard SDC - and when applied broadly such as between entire clock domains - it creates large fanin and fanout cones of logic that have to be traversed to apply the constraint.  This will really slow down the implementation runs and take a lot of memory.  It is best to use them very judiciously - only on the actual sync chains with a specfici -from and -to on the individual sync instances.  And then use report_clock_interaction and report_cdc (coming new with 2014.3) with good methodology checks and DRCs to make sure there are no undesired clock crossings.  

Greg Daughtry
Vivado Product Marketing Director, Xilinx, Inc.
Scholar dwisehart
Scholar
16,326 Views
Registered: ‎06-23-2013

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 find myself wanting to constrain skew when clock rates are slow for a certain portion of the design.  For the parts that run at a healthy clock rate of maybe 250MHz or faster, skew problems are not too likely for multiple paths that meet the max_delay constraint.  But when the clock rate is say 10MHz and you have five clocks to propogate multiple parallel paths, there is a good chance you will have a skew problem if you tell the tools what the real constraint is.  Instead, I "over-constrain" the route to make sure I do not have a skew problem.  This leads to congestion in some areas and whole clocking regions that have nothing in them.

 

set_max_skew -from $SRC -to $DEST -clock $DEST_CLK

 

would be a wonderful addition to Vivado.  No numbers are needed if Vivado understands that all of the signals from $SRC need to arrive at $DEST within the same $DEST_CLK cycle (minus the setup time of the destination).

 

Thanks,

Daniel

 

Scholar markcurry
Scholar
16,312 Views
Registered: ‎09-16-2009

Re: How to constrain clock crossing paths

Greg, and all.

 

A counter point with real examples.  I don't argue Avrum's detailed examples, nor correctness.  His analysis is spot on.  I argue from a point of view of practice, and what actually can be achieved using the tools as is.

 

We're strong advocates of use the async clock_groups use (or TIGs i.e. false paths in ISE).  Simply from a constraint management, (and as you indicated tool memory use) point of view.  It's just not feasible to come at this from the point of view of all clocks are synchronous, and then add exceptions for the cross-clock synchronizers. 

 

My current design is targetting a xc7k325t.  We have in the XDC file one line at the end which set's all the relevant clocks as asynchronous:

 

set_clock_groups -asynchronous -name async_global -group $clk_100 \
-group $clk_125 \
...

The number of clocks in that async group is 14.

 

The device passes timing, and functions.  We "bury or head in the sand" regarding the skew on the cross-clock synchronizers.  (Our constraints would be looser than Avrum's - because of our synchronizer design -  a max_delay -datapath_only of 3 * destination clk per, so it's a fairly safe bet the design's fine).

 

I did a 'reset_timing', and reapplied all constraints, without the async clk group.

 

Then I generated some timing paths -from a SINGLE CLK ($clk_100) -to all others

with "get_timing_paths".

 

The result: 

 Total number of all paths:                                                 112, 569

 Total "True" paths (fully sync - clk_100 to clk_100):     107, 079

                                                                                               -------------

(False paths) (difference):                                                      5,490
 
Of those "false" paths, I know there's (8) 32-bit buses that are on a synchronizer, that "should" have Avrum's constraint. I'll add 1 more bit for the handshaking signal.. So that's 8*33 = 264.
 
So 264/5490 "false" paths need a max_delay -datapath constraint.  That's less than 5%.  The others are all of the type that Vlad noted - configuration registers that are set at boot, and not used until MUCH later.  ("True" false_paths in my book)
 
So Avrum's "exception" is really the "rule" in my case.
 
If I followed your's and Avrum's advice, I'd need a max_delay -datapath on all 5490 paths, of which 5% are valid.
I'm sure, as you've noted, the tools would just completly choke on this.
 
And that's just from ONE of the 14 clocks, in ONE direction.
 
The suggested methodology is not feasable, nor maintainable.
 
I'm glad you're open to "not following the herd" with regard to SDC, and "standards". 
 
I'd come into this thread expecting good things from Vivado.  I've been thinking I can de-ostrich my head and come up with some kind of combined methodology, that does contrain the paths as suggested, but still leaves (my) default of unrelated clocks are NOT timed. After all, as I learned in these forums TCL in Vivado is much more powerful, and flexible.
 
But I learned in this thread that this is all hindered by the SDC priorities. Asynch clock groups (and false_paths) are priority 1, with max_delay -datapath_only below that (and thus ignored in my use case).
 
May I suggest that Xilinx considers changing this priority?  After all, as you noted -datapath only is a Xilinx  divergence from the "standard".  I think it should be default higher priority than all others, but perhaps you want to make it optional to maintain backward compat.
 
This would allow me to still go in and use the async clock groups.  But the add the exception for the cross-clock synchronizers, as suggested.  Avrum's metholdogy would still work too.
 
(As an alternative, If you want to go at this from the point of view of new features, the max_skew feature which others have suggested - make that new feature have higher priority).
 
This way, the user is free to choose the solution that best works for them.
 
Thanks and Regards,
 
Mark
 
 

 

 

 

 

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

Re: How to constrain clock crossing paths

Sorry for late response, too busy this days.

In my case clock_a is a register bus clock, clock_b is an module clock. The register value need to control the function of that module . so the clock_a and clock_b realy need set to different clock groups. This is just my case.

 

I will try your sugusstion.

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

Re: How to constrain clock crossing paths

Hi Muravin,

 

I have use set_false_path with set_max_delay datapath_only in Virtex-6 project, it works well. When we change to the Virtex-7 project, we change to set_clock_groups with set_max_delay datapah_only. But synplify says, in Virtex-7, set_clock_groups have the higher pirorty and the set_max_delay datapath_only is ignored by the tools, so the generated xdc file not include set_max_delay constraint. I try to add this contraind to vivado, vivado ignored this constraint also.

 

I have read the vivado docunment, it said set_clock_groups and set_false_path both have the higher pirorty than set_max_delay conratiant. So I did not try to use set_false_path like before.

 

Sorry for the late response, I am so busy to deliver FPGA build these days. And now I have time to try this. I will try set_falss_path with correct set_max_delay.

 

Thanks.

 

BRs

Shihua 

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

Re: How to constrain clock crossing paths

I agree with your piont, if Xilinx can adjust the priority of the set_max_delay higher, it will be the best way to solve this problem.

 

The reason why I write this post is.

Because the size of our design is very large, I need partition our design into 4 FPGAs, but the interconnection between them is over 1000 between each FPGA. So I use synopsys Certify CPM to do the pin multiplexer. So the CPM clock is fast clock which use to transfer 8 signal in 1 pins. But I need constraint all the other clock to cpm clock and cpm clock to all the other clock path delay to 1 or 2 cycle of cpm clock. Than I can caculate the clock ration between cpm clock and other clock to make sure the CPM logic can get a stable value when other clock edge come.

 

I have read some post in xilinx forums. They are also recommend not use set_false_path and set_clock_groups. I agree with them. But actually, the total number of constraint that need set with set_max_delay with datapath only is many. And my schduele is tough, so I write this post to see wethere there is some other way to do that. Now I have time to do some test on this, I will try all the suggesstion in real case.

 

It seems Xilinx change the changing this priority or let user define the priority is the best way to do that.

 

BRs

Shihua

 

 

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

Re: How to constrain clock crossing paths

(started to write this yesterday, finished this morning)

 

Greg,

 

I disagree with your in part. Sorry.

 

I agree on what you said in the beginning of your post, but I disagree that additional extensions would not solve the root problem for the FPGA designers. They would because they must :o)

 

Your final thought is the primary reason we abolished what may be called a "more correct" way of constraining the design.

 

When we started moving to VIVADO on 2013.4, a month before 2014.1 release, we saw a 1.5 hour A-Z run almost doubled in the runtime with horrible timing and placement oce we use set_max_delay. "All we do" is streaming UHD@120Hz video thru our proprietary real-time DSP engine with tonnes of configuration FFs that 99.9% of them can and should be timing-excepted. A few years from now you are looking at another letter before "HD" and probably higher speeds with wider busses.

 

Yesterday I made a little experiment. I took a project and created a little TCL script, which creates an XDC file with set_max_delay being a loop variable that decreases. The place/route time alone went from 42 min to about 1:34. Timing score was not as bad as several months ago, but it was not 0. I must admit until certain value on the set_max_delay, the inpact on the runtime is minimal, but once this is crossed down, the runtime starts ++.

 

One thing that was not explicitly said (but I assume we know that) is that the use of set_max_delay should also be "correct", i.e.one cannot just put any value on this constraint.

 

We also may be coming to this discussion, while all having enough knowledge/experience on the CDC business, from a different angles.

 

My angle is, productivity, which of course comes after proper education and design methodology. I always put lots of focus on efficiency (just as I do on proper design methodology), and the context of my participation in this discussion is mainly that because, again, I assume we are experienced profesisonals and we "know what we are doing".

 

We are a small start-up where having 2x more FPGA bitfiles with zero timing score generated per day is next to winning a lottery. In any company, if you can get 30 minutes of productivity, multiply it by the number of the designers, there you go.

 

Using set_false_path was back then the only way for us to enable 1024-bit busses data path to run at almost 300 MHz and get a synthesis done in a reasonable time. Bottom line is, I believe Xilinx MUST solve the root problem, which is the tool's inability to separate between CDC paths that we care and those that we don't.

 

Regards

Vlad

Vladislav Muravin
0 Kudos
Scholar muravin
Scholar
16,283 Views
Registered: ‎11-21-2013

Re: How to constrain clock crossing paths

Shihua,

 

Xilinx should not adjust the priority of the set_max_delay.

 

Rather, they should allow something like set_false_path -except  or set_max_delay -except or another command that would allow separating 99% of the path we are about from t1% we don't.

 

Bottom line is, choose what is best for you you, while being well-educated on this subject.

 

BR

Vlad

Vladislav Muravin
0 Kudos
Scholar dwisehart
Scholar
16,280 Views
Registered: ‎06-23-2013

Re: How to constrain clock crossing paths

How many lines it is in your XDC file depends on how you name your signals.  You can do things like:

 

set BUSA [get_pins -hier -filter { NAME =~ "*/bus_a[*]" }] 

set BUSB [get_pins -hier -filter { NAME =~ "*/bus_b[*]" }] 

set_max_delay -datapath_only -from $BUSA -to $BUSB 1.5

 

Even names like sig1a, sig2a, sig3a can be found with the right name filter:

set BUSA1 [get_pins -hier -filter { NAME =~ "*/sig*a" }] 

 

And the path can be the distinguishing name:

set BUSA2 [get_pins -hier -filter { NAME =~ "*/path1/*/s*" }] 

set BUSB2 [get_pins -hier -filter { NAME =~ "*/path2/*/s*" }] 

 

Daniel

 

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

Re: How to constrain clock crossing paths

If the RTL is generate by Synopsys Certify partition tools. The signal name will the same withe signal name between FPGA before do the CPM. These signal will not easy to get from a common name. The reason I need use Synopsys Certify tools CPM, that means after partition the signal between each FPGA exceed the total number of the FPGA pins. Current The CPM ratio is 1:8. The pin number between each FPGA before CPM over 1000.

 

So it is not easy to write contrait by that.

 

Shihua 

 

 

 

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

Re: How to set timing constraint in this case.

Hi All,

 

I draw a picture (My drawing is not good :) ) to describe the CPM logic I used in my design, The cpm clock and sys clock are async to each other. Output signa 1~8 in one FPGA need to transfer to another FPGA by 1 physical FPGA pin. there is a counter to sync the cpm logic in both FPGAs. If the counter value equal the signal name number, the data will be put on that pin to transfer. The counter will in crease from 1 to 8 then 1 to 8.

 

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. To caculate the safe clock, I need constraint the max delay from output signal sys clock domian to cpm clock and from cpm clock domain to input sys clock domain

 

In our design, we have many clock domian signal need across FPGA boundry. Some of them need to be async.

 

BRs

Shihua

WP_20140905_002.jpg
0 Kudos
Scholar markcurry
Scholar
15,075 Views
Registered: ‎09-16-2009

Re: How to set timing constraint in this case.

Shihua,

 

I don't fully understand your design from your description and pictures.  But I'm 90% sure, you need to do just as I've done and declare cpm clock and sys clock as asynchronous.  You do this as I've done with:

 

set_clock_groups -asynchronous -name async_global -group cpm_clk \
-group sys_clk

 (adjust as needed for your actual clock names)

 

And then you live with the consequences of the tool NOT timing the synchronizer.  You're diagram seems to be implying to me that this is OK, as you've designed it correctly to only sample when you (the designer) know the signals will be stable.

 

As you're seeing it's not perfect.  Nor 100%.  But the tools simply don't allow for the best of both worlds.

 

Regards,

 

Mark

 

0 Kudos
Observer zhoushihua
Observer
15,069 Views
Registered: ‎04-24-2008

Re: How to set timing constraint in this case.

Hi Mark,

 

Thanks for your reply.

 

Actully I simple the design, the diagram not inlcude the parallel to serial logic. 

 

But Actually I can not set cpm clock nad sys clock to different clock group. If I do with that, I can not control the path delay from sys clock to cpm clock in the output FPGA, and I also can not control the path delay from cpm clock to sys clock in the input FPGA. That means I do not know how many cpm clock cycle I need reserved for the output stable, and input stable also.

 

Because in sys clock domain, output signal maybe stable, but in cpm clock domain it will not ,because the path delay. The input have the same problem. I need set_max_delay to constraint that. If I set different clock group, the set_max_delay will be ignored by viviado.

 

BRs

Shihua.

0 Kudos
Scholar markcurry
Scholar
15,055 Views
Registered: ‎09-16-2009

Re: How to set timing constraint in this case.

 

Can't offer much else.  The current methodology is broken.

 

I've said before, and I'll say it again.  The decision to treat all clocks as synchronous is completly wrong, and has no utility.  Generating a timing report between async clocks is analyzing a made up number (there's no actual phase relation).  You might as well just spit out a random number for the slack.  It'd be just as valid as anything to tool comes up with.

 

I've stopped complaining, as I found the above command rather easily "fixes" this mistake.  (Before with ISE, your were forced to individually create all the false paths - TIGs -  between each clock. For my example of 14 async clocks, that's 14x13 = 182 TIG commands in my UCF.  And yes, I did just that.)  Now it's just a one-liner.

 

But now this post enlightens the fact that once you run the command, that's it.  You've now lost any other ability to run any other analysis on those paths.

 

This is simply,  broken.

 

I no longer have access to ASIC tools to test, but I can gaurantee this is NOT how things work over there.  There's some mistaken assumptions being made somewhere.

 

Regards,

 

Mark

0 Kudos
Scholar muravin
Scholar
15,046 Views
Registered: ‎11-21-2013

Re: How to set timing constraint in this case.

Mark,

If you have 182 TIGs, I would have written a TCL script with a nested for-loop that aggregates string processing :)

But I am with you on your latest.

What you said is something I decided not to write in my previous post but yes, clocks are nothing but waveforms and as you said, there is no meaning to these waveforms especially if they are generated from different reference clocks.

There is a hole and Xilinx should address it. That is, if they realize this needs to be addressed and worth addressing. There are still a few things wrong with VIVADO that are not related to the timing analysis and they are very important :o)

Regards
Vlad
Vladislav Muravin
0 Kudos
Scholar dwisehart
Scholar
15,044 Views
Registered: ‎06-23-2013

Re: How to set timing constraint in this case.

I hear what you are saying Mark, but I think the current method has merit.  Here is why.

 

Let's say you do something like this:

 

always @( posedge clk1 )

&nbsp; reg1 &lt;= wire1;

 

always @( posedge clk2 )

&nbsp; reg2 &lt;= reg1;

 

Now while you may think those clocks are unrelated, by the circuit I just built, they are now related. &nbsp;If clk1 and clk2 have unrelated frequencies, then the slack time really is 0 and the tools should--in my way of seeing things--warn you that you apparently did something wrong.

 

If in fact clk1 and clk2 circuits never cross--like having two devices on one FPGA with separate inputs and outputs--then there will be no problem because the tools won't warn you about anything.

 

By making all of the clocks synchronous by default, the tools warn you wherever clock domains cross, even if it was an unintentional cross. &nbsp;Where it is an intentional cross, you add the apropriate constraints. &nbsp;I don't have a problem with that approach because it saves me where I make an unintentional cross between clock domains and I keep the number of actual crosses down to a minimum.

 

Regards,

Daniel

 

0 Kudos
Scholar markcurry
Scholar
15,041 Views
Registered: ‎09-16-2009

Re: How to set timing constraint in this case.

Daniel,

 

There's no gaurantee that the tools will warn you about that path.

 

If for instance you declare clk1 as 100 Mhz, and clk2 as 125 Mhz, the tool does it's "harmonics" dance, and decides to time the paths with a 1 ns path (4 ns, vs 5ns periods - worst case edges are 1ns apart). 

 

Great, guess what it passes most of the time  -after all it's no logic, just flop to flop.   So you see no report on the clock cross domain path.

 

But then the numbers are made up.  The 100 MHz, and 125 Mhz, are async.  That 1ns is completely bogus.

 

As I said, a random number has as much utility.

 

Using STA as a poor-man's CDC is a fools game.  Wrong tool for the wrong job.

 

Regards,

 

Mark

 

 

0 Kudos
Historian
Historian
15,035 Views
Registered: ‎01-23-2009

Re: How to set timing constraint in this case.

Using STA as a poor-man's CDC is a fools game.  Wrong tool for the wrong job.

 

Agreed. That is why Vivado has the report_clock_interaction and (coming soon) report_cdc commands. These are based on the structure of the design and the constraints, and not on static timing analysis results.

 

Avrum

0 Kudos
Scholar dwisehart
Scholar
15,034 Views
Registered: ‎06-23-2013

Re: How to set timing constraint in this case.

So Mark, are you arguing that the tools should be more restrictive and report more errors?

 

How you define the clocks determine what the tools report.  If in the constraints file you define these clocks as having periods 10 and 8 the tools will do just what you say.  But if you define the 125 MHz clock with a period of 7.999999, the finished design will work exactly the same way and the tools will report an un-intentional cross-domain signal.

 

It is just a matter of understanding the strength of the tools and using them to your advantage.

 

Daniel

 

0 Kudos
Scholar markcurry
Scholar
15,030 Views
Registered: ‎09-16-2009

Re: How to set timing constraint in this case.

 


dwisehart wrote:

So Mark, are you arguing that the tools should be more restrictive and report more errors?

 

No I'm arguing that the tools shouldn't do "fake" analysis.

 

Sure, you can constrain your clock to 7.99999 instead of 8 to trick the tool.  But who's going to do that?

 

And I wonder what the tools actually do - I do know the tools eventually gives up when it can't find a "harmonic", which it would if your did this.  Is "giving up" equivalent to making the clocks asynchronous?  I dunno.

 

In any event, I rarely find that "tricking" the tools is the proper answer.

 

There's proper tools for the job of CDC checks.  Sounds like Vivado's has more coming down the pipe.  This is good.  Heck someone who is more adept at TCL than I could probably write some scripts around get_timing_paths().

 

My team?  We use a real CDC analysis tool.  There's plenty of choices.

 

No time for that or management doesn't want to pay for another tool? - It's pretty much design reviews only.  Once you get them right, you wish to share the (now verified) constraints as much as possible. 

 

Constraints are the underdog in the design world.  Getting them proper is tricky.  And there's very little available to verify them.  You can't "simulate" them.  There's no formal tools available to verify their validity.  Most users strive to just get the tools to accept them without syntax error, then give a cursory look at the top "n" paths in the timing report.

 

Doing just this and with tools that are doing 'fake' analysis?  Bad news.

 

Regards,

 

Mark

 

0 Kudos
Scholar dwisehart
Scholar
15,017 Views
Registered: ‎06-23-2013

Re: How to set timing constraint in this case.

Who would do that?  My team does.  And it does not make the clocks asynchronous the way set_false_path or set_clock_groups -async does.

 

Anyone who doesn't have $10K to drop on a CDC tool but wants to leverage the freely available tools to do more should consider it.

 

Daniel

 

0 Kudos