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: 
Scholar pedro_uno
Scholar
5,652 Views
Registered: ‎02-12-2013

How to iterate on timing constraints?

Jump to solution

Hello,

 

I'm trying to refine my timing constraints for a large design. In particular I am trying to put set_max_delay constraints on my false paths.  The synthesis time of the design is quite long so I don't want to recompile after each edit of the constraints.

 

I hoped that I could just read_xdc with my timing constraints and then re-run report_timing_summary and see the effect of my changes.  That does not seem to work for me.  The only way I see a change in the timing report is to recompile from the top.  That is impractical for me since the design is large.

 

Is there a way to blow away all my timing constraints and then read in a new constraints file on a compiled design?

 

What is the best way to iterate over timing constraint changes without recompiling?

 

Thanks,

 

    Pete

 

----------------------------------------
DSP in hardware and software
-----------------------------------------
0 Kudos
1 Solution

Accepted Solutions
Scholar pedro_uno
Scholar
8,800 Views
Registered: ‎02-12-2013

Re: How to iterate on timing constraints?

Jump to solution

Avrum,

 

Thanks for answering my question about iterating over xdc constraints without recompiling each time.  reset_timing is a powerful command but is actually too powerful for what I am trying to accomplish. Not only does it blow away all my timing constraints it also blows away all clocks and derived clocks.  I find that many of my constraints actually reference derived clocks that are determined during synthesis so reset_timing did not work for me.

 

Instead, I found an approach that was also recommended in the recent Xilinx video on closing timing. That video recommends that you start from a very clean timing constraints file, maybe with just period constraints.  Then the design is synthesized.  I like to save a .dcp file at this point so I can always get back to the clean constraint state.

 

Then I start applying additional constraints and re-running report_timing_summary.  I actually find that the GUI environment is better for this than pure command line.  In the GUI, report_timing_summary suggests syntactically correct timing constraints. When I see a false path I right click on it -> set max delay -> start to end.  That will construct a constraint and I just edit that TCL to have wildcards as appropriate. After applying a few of these I re-run report_timing_summary.

 

Sometimes, in this iterative process I find places where I did not cross clocks correctly. I fix the source code and start over with a new synthesis.  As I am refining the constraints I save the commands so that I can later re-run them and eventually add them to my production xdc timing constraint file.

 

From what I see, this process is inherently iterative.  This flow is pretty good for iterating with a minimum of recompilation.  The Vivado GUI automation actually helps out.

 

Finally, you tried to draw me into a side discussion of what kind of timing constraint to use on false paths. I avoid set_false_path and "set_clock_groups -asynchronous" as discussed in many other threads.

 

    Pete

----------------------------------------
DSP in hardware and software
-----------------------------------------

View solution in original post

0 Kudos
9 Replies
Scholar austin
Scholar
5,636 Views
Registered: ‎02-27-2008

Re: How to iterate on timing constraints?

Jump to solution

Pete,

 

That is asking "how do I get my answer without doing any work?"

 

Unfortunately, it does not work that way.

 

The design flow is designed, and optimized to MEET your requirements.  It does no work beyond that.  Once met, its DONE.

 

To find just when the tools cannot go any further (optimize the timing) is a terribly hard problem, and there exists no known best way to solve that other than to tighten constraints, start from scratch, get result, tighten constrains, start from scratch, get results and continue past where it fails as it may pass again with an even tighter constraint until it consistently fails.  We do that on our server farms every night for hundreds of designs to verify a new build of Vivado does a better job.  Why anyone else would do this, is not something we have to care about, as our customers know what has to be met, and goes and gets it done.

 

"Best timing" is a pursuit of academics, not actual product designers.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Scholar hbucher
Scholar
5,634 Views
Registered: ‎03-22-2016

Re: How to iterate on timing constraints?

Jump to solution

@austin

 

I will frame and hang this one, this is gold 

> "Best timing" is a pursuit of academics, not actual product designers.

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Scholar pedro_uno
Scholar
5,626 Views
Registered: ‎02-12-2013

Re: How to iterate on timing constraints?

Jump to solution

Just be be clear, I am not looking to magically improve timing on a compiled design.  As stated, I am working on my false paths.  I just want to change my timing constraints and get an updated report from report_timing_summary.

 

Any (on-topic) advice is greatly appreciated.

 

----------------------------------------
DSP in hardware and software
-----------------------------------------
0 Kudos
Scholar austin
Scholar
5,618 Views
Registered: ‎02-27-2008

Re: How to iterate on timing constraints?

Jump to solution

Pete,

 

False is false -- a false path is un-timed (do not care).  If it needs to meet some value, then apply that constraint to it.

 

So I am missing something:  does the path need to meet a constraint?  You may want to look up virtual clock path constraints, and multi-cycle constraints.  One of those might be what you are looking for to capture your requirements.

Austin Lesea
Principal Engineer
Xilinx San Jose
Historian
Historian
5,607 Views
Registered: ‎01-23-2009

Re: How to iterate on timing constraints?

Jump to solution

If I understand it correctly, you are basically trying to do "what if" analysis. Given this design "what if I replaced this set_false_path command with a set_max_delay command".

 

The answer is a little complicated. Constraints are interactive - if you apply a constraint to an open design, the constraint applies immediately, and will affect any subsequent timing report or process run after that point.

 

However, you are running into the problem of constraint priority. The set_false_path command has a higher priority over (all) other constraints. So if you have a set_false_path on a path, and you subsequently try to put a set_max_delay -datapath_only on it, then they will both actually be there, but the set_false_path has higher priority and will "win" (and the set_max_delay -datapath_only will be ignored).

 

However, there is a solution!

 

In non-Xilinx SDC you could use the reset_path command to remove the set_false_path command, but reset_path is not supported in Vivado. (So this isn't the solution...)

 

(But this is!) Instead you can use "reset_timing". This command removes all timing constraints from the design. You can then read in your (modified) XDC constraints using the read_xdc command. The constraints in your XDC will now take effect immediately - you can then do your report_timing commands...

 

So, that solves the logistic issue, but I wonder about what you are trying to do... If a path is false, why are you removing the set_false_path command? If it wasn't false in the first place, why did you have a set_false_path on it? Constraints generally shouldn't be "iterative" - you should be setting exceptions on paths because the structure of the design demands it - not because the path fails timing (or remove the set_false_path because it doesn't...)

 

Avrum

Tags (2)
0 Kudos
Scholar pedro_uno
Scholar
8,801 Views
Registered: ‎02-12-2013

Re: How to iterate on timing constraints?

Jump to solution

Avrum,

 

Thanks for answering my question about iterating over xdc constraints without recompiling each time.  reset_timing is a powerful command but is actually too powerful for what I am trying to accomplish. Not only does it blow away all my timing constraints it also blows away all clocks and derived clocks.  I find that many of my constraints actually reference derived clocks that are determined during synthesis so reset_timing did not work for me.

 

Instead, I found an approach that was also recommended in the recent Xilinx video on closing timing. That video recommends that you start from a very clean timing constraints file, maybe with just period constraints.  Then the design is synthesized.  I like to save a .dcp file at this point so I can always get back to the clean constraint state.

 

Then I start applying additional constraints and re-running report_timing_summary.  I actually find that the GUI environment is better for this than pure command line.  In the GUI, report_timing_summary suggests syntactically correct timing constraints. When I see a false path I right click on it -> set max delay -> start to end.  That will construct a constraint and I just edit that TCL to have wildcards as appropriate. After applying a few of these I re-run report_timing_summary.

 

Sometimes, in this iterative process I find places where I did not cross clocks correctly. I fix the source code and start over with a new synthesis.  As I am refining the constraints I save the commands so that I can later re-run them and eventually add them to my production xdc timing constraint file.

 

From what I see, this process is inherently iterative.  This flow is pretty good for iterating with a minimum of recompilation.  The Vivado GUI automation actually helps out.

 

Finally, you tried to draw me into a side discussion of what kind of timing constraint to use on false paths. I avoid set_false_path and "set_clock_groups -asynchronous" as discussed in many other threads.

 

    Pete

----------------------------------------
DSP in hardware and software
-----------------------------------------

View solution in original post

0 Kudos
Historian
Historian
5,503 Views
Registered: ‎01-23-2009

Re: How to iterate on timing constraints?

Jump to solution

Not only does it blow away all my timing constraints it also blows away all clocks and derived clocks.

 

Yes, that is what it should do. The "create_clock" and "create_generated_clock" commands (and the automatically generated ones) are all "timing constraints", so I don't see why it wouldn't blow them away as it does all other constraints (exceptions and set_input_delay/set_output_delay).

 

That is why I suggested re-reading your (corrected) XDC files after executing the reset_timing. It applies a "clean" set of constraints to your design for moving forward. (And I checked - your automatically generated clocks are restored when you create the primary clocks). This is basically the same as what you are doing by re-reading the .dcp file, which is a snapshot of your synthesized design with the "clean" constraints already applied.

 

The advantage of what I am suggesting is that

  - reading XDC files is faster than reading a .dcp file

  - this mechanism allows you to change everything including anything that was incorrect in the original synthesis run (and hence part of the .dcp file)

 

I also want to point out that (and I am not implying that this is what you are doing) exceptions really shouldn't be applied iteratively based on the fact that you have failing timing paths - they should be applied because they are warranted. Ideally when you design a structure that is going to need an exception, you should write that exception at that time; either directly in the XDC file or at least in a comment in your RTL code for inclusion in an XDC at a later date.

 

Furthermore there are tools that help you determine if you have missed any exceptions - things like report_cdc and report_clock_interaction. These give you a structural view of your design and where exceptions may be missing.

 

Doing it purely based on failing timing paths may ultimately get the ones required to meet timing, it may miss the ones that aren't. For example if you have two unrelated clocks that have a related frequency (i.e. a 10ns and a 5ns clock), then since these clocks are not related, and you need clock crossing circuits (and hence exceptions) between them. However,  the tools may think that paths between them pass - they will end up with a 5ns requirement even though the clocks don't actually share a common source. Remember all clocks in Vivado are related by default. Things like report_clock_interaction and report_cdc are better at finding things like this...

 

Avrum 

0 Kudos
Scholar pedro_uno
Scholar
5,432 Views
Registered: ‎02-12-2013

Re: How to iterate on timing constraints?

Jump to solution

Avrum,

 

You have a lot of good points there. 

 

In practice, I find it difficult to predict the names of source and destination registers.  That makes it tough to create false paths constraints as I design.  I prefer to let the static timing analyzer find the exact names of the endpoints. 

 

You say that create_clock on a primary clock also automatically recreates the derived clocks. That did not work for me but I will try it again next time.

 

I had not considered the case of two asynchronous clocks with periods that line up so that paths between erroneously meet timing.  I don't think I have ever faced that situation but I will watch out for it.

 

I like to apply false path constraints iteratively because it gives me another chance to look at those paths, one at a time.  Sometimes I go back into my source code to simplify the clock crossing. Now, only in that case do I have to resynthesize.

 

Have a good weekend.

 

  Pete

 

----------------------------------------
DSP in hardware and software
-----------------------------------------
0 Kudos
Historian
Historian
5,373 Views
Registered: ‎01-23-2009

Re: How to iterate on timing constraints?

Jump to solution

In practice, I find it difficult to predict the names of source and destination registers. 

 

Unless you are using some of the synthesis options (that I avoid), this shouldn't be a challenge.

 

Assuming you set flatten_hierarchy to none (which is not the default - I hate flattening, so I always set it to none). then the hierarchical path to the flip-flops are clear. The final component of the name is always the name of the underlying signal/reg/logic that is used to infer the flip-flop with the _reg suffix added. If the original is a bus, then the bit selector follows in square brackets. These rules are always followed, so the names should be easy to predict.

 

Of course, if you do something like register retiming or replication (other options I don't like - particularly during synthesis) then the names of the registers can change, But even if you are using these, registers that have been changed due to these options should never need exceptions applied. Exceptions are needed

  - for clock domain crossing

  - for multicycle paths

 

If a flip-flop is involved in clock crossing it should never be replicated or moved via register retiming.

 

If a path is multicycle before register retiming, then it is impossible to apply a multicycle path after retiming; the functionality of the path has been altered in such a way that you now don't know if the new flip-flops are or are not multi-cycle.

 

Avrum

0 Kudos