cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
xdcs
Visitor
Visitor
12,678 Views
Registered: ‎02-25-2014

UCF to XDC

Hi all.

 

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

 

1)

ucf: 

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: ?

 

2) 

ucf:

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
htsvn
Xilinx Employee
Xilinx Employee
12,676 Views
Registered: ‎08-02-2007

Hi,


Refer these resources.

 

http://www.xilinx.com/support/answers/50376.html

Quick Video http://www.xilinx.com/training/vivado/migrating-ucf-constraints-to-xdc.htm

 

--Hem

 

 

----------------------------------------------------------------------------------------------
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
siktap
Scholar
Scholar
12,674 Views
Registered: ‎06-14-2012

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

 

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_3/ug911-vivado-migration.pdf

 

FROM:TO set_max_delay

TIG set_false_path

 

 

Hope this helps.

 

Regards

Sikta

 

 

0 Kudos
avrumw
Guide
Guide
12,654 Views
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

 

 

1)

 

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?

 

2)

 

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_

REG) && IS_SEQUENTIAL)]

 

 

Avrum