This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using FPGA transceivers to directly receive encoded streams from DS32EL0421

Other Parts Discussed in Thread: DS32EL0421, DS32EL0124

Hello Experts,

I am planning to use DS32EL0421 to serialize LVDS streams from ADCs.  My question is do I need to use a deserializer at the other end to recover the stream?  The FPGA that we intend to use has a few xcvr i/os available and they have built in 8B/10B decoders.  

The serial stream is transported over Samtec's Firefly optical modules.  Therefore, 8B/10B encoding is required.

Test pattern can be inserted into the LVDS serial stream coming into the DS32EL0421 to do bit and word alignment.  

Please see the picture below - 

Thank you.

Best regards,

Sanjay

  • Hi Sanjay,

    Sorry for the delay in response.

    To answer your question, no, the DS32EL0124 (or another similar deserializer) is not needed if the Altera FPGA can perform the deserialization function. Will your FPGA be able to deserialize the following?

    If the data formatting is handled by the FPGA, then you can disable Remote Sense and DC-Balancing  so that the Scrambler and NRZI encoder are disabled. This allows you to use the test pattern and 8B/10B encoding from the FPGA to perform the lane alignment and data-scrambling.

    Regards,

    Michael

  • Thank you Michael.

    I actually intend to use DC Balancing.  I need to because the optical transceiver needs it.  But yes, I can create logic inside the FPGA to demux the data as shown in the figure you attached.

    Has the industry settled on a common 8B/10B encoding standard?  Altera's Arria 10 documentation is alluding to 8B/10B from the IEEE802.3 standard.  Can this become a problem?


    Thank you.

    Best regards,

    Sanjay

  • Hi Sanjay,

    While the DS32EL0421 is able to implement DC balancing, I would not recommend using the DC_B option if you are not interfacing with the DS32EL0124. The reason behind this is that there can be incompatibilities between the ways that the 8B/10B encoding is implemented when interfacing the DS32EL0421 with a device where the behavior is not characterized. Instead, I recommend disabling both Remote-Sense and DC-Balancing within the DS32EL0421, and instead using the host device (your FPGA) to generate the 8B/10B code that the Arria 10 FPGA is expecting.

    The standard used for 8B/10B encoding was originally made by IBM (there is a detailed Wikipedia article about this encoding), and multiple other standards have incorporated this encoding in the serial bit stream. As mentioned earlier, if the implementations for 8B/10B are incompatible, then you may run the risk of bit errors.

    Thanks,

    Michael
  • MIchael,

    Just as I had suspected :) i.e. encoding can be different than the Altera's FPGA. The problem is that not all the lanes to the serializer come from the fpga.  The majority of the lanes come from proprietary device directly and those signals are not DC balanced.  So I need to rely on the serializers DC balance. 

    Is it possible to find out what 8B/10B encoding standard is used by the serializers?

    I appreciate your help.

    Thank you.
    Best regards,

    Sanjay

  • Hi Sanjay,

    I can take a look at how the scheme is encoded, but this will take some digging on my end, as this device has been released for a few years. Please allow me a few days to get back to you.

    Thanks,

    Michael
  • Hi Sanjay,

    Thanks for your patience. I was able to get some information about the 8B/10B implementation. The DS32EL0421 uses the standard 8B/10B encoding table that is defined by the original IBM Code, so it should not be an issue for the Altera Arria FPGA to decode this if you use one of the 8B/10B megafunctions. My guess is that you have already found this information, so please give this a try. The only thing I have noted as a reminder is that, by default, the DS32EL0421 only supports the K28.5 control symbol.
    Regards,

    Michael
  • Thank you Michael.  I shall give this a try.  Point noted on the k28.5 symbols as default.