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
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).
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?
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.
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).
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)
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