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!

Reply

OOC synthesis clock constraint

Accepted Solution Solved
Highlighted
Explorer
Posts: 222
Registered: ‎01-22-2015
Accepted Solution

OOC synthesis clock constraint

In Vivado v2017.3 and during OOC synthesis of Xilinx IP, a target-clock-period must be specified (ug896, p41).

 

Based on target-clock-period, I suspect that OOC synthesis makes some “rough decisions” that are later fine-tuned during implementation?

 

If I specify the wrong target-clock-period (ie. not the actual clock period used in my project) for OOC synthesis, can implementation recover from all the wrong “rough decisions” made by OOC synthesis?  That is, can I prevent my project from achieving timing-closure by specifying the wrong target-clock-period for OOC synthesis?


Accepted Solutions
Professor
Posts: 3,925
Registered: ‎01-23-2009

Re: OOC synthesis clock constraint

The role of timing constraints is different in synthesis vs. place and route...

 

In synthesis, the constrains help the synthesis tool choose the correct circuit construction. The kinds of decisions here are generally "area vs. speed" type trade-offs; the constraints determine whether the tool can afford the smaller but slower implementation. These would be things like

  - LUT combining

  - resource sharing

  - doing operations in series rather than in parallel if it saves area

 

These decisions affect the structure of the output netlist.

 

In place and route, the main roles of the constraints are to guide the tools to make sure that things that are "timing critical" are placed near each other and given more direct routes.

 

In general a "bad" decision in synthesis cannot be corrected later on. There are some opportunities in the flow to mitigate them; phys_opt_design (assuming it is enabled - it is optional) can do some re-synthesis of critical paths, but the optimizations that are made here are "low level optimizations"; some of the "high level optimizations" that synthesis does first cannot be "fixed" at this stage.

 

That being said, the reality is that, even with Vivado, the effect of timing constraints on synthesis is fairly minor in many cases; there is rarely a large difference in the structure of the design based on the constraints. This is actually stated (and counted on) in some of the IP strategies that don't use "real" constraints for their OOC synthesis runs.

 

So, in theory, yes, under-constraining during synthesis can prevent your design from meeting timing even when the proper constraints are used in P&R. However, they probably only do so rarely. 

 

Ultimately, if your design meets timing after implementation, then you are fine. If not, then you should try applying more accurate constraints during the synthesis process. While it probably won't make a difference, you can't be sure until you try it...

 

Avrum

View solution in original post


All Replies
Professor
Posts: 3,925
Registered: ‎01-23-2009

Re: OOC synthesis clock constraint

The role of timing constraints is different in synthesis vs. place and route...

 

In synthesis, the constrains help the synthesis tool choose the correct circuit construction. The kinds of decisions here are generally "area vs. speed" type trade-offs; the constraints determine whether the tool can afford the smaller but slower implementation. These would be things like

  - LUT combining

  - resource sharing

  - doing operations in series rather than in parallel if it saves area

 

These decisions affect the structure of the output netlist.

 

In place and route, the main roles of the constraints are to guide the tools to make sure that things that are "timing critical" are placed near each other and given more direct routes.

 

In general a "bad" decision in synthesis cannot be corrected later on. There are some opportunities in the flow to mitigate them; phys_opt_design (assuming it is enabled - it is optional) can do some re-synthesis of critical paths, but the optimizations that are made here are "low level optimizations"; some of the "high level optimizations" that synthesis does first cannot be "fixed" at this stage.

 

That being said, the reality is that, even with Vivado, the effect of timing constraints on synthesis is fairly minor in many cases; there is rarely a large difference in the structure of the design based on the constraints. This is actually stated (and counted on) in some of the IP strategies that don't use "real" constraints for their OOC synthesis runs.

 

So, in theory, yes, under-constraining during synthesis can prevent your design from meeting timing even when the proper constraints are used in P&R. However, they probably only do so rarely. 

 

Ultimately, if your design meets timing after implementation, then you are fine. If not, then you should try applying more accurate constraints during the synthesis process. While it probably won't make a difference, you can't be sure until you try it...

 

Avrum

Explorer
Posts: 222
Registered: ‎01-22-2015

Re: OOC synthesis clock constraint

Thanks Avrum!!

 

-just to be clear….

Some Xilinx IP have an automatically-generated OOC XDC file with a clock constraint (eg. create_clock -name "TS_CLKA" -period 20.0 [ get_ports clka ]). I find that this constraint specifies the target-clock-period for OOC synthesis.

 

If I do NOT use OOC synthesis, then synthesis of the IP will use the period of the clock that my HDL has connected to the IP – and will not use the clock-period specified in the OOC XDC file?

 

Mark

Professor
Posts: 3,925
Registered: ‎01-23-2009

Re: OOC synthesis clock constraint

If I do NOT use OOC synthesis, then synthesis of the IP will use the period of the clock that my HDL has connected to the IP – and will not use the clock-period specified in the OOC XDC file?

 

Yes, that is correct.

 

Avrum