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: 
Explorer
Explorer
10,843 Views
Registered: ‎10-25-2012

The right (recommanded) approach to do the timing constrain and analysis

Jump to solution

I have basic understanding about timing constrain, includes both theory and tcl Xdc. Now I want to conclude a recommanded approch to do the timing constrain for the design.

 

I don't think anyone can write a complete timing constrain file at the beginning. I believe this should be a progressive process. What I did is:

 

1. After complete HDL design, I will write a basic timing constrain xdc, usually only includes set_clocks and set_generated_clocks

2. Run the synthesis, open the synthesised design, check unconstrained path (must have inputs/outputs). Add the input and output delay constrains into the xdc.

3. Run the implementation, check the timing, add the exceptions (false path, multi cycle), check the timing again, if the timing failed, determine it is constrain issue (e.g. : ignored false path), or it is because RTL design (modfied the design).

 

I wonder is this recommanded approach to do the timing constrain for the design? Any steps which are in wrong sequence or any important steps I forget?

 

Thanks in advance for any advices.

0 Kudos
1 Solution

Accepted Solutions
Guide avrumw
Guide
17,964 Views
Registered: ‎01-23-2009

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution

Ideally, Muzaffer's suggestion of having all constraints before synthesis is the best way to go.

 

However, what buddha says is also true - its hard to get constraints perfect the first time around.

 

So Xilinx has come up with a set of design methodologies that they call "UltraFAST". As part of that, they describe an approach for constraints that is not much different than what buddha suggests. This is summarized in the Xilinx UltraFAST Design Methodology Guide (UG949). In Chapter 5, in the section called "Timing Closure" they describe their approach for constraints.

 

Basically, they suggest doing your constraints after (at least) an initial synthesis. After synthesis you have access to the Timing Constraint window that can help you create constraints.

 

Then you apply your clocks - primary and generated. Then you do some analysis commands like "report_clock_networks" and "report_clock_interaction". This helps you check that your clocks are all there, and helps remind you which clocks are supposed to be related. Then you should apply the correct timing exceptions - mostly for clock crossing, but also for functional requirements. All during this effort, you have access to all the reporting and analysis commands of Vivado. As opposed to ISE, the representation of the design after synthesis is identical to that produced after place and route - so, with the exception that net delays are estimated, the timing characteristics of your design after synthesis will be the same as the final results. Of course, the actual numbers for the delays will be different, but the paths themselves will be the same paths, and the requirements will also be the same.

 

The idea here is that if you have a path with a clearly incorrect requirement (say a path between clocks that should be unrelated, but have not been declared as such), then attempting to run place_design and route_design will take a huge amount of time as the tools try to optimize paths that are impossible to meet. By fixing all of them after synthesis, and before place and route, you can save yourself a ton of time.

 

Also, since the constraint and timing commands are all interactive, you can iteratively fix and check your constraints after you have run synthesis only once! You don't have to keep re-running synthesis (or any other process) to have your new constraints take effect so that you can analyze them.

 

Once you have all the internal paths looking correct, which may include fixing your RTL if necessary, then add I/O constraints, and validate them, too, before running place and route.

 

Eventually, you will determine that your constraints are correct. At this point you can re-run synthesis with your constraints (this probably isn't in the methodology guide, but is a good idea - although there may be some syntax issues, since constraints written for the post-synthesis netlist may not be completely correct for the pre-synthesis netlist), then run place and route, and do final timing analysis. If anything fails here, they should be real (and hopefully minor) timing violations that can be fixed with things like phys_opt_design or minor RTL edits.

 

Avrum

 

 

View solution in original post

6 Replies
Teacher muzaffer
Teacher
10,840 Views
Registered: ‎03-31-2012

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution

In my opinion all timing constraints should be read before synthesis. This includes clocks, generated clocks, false paths, multi-cycle and IO delays. Not having these during synthesis would make the synthesizer do unnecessary, potentially counter-productive work (especially false paths and multi-cycles). This will be more important as (I hope) Xilinx makes the synthesizer more intelligent and with more understanding of the physical structures/routing. When that happens having the synthesizer know all timing constraints will be crucial.

I have two constraint files: timing and physical. Synthesis doesn't need the latter but I read it at the start anyway. It can't hurt.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
Explorer
Explorer
10,818 Views
Registered: ‎10-25-2012

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution
HI muzaffer,

I agree with what you mentioned "all timing constraints should be read before synthesis". But for a designer without too much experience, I can't write the completed constrain at the beginning, so for me I usually need to do is run the synthesis, check the unconstrained paths, then add more into my constrain to make it more completed.

I do the same thing as you, I seperated timing and physical constrains into two files.
0 Kudos
Guide avrumw
Guide
17,965 Views
Registered: ‎01-23-2009

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution

Ideally, Muzaffer's suggestion of having all constraints before synthesis is the best way to go.

 

However, what buddha says is also true - its hard to get constraints perfect the first time around.

 

So Xilinx has come up with a set of design methodologies that they call "UltraFAST". As part of that, they describe an approach for constraints that is not much different than what buddha suggests. This is summarized in the Xilinx UltraFAST Design Methodology Guide (UG949). In Chapter 5, in the section called "Timing Closure" they describe their approach for constraints.

 

Basically, they suggest doing your constraints after (at least) an initial synthesis. After synthesis you have access to the Timing Constraint window that can help you create constraints.

 

Then you apply your clocks - primary and generated. Then you do some analysis commands like "report_clock_networks" and "report_clock_interaction". This helps you check that your clocks are all there, and helps remind you which clocks are supposed to be related. Then you should apply the correct timing exceptions - mostly for clock crossing, but also for functional requirements. All during this effort, you have access to all the reporting and analysis commands of Vivado. As opposed to ISE, the representation of the design after synthesis is identical to that produced after place and route - so, with the exception that net delays are estimated, the timing characteristics of your design after synthesis will be the same as the final results. Of course, the actual numbers for the delays will be different, but the paths themselves will be the same paths, and the requirements will also be the same.

 

The idea here is that if you have a path with a clearly incorrect requirement (say a path between clocks that should be unrelated, but have not been declared as such), then attempting to run place_design and route_design will take a huge amount of time as the tools try to optimize paths that are impossible to meet. By fixing all of them after synthesis, and before place and route, you can save yourself a ton of time.

 

Also, since the constraint and timing commands are all interactive, you can iteratively fix and check your constraints after you have run synthesis only once! You don't have to keep re-running synthesis (or any other process) to have your new constraints take effect so that you can analyze them.

 

Once you have all the internal paths looking correct, which may include fixing your RTL if necessary, then add I/O constraints, and validate them, too, before running place and route.

 

Eventually, you will determine that your constraints are correct. At this point you can re-run synthesis with your constraints (this probably isn't in the methodology guide, but is a good idea - although there may be some syntax issues, since constraints written for the post-synthesis netlist may not be completely correct for the pre-synthesis netlist), then run place and route, and do final timing analysis. If anything fails here, they should be real (and hopefully minor) timing violations that can be fixed with things like phys_opt_design or minor RTL edits.

 

Avrum

 

 

View solution in original post

Teacher muzaffer
Teacher
10,795 Views
Registered: ‎03-31-2012

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution
My comments were mainly for final stages of development when both constraints and rtl are relatively stable. Of course during development of either things are in flux but still this is no reason to read in the constraints after synthesis. One hopefully knows at least the top level clocks in the design and the IO constraints and probably the multi-cycles from designers. In my opinion what ever is know should be entered in the timing constraints and it should be read first and updated as necessary during development. The fact that they are not perfect is no reason to wait to read them in.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Guide avrumw
Guide
10,794 Views
Registered: ‎01-23-2009

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution

The fact that they are not perfect is no reason to wait to read them in.

 

Xilinx's recommendation to wait is the possibility that "impossible" constraints will cause the tool to run significantly longer. I don't know if this applies to synthesis or not, but since synthesis is timing driven, then it is possible. I think this is why Xilinx's recommendation is to start applying and verifying your constraints after the initial synthesis.

 

Avrum

0 Kudos
Explorer
Explorer
10,789 Views
Registered: ‎10-25-2012

Re: The right (recommanded) approach to do the timing constrain and analysis

Jump to solution
I appreciate both of you discuss here.

Based on my experience, I will prefer the approach recommanded by Xilinx UG949 at beginning. I think this approach can help me do the completed and correct timing constrain.

Thanks very much.

0 Kudos