Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
977 Views

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

Hi,  

 

Forgive me if the question is basic. I am new to the field of FPGAs.  

I give a short version of the question. And a long version of the question. 

For those interested :). 

 

Note: Requirement is Rx only. No Tx. Half the problem doesn't exist. All pins discussed below are with reference to input pins. :) 

 

Short version: 

CML and LVDS are two high-speed differential signaling standards.  

FGPA Development Kit 1 has pins on a port supporting CML differential I/O according to the kit reference manual. 

 

The actual FPGA on the Development Kit supports LVDS on those pins according to the FPGA manual. 

 

But the reference manual of the Dev Kit doesn't indicate support of LVDS on that port. 

 

Is it possible to configure the actual pins of the FPGA to take an LVDS input instead of CML. 

 

Long version: 

 

Altera Stratix V DSP Development Kit. (Supports CML and LVDS on PortA)  

 

connected to Altera Stratix III Development Kit. (Supports LVDS only)  

 

Basically we want more LVDS lines on the Stratix V to receive input from the DE3 on a wider bus between the FPGAs. So looking for additional pins. 

Port A of the KIT has CML Rx receivers that could be configured as LVDS on the FPGA. 

Port B of the KIT has some differential DQS compatible pins that could be configured as LVDS on the FPGA. 

 

In both cases, the reference manual of the kit does not indicate that the pins on the port are compatible to LVDS. 

The FPGA itself supports LVDS input according to the device handbook. 

 

The connecter and cable between the boards will be based around Samtec EPLSP  

 

A possible work around would be AC coupling between CML/LVDS 

Using an IC by TI sn65cml100 

 

I'd like some guidance on going about such a task and whether its possible or not? 

 

Cheers. 

Thanks for reading till here. 

 

Zubair 

 

p.s. I can't post real hyperlinks cause I just joined the forum. I had links pasted in at every statement pointing to pdfs ..
Tags (2)
0 Kudos
21 Replies
Altera_Forum
Honored Contributor I
171 Views

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
Altera_Forum
Honored Contributor I
171 Views

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
Altera_Forum
Honored Contributor I
171 Views

 

--- 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
Altera_Forum
Honored Contributor I
171 Views

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
Altera_Forum
Honored Contributor I
171 Views

 

--- 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
Altera_Forum
Honored Contributor I
171 Views

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
Altera_Forum
Honored Contributor I
171 Views

 

--- 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
Altera_Forum
Honored Contributor I
171 Views

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
Altera_Forum
Honored Contributor I
171 Views

 

--- 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
Altera_Forum
Honored Contributor I
171 Views

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
Altera_Forum
Honored Contributor I
171 Views

 

--- Quote Start ---  

 

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

 

--- Quote End ---  

 

 

Ok. I just wanted to throw a couple of ideas out there to see if they were useful. 

 

 

--- Quote Start ---  

 

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

 

--- Quote End ---  

 

 

Given that the ADC data is multiplexed onto a pair of lanes, I suspect there will be enough transitions that you could interface a single lane to the CDR unit of a transceiver. However, I think you'd encounter a lot of problems trying to 'recover' your 6-bits of data out of that data stream, since the frame clock you would use for an LVDS application would not really be available for the transceiver channel (keep in mind that each receiver CDR PLL will have an arbitrary phase shift relative to any of the LVDS receive channels or any PLL locked to the frame clock). 

 

My advice would be to steer clear of the transceiver channels for ADC interfacing. However, you could consider them as communications interfaces for transferring ADC data between boards. For example, ADC-to-DE3 interface via LVDS, and then DE3-to-Stratix V data transport using transceivers (and possibly Stratix V to Stratix V transport via transceivers if needed). 

 

Cheers, 

Dave
Altera_Forum
Honored Contributor I
171 Views

It was actually wonderful of you to throw some ideas. Throughout our brainstorming sessions, none of us found out about the upcoming JEDEC standard.. 

 

Thanks for the heads up. Embedding the frame clock within the signal could be tricky in that case. 

 

Lets hope the IC manufacturers handle these issues. The main benefit of using ADCs designed for a specific purpose is this. 

They cater the common configurations and problems faced in that specifc application within the IC. Like the phase shifts you mention.  

Vendors usually cater for common clocks and daisy chain configurations of IC's which ensures (to a reasonable extent of accuracy) the phase margins between the signals. 

 

AD9671, an 8-channel ADC for Ultrasound applications is coming soon. 

The preview page shows : 

"the ADC contains several features designed to maximize flexibility and minimize system cost, such as a programmable clock, data alignment, and programmable digital test pattern generation. The digital test patterns include built-in fixed patterns, built-in pseudo random patterns, and custom user-defined test patterns entered via the serial port interface." 

 

The DE3(Stratix III) does not have any transceivers. Would have simplified a lot of things if it did.. 

 

Thanks, 

Zubair
Altera_Forum
Honored Contributor I
171 Views

 

--- Quote Start ---  

It was actually wonderful of you to throw some ideas. Throughout our brainstorming sessions, none of us found out about the upcoming JEDEC standard.. 

 

--- Quote End ---  

 

Glad to hear that it helped. 

 

 

--- Quote Start ---  

 

Thanks for the heads up. Embedding the frame clock within the signal could be tricky in that case. 

 

--- Quote End ---  

 

Yeah, I think it would be more trouble than its worth at this point. 

 

 

--- Quote Start ---  

 

AD9671, an 8-channel ADC for Ultrasound applications is coming soon. 

The preview page shows : 

"the ADC contains several features designed to maximize flexibility and minimize system cost, such as a programmable clock, data alignment, and programmable digital test pattern generation. The digital test patterns include built-in fixed patterns, built-in pseudo random patterns, and custom user-defined test patterns entered via the serial port interface." 

 

--- Quote End ---  

 

Alas, you often find a better part out there, or proposed ... usually after it is too late for the current project :) 

 

 

--- Quote Start ---  

 

The DE3(Stratix III) does not have any transceivers. Would have simplified a lot of things if it did.. 

 

--- Quote End ---  

 

 

Why not obtain a couple of DE4's then, or perhaps Stratix IV GX Development kits? The University Program might have an affordable option. 

 

You'll need to tradeoff how much effort it'll take to get data from the DE3 to the Stratix V. You might find its easier to use the HSMC connectors on the Stratix IV kit to get ADC data into the FPGA, and then use the transceivers on the PCIe edge connector to get over to the Stratix V. Samtec have PCIe edge-connector to SMA breakout cables (I have some). I can give you the part numbers if you need them. 

 

Cheers, 

Dave
Altera_Forum
Honored Contributor I
171 Views

The DE4/Stratix IV Dev kit only have 38 or 36 LVDS pairs. You gain transceivers but loose ADC channels per board. 

 

Also, we already have DE3 boards with us. :) 

 

"Alas, you often find a better part out there, or proposed ... usually after it is too late for the current project "  

Indeed! After the project, you always have a dozen ideas on how to do it better. Next time :p 

 

Thanks, 

Zubair
Altera_Forum
Honored Contributor I
171 Views

 

--- Quote Start ---  

The DE4/Stratix IV Dev kit only have 38 or 36 LVDS pairs. You gain transceivers but loose ADC channels per board. 

 

--- Quote End ---  

 

 

Yeah, I see; clk+17-bits RX per HSMC. 

 

I guess the DE3 has a couple of extra HSMC connectors you can use. 

 

 

--- Quote Start ---  

 

Also, we already have DE3 boards with us. :) 

 

--- Quote End ---  

 

 

Having hardware in-hand always helps push the decision making :) 

 

Good luck with your project. Feel free to ping me anytime you feel the need for a discussion. 

 

Cheers, 

Dave
Altera_Forum
Honored Contributor I
171 Views

 

--- Quote Start ---  

Yeah, I see; clk+17-bits RX per HSMC. 

 

I guess the DE3 has a couple of extra HSMC connectors you can use. 

 

Having hardware in-hand always helps push the decision making :) 

 

Good luck with your project. Feel free to ping me anytime you feel the need for a discussion. 

 

 

--- Quote End ---  

 

Indeed. 

 

I'll try not to bother with small stuff :). 

 

Thanks a lot for the help. 

 

Regards 

Zubair
Altera_Forum
Honored Contributor I
171 Views

 

--- Quote Start ---  

My advice would be to steer clear of the transceiver channels for ADC interfacing. However, you could consider them as communications interfaces for transferring ADC data between boards. For example, ADC-to-DE3 interface via LVDS, and then DE3-to-Stratix V data transport using transceivers (and possibly Stratix V to Stratix V transport via transceivers if needed). 

 

--- Quote End ---  

 

 

Hi Dave, 

 

I stumbled upon this thread as I'm currently working on a project using a Stratix IV GX device for the first time (EP4SGX70HF35) while interfacing with 16-bit ADCs. My dilemma right now is trying to figure out the best way to get the data into the FPGA. What's the main reason you advised staying away from the transceivers when interfacing with the ADCs? If I am using the transceivers, do I need to use the ALTGX megafunction in order to get data in/out or can I treat them like regular I/O pins? 

 

Thanks. You seem quite knowledgeable. 

 

-Mike
Altera_Forum
Honored Contributor I
171 Views

I believe he meant that aligning samples from the ADC could pose a problem with transceivers. 

 

If your requirement is such that samples from each channel of the ADC have to be in sync, then it might pose a problem knowing which sample was which. 

This shouldn't be much of a problem if there are only 3 ADC channels. The case I was discussing had 96 channels :) 

Although, only he can properly answer your question. This was my understanding of it. 

 

I guess it would also depend on the ADC in question.. Which part are you using?  

 

 

Hope this helps. 

 

Zubair
Altera_Forum
Honored Contributor I
171 Views

 

--- Quote Start ---  

I believe he meant that aligning samples from the ADC could pose a problem with transceivers. 

 

If your requirement is such that samples from each channel of the ADC have to be in sync, then it might pose a problem knowing which sample was which. 

This shouldn't be much of a problem if there are only 3 ADC channels. The case I was discussing had 96 channels :) 

Although, only he can properly answer your question. This was my understanding of it. 

 

I guess it would also depend on the ADC in question.. Which part are you using?  

 

 

Hope this helps. 

 

Zubair 

--- Quote End ---  

 

 

Thanks Zubair, 

 

I started a new thread for this since my reply to this thread was getting hung up in the approval process. Dave answered my question in the other thread.  

 

I have a lot of channels too (16 x 3 ADCs) that I need to get into the FPGA so the transceivers do not seem like the right solution. I'm using the AD9650. 

 

-Mike
Altera_Forum
Honored Contributor I
82 Views

Ok.  

Great :) 

 

Zubair
Reply