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


Hi all.


Can anyone help me to convert some constraints from ucs syntax to xdc one.




NET "clk156_25" TNM_NET = "mac_clk";

NET "clk312_5" TNM_NET = "mac_clk_x2";

TIMESPEC TS_0 = FROM "mac_clk" TO "gt0_txusrclk2_i" 6 ns DATAPATHONLY;


xdc: ?




INST "u_pcs_top/u_HOST_RG_PCS/u_RW*/g_HOST_REG[*].HOST_REG" TNM = FFS "pcs_host_reg_tnm";
TIMESPEC TS_false_path_0 = FROM "pcs_host_reg_tnm" TIG ;


xdc: ?


Thanks in advance

0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
Registered: ‎08-02-2007


Refer these resources.

Quick Video





Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Registered: ‎06-14-2012

You can also check the section ucf to xdc mapping in the migration guide.


FROM:TO set_max_delay

TIG set_false_path



Hope this helps.






0 Kudos
Registered: ‎01-23-2009

The reason that XIlinx doesn't provide an "automatic" mechanism of converting from UCF to XDC is that generally you don't want to do a literal "line by line" conversion between one and the other.


UCF is a proprietary "language" for communicating timing constraints. It has fairly odd syntax, and evolved over years to meet the needs of the timing engine in ISE.


Timing constraint using XDC (SDC) is an industry standard set of interactive commands for communicating constraints to the timing engine in Vivado.


The two timing engines are VERY different. Vivado using a very consistent approach to how it deals with timing paths and constraints on them. ISE uses (well) whatever ISE used...


So while they both need the same underlying constraints, the mechanism of communicating them is extremely different - with Vivado being generally far more powerful.


The ISE constraints you have are very specific formats for ISE (and are incomplete). Without knowing the structure of the design, and the complete set of constraints, its not really possible to do the "right" thing which is:

  - determine from the UCF constraints and the structure of the RTL code (primarily the clocking) what the timing requirements are

  - determine if the same sets of requirements are needed in Vivado

      - sometimes they aren't since Vivado deals with unrelated clocks completely differently than ISE

  - determine a clear and efficient way to communicate these constraints to Vivado using XDC


It is highly recommended that if you are going to use XDC constraints you learn how to do them properly. There are some quick-take videos (others have posted them) and manuals. There are also some good classes from Xilinx training - particularly this one.


Given all that, here is my best guess as to how these specific constraints should be written in XDC





The UCF constraints are not complete - they need some clock definitions on the clk156_25 and clk312_5 nets.


In XDC, I am assuming that there have been clocks created appropiatedly, with something like


create_clock -name clk156_25 -period  6.4 [get_ports <something>]

create_clock -name clk312_5   -period 3.2  [get_ports <something>]

although the creation of these clocks may be completely different

   - they may come from an internally net

   - they may be internally generated, and hence already have a name

   - they may be synchronous or not...


The other problem is that we have no idea what gt0_txusrclk2_i is. Since it is used in a FROM/TO, it needs to be a timegroup, but you haven't given us its definition... Assuming it is a clock too, which has a


create_clock -name gt0_txusrclk2_i <some value> <[get_something...]>


(and, by the way, the definition of clk312_5 is irrelevent to this discussion)


then the XDC command would be


set_max_delay -from [get_clocks clk156_25] -to [get_clocks gt0_txusrclk2_i] 6 -datapath_only


But, as you can see, without a lot more context, its impossible to make a one-to-one conversion


Also, its a pretty odd constraint - why would you be setting a datapath_only constraint between these two clocks of 6ns? Where does the 6ns come from?




Here too, line to line conversion of the UCF to XDC is not recommended. This UCF constraint was written using the (limited) capabilities of the UCF language to convey some timing requirement. While the timing requirement may need to be the same in XDC, the way of expressing it can be very different. Notably, the way XDC and UCF treat hierarchy is very different. While we can "translate" this command, it uses a relatively un-recommended style of identifying cells...


set_false_path -from [get_cells -hier -filter {(NAME =~ u_pcs_top/u_HOST_RG_PCS/u_RW*/g_HOST_REG[*].HOST_