Data Decoding at 10 Gbit/s

[Martin Schimmelpfennig]

Hi,

I would like to design a 16 channel SERDES ASIC in 0.13ľm running at 10
Gbit/s per channel. For transmission a standard 8B/10B is to be applied. My
concern is now how to achieve real-time decoding of the 8B/10B transmission
code at 10 Gbit/s with that technology? Can that easily be achieved? What is
state-of-the-art? As far as I know the 8B/10B decoding cannot be down by a
simple lookup table because the corresponding code words depend on the
running disparity of the previous transmitted data and there is no simple
1-on-1 mapping.
Since the 8B/10B coding is a self-synchronizing (?) code (i.e. the clock can
be retrieved from the transmitted data) I would have to use a kind of clock
recovery at my SERDES input. Another question would be if a PLL at the input
is advisable or even feasible at data rates of 10 Gbit/s.

I would be very thankful if some of you could give me a hint.

Best Regards

Martin

 

[PeteS]

Martin Schimmelpfennig wrote:

Hi,


I would like to design a 16 channel SERDES ASIC in 0.13ľm running at 10
Gbit/s per channel.
You are not the only one. I know Mellanox (http://www.mellanox.com/) is

working on it to support the InfiniBand (http://www.ibta.org) QDR rate
(10Gb/s per pair). Others are working on it for higher speed versions
of PCI express, at the least.

For transmission a standard 8B/10B is to be applied.

As it is for virtually all other flavours of data transmission at these
rates nowadays (Ethernet, Fibre channel, InfiniBand, PCI Express)

My

concern is now how to achieve real-time decoding of the 8B/10B transmission
code at 10 Gbit/s with that technology? Can that easily be achieved?

Others are certainly achieving it at 5Gb/s

What is

state-of-the-art? As far as I know the 8B/10B decoding cannot be down by a
simple lookup table because the corresponding code words depend on the
running disparity of the previous transmitted data and there is no simple
1-on-1 mapping.

You don't seem to have a firm grasp of 8B/10B encoding. I would
strongly suggest you look that up first. Note that the running
disparity enables a serdes to detect which 'sense' the input signal has
been connected and automatically switch the 'p' and 'n' inputs
appropriately.

Since the 8B/10B coding is a self-synchronizing (?) code (i.e. the clock can
be retrieved from the transmitted data)

Inherently so, and designed specifically with that in mind. Maximum run
length = 5. Strictly speaking, that makes the system 'source
synchronous'

I would have to use a kind of clock recovery at my SERDES input.

Of course. This is a well understood technology (although not
necessarily at 10Gb/s)

Another question would be if a PLL at the input

is advisable or even feasible at data rates of 10 Gbit/s.

There are PLLs operating well beyond this in a number of areas

I would be very thankful if some of you could give me a hint.

Get the background on 8B/10B encoding (part of the IEEE802.x specs),
clock recovery techniques (google is your friend) and the latest high
speed existing serdes devices. Without that background, I fear you will
have a frustrating time.

Best Regards

Martin

Cheers

PeteS

 

[MaWin]

"Martin Schimmelpfennig" <quinn_the_esquimo@freenet.de> schrieb im Newsbeitrag
news:dobhcn$kpq$1@mamenchi.zrz.TU-Berlin.DE...

Hi,

Is it possible to use only one newsgroup instead of a
crosspost without followup to 7 ?

I would like to design a 16 channel SERDES ASIC in 0.13ľm running at 10 Gbit/s
per channel.

Really ? 10Gbit/channel? I know only of 3.2GBit technologoy,
who's manufacturing the 10GBit device ?

For transmission a standard 8B/10B is to be applied.

Google for "8B/10B" and read the first hit from the Siemens Communication
Lexicon and you understand that at least workers of Siemens Communication
Group do not have the slighest clue about 8B/10B, but THINK that they know
everything.

My concern is now how to achieve real-time decoding

State machine, depending on your output (8 bit parallel ?) clocking in
single bits and decode using minimized terms (PLA) instead of table ROM.

Since the 8B/10B coding is a self-synchronizing (?) code (i.e. the clock can
be retrieved from the transmitted data) I would have to use a kind of clock
recovery at my SERDES input. Another question would be if a PLL at the input
is advisable or even feasible at data rates of 10 Gbit/s.

Only PLL, clock of chip must be derived from clock of input.

Synchronizing (digial) is not used for bit clock signal, but for word clock.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Falk Brunner]

MaWin schrieb:

Hi,



Is it possible to use only one newsgroup instead of a
crosspost without followup to 7 ?

Indeed!

I would like to design a 16 channel SERDES ASIC in 0.13ľm running at 10 Gbit/s
per channel.


Really ? 10Gbit/channel? I know only of 3.2GBit technologoy,
who's manufacturing the 10GBit device ?

Vitesse, TDK etc.

For transmission a standard 8B/10B is to be applied.


Google for "8B/10B" and read the first hit from the Siemens Communication
Lexicon and you understand that at least workers of Siemens Communication
Group do not have the slighest clue about 8B/10B, but THINK that they know
everything.

At 10 Gbit/s you dont want to use 8B10B, since it wastes 20% of
bandwidth for coding overhead. Most (all?) 10G systems use 64B/66B
instead. Uses only 3% overhead.

My concern is now how to achieve real-time decoding


State machine, depending on your output (8 bit parallel ?) clocking in
single bits and decode using minimized terms (PLA) instead of table ROM.

Sure. But even 8bit is a little bit too fast (1.2 GHz). BEtter go for 16
oder more bit, this get your clock rate down to feasable levels.
The price for slower clocks is silicon area.

Since the 8B/10B coding is a self-synchronizing (?) code (i.e. the clock can
be retrieved from the transmitted data) I would have to use a kind of clock
recovery at my SERDES input. Another question would be if a PLL at the input
is advisable or even feasible at data rates of 10 Gbit/s.

????
You just need one (maybe even two, RX and TX)

Have a look at the VSC8476 from vitesse, this might give you an idea
what you are trying to do.

Regards
Falk

 

[Kai Harrekilde-Petersen]

"Martin Schimmelpfennig" <quinn_the_esquimo@freenet.de> writes:

Hi,

I would like to design a 16 channel SERDES ASIC in 0.13ľm running at 10
Gbit/s per channel.

Vitesse is certainly achieving >10Gbit/s in 0.13um - ISTR that they
also have done 12.5Gbit/s. They have chips doing 10Gbit/s SERDES for
at least 2 years now, but as far as I remember, this is only 1-4
channels per chip. YMMV.

For transmission a standard 8B/10B is to be applied. My
concern is now how to achieve real-time decoding of the 8B/10B transmission
code at 10 Gbit/s with that technology? Can that easily be achieved?

It's only a 1GHz encoding/decoding rate (parallel datarate), so I
don't see why it should be a problem. Again, Some/all of Vitesse
10Gbit/s chips implement 8B/10B.

Disclaimer: I don't work Vitesse (any more).


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[JosephKK]

Martin Schimmelpfennig wrote:

Hi,

I would like to design a 16 channel SERDES ASIC in 0.13ľm running at 10
Gbit/s per channel. For transmission a standard 8B/10B is to be applied.
My concern is now how to achieve real-time decoding of the 8B/10B
transmission code at 10 Gbit/s with that technology? Can that easily be
achieved? What is state-of-the-art? As far as I know the 8B/10B decoding
cannot be down by a simple lookup table because the corresponding code
words depend on the running disparity of the previous transmitted data and
there is no simple 1-on-1 mapping.
Since the 8B/10B coding is a self-synchronizing (?) code (i.e. the clock
can be retrieved from the transmitted data) I would have to use a kind of
clock recovery at my SERDES input. Another question would be if a PLL at
the input is advisable or even feasible at data rates of 10 Gbit/s.

I would be very thankful if some of you could give me a hint.

Best Regards

Martin


Congratulations PeteS and Kai, you told this willfully ignorant SOB graduate

student trying to get you to do his schoolwork for him to do the work
himself. Better still you gave him good paces to learn what what he should
have found out for him self if he could been bothered to google a bit.
--
JosephKK