cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
billypowell
Visitor
Visitor
4,065 Views
Registered: ‎06-06-2014

IDELAYE3 DATAIN path constraints

Jump to solution

Hi,

in my project I'm using an IDELAYE3 instance to shift an internal logic signal driven by a FF (let's call it FD1).

I need to respect a timing window for the path from this FF to DATAIN of the IDELAYE3 instance.

I tried with the following constraints:

set_min_delay -from [get_pins FD1/C] -to [get_pins IDELAY_INST/DATAIN] 3

set_max_delay -from [get_pins FD1/C] -to [get_pins IDELAY_INST/DATAIN] 4

When I compile the design I get a warning: since the timing endpoint is not valid, my constraints caused a path segmentation.

Furthermore, by opening the implemented design I can verify that these constraints are not respected at all.

Is there a better way to reach my goal?

I'm using Vivado 2016.1 on a Kintex UltraScale device.

Thank you in advance

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
7,227 Views
Registered: ‎01-23-2009

Is there a better way to reach my goal?

 

No - in fact, what you are asking for cannot be constrained, and the values you are asking for are impossible anyway.

 

While the IDELAY is calibrated, the routing to and from it is not. So, the tools can use any route to get from your internal flip-flop to the IDELAY. Furthermore, unless the result of the IDELAY is going to the IOB flip-flop (and I am not even sure that is legal when using an internal data path to the IDELAY), then it, too, will be subject to routing variation.

 

In Vivado, only paths are constrained. This path starts at an internal flip-flop and ends (presumably) at some other flip-flop (either IOB or fabric). You can set a set_max_delay -datapath_only on this path, and maybe constrain the path somewhat; the delay will include the calibrated delay of the IDELAY and the uncalibrated delay getting to and from it.

 

However, you have to realize that these delays are affected by Process, Voltage and Temperature (PVT). In a silicon device, these variations usually amount to a roughly 3:1 variation (slowest to fastest). The numbers you are asking for - between 4 and 3 - are impossible to meet in silicon over PVT.

 

I will ask the usual question - why do you want to do something like this? In normal synchronous digital systems, you should never need to control something like this. Because it is generally impossible to constrain timing this tight (due to the PVT nature of silicon) synchronous design techniques have been devised that work in spite of this fundamental limitation, and the tools have all been designed to work using these synchronous design techniques.

 

Avrum

View solution in original post

1 Reply
avrumw
Guide
Guide
7,228 Views
Registered: ‎01-23-2009

Is there a better way to reach my goal?

 

No - in fact, what you are asking for cannot be constrained, and the values you are asking for are impossible anyway.

 

While the IDELAY is calibrated, the routing to and from it is not. So, the tools can use any route to get from your internal flip-flop to the IDELAY. Furthermore, unless the result of the IDELAY is going to the IOB flip-flop (and I am not even sure that is legal when using an internal data path to the IDELAY), then it, too, will be subject to routing variation.

 

In Vivado, only paths are constrained. This path starts at an internal flip-flop and ends (presumably) at some other flip-flop (either IOB or fabric). You can set a set_max_delay -datapath_only on this path, and maybe constrain the path somewhat; the delay will include the calibrated delay of the IDELAY and the uncalibrated delay getting to and from it.

 

However, you have to realize that these delays are affected by Process, Voltage and Temperature (PVT). In a silicon device, these variations usually amount to a roughly 3:1 variation (slowest to fastest). The numbers you are asking for - between 4 and 3 - are impossible to meet in silicon over PVT.

 

I will ask the usual question - why do you want to do something like this? In normal synchronous digital systems, you should never need to control something like this. Because it is generally impossible to constrain timing this tight (due to the PVT nature of silicon) synchronous design techniques have been devised that work in spite of this fundamental limitation, and the tools have all been designed to work using these synchronous design techniques.

 

Avrum

View solution in original post