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: 
Visitor endal1120
Visitor
148 Views
Registered: ‎12-12-2016

Correct timing constraints?

Jump to solution

Timing constraints conversion from ucf to xdc.

Is it correct?

<ucf>

NET "P60" TNM_NET = P60;
TIMESPEC TS_P60 = PERIOD "P60" 2.8 ns HIGH 50%;

NET "P30" OFFSET = IN 0 ns VALID 2.8 ns BEFORE "P60" rising;

<conversion to xdc>

create_clock -period 2.800 -name P60 -waveform {0.000 1.400} [get_ports P60]

set_input_delay -clock P60 -max 2.8 [get_ports P30];
set_input_delay -clock P60 -min 0 [get_ports P30];

Please give guidence for me.

thanks

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
107 Views
Registered: ‎05-14-2008

Re: Correct timing constraints?

Jump to solution

Both -max and -min are 2.8ns

set_input_delay -clock P60 -max 2.8 [get_ports P30];  # (period - <offset in before> = 2.8 - 0= 2.8)
set_input_delay -clock P60 -min 2.8 [get_ports P30];   # (valid - <offset in before> = 2.8 - 0= 2.8)

OR

set_input_delay -clock P60 2.8 [get_ports P30];

Your example is an ideal one that the data valid window is equal to the clock period.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
3 Replies
Moderator
Moderator
124 Views
Registered: ‎11-04-2010

Re: Correct timing constraints?

Jump to solution

Hi, @endal1120 ,

It looks correct.

For ISE->Vivado Migration question, you can refer to UG911 first.

In PlanAhead, using read_xdc XX.xdc command can help to do initial constraint convertion for you.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Xilinx Employee
Xilinx Employee
108 Views
Registered: ‎05-14-2008

Re: Correct timing constraints?

Jump to solution

Both -max and -min are 2.8ns

set_input_delay -clock P60 -max 2.8 [get_ports P30];  # (period - <offset in before> = 2.8 - 0= 2.8)
set_input_delay -clock P60 -min 2.8 [get_ports P30];   # (valid - <offset in before> = 2.8 - 0= 2.8)

OR

set_input_delay -clock P60 2.8 [get_ports P30];

Your example is an ideal one that the data valid window is equal to the clock period.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Historian
Historian
83 Views
Registered: ‎01-23-2009

Re: Correct timing constraints?

Jump to solution

Your example is an ideal one that the data valid window is equal to the clock period.

Let me be clear about what @viviany is saying... This is telling the tool that the input has "ideal" timing, which is impossible - the data changes instantaneously at the rising edge of the clock with absolutely no variation, no slew, no jitter, no process/temperature/voltage dependence. This is impossible.

Doing this is underconstraining your input (probably pretty significantly). As a result, even if the tools tell you "this passes" there is no reason to believe this will actually work.

Furthermore, specifying an input delay of one clock period is pretty wierd. You are basically saying that the data required for the clock edge at 2.8ns arrives at 2.8ns - unless there is a significant internal clock delay, this is guaranteed to fail the setup check...

In a nutshell, these constraints, while being a correct "translation" of the UCF constraints, are almost certainly incorrect from the system point of view...

Forget about UCF. Go back to the datasheet of the device that is driving the FPGA and generate complete and correct XDC timing constraints...

Avrum