Prev: modelsim simulation problem
Next: Small C Compiler for Picoblaze
From: acetylcholinerd@gmail.com on 21 Sep 2005 18:15
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!

From: Austin Lesea on 21 Sep 2005 18:34
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

acetylcholinerd(a)gmail.com wrote:

> 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!
>
From: sulimma on 22 Sep 2005 06:56

acetylcholinerd(a)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

From: acetylcholinerd@gmail.com on 22 Sep 2005 09:34
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

From: Brian Davis on 22 Sep 2005 22:14
acetylcholinerd(a)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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: modelsim simulation problem
Next: Small C Compiler for Picoblaze