Using CML or DQS transceiver pins as LVDS possible in Stratix V DSP Dev Kit?

General comments to help you (not specific to the Stratix V kit).

LVDS channels and transceiver channels are not interchangeable, so you have to describe your application in a little more detail.

Here's some caveats/typical use-cases.

LVDS channels can operate up to 1Gbps (or so). A multi-channel LVDS interface can consist of multiple data lanes, along with a frame clock. The frame clock is used as a PLL reference, with the PLL increasing the frame clock to the data rate. Depending on the data rate, the clock will be used for single-data-rate or double-data-rate clocking of I/O element registers, or clocking of serializer registers.

A SerDes channel is a stand-alone entity, with the receivers employing clock-and-data-recovery (CDR). If the common-mode voltage of your signal is different than the common-mode of the receiver, then you need to AC couple the signal (you'd have to check whether the LVDS common-mode was in the acceptable range for the Stratix V receivers). Because of the AC coupling, your input data stream needs to be modulated to ensure a zero DC bias, eg., 8/10B encoding, or PRBS modulation. Multi-channel SerDes applications rely on synchronization/alignment codes being sent across the stand-alone channels, so they are not 'synchronous' (each lane needs its own clock-domain crossing FIFO).

You can configure a SerDes channel in a pseudo-synchronous mode, where the receiver PLL is held in lock-to-reference (rather than being allowed to transition to lock-to-data), however, this only works for low frequencies. In this mode, for a mutli-lane application, you would still need to send synchronization codes to align the lanes.

If your LVDS data data rate is synchronous and 'not too high', you may want to consider using external LVDS-to-LVCMOS level translators. National Semiconductor (now owned by Texas Instruments) have some 9-bit parts that operated to ~100Mbps

http://www.ti.com/lit/ds/symlink/ds92lv090a.pdf

Check out the "LVDS Owners Manual"

http://www.ti.com/lit/ml/snla187/snla187.pdf

Cheers,

Dave

Hi,

Thanks for the informative reply.

I understand your reference regarding SERDES requiring frame clocks for synchronization and the PLL.

But what if the frame clock is embedded in the signal itself using a unique pattern.

And the data is encoded for DC balancing..

If I AC couple the LVDS transmitters from the DE3 board to CML Receivers of the Stratix V board, embed a clock signal in the data stream and encode the data for DC balancing, I should be able to transfer the data right?

-

Zubair

--- Quote Start ---

But what if the frame clock is embedded in the signal itself using a unique pattern.

And the data is encoded for DC balancing..

--- Quote End ---

Then you can AC couple the LVDS signal to the CML SERDES receiver. You can then use the hard-IP in basic mode, and use it to search for the synchronization patterns.

For example, I use the Stratix IV GX/GT transceivers in basic mode, and send data XOR modulated by a PRBS pattern across an AC-coupled link. Before sending data, I just send the PRBS pattern, and first synchronize lanes to that pattern. I then turn on data and demodulate in the receiving FPGA. The data is disabled periodically to check that the PRBS generators in the TX and RX are still synchronized. 8/10B encoding is nicer, in that its always 'checking'.

Note that the transmitter and receiver should use a common clock reference. The receiver SERDES uses that reference during power-on-initialization, and then will transition to lock-to-data mode (where the data is captured at an optimal location relative to the data eye). The CDR clock and the reference will be 'phase locked', but the phase can change over process-variation-temperature (PVT). The hard-IP FIFOs can be used to cross from the CDR clock domain over to the clock reference domain (or the PLL locked to the clock reference).

Cheers,

Dave

Thank-you.

AC-coupling seems to be the way to go. I see various strategies. Mostly involving two capacitors. Some indicate a couple of resisters as well. SN65CML100 by TI is also there.

I am guessing the speed limits in such a design would be the limitations of the transceivers on the LVDS side. My application requires upwards of 1Gbps. Preferably close to the LVDS limit of the DE3 (1.6Gbps)

The hard-IP transceiver block on the Stratix V in basic mode shouldn't be a choking point at these speeds?

Also, 8/10B introduces a 25% overhead. It should be possible to opt for 64/66B encoding?

Sorry for the petty questions. I can clearly see that I need more practical experience on the FPGA than simply musing over it a-lot and thinking over a bigger design.

But I'm learning as it comes. Just don't want to spend time trying to do something impossible :)

Thank-you,

Zubair

--- Quote Start ---

AC-coupling seems to be the way to go. I see various strategies. Mostly involving two capacitors. Some indicate a couple of resisters as well. SN65CML100 by TI is also there.

--- Quote End ---

At 1.6Gbps a couple of 100nF capacitors should be fine.

--- Quote Start ---

I am guessing the speed limits in such a design would be the limitations of the transceivers on the LVDS side. My application requires upwards of 1Gbps. Preferably close to the LVDS limit of the DE3 (1.6Gbps)

--- Quote End ---

Yes, the limit will be the LVDS.

--- Quote Start ---

The hard-IP transceiver block on the Stratix V in basic mode shouldn't be a choking point at these speeds?

--- Quote End ---

Worst-case, you may find that 1.6Gbps is too slow (but probably not). If that is the case, then configure the transceiver block receivers and CDR PLLs for 2x or 4x oversampling, and just throw-away the 'extra' bits inside the FPGA. You can also use the 'extra' bits for error checking, eg., in 2x over-sampling mode, confirm that each pair of bits is identical.

--- Quote Start ---

Also, 8/10B introduces a 25% overhead. It should be possible to opt for 64/66B encoding?

--- Quote End ---

Or PRBS modulation, which introduces no over-head, but does assume a certain level of randomness in your data. Here's a document plus code that generates PRBS patterns:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial.pdf

http://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial_src.zip

--- Quote Start ---

Sorry for the petty questions. I can clearly see that I need more practical experience on the FPGA than simply musing over it a-lot and thinking over a bigger design.

But I'm learning as it comes. Just don't want to spend time trying to do something impossible :)

--- Quote End ---

No need to apologize.

Asking intelligent questions that show you've thought about the problem will generally result in useful responses :)

Cheers,

Dave

Thank-you very much for the help and support.

I'll look into PRBS modulation. The data is from an ADC for Ultrasound detection at 80MSPS.

The final bit-stream should be random enough and DC-balanced. but I will run a few tests on actual data just in case.

Thanks again,

Zubair

--- Quote Start ---

The data is from an ADC for Ultrasound detection at 80MSPS.

--- Quote End ---

Which part? 80MSps is pretty slow, why are you considering using LVDS? Is this part serializing the data onto a higher data rate LVDS lane? If the part is JEDEC JESD204 compliant, then you can interface it directly to an FPGA transceiver.

--- Quote Start ---

The final bit-stream should be random enough and DC-balanced. but I will run a few tests on actual data just in case.

--- Quote End ---

It might not be, and unless the ADC is design to take in a modulation source, you cannot use PRBS to 'fix' this part.

It sounds to me like you are trying to re-use existing hardware or a development kit. If that is the case, then just use these kits to get a subset of functionality working, and then design your own board with the actual parts and features you need. That is assuming you have the time and resources to go that route :)

Cheers,

Dave

Interesting. The JEDEC standard is the future and I'd like to see ADCs with them for our application.

But a quick search didn't turn up anything for Ultrasounds that has developed/matured. The AD9250 can be used.

The AD9671 is about to be released which could simplify stuff. But I wish it had been released a year ago :).

We intend on using the AFE5807 by TI, 8 Channel, 12bit, 80MSps, specifically for Ultrasound applications.

And there are 18 ADCs in total. (18 x 8 = 144 Channels) ;)

3 Stratix III boards(DE3 by Terasic) connected to 1 Stratix V (DSP Dev Kit).

Each DE3 connected to daughter cards hosting a total of 48 ADC Channels.

48 ADC Channels -- DE3--

48 ADC Channels -- DE3-- } -- Stratix V Dev kit --> PC (via PCI Express Gen3)

48 ADC Channels -- DE3--

We are kinda limited to the DE3 because it provides a large number of LVDS inputs which we can use to connect to the ADCs.

However, the Stratix III on the DE3 isn't powerful enough for processing. And we can't get data off the DE3 to the PC fast enough either.

Also, it doesn't have any high-speed transceivers.

Hence the above addition of a Stratix V.

This isn't a final product, but a research platform. Hence, the large number of channels connected to FPGA development kits.

Each aspect of the entire platform has to be configurable for further research into Ultrasonics.

I understand your point regarding implementing a subset functionality. And a custom design would easily reduce the number of FPGAs.

But as you said, time and resources :).

Thanks,

Zubair

--- Quote Start ---

We intend on using the AFE5807 by TI, 8 Channel, 12bit, 80MSps, specifically for Ultrasound applications.

--- Quote End ---

From a brief look at the data sheet, each 12-bit channel is multiplexed onto 2 LVDS signals. At a sample rate of 80MSps, the LVDS lane rate is 480Mbps. This is "slow" enough that you could interface each ADC to a Cyclone IV GX device, and use that to serialize to a much higher data rate on a transceiver, eg., each 8 channel ADC requires 16 x 480Mbps LVDS inputs for a total data rate of 7680Mbps, 8/10B encoded this would be 9600Mbps, which could be divided across four transceiver lanes at 2400Mbps or two at 4800Mbps (on an Arria device). The EP4CGX22 has 4 transceiver lanes and 17 LVDS in the smallest package, 52 in the larger package. The four output lanes can be transmitted over QSFP (or QSFP+) cables. Alternatively, you could use an Arria or Stratix series device and use a faster lane rate. The faster lane rate would allow more channels to be routed to your high-end processing node.

--- Quote Start ---

And there are 18 ADCs in total. (18 x 8 = 144 Channels) ;)

--- Quote End ---

Lets say each ADC was converted to a 9.6Gbps data stream ... then you only need 18 10Gbps transceiver channels to get all ADC data into a single FPGA.

I know its 'easier' to use kits than to develop your own boards. However, you might find it easier to develop a front-end board for your ADC board that then allows you to interface to your Stratix V kit (or some other kit). For example, getting all ADC data into a single FPGA may save significant development time elsewhere in the project, eg., if it eliminates trying to figure out how to distribute processing over multiple boards. If your ADC front-end board re-transmits ADC data in a format similar to JESD204, then future upgrades of the ADC will also be simpler, since the interface to the processing node will not change.

Feel free to continue discussing this design on the forum, or just email me directly (via my forum name), if you like.

Cheers,

Dave

You are correct and we did think of such a design during our brainstorming sessions. i.e. adding a smaller fpga on the ADC front-end card to serialize the channels.

However..

The DE3 setup already exists. Along with a version of the custom ADC Front-end daughter cards.

Currently, we are upgrading the capability of the entire setup by adding a Stratix V behind 2 DE3s.

Hopefully, in the next iteration, we'll have ADC's with the JEDEC standard. And we'll be able to directly connect a lot of ADCs with one FPGA kit.

Indeed, that would simplify stuff a lot :).

Thanks,

Zubair