cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Newbie
Newbie
12,772 Views
Registered: ‎01-27-2015

Using IF{} in XDC Files

Hello,

 

I'd like to dynamically activate or deactivate the set_property PACKAGE_PIN constraints I have for used or unused ports in a generic design I am working. I know Vivado handles PACKAGE_PIN assignments to non-existant ports, but I'd like to avoid receiving multiple Critical Warnings for these ports that I know don't exist for a particular build of this generic design. I'd also like to avoid changing the XDC file for every single design where I use this generic HDL port list.

 

My original concept was to put this in the XDC file for each and every port that may or may not be used based on the design in question:

 

if { [get_ports -quiet <target port name>] != "" } { set_property PACKAGE_PIN <pad loc> [get_ports <target port name>] }

 

However Vivado 2014.4 throws a critical warning stating if{} statements are unsupported in XDC files. Wait what?! I thought all the constraining was TCL based, so why can I not use if{} statements?

 

Thoughts on another way to do this? No I don't want to create different XDC files defining port to pad relationships for every conceivable set of ports.

 

Thanks!

 

-Dustin B

Tags (3)
0 Kudos
5 Replies
Highlighted
Guide
Guide
12,758 Views
Registered: ‎01-23-2009

The prohibition on "if" (and other control statements) in .xdc files has to do with the concept of "Managed constraints".

 

When a constraint is executed (and they are executed, since XDC is Tcl, which is an interpreted language), the constraint is applied to your design. From the "pure static timing analysis" point of view, once it is applied, the constraint itself is no longer needed - its effect is felt by the design, but the command itself (i.e. the actual string used to express the constraint) is no longer necessary.

 

However, in Vivado, the tools manage the constraints. What this means is that it keeps track of the actual constraint command - where it came from, how it was applied, when it is valid, etc... It uses this for a variety of reasons. One of the most obvious reasons is that you can create/modify constraints using the graphical helpers in the IDE; to do this, you need the original constraints. Furthermore, the tool needs to write these new/modified constraints back to an XDC file so that they are applied the next time the design is opened; this too is part of the managed constraints concept. (There are LOTS of other ways in which the tool uses managed constraints).

 

Unfortunately, this does place restrictions on the syntax that is allowable in the XDC files.

 

To overcome this, Xilinx introduced "unmanaged constraint files". These are files that contain constraints that the tool does not attempt to manage. The will be applied to the design appropriately, but the "text" of the command is not tracked by the tool; you cannot modify these constraints in the GUI (and all the other wonderful things that managed constraints do). In an unmanaged constraint file you can use the full syntax of Tcl (in any way you want).

 

To do this

  - in project mode, simply name your constraint file with the .tcl extension instead of the .xdc extension

  - in non-project batch mode use "source <filename>" to read in the constraint file rather than "read_xdc <filename>".

 

BUT...

 

I was a big fan of the unmanaged constraints until I started doing some of the more complex flows like hierarchical design (or "Out of context" builds). Even though this is in non-project batch mode, the managed constraints play a vital role in how the whole system works. So, now, wherever possible, I do try and stick to managed constraints.

 

That being said, for physical constraints, using unmanaged constraints probably won't cost you that much hardship (its much more important with timing constraints). So, if you are only doing PACKAGE_PIN and IOSTANDARD (etc...) properties, you can probably use unmanaged constraints without any real problems (though, I haven't tried it). If you do, then you can use "if" statements in the .tcl files.

 

Avrum

Tags (1)
Highlighted
Newbie
Newbie
12,725 Views
Registered: ‎01-30-2015

Hello Avrum,

Instead of doing 'srouce file.tcl' for reading unmanged constraints files. There is a switch (although it is hidden), you can use read_xdc -unmanged file.tcl. This will also allow you to specify -ref and -cells options to read_xdc whic is not possible for 'source'.

Regards

Dinesh Monga

Highlighted
Guide
Guide
12,712 Views
Registered: ‎01-23-2009

Dinesh,

 

Thank you very much for this information. That is extremely helpful.

 

Avrum

0 Kudos
Highlighted
Participant
Participant
190 Views
Registered: ‎01-06-2014

Hello,

When using unmanaged constraints I get errors which are not present without the '-unmanaged' exception. For example, a false path linked to a Xilinx IP results in an error during the elaboration phase of the synthesis as the IP is not yet linked. Is this normal? And is there a workaround?

I am working with a no-project flow.

Thanks,

Jorgen

0 Kudos
Highlighted
Participant
Participant
179 Views
Registered: ‎01-06-2014

OK, I think I found it: given that it's a non-project flow, the constraint (false path) has to be called upon after synthesis. Currently it's called on after elaboration.
0 Kudos