Xilinx Spartan-3

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

Aust> Hello! I have an application with a Spartan-3 mainboard and 3

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

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

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.

Aust> Austin,

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!

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.

Aust> Our application is we have one main board and 3 daughter boards, up to

snipped-for-privacy@gmail.com schrieb:

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

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

Keep it differential.

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.

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

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.

Alvin,

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