Virtex-4 ISERDES and ADS527X ADCs
Sean Durkin
I'm having a litte problem trying to understand some things regarding
the ISERDES in Virtex-4-IOs.
Here's what I want to do:
We use a lot of ADS527X-ADCs from TI. Those parts output 12bit/sample
via LVDS-DDR-links running at up to 480Mbit/s. Up to now, using Virtex-2
Pro, getting this into the FPGA is a little tricky (see xapp774). In
short, the current way is to feed the serial data into two carefully
hand-placed 6-bit-shift-registers that are clocked with 180-degrees
shifted clocks, and read those shift registers out in parallel once all
12 bits have arrived. Takes quite a bit of hand-placement, you have to
be careful which I/Os you use to connect the clocks and data, you need
DCMs to do phase-shifting, etc. Kinf of tricky, but it works.
Now we're about to switch to Virtex-4, and at first glance the ISERDES
seems like the perfect thing to make it all easier. But the more I think
about it the more problems arise.
First, since all signals coming from the ADCs are differential signals,
I need to instantiate an IBUFDS for each one. Plus I need to assign the
LVDS_25-IOSTANDARD-attribute to it, as well as the DIFFTM-attribute,
since there are usually no external termination resistors on the board
to save space.
The signal I get as output from the IBUFDS I can feed into an ISERDES.
Since one ISERDES can only give me 6 bits in parallel, I need to use two
ISERDES in Master-/Slave-mode, but then they can only give me 10bits
instead of the 12 I actually get from the ADCs. So it's not going to
work that way.
Someone here posted awhile back that they would simply feed the
_n-signal in one ISERDES, the _p in another, and have them run at clocks
shifted by 180 degrees. That way, each ISERDES would give me one
6-bit-nibble of my 12-bit data word, one the "even" bits, one the "odd"
bits of my data word. Sounds pretty easy to do.
But that would mean using the two signals from a differential pair as
two separate single-ended signals. Kinda misses the whole point of using
differential signaling in the first place...
The way I see it there are several problems with this approach:
1. If I don't use an IBUFDS for the differential input signal, I can't
turn on the differential termination, plus I can't set the I/O-standard
to LVDS_25 (the tools simply ignore those settings for single-ended
I/Os). Again, kind of takes away the advantage of using LVDS in the
first place. If I do instantiate an IBUFDS to at least get termination
and set the IO-standard, I can't access the _n and _p-signals to supply
two separate ISERDES anymore, and I can't feed the IBUFDS-output-signal
to two separate ISERDES either.
2. If I use the two signals of a differential pair as two separate
single-ended signals, what I/O standard do I assign to them? It would
have to be something that can cope with the tiny little swing of an
LVDS-signal. Looking at the datasheet, each line of a differential pair
has a worst-case V(high) = 1.265V and V(low) = 1.140V, so I'd have to
use LVCMOS_15 or something like that and pray that this works.
3. To control the ADCs (reset, powerdown, serial interface for enabling
test-modes etc.), I need an I/O-voltage of 3.3V. Normally it is not a
problem to use LVDS_25-INPUTS in a bank that otherwise uses 3.3V-I/Os,
since the differential input buffers are powered by Vccaux, which is
availabe in all banks (at least that's how it is in Virtex2 Pro).
But if I have to use e.g. LVCMOS_15 for the LVDS-inputs, I need to power
the entire bank with 1.5V. Not only would that mean I need to supply yet
ANOTHER voltage on the board (one that I wouldn't need otherwise), but
it would also mean I'd waste most of an entire bank of I/Os I could've
otherwise used to control the ADCs and do some other little things. I/Os
are precious as well as the board space I'd need for an additional
regulator.
So I'm not really comfortable with this approach...
The way I see it the only way to do it "properly" is doing it the way it
was done in xapp774, which will take some effort "porting" it to Virtex-4.
Is there some more "elegant" way to do it? I'd hate to just not use the
ISERDES, those things are way to kewl to waste... :)
Any suggestions?
cu,
Sean
Brian Davis
> We use a lot of ADS527X-ADCs from TI. Those parts output 12bit/sample
> via LVDS-DDR-links running at up to 480Mbit/s. Up to now, using Virtex-2
> Pro, getting this into the FPGA is a little tricky (see xapp774). In
> short, the current way is to feed the serial data into two carefully
> hand-placed 6-bit-shift-registers that are clocked with 180-degrees
> shifted clocks, and read those shift registers out in parallel once all
> 12 bits have arrived. Takes quite a bit of hand-placement, you have to
> be careful which I/Os you use to connect the clocks and data, you need
> DCMs to do phase-shifting, etc. Kinf of tricky, but it works.
(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
Symon
"Brian Davis" <brim...@aol.com> wrote in message
news:1138387310.3...@z14g2000cwz.googlegroups.com...
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.
johnp
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
Brian Davis
>
> I don't see any documentation on the DIFF_OUT buffers you mention.
> Do you have any info on them or pointers to doc?
>
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
Kolja Sulimma
> The signal I get as output from the IBUFDS I can feed into an ISERDES.
> Since one ISERDES can only give me 6 bits in parallel, I need to use two
> ISERDES in Master-/Slave-mode, but then they can only give me 10bits
> instead of the 12 I actually get from the ADCs. So it's not going to
> work that way.
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
Erik Widding
Sean Durkin wrote:
>
> The signal I get as output from the IBUFDS I can feed into an ISERDES.
> Since one ISERDES can only give me 6 bits in parallel, I need to use two
> ISERDES in Master-/Slave-mode, but then they can only give me 10bits
> instead of the 12 I actually get from the ADCs. So it's not going to
> work that way.
>
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.
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
Brian Davis
>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.
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
Sean Durkin
> 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.
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
Sean Durkin
> 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.
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.
> 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.
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.
> At 480 Mbps, I'd advise sticking with LVDS & DT terminators.
That's what I thought.
cu,
Sean
Sean Durkin
> 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.
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
Kolja Sulimma
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
Kolja Sulimma
> 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
Erik Widding
> 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.
Bob
"Erik Widding" <wid...@birger.com> wrote in message
news:1138508679....@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-
Sean Durkin
> For those ADCs it is not necessary to route both the full clock and the
> 1/6 clock to the FPGA.
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
Sean Durkin
> No need for 1/3 divide. No need to use more than one clock coming
> back from the ADCs either, the sample clock.
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
Sean Durkin
> You still need the /12 clock, from the ADC, in order to locate each sample
> boundary, right?
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
Kolja Sulimma
> And since the clocks you get
> from the ADCs are perfectly edge-aligned,
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
Bob
"Sean Durkin" <s...@despammed.com> wrote in message
news:443kkj...@individual.net...
> 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.
Bob
Brian Davis
>
> 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 :)
>
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
Sean Durkin
> 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.
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
Sean Durkin
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
Sean Durkin
> 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).
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
Bob
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
Brian Davis
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?
>
I'd need more info about your application ( input signal freq/BW,
why the need for varying A/D clocks ) to make a definite assessment,
but I'd advise staying far away from any programmable PLL based
clock sources.
To avoid compromising the input aperture specs of the ADS5273
at the rated input bandwidth, I'd probably use a good/great
crystal oscillator, with a passive ( power divider + baluns )
or {P}ECL ('EL14) clock distribution network if multiple A/D's
are needed.
A low jitter buffer/divider intended for clocking fast A/D's,
something like the recent AD9514, may work fine, but I haven't
tested any of those parts.
Here are some online references for A/D clock jitter specs, and
conversions between clock jitter and Effective_Bits(Input_Freq):
Analog Devices AN-501
<http://www.analog.com/UploadedFiles/Application_Notes/547373956522730668848977365163734AN501.pdf>
Analog Devices AN-756
<http://www.analog.com/UploadedFiles/Application_Notes/534504114752208671024345AN_756_0.pdf>
Analog Devices AN-741
http://www.analog.com/UploadedFiles/Application_Notes/54506699244016AN741_0.pdf
Analog Devices (Radio 101)
http://www.analog.com/UploadedFiles/Technical_Articles/480501640radio101.pdf
RF Design
http://rfdesign.com/images/archive/0802Goldberg26.pdf
have fun,
Brian