cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
florian_
Observer
Observer
668 Views
Registered: ‎03-25-2013

ODELAYE3 tap delay variance and CNTVALUEIN limitations

Hi,

I'm using the ODELAYE3 primitive on multiple banks in an UltraScale device with the following settings:

CASCADE => "NONE",
DELAY_FORMAT => "COUNT",
DELAY_TYPE => "VARIABLE",
DELAY_VALUE => 0,
IS_CLK_INVERTED => '0',
IS_RST_INVERTED => '1',
REFCLK_FREQUENCY => 250.00,
SIM_DEVICE => "ULTRASCALE",
UPDATE_MODE => "ASYNC"

tap delay variance: According to [DS893], the IDELAY/ODELAY chain resolution is 2.5 to 15 ps per tap, resulting in 1.280 to 7.680 ns for 512 taps. I assume this variance results from PVT, but what other dependencies (e.g. the REFCLK_FREQUENCY or IOSTANDARD) exist? (I am aware that I could use the "TIME" mode to work around this chain resolution variance). I'd like to know if I could expect a lower variance for a particular part and configuration?

CNTVALUEIN limitations: According to [UG571] "The delay line can be changed from 1 to 8 taps at a time" via CNTVALUEIN[8:0], whereas "Jumps higher than 8 taps might result in the delay line jump causing data to glitch". Is it safe to assume that this data glitch will last no longer than the difference in taps between old and new CNTVALUEIN, and in any case will not be persistent?
For example, if I jump 100 taps, the glitch will endure no more than 0.250 to 1.500 ns, depending on the IDELAY/ODELAY chain resolution? Is the wrap around from tap 511 to 0 (or vice versa) excluded from above "8 tap rule"?

Thanks,
Florian

0 Kudos
5 Replies
avrumw
Guide
Guide
658 Views
Registered: ‎01-23-2009

I'd like to know if I could expect a lower variance for a particular part and configuration?

Your resoning makes sense - the variation is across the complete Process/Voltage/Temperature space, so it is reasonable to expect that the variaion would be less on the same die. However, you cannot count on it, and there is no mechanism for quantifying what this reduced variance might be - Xilinx publishes this (and only this) specification, and there is no other information available for "derating" this, so you to be safe you have to assume that each tap can vary over the entire range at any PVT (even if this is likely impossible according to the rules of physics).

Is it safe to assume that this data glitch will last no longer than the difference in taps between old and new CNTVALUEIN, and in any case will not be persistent?

It is reasonable to assume this. While Xilinx doesn't specifically state the characteristics of the "glitch" they do provide enough of an idea as to how the delay line works to make this a reasonable assumption. However, there is no "authoritative" confirmation of this, so assume it at your own risk...

Is the wrap around from tap 511 to 0 (or vice versa) excluded from above "8 tap rule"?

The wrap around on the IDELAY is not smooth - when you go from 511 to 0, you will have a sudden discontinuity in delay of the entire tap chain - the wrap around is a pure binary wrap around - there is no way of representing "512", so setting it to 512 (via, say, doing an INC when it is at 511), will result in a delay that is in every way identical to a delay of 0. Given this, I would expect the output to "eat" a significant portion (up to 7.68ns) of a pulse (thus reducing any pulse shorter than or close to 7.68ns to either nothing or a glitch).

Avrum

Tags (1)
0 Kudos
florian_
Observer
Observer
580 Views
Registered: ‎03-25-2013

Thank's avrumw, good to see you back my considerations.

Still I'd appreciate an "official" statement from Xilinx on this matter, especially about the ODELAY tap variance on a paritcular part or even a particular IO bank.

0 Kudos
sandrao
Community Manager
Community Manager
555 Views
Registered: ‎08-08-2007

Hi @florian_ 

 

tap delay variance: According to [DS893], the IDELAY/ODELAY chain resolution is 2.5 to 15 ps per tap, resulting in 1.280 to 7.680 ns for 512 taps. I assume this variance results from PVT, but what other dependencies (e.g. the REFCLK_FREQUENCY or IOSTANDARD) exist? (I am aware that I could use the "TIME" mode to work around this chain resolution variance). I'd like to know if I could expect a lower variance for a particular part and configuration?

The variance is PVT and there is no dependancy on REFCLK, IOSTANDARD etc. The variance is 2.5ps to 15ps per tap regardless of part or configuration. 

 

CNTVALUEIN limitations: According to [UG571] "The delay line can be changed from 1 to 8 taps at a time" via CNTVALUEIN[8:0], whereas "Jumps higher than 8 taps might result in the delay line jump causing data to glitch". Is it safe to assume that this data glitch will last no longer than the difference in taps between old and new CNTVALUEIN, and in any case will not be persistent?
For example, if I jump 100 taps, the glitch will endure no more than 0.250 to 1.500 ns, depending on the IDELAY/ODELAY chain resolution? Is the wrap around from tap 511 to 0 (or vice versa) excluded from above "8 tap rule"?

If you jump by more than 8 taps you can jump to anywhere in the delay chain (if the delay chain is 0.25 to 1.5ns you will be somewhere within that range).

If you were to wrap around by incrementing from 511 to 0 that should be fine. However if you load in a value of 0 after a value of 511 that would be a jump greater than 8 taps. 

 

Sandy

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------
0 Kudos
florian_
Observer
Observer
535 Views
Registered: ‎03-25-2013

Hi @sandrao

I'm a litte unsettled by the "per tap" in "... chain resolution is 2.5 to 15 ps per tap...". In my application I'd like to delay a output data bus of > 32 bit (stretched across 2 HP IO banks) - do I have to consider the case that for e.g. the setting CNTVALUEIN = 100 taps, I'll end up with an ouput delay of 2.5x100 = 250 ps for one data bit and maybe 15x100 = 1500 ps for another data bit? If that is the case, I guess your recommendation would be to use DELAY_FORMAT = TIME to compensate for Voltage and Time and use DELAY_VALUE of each individual delay to calculate the correspondent tap setting to be loaded to CNTVALUEIN[8:0] in order to get a uniform delay (in ps) across the entire data bus?

Yet regarding CNTVALUEIN limitations, switching to DELAY_FORMAT = TIME wouldn't help beacause the required delay change (in ps) needs to be translated into an amount of taps which can be written to CNTVALUEIN[8:0] and the same 8-tap rule applies.

Florian

0 Kudos
sandrao
Community Manager
Community Manager
523 Views
Registered: ‎08-08-2007

Hi @florian_ 

 

If you have a 32 bit bus across 2 banks with a CNTVALUEIN of 100 the theortical worst case variance would be 100*2.5 to 100*15ps. In practise all the IOs are on the same process as they are on the same device. They would have very similar voltage and temp. 

If you do static timing in Vivado (set_input_delay) you will get timing numbers that account for this. 

The benefit of the DELAY_FORMAT = TIME is that the delay is compensated for VT. In a FIXED mode if you choose 500ps then BISC will work out how many Taps = 500ps and will keep updating to keep the delay at 500ps. If you need to change the delays then it is trickier to use the CNTVALUEOUT to calculate the current Tap size and how many Taps for the new delay, with the 8 Tap rule still applying as you said.

 

Sandy

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------
0 Kudos