Xilinx Spartan-3

[acetylc...@gmail.com]

Hello! I have an application with a Spartan-3 mainboard and 3
spartan-3-based daughterboards -- we had planned on connecting the
daughterboards to the mainboard via SATA connectors, and running a 300
Mbps LVDS link in each direction (M->D and D->M). We had hoped that the
daughterboards could do clock-recovery of the incoming (M->D) 300 Mbps
stream, and then (since effectively the whole system would be
synchronous) this would eliminate the need for explicit clock-recovery
on the mainboard (which would be receiving the 3 LVDS streams from the
daughterboard.

However, Xilinx engineers told me yesterday that the Spartan-3s have no
built-in CDR hardware (which is required to make XAPP250 "work"). So:

1. Can anyone recommend any external chips to do this sort of CDR? I've
seen clock and data retiming chips available from Maxim, etc. but they
all look targeted at optical applications.

2. If we run the M->D link at 75 Mbps, recover that clock, use it to
drive the daughterboard FPGA, and then (using a DCM) clock-quadruple it
to 300 MHz (and use that to send out the 8b/10b data on the D->M
differential pair) can I assume that the phase relationship between the
D and the M FPGA will be constant (assuming the master FPGA is also
running a 4x clock)?

I'll happily take any other suggestions -- I wish I could just feed the
8b/10b stream into the DCM, but I guess life isn't that simple :)

Thanks,

Eric

[Austin Lesea]

a-nerd,

Have you considered the use of the dynamic phaseshift feature of the DCM?

By having a synchronous system, one can use the clock, shifting its
phase, until the data received is in the center of the "eye."

Austin

[acetylc...@gmail.com]

Austin,
Thanks for the quick reply; I guess my question is then "how do I
get a synchronous system" using this configuration. XAPP250 ("Clock and
Data recovery with coded data streams") is listed under the Spartan-3
Application Notes, but as " There is no CDR in Spartan-3", I was hoping
to get suggestions for external recovery options.
Are there any reference designs or recommendations for using the
dynamic phaseshift features of the DCM to adjust for phase offset in
real-time?
On that note, are there any reference-designs or examples of the
Spartan-3 doing > 300 Mbps LVDS serial IO? I'm a bit worried about the
timing of the IOBs, even though I see the 622 Mbps rate all over
xilinx.com in conjunction with the S-3.

Thanks again for making such a great product,

Eric

[Peter Alfke]

Why do you even think of clock recovery, which has complicated
implications, like 8B10B encoding.
Just buid the whole system as a straightforward synchronous system with
one common clock. Then analyze the undesired clocking and data
propagation delays, and compensate for them by using the dynamic phase
shift option in the DCMs, effectively adjusting various clocks with a
granularity of 1/256 clock period, or 50 ps, whichever is greater.
That's what Austin suggested, I am just embellishing his explanation.
Peter

[Austin Lesea]

http://www.xilinx.com/bvdocs/appnotes/xapp774.pdf

http://www.xilinx.com/bvdocs/appnotes/xapp806.pdf

http://www.xilinx.com/bvdocs/appnotes/xapp764.pdf

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=19815

Should get you started.

Perhaps I do not understand the application: is there no clock at all,
just data from point A to point B?

If so, you will need some sort of PLL to recover the clock.

Xapp 224, 250, and 704 may be useful.

Austin

[acetylc...@gmail.com]

Our application is we have one main board and 3 daughter boards, up to
1m away, and we are constrained to essentially using seven wires to
connect each daughter board to the main board. For this sort of
distance, we wanted to go LVDS in both directions, but to keep
everything synchronous, that would require that the B->D lvds pair also
contain the clock; clock recovery was going to let us still keep
everything synchronous. We knew we'd need a PLL :)

We've decided to go with a single-ended clock/data pair on one set of
wires and a (clock-multiplied) LVDS pair for the receiver (from
daughterboard -> mainboard), like Austin suggested. But Austin, I'm
really curious, how does xapp250 help with a spartan-3 device?

Thanks!

[Austin Lesea]

OK,

Xapp250 can also be done in S3 as there is nothing specific in there
that isn't in S3.

The idea that you put all the digital stuff to do CDR in the FPGA, and
then have the LPF and VCO off chip is not new.

One lane that recovers clock, along with using the variable phase shift,
could then be used to time all the other lanes.

Austin

[sulimma]

acetylc...@gmail.com schrieb:

> Our application is we have one main board and 3 daughter boards, up to
> 1m away, and we are constrained to essentially using seven wires to
> connect each daughter board to the main board. For this sort of
> distance, we wanted to go LVDS in both directions, but to keep
> everything synchronous, that would require that the B->D lvds pair also
> contain the clock; clock recovery was going to let us still keep
> everything synchronous. We knew we'd need a PLL :)
>
> We've decided to go with a single-ended clock/data pair on one set of
> wires and a (clock-multiplied) LVDS pair for the receiver (from
> daughterboard -> mainboard),

Hmm. Seven wires. That is
- GND
- LVDS pair data D->M
- LVDS pair data M->D
- LVDS pair clk M->D

That's enough for a synchronous system. Somehow I do not see your
problem.
You can use one clock for data transfer in both directions.

Kolja Sulimma

[acetylc...@gmail.com]

Our configuration is:
GND
LVDS pair M->D
GND
LVDS pair D->M
GND

The cables we are using only have the wires 2&3 and 5&6 as "pairs"
internally.

If we break one of those pairs and run a (say) 70 MHz clock on the +
wire and a 70 MHz data stream on the -, and then just feed that clock
directly into the DCM, I think this could work... I just worry about
the SI problems with running a 70 MHz clock over 1m of cable...

Eric
Thanks,
...Eric

[Brian Davis]

acetylc...@gmail.com wrote:
>
> If we break one of those pairs and run a (say) 70 MHz clock
> on the + wire and a 70 MHz data stream on the -
>

Keep it differential.

>
>I just worry about the SI problems with running a 70 MHz
> clock over 1m of cable...
>

Offhand, for 70 Mhz out and 280 Mbps back, I'd run the
drivers as LVDS_EXT, layout for a 3dB differential attenuator
at each end of the link (Note 1), use the LVDS_25_DCI on-chip
terminations at the receivers, and simulate & prototype before
relying on this advice.

>
>I'll happily take any other suggestions
>

And now for something completely different...

If you can live with 70 Mbps of outgoing data on a
cable with bandwidth to spare, try this for a clock
recovery scheme (untested, designed-as-I-type-this,
probably been done better before):

Phase modulate your outgoing 70 Mhz clock's falling
edges to encode the data, using a 140 MHz master clock
and DDR output regs (Note 2):

for a zero, send -___

for a one, send ---_

So 10110 would be ---_-___---_---_-___

Which has the rising edges all neatly lined up with
those of the original source clock.

At the receiving end, divide this by two (Note 3)
with a rising edge FF to get an 35 Mhz clock, which
now has no duty cycle modulation.

Use the daughtercard DCMs to multiply this 35 MHz
clock back to 70 Mhz to re-clock the input data
( a fixed 180 or 270 phase shift should do, this is
a forwarded clock so cable prop delay doesn't matter).

Also use the DCMs to generate a daughtercard 140 MHz to
use as a DDR output clock for your outgoing 280 Mbps data.

Back on the motherboard, you'll need a dynamic or
cable-length-calibrated fixed phase shift of the master
140 Mhz to re-clock the data, as a two meter round trip
cable delay is longer than a bit period at 280 Mbps.

have fun,
Brian

(Note 1) Digikey, 3db 100 ohm diff. 0404, EXB-24AB3CR8X

(Note 2) using a good differential osc. to directly
clock the output DDR register, without using a DCM,
will avoid cascading two DCMs in the overall link.
SDR with 280 MHz clock or DDR with 140 Mhz clock.

(Note 3) the DCMs have an input divider, which may
be rising edge triggered

[Alvin Andries]

"Brian Davis" <brim...@aol.com> wrote in message
news:1127441657....@g47g2000cwa.googlegroups.com...

Hi,

Normally, you houldn't neeed the divide by 2 and cable stub: just use the
fact that DCMs align to the rising edge and use their CLK180 to clock your
data in.

Regards,
Alvin.

[Brian Davis]

Alvin,

>
> Normally, you houldn't neeed the divide by 2 and cable stub: just use the
> fact that DCMs align to the rising edge and use their CLK180 to clock your
> data in.

Without the divide by two to strip the phase modulation, I think the
duty cycle variation might drive the DCM's batty, as it's well outside
the allowed DCM input clock duty cycle and cycle-cycle jitter specs.

Brian