Virtex-4 ISERDES and ADS527X ADCs

(posted without having looked at the ADS datasheet or V4 IO clocking)

I've sucessfully done this sort of thing in V2-ish parts using one of the nifty _DIFF_OUT buffers ( or hand built equivalent) to create complementary local clocks to the DDR IOB registers (XAPP609), with the next CLB register stage constrained only by a MAX_DELAY, and the DCM clocks only used for the half rate logic.

This makes it fairly easy to hit IOB DDR timing without needing any funky DCM phase shift delay calibration logic, only LOC's on the I/Os to the proper local clocking region.

At 480 Mbps, I'd advise sticking with LVDS & DT terminators.

have fun, Brian

Guys, It's Friday night and I hear the siren call of the pub, so excuse the briefness of this answer!

I've also had great success with DDR links without resorting to DCM phase shift complexity. Check out XAPP233 figs. 9 and 10. The key insight is to use a latch (NOT a FF) to align the clock enables in the rising and falling edge clock domains. The latches are fast enough to meet the timing way beyond 480M, my stuff is working great at 622M. Agree totally with Brian's recommendation re. LVDS_DT. HTH, Syms.

Brian -

I don't see any documentation on the DIFF_OUT buffers you mention.

Do you have any info on them or pointers to doc?

Thanks!

John Providenza

All the V2-ish differential input buffers have a complementary output available, that can be used to create a 180 degree clock without needing a DCM.

These can also be used just to invert a differential input without needing any other logic (or board cuts & jumps).

Look at the DIFFS component in fpga_editor to see what's going on; besides the normal 'phantom' route from the DIFFS to the DIFFM, there's also a route from the DIFFM to a differential receiver in the DIFFS that outputs the complement signal.

I first spotted these when they showed up in early versions of XAPP622 as a hard macro.

Support & tool bugs for these have varied version to version, see Answer Record 21958 for recent problems.

I've banged into various other problems in using them over the years; if I get a chance this weekend, I'll try to dig up some old webcase code showing how to create one out of two normal IBUF{G}DS's as a work around.

These can be used on regular IOB inputs as well as global clock inputs, but you've generally needed to LOC the global input buffer and bufg's to allowed sites to get this to work.

search for ibufgds_diff_out ibufds_diff_out

Brian

Sean Durkin schrieb:

Why? An ethernet frame is hundreds of bits and you can still receive it with an ISERDES.

Use a 1:6 serdes and continue to process your data stream in chunks of

6-bit at a convenient rate of 80 MHz. You can add logic in the FPGA-fabric that immediately converts the stream to 12-bits at 40MHz. But probably you get a smaller circuit when you do all your signal processing 6-bit-nibble serial at 80MHz.

This issue came up in this newsgroup a few times before. Somehow everybody immediatly recognizes that a 16-bit entity can be split up into two bytes of 8-bits. But as soon as the numbers change a little apparently it becomes less obvious.

Kolja Sulimma

Use the ISERDES setup you describe here to get 6 bits at a time. Really quick pseudo code for a solution:

signal left : std_logic_vector ( 5 downto 0); signal sample : std_logic_vector ( 11 downto 0);

if ( falling_edge( sample_clock ) ) then left

Alas, I swore off Xilinx latches after the Great Latch Inversion of '00

Brian

p.s. Actually, it's not the actual latches I distrust; it's the software guys configuring the latches, having to interpret the latch enable sense when it's not properly documented in the datasheet.

GoogleGroups "CLB latch clock inversion"

from latch_bug1.txt: : For an active low latch in an EDIF input file, you get : the following results when tracing the clock signal through : the tool flow: : : tool stage XC4000EX derived Virtex Derived : ------------------------------------------------------- : EDIF in active low active low : MAP out CLK:CLKNOT CLK:CLK : EPIC display dot clock normal clock : SIMPRIM model X_INV -> X_LATCH X_INV -> X_LATCH : real HW transparent low transparent low : : note: X_LATCH SIMPRIM models are transparent high

Kolja Sulimma schrieb:

That's not the problem.

The thing is that the ADC sends out, along with the data, a fast clock and a 6x slower clock. If you run the ADC at 70MHz, it sends back a

420MHz clock and a 70MHz clock. The whole thing is designed so you use the 420MHz to clock some sort of deserializing-circuit and the 70MHz to clock out the parallel data and do your processing. So that's the "intended" way to handle this, and of course you'd first look for a way to do it with what you're provided with.

Now, since one single ISERDES doesn't handle DDR, it would have to be run at 840MHz, plus I'd need to waste a DCM to double the clock (can they even get up to 840MHz?) I get from the ADC. No way. Alternatively, I could use two ISERDES in Master-/Slave-Mode (then they can handle DDR) to output two 6bit-nibbles, as you suggested. But to get these out, I'd have to have a 140MHz clock, which I don't have. Again, waste a DCM to generate it. And since I normally have 4 of those ADCs hooked up to one FPGA, that's 4 DCMs gone already, in addition to the 4 I need to do phase-shifting anyway. That's 8 total, which is probably every single one available in the devices I have available. Again, no way.

The whole point of using the ISERDES in the first place is to save on DCMs, clock nets and hand-placed components, to make do with what is readily available.

I still don't see where the ISERDES would make anything easier.

cu, Sean

First of all, typo in the original posting: it's 840MBps, not 480Mbps I have to deal with.

Then on to your suggestion: Sounds good, but the half-rate logic would still be running at 210MHz in my case. I need more deserializing, need to make it slower :)

The thing is that the ADC sends out a 420MHz clock and a 70Mhz clock along with the data. So obviously this is designed so that you run some deserializing circuit with the 420MHz, and clock out the parallel data with the 70MHz clock. Plus, you'd do the rest of the processing in the FPGA with the 70MHz, which is easily handled.

The latter is the biggst constraint. In the first board we did, the clocks weren't connected to the local clocking pins. But even if they were, at

840Mbps (sorry, typo in the original posting, it's 840, not 480!), I still needed to do some calibration in every case. At these speeds you're already getting problems if the traces on the board aren't closely matched. I could never get it to work reliably (i.e. considering temperature drift etc.) without phase-shifting and re-calibration from time to time.

That's what I thought.

cu, Sean

I see what you're getting at. But I'd still need to supply the ISERDES with a 1/3-divided clock to get a 6bit-output (this is the clock the ISERDES output is registered with). That clock I don't have, I'd need to use a DCM or something to generate it. The sample clock on the other hand I get from the ADCs along with the data. The whole point of using the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm supplied with.

cu, Sean

Sean Durkin schrieb: The whole point of using

The point of the ISERDES is to meet timing that you would not with a LUT based SERDES.

The point of the IO delay lines is to save DCMs and clock nets. Without them you would need a DCM per ADC anyway to do the phase alignement, even if you could use the frequency 1:1.

Kolja Sulimma

Sean Durkin schrieb:

For those ADCs it is not necessary to route both the full clock and the

1/6 clock to the FPGA.

You have a phase shift in every pin of virtex-4, use that to do your phase alignement. If a DCM can go to 840 MHz with clock FX you can get the 840MHz, 70MHz and 140MHz for all ADCs out of a single DCM.

If it can not you can use an ISERDES in master slave mode to get 2x3=6 bits still using only one DCM total for an unlimited number of ADCs.

Kolja Sulimma

No need for 1/3 divide. No need to use more than one clock coming back from the ADCs either, the sample clock. There are two issues with clocking, frequency and phase.

The frequency is not an issue because all of your ADCs and all FPGA resources are receiving from the same clock source (I would hope).

The phase issue can be broken into two parts, one of global phase, and a second of bit to bit skew across the channels. The global phase can be taken care of by using the sample clock output of one of the ADCs to feed the FPGA. As temperature changes in the system, and delays on ADC and FPGA buffers change, they will change together. This of course assumes that the ADCs in different discrete packages are subject to the same thermal conditions. The issue of bit skew across all channels can be accounted for without the ISERDES and the delay element in the IO pin. Your ADC ouputs all of the necessary test patterns to null the channel to channel skew. This calibration step would be performed at power up.

You will only need one DCM in the FPGA to multiply up to your bit clock from the single ADC sample clock, to drive the ISERDES. This will also get you the proper duty cycle and phasing of the sample clock in the FPGA to make the suggestion in my previous post work.

You should need one DCM and two clock nets to get this working regardless of the number of channels.

Regards, Erik.

--
Erik Widding
President
Birger Engineering, Inc.


 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234 
  (web) http://www.birger.com

You still need the /12 clock, from the ADC, in order to locate each sample boundary, right?

Bob

-snipped the rest-

Kolja Sulimma schrieb:

Of course it's not neccessary, but if that's what you're provided with, naturally you look for ways to make it work with that, that's all I'm saying. At first glance, all you need to do is feed the data into two ISERDES in master/slave mode, clock them with the fast clock, hook up the slow clock to the CLKDV-inputs and that's it. And since the clocks you get from the ADCs are perfectly edge-aligned, and the data is perfectly phase-aligned, and you can use the Virtex4-IO-Clocks for everything, theoretically there should be no need whatsoever for any phase-shifting. Instantiate two ISERDES per channel and you're done, no need for anything else, the perfect solution!

Now if you start looking more closely it turns out it doesn't work that way. The whole point of the original posting was to find out if I've missed something and you could still do it like that.

Of course there's dozens of other ways to do it, and I appreciate all of your suggestions.

cu, Sean

Erik Widding schrieb:

Ah, OK. I thought the ISERDES outputs were always registered with CLKDV. I just "found" the combinatorial output. :)

Yes, but not all ADCs neccessarily run with the same sampling frequency. At the moment I have one clock source on the board feeding the FPGA. In the FPGA I generate the sample clocks for the ADCs. Those clocks can be different for each ADC (meaning, it's possible I'll have one ADC running at 70MHz, another one at 40MHz and so on; but of course the system has to be designed for the "worst case" of 70MHz). So yes, theoretically everything's coming from the same clock source, but it's going through DCMs and PLLs inside the FPGA and the ADCs, and then I'm not sure about anything anymore.

See above, usually it has to be the other way around. OK, I can still use the sample clocks I get back from the ADCs to run the receiving parts in the FPGA, but that's 4 more clock nets, which I admit I have a lot more of in Virtex-4. I've been looking at external programmable clock sources, but up to now using the FPGA was the easiest way to do it.

... and the FPGA is as well, which is highly unlikely. In some cases they're not even on the same board. Or the FPGA runs hotter because it has some other stuff to do as well.

Yes, that's what I'm doing at the moment, but using DCMs in Virtex2 Pro to shift the fast clock from the ADCs.

Well, considering the fact that I potentially have 4 different sample clocks, I'm back at 4 DCMs and 8 clock nets, which is exactly what is needed in the current solution. And potentially I'll have to hook up 8 or even more ADCs to one FPGA, so you see where this is going.

As I said in another post: When I first read about the ISERDES, it seemed like the perfect thing: run it with the fast clock from the ADCs, hook up the sample clock to the CLKDV-input, and you're done. No DCMs neccessary, maybe a little delay-tuning here and there, that's it. And with the IO- and regional clocks available in Virtex-4, this would've worked for lots and lots of ADCs running at whatever frequencies.

The whole point of my original posting was to find out if there isn't still a way to do it like that. Obviously there are lots of more elegant ways to do it than xapp774, now that Virtex-4 is available.

But I do see that your way is probably the most elegant if all the clocks are the same. And there are cases when I need exactly that, so I'll probably be implementing it like that at least in some cases.

So, thanks a lot for your insight and this suggestion, it's really helpful!

cu, Sean

Yupp, that you would have to generate using a DCM. But the clever thing about this is that since you're running the FPGA with the sample clock from the ADC, and the DCM generates a perfectly edge-aligned /12 clock, you have perfect phase relationship between all clocks and data channels, it all fits together perfectly, regardless of the number of channels (assuming that the sample clock is the same for all channels).

cu, Sean

Sean Durkin schrieb:

They are not. They are out of phase between 330ps and 860ps at the ADC (according to the datasheet). They will be more out of phase once they arrive inside your FPGA. You will not get away without delay buffers at these data rates.

Kolja Sulimma

Simply dividing the sample clock by 12 (using a DCM) doesn't give you the boundary of the 12bit sample. You only have a one-in-twelve chance of getting it right. There is no way to deduce the sample boundary by inspecting the serial data stream.

Bob