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: 
Highlighted
Participant alexis_jp
Participant
198 Views
Registered: ‎09-10-2019

How to know the TAP delay resolution? Single IDELAYCTRL multi banks?

Jump to solution

For Virtex US+ with delay mode TIME and type VARIABLE. (not FIXED not VAR_LOAD)

I found a partial answer in AR60802 but there is no mention of VARIABLE mode. And the @avrumw 's answer here https://forums.xilinx.com/t5/Versal-and-UltraScale/How-to-calculate-the-IDELAY-RESOLUTION/td-p/659265 states it isn't possible to know the resolution.

DS923 stipulates 2.1ps to 12ps but I want a range of 2ns minimum that is 3.9ps step for 512 taps.

  • How can I be sure the resolution is higher than 3.9ps?
  • How is the resolution defined underneath? What factors if not the IDELAYCTRL's refclk?
  • Does a IDELAYCTRL or IODELAY reset change the tap resolution?

A different question, using two different IO banks, do I need to instanciate two IDELAYCTRL? How can I link one to a bank?

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
153 Views
Registered: ‎01-23-2009

Re: How to know the TAP delay resolution? Single IDELAYCTRL multi banks?

Jump to solution

 

How can I be sure the resolution is higher than 3.9ps?

You can't. As I understand it the taps are simply uncalibrated, uncompensated delay elements. As such, they vary over Process, Voltage and Temperature (PVT) between the specified range of 2.1 to 12ps (which, admittedly, is much larger than the 3:1 "rule of thumb" used for variation of a silicon transistor over PVT).

So if the device you happen to get is faster than average, and it is at a lower VT corner (which is no longer necessarily the highest voltage and lowest temperature) then you can be in a situation where the taps are averaging closer to the 2.1ps limit than the 12ps. If that happens, then you cannot get a full 2ns with one delay line. Changing the REFCLK for the IDELAYCTRL and resetting the IDELAY/IDELAYCTRL will have no effect on this - this is physically how long the delay is (the IDELAYCTRL isn't even used in COUNT mode).

Be aware, though, that the delay lines can be cascaded (between the inputs and outputs, and even the input of the LVDS pair), so you can pretty easily get 2x or 3x the "minimum" delay - this would be enough to get your 2ns even if you do have a "fast" part.

The IDELAYCTRL in UltraScale/UltraScale+ does not calibrate the taps (as it did in the 7 series and earlier), but calibrates TIME mode delay. If you ask for (say) 1ns of delay in TIME mode, this will correspond to a certain number of taps. However, since the tap delays are variable over PVT, the device needs a way of "measuring" how long each tap is, in order to select the correct number of taps (at this PVT combination) to obtain the 1ns delay you are asking for. This is what the IDELAYCTRL and the REFCLK are used for - to determine the delay of a single tap at the current PVT so that a fixed delay can be obtained in TIME mode. This calibration (and potential changing of the number of taps) happens continuously as long as the EN_VTC pin of the IDELAY is enabled.

A different question, using two different IO banks, do I need to instanciate two IDELAYCTRL? How can I link one to a bank?

In UltraScale the IDELAYCTRLs are actually one per nibble group (so 8 per bank). The tool will automatically replicate a single manually instantiated IDELAYCTRL (including the connections to REFCLK, RDY and RST) into each nibble group where an IDELAY in TIME mode is used. If there is only one IDELAYCTRL instantiated in your design, then the REFCLK, RST and RDY will be used for all such replicated IDELAYCTRLs (the RDY will be ANDed between all the IDELAYCTRLs). If you need different IDELAYCTRLs for different interfaces (say they use a different REFCLK or RST), then you associate them with the IODELAY_GROUP attribute.

And, yes, it is hard to understand how VARIABLE mode fits in with TIME mode. To change the tap delays you need to turn of EN_VTC. Once you do this, the delay isn't really in TIME mode anymore - you can read and then modify the "current" number of taps, but since EN_VTC is disabled, calibration is no longer occurring. I have to admit that I don't understand what happens when you program in a new number of taps, and then re-enable EN_VTC...

Avrum

 

0 Kudos
3 Replies
184 Views
Registered: ‎07-23-2019

Re: How to know the TAP delay resolution? Single IDELAYCTRL multi banks?

Jump to solution

 

My understanding is that each tap can be anything uncontrolled and unknown between 2 and 12 ps. You can specify a delay and the tap will be chosen. The delay will jump in irregular steps as each tap is variable.

0 Kudos
Historian
Historian
154 Views
Registered: ‎01-23-2009

Re: How to know the TAP delay resolution? Single IDELAYCTRL multi banks?

Jump to solution

 

How can I be sure the resolution is higher than 3.9ps?

You can't. As I understand it the taps are simply uncalibrated, uncompensated delay elements. As such, they vary over Process, Voltage and Temperature (PVT) between the specified range of 2.1 to 12ps (which, admittedly, is much larger than the 3:1 "rule of thumb" used for variation of a silicon transistor over PVT).

So if the device you happen to get is faster than average, and it is at a lower VT corner (which is no longer necessarily the highest voltage and lowest temperature) then you can be in a situation where the taps are averaging closer to the 2.1ps limit than the 12ps. If that happens, then you cannot get a full 2ns with one delay line. Changing the REFCLK for the IDELAYCTRL and resetting the IDELAY/IDELAYCTRL will have no effect on this - this is physically how long the delay is (the IDELAYCTRL isn't even used in COUNT mode).

Be aware, though, that the delay lines can be cascaded (between the inputs and outputs, and even the input of the LVDS pair), so you can pretty easily get 2x or 3x the "minimum" delay - this would be enough to get your 2ns even if you do have a "fast" part.

The IDELAYCTRL in UltraScale/UltraScale+ does not calibrate the taps (as it did in the 7 series and earlier), but calibrates TIME mode delay. If you ask for (say) 1ns of delay in TIME mode, this will correspond to a certain number of taps. However, since the tap delays are variable over PVT, the device needs a way of "measuring" how long each tap is, in order to select the correct number of taps (at this PVT combination) to obtain the 1ns delay you are asking for. This is what the IDELAYCTRL and the REFCLK are used for - to determine the delay of a single tap at the current PVT so that a fixed delay can be obtained in TIME mode. This calibration (and potential changing of the number of taps) happens continuously as long as the EN_VTC pin of the IDELAY is enabled.

A different question, using two different IO banks, do I need to instanciate two IDELAYCTRL? How can I link one to a bank?

In UltraScale the IDELAYCTRLs are actually one per nibble group (so 8 per bank). The tool will automatically replicate a single manually instantiated IDELAYCTRL (including the connections to REFCLK, RDY and RST) into each nibble group where an IDELAY in TIME mode is used. If there is only one IDELAYCTRL instantiated in your design, then the REFCLK, RST and RDY will be used for all such replicated IDELAYCTRLs (the RDY will be ANDed between all the IDELAYCTRLs). If you need different IDELAYCTRLs for different interfaces (say they use a different REFCLK or RST), then you associate them with the IODELAY_GROUP attribute.

And, yes, it is hard to understand how VARIABLE mode fits in with TIME mode. To change the tap delays you need to turn of EN_VTC. Once you do this, the delay isn't really in TIME mode anymore - you can read and then modify the "current" number of taps, but since EN_VTC is disabled, calibration is no longer occurring. I have to admit that I don't understand what happens when you program in a new number of taps, and then re-enable EN_VTC...

Avrum

 

0 Kudos
Participant alexis_jp
Participant
139 Views
Registered: ‎09-10-2019

Re: How to know the TAP delay resolution? Single IDELAYCTRL multi banks?

Jump to solution

@avrumwI see, the tap resolution depends on physical components and depends on the silicon's quality. It varies depending on the speedgrade unlike what's assumed by reading the documentation.

The problem is in the TIME mode, there are 3 types.

  • FIXED where we can select in ps the delay
  • VARIABLE which is pretty much same as the COUNT mode with increment/decrement only but with PVT control.
  • VAR_LOAD which is pretty much same as FIXED but loadable by giving number of taps instead of ps.

Delay value:

  • The type FIXED of the TIME mode ONLY makes sure we have the delay in ps we set before compilation, can't be change while running.
  • VARIABLE and VAR_LOAD: we are sure the delay is constant but we don't know the value in ps.
  • COUNT mode, the delay isn't constant and we don't know the value.

That's now clear.

IDELAYCTRL:

Ok, now it's clear, Vivado should know where to duplicate and place IDELAYCTRL since I use the RDY signal to the IODELAY's reset pin.

VARIABLE type makes more sense than COUNT mode for me. At least we know the delay in ps won't change once we made the setting with inc/dec. Since we can't read the tap value, it's impossible to know when we overflow the taps number.

 

Thanks for you concise answer. That'll help other people for sure.

 

0 Kudos