Sorry to take so long to reply, I wanted to look at the
V4 and ADS5273 datasheets first.
-------------------
Master/Slave ISERDES
-------------------
Sean wrote:
>
>But, you were right about the IBUFDS_DIFF_OUT: Those still exist in V4,
>and *tadaaa* I just found out you can actually feed the two ISERDES in
>one IOB tile with those 2 inverted outputs.
>
OK, but can you independently invert the clock on the second
ISERDES in the same tile to accomplish what you want?
( I haven't created a test design to check this. )
Although, rather than trickery with two ISERDES, it looks like
you could just do 6 bit data with the master/slave configuration
shown on page 7 of XAPP705 (v1.2)
Then you could use the clocking scheme shown in UG070 (v1.4) p39,
with a BUFIO clocking the I/O and driving a BUFR regional clock;
the BUFR can then divide by six to get you a 2x clock.
Add a word alignment shifter, and this would get you data,
enable, and a 2x regional clock for each A/D without using
a single DCM or global clock resource.
-------------------
12 bit word sync
-------------------
Rather than attempting to have a matching global clock for
each A/D to maintain word sync, I'd try either:
- treat the word clock like a data bit, and sample it to find
the proper alignment shift ( may be only enough timing margin
to sample the word clock on one edge of the bit-rate clock )
or,
- use the built in ADS5273 sync patterns for word alignment
-------------------
Cin vs. Zout
-------------------
One thing that jumped out at me from the ADS5273 datasheet
was the output slew rate and impedance specs:
LVDS Outputs Rise/Fall Time (typ)
2.5mA 400 ps
3.5mA 300 ps
4.5mA 230 ps
6.0mA 180 ps
Differential Output Impedance
13 Kohm
If you hook such a part directly to an FPGA with 10 pF of
input capacitance, Very Bad Things will happen to your
840 Mbps data due to the input reflections off the FPGA.
Most likely, the guys doing the precision mixed signal part
intentionally decided not to absorb the reflections on-chip,
requiring you do do this externally.
For a short, well designed 100 ohm differential net, I'd
recommend starting with somthing like this:
- crank up the drive level on the ADS9753 to the mid/high range
- place a 100 ohm back termination and 3 dB differential attenuator
at the source (1)
- place a 6 dB differential attenuator at the FPGA
- use the _DT internal terminations in the FPGA
- plenty of simulation, prototyping, and real world measurements
Starting with 9 dB of intentional forward loss may be
too much, but it makes for a return loss of at least 18 dB
even with a horrible load at the far end; experimenting
with more/less drive and less/more attenuation should find
a happy medium.
Also, using differential terminations at both ends doesn't
help with any common mode crud, but adding extra parts to do
a common mode termination would also add more parasitics.
(1) Digikey, 3db, 100 ohm differential, 0404, EXB-24AB3CR8X
-------------------
A/D Clocking
-------------------
>
>> Clocking high speed A/D's with an FPGA generated clock is a very
>> bad idea, as the inherent DCM & SSO jitter will quickly render the
>> sub-ps RMS A/D aperture jitter specs useless, giving you maybe
>> a handful of effective bits worth of data at the rated A/D input
>> bandwidth.
>
>You're absolutely right, which is why I'm looking for programmable
>external clock sources at the moment. BTW, any recommendations?
>
"Sean Durkin" <smd@despammed.com> wrote in message
news:43ddc622$1@news.fhg.de...
> Bob wrote:
>> 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.
> I think we're getting confused here (I know I am) with the naming of our
> clocks. ;)
>
> Now, assuming the ADC sends out, together with the data, a fast clock of
> 420MHz, and a slow clock of 70MHz. Now what Eric calls the "sample
> clock" is the latter, which gives you the boundary of your 12bit sample.
>
> Now as I understand it, what Eric is suggesting is to feed the FPGA with
> this slow "sample clock", to have ADC and FPGA running synchonously. We
> don't use the fast clock from the ADC as bit clock, but instead use a
> DCM to multiply the sample clock, and use this perfectly edge-aligned
> (the DCM takes care of that) clock to run the ISERDES.
>
> Now assuming that you feed all ADCs with the same clock source and the
> thermal conditions etc. are the same, all sample clocks returned from
> the ADCs should be identical (maybe with a little skew because of
> different trace lengths on the PCB, but the frequencies should match),
> so you only need to do this once for all ADCs. As Eric said, one DCM and
> two clock nets, regardless of how many channels you have.
>
> cu,
> Sean
Ahhhh. Ok. TI call the faster clock "SCLK", but it actually stands for
Serial Data Clock. The slower clock is "ADCLK". I think we're on the same
page, now.
Anywho, I think he's going to have a problem using the DCM to multiply by
twelve. This would require use of the FX output which can have terrible
jitter (depending on the m/n ratio used). I would be surprised if it could
capture data reliably at 480Mbps, doing it this way.
Bob
Reply by Sean Durkin●January 30, 20062006-01-30
Brian Davis wrote:
> I was trying to point out that that capability already exists in the
> V2 derived parts, and most likely in V4 as well (esp. with the V4
> differential clock tree, I'd expect one to get inverted clocks for free
> with no local inversion skew penalty, but I haven't checked this yet).
Yes, you're right, inverted clocks should be easy to get. I'll check
that out sometime this week, once I find the time.
But, you were right about the IBUFDS_DIFF_OUT: Those still exist in V4,
and *tadaaa* I just found out you can actually feed the two ISERDES in
one IOB tile with those 2 inverted outputs. So all I need now is to
provide the ISERDES with 0/180 clocks. Not sure when I'll find the time
to check that out. Getting the clocks shouldn't be a problem, but maybe
driving the ISERDES in one IOB tile with different clocks is.
> Clocking high speed A/D's with an FPGA generated clock is a very
> bad idea, as the inherent DCM & SSO jitter will quickly render the
> sub-ps RMS A/D aperture jitter specs useless, giving you maybe
> a handful of effective bits worth of data at the rated A/D input
> bandwidth.
You're absolutely right, which is why I'm looking for programmable
external clock sources at the moment. BTW, any recommendations?
Up to now the fastest I had these ADCs running was 40MHz (the fastest
speedgrades aren't available yet), and there it did still work reliably.
But in the future this has to work for 70MHz as well, so I'll be
transitioning to "proper" clock sources.
cu,
Sean
Reply by Sean Durkin●January 30, 20062006-01-30
Kolja Sulimma schrieb am 29.01.2006 15:32:
> 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.
Yes, but as you stated earlier, THOSE are not the problem, since I have
possibilities to delay in every IOB. The calibration has to be done anyway.
What I'm trying to avoid is to introduce additional DCMs and clock nets.
Up to now, every suggestion I've heard uses at least the same amount of
DCMs and clock nets as the current solution (xapp774), which is
something I can't afford once I have 8 or even more of those ADCs hooked
up to one FPGA.
cu,
Sean
Reply by Sean Durkin●January 30, 20062006-01-30
Bob wrote:
> 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.
I think we're getting confused here (I know I am) with the naming of our
clocks. ;)
Now, assuming the ADC sends out, together with the data, a fast clock of
420MHz, and a slow clock of 70MHz. Now what Eric calls the "sample
clock" is the latter, which gives you the boundary of your 12bit sample.
Now as I understand it, what Eric is suggesting is to feed the FPGA with
this slow "sample clock", to have ADC and FPGA running synchonously. We
don't use the fast clock from the ADC as bit clock, but instead use a
DCM to multiply the sample clock, and use this perfectly edge-aligned
(the DCM takes care of that) clock to run the ISERDES.
Now assuming that you feed all ADCs with the same clock source and the
thermal conditions etc. are the same, all sample clocks returned from
the ADCs should be identical (maybe with a little skew because of
different trace lengths on the PCB, but the frequencies should match),
so you only need to do this once for all ADCs. As Eric said, one DCM and
two clock nets, regardless of how many channels you have.
cu,
Sean
Reply by Brian Davis●January 29, 20062006-01-29
Sean Durkin wrote:
>
> 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 :)
>
Once you have the DDR data reclocked successfully off the local
clock domain onto your global clock, you can use a straightforward
demux to lower the data rate as much as you'd like, generating the
lower rate clock with a DCM; those V4 phase-matched-divider widgets
could probably be used in place of a DCM for the sub-rate clock.
Your original post seemed to be looking for a method of obtaining
complementary internal output signals from only one LVDS input pin.
I was trying to point out that that capability already exists in the
V2 derived parts, and most likely in V4 as well (esp. with the V4
differential clock tree, I'd expect one to get inverted clocks for free
with no local inversion skew penalty, but I haven't checked this yet).
DDR clocking notes:
One tricky bit on V2, getting that same local clock on a global
clock network, is made easier in S3E by provision for local clock
pins to drive the global clock network; I'd expect that something
similar exists in V4.
Another DDR clock alternative in V2 is to use an IBUFGDS_DIFF_OUT
to directly drive your 0/180 DDR clocks without getting a DCM involved.
A/D Clocking notes:
You seem to be saying in another post that you source variable rate
A/D sample clocks directly from the FPGA; perhaps I misunderstood
that post.
Clocking high speed A/D's with an FPGA generated clock is a very
bad idea, as the inherent DCM & SSO jitter will quickly render the
sub-ps RMS A/D aperture jitter specs useless, giving you maybe
a handful of effective bits worth of data at the rated A/D input
bandwidth.
Brian
Reply by Bob●January 29, 20062006-01-29
"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
Reply by Kolja Sulimma●January 29, 20062006-01-29
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
Reply by Sean Durkin●January 29, 20062006-01-29
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
Reply by Sean Durkin●January 29, 20062006-01-29
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