"Brian Davis" <brimdavis@aol.com> wrote in message
news:1127441657.143241.31760@g47g2000cwa.googlegroups.com...
> acetylcholinerd@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
>

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.

acetylcholinerd@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

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

acetylcholinerd@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

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@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!
>

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!

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

acetylcholinerd@gmail.com wrote:

> 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

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