cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
iakovosmavro
Observer
Observer
8,956 Views
Registered: ‎10-03-2013

SERDES vs Parallel interface

Jump to solution

Hi all,

 

I have a basic question. Let's assume that I have 9 same length links (single bit pin to pin) between two FPGAs (8 for data and 1 for clock) and I want to transfer data from one FPGA to the other using a source synchronous communication.

 

One way is to use two 8-bit data registers one in each FPGA and simply send the data from one register to the other. The clock is transfered along with the data and it is used on the receiver side to capture the incoming data. If I understand correctly in this case we will have very low clock frequencies (<100MHz). Is that correct? If yes is this because the incoming clock on the receiver side has to be synchronized with all 8 data bit lines and not just one? 

 

The other solution would be to have multiple independent serial links (I am not talking about high speed serial links) using SERDES'. Now we have to spit the traffic into 4 differential (4*2=8 pins in total) independent flows on the transmitter side and merge the 4 flows back on the receiver side. This is much more difficult but the advantage of this is that you can have speeds at about 1Gbit/s on each serial link compared to <100MHz and thus you will have 5 times (1Gbps*4/8*0.1Gbps) faster link. Is this indeed the advantage? If yes why is this so? Is it because now on the receiver side I have to synchronize the incoming clock with a single differential input while in the previous case I had to synchronize the incoming clock with 8 data lines?

 

Thanks in advance,

Iakovos

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
14,762 Views
Registered: ‎01-23-2009

Iakovos,

 

There is nothing inherently wrong with a parallel source synchronous interface - even one with many bits.

 

In general, you need

  - the outputs to come from your transmitter with very low skew

    - this can easily be done in an FPGA by having your data generated by IOB flip-flops, and your clock being generated with an ODDR

  - the traces on the board are well matched in terms of length

  - the receiver circuit correctly constructed

    - clock entering on a clock capable pin

    - data being captured in IOB FFs - preferably in the same I/O bank as the clock

    - IOB FFs clocked using either

         - "ChipSync" clocking (the BUFIO or BUFR) or

         - global clocking with deskew (an MMCM with feedback, using either BUFGs or BUFHs)

   - proper static phase adjustment using either

      - IDELAYs on your clock and data, with one or the other set to the correct value or

      - phase adjustment in your MMCM

 

If you do all of these, you can capture data at quite high bit rates per pin - definitely well over 100Mbps/pin. With differential signals, you can even go above 1000Mbps/pin - with single ended signals, this will be somewhat slower. Also, faster data transfers can be done with double data rate clocks, than with single data rate clocks.

 

That being said, it is very hard to work with 1GHz or even 500MHz signals inside the FPGA. You generally want to reduce them to slower (and hence wider) signals. This is where the ISERDES comes in. If you have an interface (lets say it is 8 bits wide) where each signal is operating at 1Gbps, you would want to change that to a more managable interface inside. Rather than having 8 bits at 1Gbps, you would be better converting that to 32 bits at 250MHz - this is much more managable in the FPGA fabric. To do this, you would use the ISERDES in 4:1 deserialization. If your bus is inherently parallel to start with, then you will end up with 4 competely correlated 8 bit words every clock (at 250MHz).

 

The only time things get complex is if you are trying to send a "wide" bus over a "narrow" interface. As a second example, lets say you want to send 8 bits at 125MHz between the two FPGAs. You can easily do this with 8 data bits and one clock signal running at 125MHz. But, in order to save pins, you can, instead, do it with one clock pin and one data pin, but running at 1Gbps. To do this, you need to serialize your data. When you do that, you now need to deal with "framing" - on the receiving end you need to figure out which 8 consecutive bits make up your original data word. Now you may need to deal with training patterns, or a frame signal (on a 3rd pin), or something like 8b10b encoding to recover the framing.

 

Avrum

    

View solution in original post

0 Kudos
2 Replies
avrumw
Guide
Guide
14,763 Views
Registered: ‎01-23-2009

Iakovos,

 

There is nothing inherently wrong with a parallel source synchronous interface - even one with many bits.

 

In general, you need

  - the outputs to come from your transmitter with very low skew

    - this can easily be done in an FPGA by having your data generated by IOB flip-flops, and your clock being generated with an ODDR

  - the traces on the board are well matched in terms of length

  - the receiver circuit correctly constructed

    - clock entering on a clock capable pin

    - data being captured in IOB FFs - preferably in the same I/O bank as the clock

    - IOB FFs clocked using either

         - "ChipSync" clocking (the BUFIO or BUFR) or

         - global clocking with deskew (an MMCM with feedback, using either BUFGs or BUFHs)

   - proper static phase adjustment using either

      - IDELAYs on your clock and data, with one or the other set to the correct value or

      - phase adjustment in your MMCM

 

If you do all of these, you can capture data at quite high bit rates per pin - definitely well over 100Mbps/pin. With differential signals, you can even go above 1000Mbps/pin - with single ended signals, this will be somewhat slower. Also, faster data transfers can be done with double data rate clocks, than with single data rate clocks.

 

That being said, it is very hard to work with 1GHz or even 500MHz signals inside the FPGA. You generally want to reduce them to slower (and hence wider) signals. This is where the ISERDES comes in. If you have an interface (lets say it is 8 bits wide) where each signal is operating at 1Gbps, you would want to change that to a more managable interface inside. Rather than having 8 bits at 1Gbps, you would be better converting that to 32 bits at 250MHz - this is much more managable in the FPGA fabric. To do this, you would use the ISERDES in 4:1 deserialization. If your bus is inherently parallel to start with, then you will end up with 4 competely correlated 8 bit words every clock (at 250MHz).

 

The only time things get complex is if you are trying to send a "wide" bus over a "narrow" interface. As a second example, lets say you want to send 8 bits at 125MHz between the two FPGAs. You can easily do this with 8 data bits and one clock signal running at 125MHz. But, in order to save pins, you can, instead, do it with one clock pin and one data pin, but running at 1Gbps. To do this, you need to serialize your data. When you do that, you now need to deal with "framing" - on the receiving end you need to figure out which 8 consecutive bits make up your original data word. Now you may need to deal with training patterns, or a frame signal (on a 3rd pin), or something like 8b10b encoding to recover the framing.

 

Avrum

    

View solution in original post

0 Kudos
iakovosmavro
Observer
Observer
8,940 Views
Registered: ‎10-03-2013

Dear Avrum,

 

Thanks a lot! Your reply was crystal clear. It is highly appreciated.

 

Thanks again,

Iakovos

0 Kudos