Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎07-17-2014

Changing clock/timing constraints based on IP module configuration

Not sure I have the right section for this discussion -- hopefully so.

I'm upgrading a project from using the parallel version of an On-Semi Imager IC (VITA Series) to start using LVDS.

The Imagers both come with the same pins used for CMOS parallel or LVDS signalling making it easy to switch back and forth in the project with just proper signal editing.

I've learned to use the verilog "generate" syntax (instead of `define) which is awesome as it lets me build my IP module and select which interface I want to use.

The tricky part now is each sensor comes with a different set of constraints I need to deal with in the XDC file. Clock speeds are different, one imager has a single clock while the LVDS version has a clock that I'm pushing through a PLL/MMCM to generate the byte clock (divided down by 4 from the bit clock).

What's the best way to accomplish this in code or topology where I can best leverage all the automation the IP packaging can provide?

Can I use (* some parm = value *) syntax or should I be creating an XDC file that's included with my module based on IP Module parameters?



0 Kudos
4 Replies
Registered: ‎01-22-2015

Hi Ben,

     Can I use (* some parm = value *) syntax or should I be creating an XDC file that's included with my
     module based on IP Module parameters?

We do something very similar to what you are doing – and we handle it by creating two XDC files and “telling” Vivado to use only one of them.

“Telling” Vivado (via the IDE) to use only one of the XDC files consists of:

  • right-clicking the XDC-file that you want to use and selecting “Set as Target Constraint File”.  The Target Constraint File is the file to which the Vivado IDE writes constraints (ref UG893, pg63)
  • right-clicking the XDC-file that you DON’T want to use and selecting “Disable File”.  It is important to disable the unused XDC file – otherwise Vivado tries to use both XDC files.


0 Kudos
Registered: ‎07-17-2014

I suppose that's one solution. (kind of a last resort)

I'd really prefer to automate it better than that so the end user doesn't have to fuss with it as much.

I think I'll review the TCL and Constraints guides again to see how I can work it into the Verilog so Generate/Endgenerate can do the work for me.



0 Kudos
Registered: ‎01-23-2009

What you are trying to do is "difficult" (certainly not clean) through the Vivado project environment.

While XDC files use Tcl syntax, they are not allowed to use the complete syntax structure of Tcl. One of the major limitations is that they are not allowed to use Tcl flow control (while, for, if). So while you could theoretically query structures from your design database, since you can't use an "if" statement, you cannot put conditions in the XDC file.

It may be possible to get around this using "unmanaged constraints" - using Tcl files instead of XDC files - but doing so means that you can't use the constraint management system - things like the constraint wizard and the constraint viewer won't be available, and anything involving IP packaging probably won't work (and a whole bunch of other side effects).

The "better" option is to do what was suggesting, and have two XDC files - one for boardA and one for boardB. With two files, you can enable on or the other (through the IS_ENABLED property). However, you cannot automate that through the project management process.

That being said, you can automate the build process using scripts - you can have Vivado execute a script that takes a command line argument (which board you want) and generate a build for that board. It is actually somewhat easier to do this in non-project mode, but it can be done in project mode as well.

The script would be launched with something like

vivado -mode Tcl -source "my_script.tcl" -tclargs boardA

(or boardB)

The essence of the script my_script.tcl is:

  • Query the $argv parameter, it will contain the stuff after the -tclargs option of the command line
    • So in this case $argv will be "boardA"
  • (maybe) create a new directory for the build
  • create a new project for the build - this is done with the create_project command
  • Add all your RTL source to the project with "add_files"
  • Add the correct constraint files to the prokect
    • In my_script.tcl you can use the entire Tcl syntax so you can do
    • if {$argv == "boardA"} {add_files "boardA.xdc"} {add_files "boardB.xdc"}
  • Setup the project properties you want. This includes setting the top level HDL parameter that controls your generate commands in RTL
    • set_property generic <parameter_name>=<parameter_value> [current_fileset]
  • Setup the synthesis run as you want
    • set_property <property_name> <value> [get_runs synth_1]
  • Launch the synthesis run
    • launch_runs synth_1
    • wait_on_runs synth_1
  • Setup the implementation run
  • Launch the implementation run
    • launch_runs impl_1
    • wait_on_runs impl_1
  • Create the bitstream if you want
    • launch_runs impl_1 -to_step write_bitstream
  • Close the project (close_project) and exit the script

If you have an existing project, you can get a good starting point for my_script.tcl using the "write_project_tcl" command - this will create a Tcl that sets up the runs and the properties to be able to regenerate the state of the current project.

Note that this process will create a new project each time the script is run - it will never "reuse" stuff from a previous run. This is different than the way people generally work with projects, but is much more "build based" and, consequently, can be much friendlier to revision control...

This process isn't trivially easy, but once mastered is very powerful...


Registered: ‎07-17-2014

Both interesting solutions.

This will be a while as I'm stilll working on getting all this new code functioning... I'll post what I end up doing.

Thanks for the suggestions!


0 Kudos