Virtex-4 ISERDES and ADS527X ADCs

Erik Widding wrote:
> 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 <= ISERDES_out(5 downto 0);
>    end if;
> 
>    if ( rising_edge( sample_clock ) ) then
>       sample <= left && ISERDES_out(5 downto 0);
>    end if;
> 
> Sample clock needs to be properly phased to the ISERDES output, and a
> timing constraint with 1/2 the period of sample_clock is placed between
> ISERDES_out and the two destination registers.  The tools will take it
> from here.
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 ISERDES is to save on clock nets, DCMs etc., and simply use what I'm
> supplied with.

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:

> 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.

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

Sean Durkin wrote:
> 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.

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

"Erik Widding" <widding@birger.com> wrote in message 
news:1138508679.802556.42560@g14g2000cwa.googlegroups.com...
> Sean Durkin wrote:
>> 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.
>
> 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.
>

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

Bob

-snipped the rest-

Kolja Sulimma schrieb:
> For those ADCs it is not necessary to route both the full clock and the
> 1/6 clock to the FPGA.
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:
> No need for 1/3 divide.  No need to use more than one clock coming
> back from the ADCs either, the sample clock.
Ah, OK. I thought the ISERDES outputs were always registered with CLKDV.
I just "found" the combinatorial output. :)

> 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).
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.

> 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. 
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.

> 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.
... 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.

> 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.
Yes, that's what I'm doing at the moment, but using DCMs in Virtex2 Pro
to shift the fast clock from the ADCs.

> 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.
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

Bob wrote:
> You still need the /12 clock, from the ADC, in order to locate each sample 
> boundary, right?
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:
> And since the clocks you get
> from the ADCs are perfectly edge-aligned,
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

"Sean Durkin" <smd@despammed.com> wrote in message 
news:443kkjF6j7sU1@individual.net...
> Bob wrote:

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

> 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

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