Re: [oc] High speed serial comms links

["Carl van Schaik" <carl@openfuel.com>]

Hi

After some more investigation, in order to do high speed LVDS serial
comms, you basically need to write the whole thing in a schematic
and manually route or make placement rules for the FPGA that
you are targeting.
I tried to instantiate what Xilinx had done in schematic language in VHDL
and I got horible results. (clocking on both edges of a 266MHz signal
is not pretty.)

As for a proposed protocol I have:

(System(base) clock = 66.67MHz, Internal generated clocks = 133.3MHz,
266.7MHz)

Use Clock-Frame encoding over two channels.

Data is sent 24bits wide and divided into 4bit blocks:

Frame character = "1111"
All data is send in 3bit sub blocks prefixed with a '0'
ie "0DDD"   - 'D' = data bit

so a frame is"
"11110DDD0DDD0DDD0DDD0DDD0DDD0DDD0DDD"

a frame is detected by the reception of "1111" because the
protocol gaurentees that no combination of data can produce
this sequence other than if errors are present.

Recieving data is more problematic:
all reception is performed with the clock recovered from the data/frame.

The demultiplexer goes

1 x 533Mb/s stream input
dual edge demultiplexing at (266MHz)
    \/
2 x 266Mb/s streams
dual edge demultplexing at (with 0 and 90 degree phase clocks at 133MHz)
    \/
4 x 133Mb/s streams
dual edge demultplexing at (with 0 and 90 degree phase clocks at 133MHz)
   \/
8 x 66.7Mb/s streams

So we get 8 bits of data every system clock

We need a recieve buffer of (9+2)*4 bits (48 bits)

Each base clock tick, we shift the buffer to the left 8 bits and add the new
8-bit block to the start.

A parallel set of 8 decoders scans the top 11 bits for the frame character.

ie: recieve buffer
001001111010101110111011101110111011101000000000
1111____________________________________________    AND = 0 shift = 0
_1111___________________________________________    AND = 0 shift = 1
__1111__________________________________________    AND = 0 shift = 2
___1111_________________________________________    AND = 0 shift = 3
____1111________________________________________    AND = 0 shift = 4
_____1111_______________________________________    AND = 1 shift = 5
(match)
______1111______________________________________    AND = 0 shift = 6
_______1111_____________________________________    AND = 0 shift = 7

on a match by any decoder, the buffer is latched to a secondary buffer along
with which
decoder matched.
On the secondary buffer can then be barrel shifed acording to which
decoder matched. This shifted data is now aligned, and the data
can be verified by checking the "Space" bits in between every three data
bits.
The data can be contatenated back into a single 24bit value and passed
through a fifo which performs clock domain translation.

The shifting, decoding and insertion into the FIFO must take 4 or less
base clock cycles as the next frame appears on average every 4.5
base clock cycles.

what do you think?

regards
Carl

> Carl,
> A simple way embed clock and data is to use data and strobe technique
> similar to 1394a.  data is xor'ed with clock to generate a strobe
> signal.  It still requires 2 lines, however the effective bandwidth is
> reduced allowing for longer cable lengths with less crosstalk.
>
> justin
>
> Carl van Schaik wrote:
> >
> > Hi
> >
> > I have a board design with 4 LVDS transmit and 4LVDS recieve pairs and
I'm
> > looking to
> > get a high speed comms system to run across it.
> >
> > I want to use 2TX and 2RX lines, I have two RJ45 connectors
> > with 2TX and 2RX pairs each.
> >
> > I have already tested the recievers and transmitters by sending a 266MHz
> > clock
> > (533MBits/s theoretical max data rate) over
> > a piece of CAT-5 cable and verified its reception.
> > I now want to design a high speed serializer/deserializer over 2 LVDS
> > channels (single direction)
> >
> > I'm a bit at a loss as to the best way to do this...
> >
> > Sending Clock and Frame data requires two channels alone in synchronous
> > comms.
> >
> > I'll be wanting a way to embedd the clock, data and frame over the 2
signals
> > in a way
> > to maximise the bandwidth.
> > The comms will be eventually implmented between two separate boards that
> > don't have
> > synchronised clocks so the design must cater for this.
> >
> > any input would be great.
> >
> > Hey, if it works out, it could become anouther opencores core.
> >
> > thanks
> > Carl van Schaik
> > --
> > OpenFuel Pty Ltd.
> >
> > --
> > To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
>
> --
> Justin Gaither                           Phone: 512-306-7292  x529
> Xilinx, Communications Technology Div.   Fax:   512-306-7293
> 500 N. Capital of TX Hwy.
> Bldg 3                         email: justin.gaither@xilinx.com
> Austin, TX 78746               WWW:   www.rocketchips.com
>                                       www.xilinx.com

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml