cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Voyager
Voyager
847 Views
Registered: ‎07-28-2008

ls Vivado Synthesis timing driven?

Jump to solution

I always thought clock definition by (create_clock) is a key driving factor to Synthesis.

 

Changing clock definition and re-run synthesis is a very quick process.

 

Are the netlists synthesized with/without clock definition the same, and the re-run is just a timing analysis process, or actually timing definition drives synthesis results.

 

Thanks,

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
822 Views
Registered: ‎01-23-2009

I always thought clock definition by (create_clock) is a key driving factor to Synthesis.

 

Synthesis is (at least) weakly timing driven. However, the choices it makes tend to be pretty high level; synthesis will avoid logic sharing and LUT combining on a path that is likely to be a timing problem, but will do it if the timing has lots of slack - it needs the create_clock to tell it the difference between the two.

 

Changing clock definition and re-run synthesis is a very quick process.

 

Is it possible you are being misled by the compilation of IP. When you run synthesis on a design for the first time, and all IP is left at the default value for synthesis method (which is out of context), then all the IP is first synthesized. This can take a long time if there are multiple IP.

 

However, once the IP is built (in project mode), they are managed by the build management system; if you don't change the IP source, they don't need to be rebuilt. So if you change your XDC file and re-run synthesis, it is only re-synthesizing the top level of the design (not the IP) - that can be much faster.

 

Are the netlists synthesized with/without clock definition the same, and the re-run is just a timing analysis process, or actually timing definition drives synthesis results.

 

Re-running synthesis with different constraints can definitely result in different netlists - it is not simply rerunning the timing analysis. In fact with an open synthesized design you can interactively change constraints and re-run a timing analysis without resynthesizing the design... (but be careful, the tool will ask if you want to save the modified constraints, and if you do so, the synthesis will be declared out of date and re-run the next time you try and run implementation or bitstream generation or try to open the design).

 

Avrum

View solution in original post

Tags (1)
3 Replies
Highlighted
Adventurer
Adventurer
830 Views
Registered: ‎04-24-2012

@legendbb

"I always thought clock definition by (create_clock) is a key driving factor to Synthesis"

Yes, it helps the tool to close on the frequency you request the design to work with, and those constraints helps the tools to understand how close (near) the logic should be in order to give what you request and a little bit if possible.

If you do not define the source clock, generated clocks and input-output delays, the tool will try the best and give you the most optimized result, that may be not what you wanted (play with Pblocks and you will understand).

 

"Changing clock definition and re-run synthesis is a very quick process."

How big is the design?, what frequency you use?. Imagine you have a design in which your logic takes 60% of the device at 20MHz, if you try to increase that to 40MHz, the tool will take too much more time and you may end with an implementation with very bad QoR.

 

"Are the netlists synthesized with/without clock definition the same, and the re-run is just a timing analysis process, or actually timing definition drives synthesis results".

Because you design may not have timing issues. If you target frequency is 50MHz and you "forget" to add the constraints, but the tool is giving you 70MHz, then if you add the constraints you ensure everything is QoR compliant but there is no  change at all in the implementation, right?

 

Said that, yes, Vivado is both Synthesis and Place-and-Route timing driven tool. May not be the best, btw :).

/* Don't forget to give kudos and/or accept as a solution */
Highlighted
Guide
Guide
823 Views
Registered: ‎01-23-2009

I always thought clock definition by (create_clock) is a key driving factor to Synthesis.

 

Synthesis is (at least) weakly timing driven. However, the choices it makes tend to be pretty high level; synthesis will avoid logic sharing and LUT combining on a path that is likely to be a timing problem, but will do it if the timing has lots of slack - it needs the create_clock to tell it the difference between the two.

 

Changing clock definition and re-run synthesis is a very quick process.

 

Is it possible you are being misled by the compilation of IP. When you run synthesis on a design for the first time, and all IP is left at the default value for synthesis method (which is out of context), then all the IP is first synthesized. This can take a long time if there are multiple IP.

 

However, once the IP is built (in project mode), they are managed by the build management system; if you don't change the IP source, they don't need to be rebuilt. So if you change your XDC file and re-run synthesis, it is only re-synthesizing the top level of the design (not the IP) - that can be much faster.

 

Are the netlists synthesized with/without clock definition the same, and the re-run is just a timing analysis process, or actually timing definition drives synthesis results.

 

Re-running synthesis with different constraints can definitely result in different netlists - it is not simply rerunning the timing analysis. In fact with an open synthesized design you can interactively change constraints and re-run a timing analysis without resynthesizing the design... (but be careful, the tool will ask if you want to save the modified constraints, and if you do so, the synthesis will be declared out of date and re-run the next time you try and run implementation or bitstream generation or try to open the design).

 

Avrum

View solution in original post

Tags (1)
Highlighted
803 Views
Registered: ‎01-22-2015

@legendbb

 

Similar to your concern is the fact that some Xilinx IP use a target clock period for OOC synthesis. Sometimes you can specify this target clock period and sometimes you can’t and are stuck with a default (ie. incorrect) clock period assigned by the IP wizard.  An example of this problem is the block-RAM IP as described in <this> post.

 

As explained by Avrum in <this> post, getting the correct target clock period for IP synthesis can be done by simply turning off OOC synthesis for the IP.

 

Mark