[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] High speed serial comms links



Hi Jamie

That would be great except that the data rate is twice the maximum clock
rate.
The clock needs to be transmitted as the reciever clock is not synchronised.
The method of reception needs to be a series of demultiplexing the signal
down using the transmitter clock, frame/byte synchronisation and then
insertion into a DualPort FIFO memory that can operate with different
clocks at each side. The average data rate must be slightly slower than
the reciever capability to account for differences in clock speeds
between the boards.

_=_=_=_=_=_=_=_=_=_=_=_=_=_=_    -- Clock (266Mhz)
_____====_=__=___==__=_==_=__    -- Data
_____|________|________|________|    -- Frame

how to put this down a single twisted pair line / two pairs
two pairs should ideally be used to send 2 bits at a time??

thanks
Carl


> Hi Carl,
>
> Not sure if this is what you are after, but I think you want to send a
> serial stream of data
> and have the receiver receive the data with no clock being sent?  If so,
> something like the AX.25 protocol would work for this.  It is a pretty
> simple protocol that
> declares the beginning of a dataframe by sending the line from 1 to 0.
The
> receiver must listen
> at least 3X the "clock" rate so that it can synchronize well with the
> transmitter  at the 1 to 0 transition.
> Only 1 to 0 transitions that have x number of 1's in a row (ie. 1111110)
are
> considered valid startframes.
> This allows for 1 to 0 transitions in your data up to x 1's (ie. six 1's)
If
> your data has more than six 1's, then
> bit stuffing is used which means a 0 is inserted in the transmitted data
to
> make sure there are never six 1's in a row.
> This zero is detected by the receiver and removed.
> I have some c code I wrote that implements this over a half duplex radio
> link if you are interested.
>
> Not sure at all if this is what you are after - let me know what you are
> doing if this isn't it!  :)
>
> best regards,
> Jamie
>
>
>
>
> ----- Original Message -----
> From: Carl van Schaik <carl@openfuel.com>
> To: <cores@opencores.org>
> Sent: Monday, August 06, 2001 12:28 AM
> Subject: Re: [oc] High speed serial comms links
>
>
> > Hi
> >
> > Sorry, I should have said that this link is being implemented on a
> > Virtex-E 200,000 gate device which has LVDS I/O but no
> > hardware CDR (Clock Data Recovery), so a synthesisable
> > link layer is what I'm after. (Probably will have to be
> > specific to the Virtex-E devices)
> >
> > regards
> > Carl
> >
> > > Xilinx Virtex-II chips support LVDS directly and AMD hypertransport
> > protocol as well.
> > > Are you looking for a more general (chipwise) solution?
> > >
> > > ----- Original Message -----
> > > From: "Carl van Schaik" <carl@openfuel.com>
> > > To: <cores@opencores.org>
> > > Sent: Sunday, August 05, 2001 11:17 AM
> > > Subject: [oc] High speed serial comms links
> > >
> > >
> > > > 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
> > >
> > > --
> > > To unsubscribe from cores mailing list please visit
> > http://www.opencores.org/mailinglists.shtml
> > >
> >
> > --
> > To unsubscribe from cores mailing list please visit
> http://www.opencores.org/mailinglists.shtml
>
> --
> To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

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