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
1,477 Views
Registered: ‎04-12-2012

Constraints necessary for synthesis

Jump to solution

Hello,

Vivado allows us to choose whether an XDC constraint file will be active during Synthesis, Implementation or both.

What type of constaints MUST be active for both ? 

 

1 Solution

Accepted Solutions
Historian
Historian
934 Views
Registered: ‎01-23-2009

Re: Constraints necessary for synthesis

Jump to solution

There are a couple of discussion points in this thread...

First, lets take the original question - should you have more than one constraint file. In general, I have two:

  • One for all timing constraints
    • This is used both for synthesis and implementation
    • This should include all timing constraints
  • One for all physical constraints
    • This is used for implementation only

The physical constraint file contains everything having to do with placement. This would include:

  • PACKAGE_PIN constraints for all ports
  • IOSTANDARD, SLEW, DRIVE, etc... for all ports
  • PBLOCK definitions (if any exist)
  • LOC constraints for any cells (if any exist)

While it is true that you can have all of these physical constraints along with the timing constraints in one file (the synthesis process will just ignore the physical constraints), there is an advantage to having them separate. If you have an synthesized (or implemented) design, and you need to change the physical constraints, then if they are in their own file (and the file is marked as being for implementation only), then the synthesis run will not be marked out of date - in other words, the tools will not need to re-run synthesis. If you have all the constraints in the same file (and hence the file is marked as being for synthesis and for implementation) then chagning anything in the file will result in the synthesis run as being marked out of date, and hence will need to be re-run. In a big design, this can waste a reasonable amount of time.

The second topic has to do with constraints that need to be applied differently during synthesis and implementation. When the design is first elaborated (during synthesis), a "generic technology" implementation of the design is created. This generic technology implementation (which can be viewed by doung an "Open Elaborated Design") is a fairly literal impementation of your RTL using generic netlist elements (registers, adders, incrementers, AND, OR, INV gates, etc...). Constraints are then applied to this generic netlist during the rest of synthesis, reading from constraint files that have the USED_IN_SYNTHESIS property set.

During synthesis, the design is converted to a netlist of Xilinx Basic ELements (BELs), and optimization is done. The result of this process is a different netlist. Depending on flow (project vs. non-project) the constraints are applied again on this BEL netlist either at the end of synthesis or the beginning of implementation, but only those constraints that are in files that have the USED_IN_IMPLEMENTATION property set.

These two netlists are different. Therefore it is possible to write constraints that will work during one pass, but not during the other. When this occurs:

  • You will get critical warnings for any constraint that can't be applied
  • More importantly, your design will not be properly constrained

So (in general) these are warnings that cannot be ignored - you have to fix them. The two ways of fixing them are having separate timing constraints for synthesis and implementation, with the synthesis ones being correct for the generic technology netlist and the implementation ones being correct for the BEL netlist. But, wherever possible, this should be avoided. The goal is to write constraints that will be able to be applied to both netlists.

To do this, you need to understand what is "preserved" through the synthesis process - what is guaranteed to be the same in the generic technology and BEL netlist:

  • Ports (top level ports of the design) are always preserved
  • Pins of hierarchical modules are always preserved if and only if flatten_hierarchy is set to "none"
  • Register cells are preserved if:
    • The registers are not optimized out because they are redundant
    • Register retiming (-retiming) is not enabled during synthesis
    • The registers are not merged into an SRL
    • Note: the names of the registers may be different if flatten_hierarchy is not set to "none"
  • Cells and pins of instantiated resources (clock buffers, MMCM/PLLs, instantiated RAMs unless they are optimized out, DSP cells, etc...) are preserved

That's pretty much it.

So, if you can write your constraints such that they use only design objects that are known to be preserved, and/or you can use appropriate wildcards in your constraints to adapt to the differences between the two netlists, then you should be able to have a single set of timing constraints that can be applied to both netlists - this should always be your goal (and is usually possible)...

Avrum

Tags (1)
13 Replies
Scholar drjohnsmith
Scholar
1,449 Views
Registered: ‎07-09-2009

Re: Constraints necessary for synthesis

Jump to solution
interesting question
I seem to only have one constraint file , used for both, and the tools ignore what they can't use,

are you using separate files ?
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Explorer
Explorer
1,425 Views
Registered: ‎04-12-2012

Re: Constraints necessary for synthesis

Jump to solution

Yes.

I have more than one constraint file.

I know Vivado does timing analysis as part of the synthesis stage (not just for implementation) so maybe declaring clocks is important for both stages.

But what else ?

0 Kudos
Scholar drjohnsmith
Scholar
1,398 Views
Registered: ‎07-09-2009

Re: Constraints necessary for synthesis

Jump to solution

for my interest , Any reason why you have separate files ?

Whats the advantage of separate files over one file and use that for all ?

As a thought, you could make one file and run,

   you see in the reports which constraints each process  ignores,

 

from that you can make up your seperate files.

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
1,389 Views
Registered: ‎01-22-2015

Re: Constraints necessary for synthesis

Jump to solution

You’ll find pretty good reading on constraints necessary for synthesis on about pg58 of UG903 and on about pg140 of UG949.  In UG903, you may also want to read about scoped constraints which are constraints that apply to only part of your design.

I follow the guidance of drjohnsmith to have only one constraints file that is marked for use by both synthesis and implementation - letting each use or not use the constraints it recognizes/needs.  This is the default setting for Vivado (pg10, UG903).  I also follow the Xilinx guidance (pg8, UG903) to use as few constraints as possible.

I have not found any strong advantage to having separate constraints files for synthesis and implementation.  However, I read on pg141 of UG949 that separate files may sometimes be needed to prevent conflicting constraints - although I have never needed to worry about this.

Finally, keep in mind that constraints are used in the order that they are read (pg12, UG903).  So, if you have duplicate constraints then only the last-read one will be observed.  This can sometimes be used to advantage by placing a constraint in the project constraints file that overwrites one (eg. naming a clock) found in the locked constraints file for Xilinx IP - because, by default, the project constraints file is read after the IP constraints files.

Mark

 

 

Explorer
Explorer
1,381 Views
Registered: ‎04-12-2012

Re: Constraints necessary for synthesis

Jump to solution

I have not found any strong advantage to having separate constraints files for synthesis and implementation.  However, I read on pg141 of UG949 that separate files may sometimes be needed to prevent conflicting constraints - although I have never needed to worry about this

Think of the following scenario:

You want to apply a false path from point a to b.

Vivado can change or even create new paths during implementation. If you have only one file - you'll get an ugly critical warning for trying to apply a constaint to a path that doesn't actually exist (during the synthesis stage).

 

 

0 Kudos
1,373 Views
Registered: ‎01-22-2015

Re: Constraints necessary for synthesis

Jump to solution

Vivado can change or even create new paths during implementation.
Constraints are written using netlist names.  With the possible exception of clocks (whose names seem unknown until implementation - weird), netlist names are created during synthesis – and cannot be changed by implementation (I think).  Although, implementation can add netlist names (eg. during  -force_replication_on_nets).

…you'll get an ugly critical warning for trying to apply a constaint to a path that doesn't actually exist (during the synthesis stage).
I think you are describing a situation where we write a constraint using a netlist name (eg. register, dat1_reg) - and the part/name gets optimized out during synthesis – and then we later get the “ugly critical warning” – because the netlist name no longer exists.  Ways to solve this are 1) place a DONT_TOUCH constraint on the netlist name, or 2) turn off some synthesis optimization.  However, you cannot solve this by using different constraints files for synthesis and optimization.

0 Kudos
Explorer
Explorer
1,356 Views
Registered: ‎04-12-2012

Re: Constraints necessary for synthesis

Jump to solution

netlist names are created during synthesis – and cannot be changed by implementation (I think).

I encountared a (perhaps very specific) scenario where a name is CREATED during implementation.

This happened when I used a single instantiation of a IDELAYCTRL in the top level and had Vivado automatically replicate this component the required number of times.

When I false pathed each of the RDY flag from all the replicated components and re-synthesized - I got a critical warning saying that the path can't be located.

The same constraints did apply correctly during the implementation stage.

Note: I'm not using OOC synthesis.

0 Kudos
1,334 Views
Registered: ‎01-22-2015

Re: Constraints necessary for synthesis

Jump to solution

   ....where a name is CREATED during implementation.
Yes, I have seen new netlist names "created" during implementation.  -but, I have not seen implemenation "change" a synthesis netlist name.  I have also seen synthesis netlist names "destroyed" when synthesis optimizes out the part associated with the netlist name.

As you say, we can use implementation to replicate parts (eg. using -force_replication_on_nets).  When I did this for a register, p_adrp_reg[3] (a synthesis netlist name), in my project, I got the following:
replicate_reg.jpg

Note how the synthesis netlist name, p_adrp_reg[3], is unchanged by implementation.  However, implementation created new netlist names for each of the replicated registers.

Explorer
Explorer
1,322 Views
Registered: ‎04-12-2012

Re: Constraints necessary for synthesis

Jump to solution

However, implementation created new netlist names for each of the replicated registers.

I needed to apply constraints to these (implementation) created names withought systhesis - showing warnings about them.

My solution is to use seperate files and have the constraints in question only in the one targeted for implementation.

Do you have another suggestion ?

 

 

0 Kudos
1,207 Views
Registered: ‎01-22-2015

Re: Constraints necessary for synthesis

Jump to solution

My solution is to use seperate files and have the constraints in question only in the one targeted for implementation.

I cannot find a better solution. 

Although, being kinda tolerant of the “ugly critical warnings” and a lazy typist, I would probably try to do this using one constraint w/wildcards that is placed in my one XDC file.  -something like the following (rather silly) example:

set_false_path -from [get_cells {adrb_reg[3]}] to [get_cells {p_adrb_reg[3]*}]

 

 

 

Highlighted
Scholar drjohnsmith
Scholar
1,104 Views
Registered: ‎07-09-2009

Re: Constraints necessary for synthesis

Jump to solution
@shaikon , Its no help , but
I think your running into one of the Xilinx things.

They seem to have attitude that warnings are just that , if you look at the Xilinx IP, typically the number of warnings they chuck out is over whelming , but the answer we always get is they are just warnings.

Certainly most of the companies I work for, one has to document and justify each warning before release to production, A real pain in the key board,,,,,,,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
1,079 Views
Registered: ‎01-22-2015

Re: Constraints necessary for synthesis

Jump to solution

Yes, the “more warnings is better” philosophy of Xilinx gave me fits when it started.  I recall clearly the day it hit me.  In a 2014 version of Vivado, my project had about 30 warnings, which I had memorized (ie. no life back then). Then, I upgraded to a 2015 version of Vivado and started getting over 600 warnings - the vast majority being warnings about Xilinx IP which I had absolutely no control over.  Drjohnsmith comforted me back then and I’ve calmed (numbed) a lot since.

There are ways to manage the warnings (eg. hiding those that you have no control over) so you can focus on the maybe-important ones.  However, the warning overload has bad effects.  In my olden day quest to write error/warning free code, I would find lots of ways to improve both my coding style and my documentation/comments.  Now-a-days, I have fallen to “they’re just warnings - don’t worry about them” - forgive me.

Historian
Historian
935 Views
Registered: ‎01-23-2009

Re: Constraints necessary for synthesis

Jump to solution

There are a couple of discussion points in this thread...

First, lets take the original question - should you have more than one constraint file. In general, I have two:

  • One for all timing constraints
    • This is used both for synthesis and implementation
    • This should include all timing constraints
  • One for all physical constraints
    • This is used for implementation only

The physical constraint file contains everything having to do with placement. This would include:

  • PACKAGE_PIN constraints for all ports
  • IOSTANDARD, SLEW, DRIVE, etc... for all ports
  • PBLOCK definitions (if any exist)
  • LOC constraints for any cells (if any exist)

While it is true that you can have all of these physical constraints along with the timing constraints in one file (the synthesis process will just ignore the physical constraints), there is an advantage to having them separate. If you have an synthesized (or implemented) design, and you need to change the physical constraints, then if they are in their own file (and the file is marked as being for implementation only), then the synthesis run will not be marked out of date - in other words, the tools will not need to re-run synthesis. If you have all the constraints in the same file (and hence the file is marked as being for synthesis and for implementation) then chagning anything in the file will result in the synthesis run as being marked out of date, and hence will need to be re-run. In a big design, this can waste a reasonable amount of time.

The second topic has to do with constraints that need to be applied differently during synthesis and implementation. When the design is first elaborated (during synthesis), a "generic technology" implementation of the design is created. This generic technology implementation (which can be viewed by doung an "Open Elaborated Design") is a fairly literal impementation of your RTL using generic netlist elements (registers, adders, incrementers, AND, OR, INV gates, etc...). Constraints are then applied to this generic netlist during the rest of synthesis, reading from constraint files that have the USED_IN_SYNTHESIS property set.

During synthesis, the design is converted to a netlist of Xilinx Basic ELements (BELs), and optimization is done. The result of this process is a different netlist. Depending on flow (project vs. non-project) the constraints are applied again on this BEL netlist either at the end of synthesis or the beginning of implementation, but only those constraints that are in files that have the USED_IN_IMPLEMENTATION property set.

These two netlists are different. Therefore it is possible to write constraints that will work during one pass, but not during the other. When this occurs:

  • You will get critical warnings for any constraint that can't be applied
  • More importantly, your design will not be properly constrained

So (in general) these are warnings that cannot be ignored - you have to fix them. The two ways of fixing them are having separate timing constraints for synthesis and implementation, with the synthesis ones being correct for the generic technology netlist and the implementation ones being correct for the BEL netlist. But, wherever possible, this should be avoided. The goal is to write constraints that will be able to be applied to both netlists.

To do this, you need to understand what is "preserved" through the synthesis process - what is guaranteed to be the same in the generic technology and BEL netlist:

  • Ports (top level ports of the design) are always preserved
  • Pins of hierarchical modules are always preserved if and only if flatten_hierarchy is set to "none"
  • Register cells are preserved if:
    • The registers are not optimized out because they are redundant
    • Register retiming (-retiming) is not enabled during synthesis
    • The registers are not merged into an SRL
    • Note: the names of the registers may be different if flatten_hierarchy is not set to "none"
  • Cells and pins of instantiated resources (clock buffers, MMCM/PLLs, instantiated RAMs unless they are optimized out, DSP cells, etc...) are preserved

That's pretty much it.

So, if you can write your constraints such that they use only design objects that are known to be preserved, and/or you can use appropriate wildcards in your constraints to adapt to the differences between the two netlists, then you should be able to have a single set of timing constraints that can be applied to both netlists - this should always be your goal (and is usually possible)...

Avrum

Tags (1)