Connect with us

Doubt about SERDES

Discussion in 'Electronic Design' started by pinku, Mar 31, 2006.

Scroll to continue with content
  1. pinku

    pinku Guest

    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
     
  2. Rob

    Rob Guest

    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
     
  3. Chris Jones

    Chris Jones Guest

    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
     
  4. KJ

    KJ Guest

    Altera provides these SERDES transmit and receive functions within their
    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
     
  5. Rob

    Rob Guest

    KJ,
    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).
    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
     
  6. KJ

    KJ Guest

    Rob,
    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.
    And this was my mistake when I thought this to be true with Stratix SERDES
    also...thanks to Figure 5-14

    KJ
     
  7. Rob

    Rob Guest

    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
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-