Doubt about SERDES

[pinku]

Hello Groups,

I have a 1Gbps SERDES output from the Network processor. But as i have
2 SERDES signal coming from the back plane, depending of SEL line i
have to connect one of the SERDES to network processor. So i am using
FPGA to interface this, which takes a SERDES input and I have FIFO for
transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again
connected to another SERDES which in turn connect to the Backplane. So
i need 4 SERDES for implementing it. Will this intermediate Logic
create for end to end SERDES data transfer ? Is there any other way of
implementing this logic? I am planning to use Stratix GX FPGA.

Please let me know your suggestion,
waiting for your reply,
Kumar

 

[Rob]

Stratix has fast fabric on two sides of the chip for handling the SERDES
interface. The internal logic fabric can NOT handle these high serialized
data rates. One must de-serialize the data, do whatever logic is necessary,
and send it through a SERDES transmitter on the other side of the FPGA.

Altera provides these SERDES transmit and receive functions within their
Mega Wizard tool box. These packaged functions take care of all of the
timing needed to either receive or transmit the high speed serial data.

It sounds like you have 2 SERDES channels coming in and one going out; and
you need to select which input gets routed to the output--the FPGA is the
right solution for his situation. If the input and output SERDES channels
have the same make up (lanes and bits / lane) and there is nothing you have
to do with the data, then the design is fairly staright forward.
Deserialize both of the input SERDES channels (using the MegaWizard
function) into a mux; and then connect the output of the mux to the input
of the SERDES transmitter (MegaWizard function).

Take care,
Rob

 

[Chris Jones]

Hello Groups,

I have a 1Gbps SERDES output from the Network processor. But as i have
2 SERDES signal coming from the back plane, depending of SEL line i
have to connect one of the SERDES to network processor. So i am using
FPGA to interface this, which takes a SERDES input and I have FIFO for
transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again
connected to another SERDES which in turn connect to the Backplane. So
i need 4 SERDES for implementing it. Will this intermediate Logic
create for end to end SERDES data transfer ? Is there any other way of
implementing this logic? I am planning to use Stratix GX FPGA.

Please let me know your suggestion,
waiting for your reply,
Kumar

Perhaps this is a silly response (since I don't know the timing of your
data, for example whether you need to be able to switch data sources
without losing any words during the switching), but would it be possible to
just multiplex the serial data?

For example, could you use two of these:
http://www.analog.com/en/prod/0,,768_835_ADG3243,00.html
or something similar?

Chris

 

[KJ]

Altera provides these SERDES transmit and receive functions within their

Mega Wizard tool box. These packaged functions take care of all of the
timing needed to either receive or transmit the high speed serial data.

The one thing that bit me though was that the SERDES transmit/receivers is
that the Stratix II family had no knowledge of bit alignment.relative to the
SERDES clock. My previous SERDES experience used discrete parts where the
timing of each bit relative to the rising edge of the clock was defined.
The Stratix II documentation I worked with sure implied that this was true
also (bit as I realized later when the bite chomped down it did not directly
say so. Having worked with the discrete chips seeing the same drawings in
the Stratix documentation led me astray).

With Stratix II (and maybe this is common with all SERDES other than
discrete chips) the receive side needs to manually align the bits relative
to the clock. The MegaWizard brings has an optional input that you
absolutely must use since you most likely will not power up with bits
aligned where you want them. Also, each SERDES channel needs to be
individually aligned (i.e. bit 7 may show up at one spot relative to the
clock on channel 1 but there is no guarantee that bit 7 on channel 2 will be
there as well).

The problem then becomes how do you get the transmitter and receiver to
'know' when they should be trying to align bits relative to the clock and
when are you all aligned and ready to go? That solution comes on a case by
case basis depending on what your system is.

In hindsight this was all ignorance on my part in part caused by prior
SERDES knowledge with the discrete chips...but thought I'd pass the 2 cents
along.

KJ

 

[Rob]

KJ,

The one thing that bit me though was that the SERDES transmit/receivers is
that the Stratix II family had no knowledge of bit alignment.relative to
the SERDES clock.

Of course the FPGA doesn't have any knowledge of the bit stream; which is
why you have to tell it where the data is in relation to the rising edge of
the clock. In the case of a receiver, the MegaWizard function gives you the
option of choosing 0, 45, 90, 135, 180, 225, 270, & 315 degrees. This is
possible because the Wizard funcion uses a PLL to strip the data from the
serialized stream. Most discrete SERDES type chips, like National's 90CR
types, align the data with the rising edge of the PLL clock. In this case
you would setup the FPGA's receiver to have 0 degree phase between the data
and the clock, which will tell Quartus to latch the data on the falling edge
of the receiver's PLL clock.

I've used this functionality about 1/2 dozen times over the last year and
have NEVER had a problem. I've interefaced with National parts and other
FPGA (which simulated National parts).

Also, each SERDES channel needs to be individually aligned (i.e. bit 7 may
show up at one spot relative to the clock on channel 1 but there is no
guarantee that bit 7 on channel 2 will be there as well).

If this is the case then the data coming into the FPGA probably has too much
skew between the lanes. This is not the FPGA's problem. The receiver
assumes that all the lanes are aligned. If they're not then one has to play
games with the timing on each lane--not fun (I've been there). Also remember
that all systems like this get affected by clock jitter, cable skew, and
flop setup/hold times: all of which contribute to the RSKM (receiver skew
margin).

Take care,
Rob

 

[KJ]

Rob,

Of course the FPGA doesn't have any knowledge of the bit stream; which is
why you have to tell it where the data is in relation to the rising edge
of the clock. In the case of a receiver, the MegaWizard function gives
you the option of choosing 0, 45, 90, 135, 180, 225, 270, & 315 degrees.
This is possible because the Wizard funcion uses a PLL to strip the data
from the serialized stream.

What you're talking about here has to do with what Altera calls 'DPA' .
What the data book has to say about DPA is the following (page 51 of 68)
http://www.altera.com/literature/hb/stx2/stx2_sii5v2_03.pdf:

The DPA block aligns the incoming data to one of eight clock
phases to maximize the receiver's skew margin. The DPA circuit can be
bypassed on a channel-by-channel basis if it is not needed. Set the DPA
bypass statically in the Quartus II MegaWizard Plug-In or dynamically
by using the optional RX_DPLL_ENABLE port.

DPA has to do with skewing the SERDES clock a bit (with one of 8 settings)
relative to a particular bit position in order to improve receiver skew
margin in order to correct for known skew that may exist in your system but
can be accounted for ahead of time (i.e. at design time when you're picking
one of those 8 settings). This is not the same thing that I was talking
about though. What I was talking about was along the lines of what is on
the next page in the section titled "Receiver Data Realignment Circuit"
where they say...

The data realignment circuit aligns the word boundary of the incoming
data by inserting bit latencies into the serial stream. An optional
RX_CHANNEL_DATA_ALIGN port controls the bit insertion of each
receiver independently controlled from the internal logic. The data slips
one bit for every pulse on the RX_CHANNEL_DATA_ALIGN port.

If you scroll a bit further to page 58 under the section titled
"Differential I/O Bit Position" is a nice description showing the bit order
of differential data that basically shows that the nominal rising edge of
the SERDES clock occurs roughly at the transition between when data bits 2
and 1 are being transmitted. What they don't say is that you have to use
the above mentioned "Receiver Data Realignment" feature first in order to
get the bits in the proper position.

I ran across this one first in simulation since the receiver was not
performing per the 'Figure 5-14' diagram where I suspected that it was just
Altera's simulation model that was in error. After opening a service
request and subsequent escalations since the problems wasn't resolved and
actually talking to someone at Altera who is very familiar with the SERDES
circuitry the end result was that the simulation model is correct the
diagrams they agreed are somewhat misleading and that the 'Receiver Data
Realignment' feature really does need to be used in order to guarantee that
your design is working correctly at every power up.

Typically everything seems to power up in the same fashion but I've also
seen the actual hardware have to get 're-aligned' after having already been
aligned.

Most discrete SERDES type chips, like National's 90CR types, align the
data with the rising edge of the PLL clock. In this case

And this was my mistake when I thought this to be true with Stratix SERDES
also...thanks to Figure 5-14

KJ

 

[Rob]

KJ,

Now we're on the same page. Thanks for clearing up my misunderstanding.
You're add on this thread is very valid.

Take care,
Rob