cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
darkroom
Visitor
Visitor
401 Views
Registered: ‎05-03-2019

A7 IDELAYCTRL FIDELAYCTRL_REF frequency specifications

Jump to solution

Hi,

I read through a couple of other IDELAY similar questions, but they don't seem to answer the question about the frequency range of the 7 series architecture.

What is the frequency range for the FIDELAYCTRL_REF clock in the 7 series?  Is it required to be as close to the stated fixed frequencies of 200 or 300 (or 400), or is it variable, with a min and a max?  The part I am using is an A7 -1 speed grade.

XAPP707, for another architecture, says the delay lines are fixed at 72ps per, and the reference clock is "help keep constant", which means there is no variability in that architecture's clock and tap delay.  Is this the same for the A7, with two/three different tap paths, depending on the input frequency, or is the A7 a different architecture with variable tap delays?  Any document like XAPP707 for the 7 series?

Thanks,

Austin

 

0 Kudos
1 Solution

Accepted Solutions
darkroom
Visitor
Visitor
191 Views
Registered: ‎05-03-2019

Hi Avrum,

Thank you very much for all the input and information.  It looks like it is variable, per the post that the poster did the experiment, and it worked for him, but Xilinx only "guarantees" it operates at the two/three frequencies, so no min/max frequencies are specified.  Now that I know that, I can just use the 200 or 300MHz options, and that will work fine for my current application.

Best Regards,

Austin

 

View solution in original post

0 Kudos
8 Replies
darkroom
Visitor
Visitor
377 Views
Registered: ‎05-03-2019

This post:

https://forums.xilinx.com/t5/Other-FPGA-Architecture/IDELAYCTRL-REFCLK-FREQUENCY/td-p/469176

seems to indicate that the delay taps are not fixed at 200MHz, 300MHz & 400MHz, but allow for variability, based on the frequency of the reference clock.  The poster said they just got warnings their clock wasn't within the range, but that it still worked.  So, either these delay taps are fixed, or are not fixed.  And if they are fixed, how can this ability to vary the delay directly related to the reference clock be explained?

 

0 Kudos
miker
Xilinx Employee
Xilinx Employee
351 Views
Registered: ‎11-30-2007

@darkroom 

You can reference the Artix-7 FPGAs Data Sheet: DC and AC Switching Characteristics (DS181; v1.25) in Table 25: Input/Output Delay Switching Characteristics.

forums_ds181_table25.png

Please Reply, Kudos, and Accept as Solution.
0 Kudos
avrumw
Guide
Guide
337 Views
Registered: ‎01-23-2009

The tap delays are not fixed - the calibration mechanism used by the IDELAYCTRL calibrates the delay of the taps using the frequency reference provided by the IDELAYCTRL; the calibration is performed so that 64 taps represents one full clock period of the REFCLK (in spite of the fact that the IDELAYs themselves only have 32 taps).

The calibration mechanism is only guaranteed at REFCLK = 200MHz+/-10MHz, 300MHz+/-10MHz, or 400MHz+/-10MHz (with not all possibilities allowed in all speed grades). No other frequencies for REFCLK are allowed.

We don't (officially) know how this calibration mechanism works. While we might speculate that most mechanisms would allow for frequencies between these discrete frequency ranges should work, the documentation states otherwise, so we have no choice but to believe it. What is specified in the datasheet is what we must stick to...

Avrum

0 Kudos
darkroom
Visitor
Visitor
321 Views
Registered: ‎05-03-2019

Thanks.  I read through the datasheet, and any other documentation I could find (including the forums) before posting my question.  The issue is the datasheet, nor any other documentation/forum posts, provide the answers I am looking for.

0 Kudos
darkroom
Visitor
Visitor
304 Views
Registered: ‎05-03-2019

Hi Avrum,

Thank you for the reply.

In the post I reference, it is for an older architecture, and it was stated that the taps were fixed, and based on the process technology.  Now, that may have been speculation, or perhaps it was how it was done in the older technology, as XAPP707 says that there are two delay tap paths, one fixed, and one the 200MHz divided by 64, and  uses phase comparators etc.  I find any explanation of the A7 IDELAY so far not %100 cohesive, but your information certainly adds a lot to an attempt to get a better understanding.   I am inclined to believe your explanation, that they are not fixed, especially given the post that someone tried intermediate frequencies, with proportional delay results as one would expect.  But that just seems odd that it is spec'd for only three fixed frequencies, instead of a range for the reference clock.  Where did you get the information on the calibration and that it calibrates 64 taps (why do we only get 32 of the 64?) for one full cycle?  It's not in the 7 series library guide, not in the Select I/O guide.  Is there another place IDELAYCTRL is documented with further information?

I am not sure why it is necessary to keep this info "secret".  And, unfortunately, it sounds to me, like it or not, just use what we tell you to use.

Best Regards,

Austin

0 Kudos
avrumw
Guide
Guide
284 Views
Registered: ‎01-23-2009

Here is what I can tell you.

The IDELAY/ODELAY/IODELAY functionality depends on family. The first device to introduce this was the Virtex-4, and the fundamentals of the Virtex-4 IDELAY is fundamentally the same as the Virtex-5 IODELAY, and the Virtex-6 and 7 series IDELAY/ODELAY. You are right that they never describe how the calibration is done...

In the earlier versions, the only allowed REFCLK frequency was 200MHz. This allowed them to say the IDELAY tap delay was "fixed" at 75ps. Later versions allowed 300MHz and eventually 400MHz REFCTL clocks, which changed the TAP delay. Looking at the 7 series datasheet (say Kintex-7, DS182, Table 28, footnote 1), though, there is a clear correlation:

  • REFCLK=200MHz -> Tap Delay=78ps
    • 78ps*64=4.992 (almost exactly 5ns - one period @ 200MHz)
  • REFCLK=300MHz -> Tap Delay=52ps
    • 52ps*64=3.328 (almost exactly 3.33ns - one period @300MHz)
  • REFCLK=400MHz -> Tap Delay=39ps
    • 39ps*64=2.496 (almost exactly 2.5ns - one period @400MHz)

So, while it isn't stated anywhere that the tap delay is exactly 1/64 of the period of the REFCLK, it clearly appears to be true. I won't speculate as to how each tap is calibrated, but the documentation certainly implies that there are 32 (and in older technologies 64) discrete delay buffers, each with this calibrated delay (and the XAPP states this pretty explicitly).

The IODELAY in Spartan-6 is different; it is uncalibrated, There are more taps (255), but the tap delay varies more widely across PVT, and is also not uniform. The user guide gives you more information on how it is implemented (as a delay counting state machine rather than multiplexed taps). One of consequences of this is that you cannot (should not) use the IDELAY to delay a clock in Spartan-6, whereas in the other technologies (V4/V5/V6/7 series) you could (and it was, in fact, preferred to delay the clock rather than the data).

The  IDELAY/ODELAY on UltraScale/UltraScale+/Versal are different yet. Here, the delay seems to be implemented as a much larger set of smaller individual delay buffers (511). In DELAY_FORMAT=COUNT the taps are uncalibrated with a very wide delay variation (2.5 to 15ps). These are great for systems that use the taps with a closed loop calibration process (dynamic capture) where you don't care about the actual delay value. In DELAY_FORMAT=TIME, the there is a calibration state machine that dynamically adjusts the number of taps needed to get a desired delay measured in time (ns). The documentation is pretty clear that it isn't adjusting the delay of each tap (as was done in V4/V5/V6/7 series) but is, instead, adjusting the number of taps used to get a desired delay. Again, these should not be used for delaying clocks...

As for keeping this stuff a "secret", it isn't really. First, in the Spartan-6 and UltraScale/UltraScale+/Versal User Guides they actually describe the system in pretty good detail. For the V4/V5/V6/7 series, you are right, the dividing by 64 isn't explicitly mentioned (at least not that I can find), but it isn't all that carefully hidden either. I also suspect that you can find details on how it works in one of the Xilinx patents (which are available) - but I have never looked.

Avrum

Tags (3)
0 Kudos
avrumw
Guide
Guide
280 Views
Registered: ‎01-23-2009

Sorry - looking more carefully at XAPP707 it does explicitly state how the delays are calibrated in V4 (which, as I mentioned, is very similar to V5/V6/7 series)

While conventional logic delays vary significantly with temperature, voltage, and
processing differences, the delay through the IDELAY chain of 64 buffers is kept constant
with the help of a 200 MHz (nominal) oscillator. This oscillator feeds an additional 64-tap
delay line that is invisible to the user. A phase comparator compares the output of this
delay line against its input. When the through delay differs from a period of the clock
(nominally 5 ns), the output of the phase comparator changes the supply voltage of all
associated IDELAY circuits making the through delay equal to one clock period. This
phase-locked loop has a naturally slow response time and therefore suppresses any
oscillator frequency jitter.

What it is saying is that it feeds the REFCLK to a 64 tap delay chain in the IDELAYCTRL. It then compares the output of this complete 64 tap delay chain with one full period of the REFCLK (which was fixed at 200MHz in V4) using a phase comparator. If the delay through the 64 tap delays comes earlier than the next rising edge of the reference clock, the taps are too small so it makes each tap longer by reducing the voltage on the delay chain buffers. If the output of the 64 taps happens after the next REFCLK clock edge, the delay through the 64 taps is more than one clock period, so the delays are all too slow, so it makes each buffer faster by raising the voltage. Done this way, it determines (and maintains) the proper voltage on the delay buffers to make the total delay through the 64 delay buffers equal to exactly one clock period of the REFCLK, and hence each delay buffer exactly (well not exactly, the paper describes the non uniformity of the buffers) 1/64th of the REFCLK period.

It is not explicitly stated, but it is assumed that the voltage generated by this calibration process powers not only the 64 tap delay chain in the IDELAYCTRL, but all the IDELAY/ODELAY/IODELAY taps in the same bank - this is how the REFCLK fed to the IDELAYCTRL calibrates the taps in all the IDELAY/ODELAY/IODELAY in the same I/O bank.

Avrum

Tags (1)
0 Kudos
darkroom
Visitor
Visitor
192 Views
Registered: ‎05-03-2019

Hi Avrum,

Thank you very much for all the input and information.  It looks like it is variable, per the post that the poster did the experiment, and it worked for him, but Xilinx only "guarantees" it operates at the two/three frequencies, so no min/max frequencies are specified.  Now that I know that, I can just use the 200 or 300MHz options, and that will work fine for my current application.

Best Regards,

Austin

 

View solution in original post

0 Kudos