Struggling with LVDS.

[Altera_Forum]

Hi Guys, 

 I've had experience with FPGAs in the past, however I've never before been required to implement the LVDS standard for data communication. I thought it would be trivially easy, but it seems like I was wrong!  I'm having a great bit of difficulty finding any examples of how LVDS I/O can be implemented. There are two kinds of MegaWizard Plugin instances I can choose between; ALTDDIO and ALTLVDS_TX/RX. I'm more inclined to use the basic ALTDDIO IP, purely because I don't really understand what impact serialisation has on the data (I just assume that it takes all of the parallel data bits and outputs them sequentially?).  So, I have a couple of questions, just so that I can gain some knowledge about how they're used.  Q: When using LVDS on the Cyclone III, is DDR I/O supported? If so, is it implicit or do I have to code in a particular way to implement DDR?  Q: When generating a MegaWizard plugin for ALTDDIO_IN (I assumed this would be for receiving data), what I get is a module that looks like it's used for generating LVDS signals. The opposite happens for ALTDDIO_OUT. Am I missing something fundamental?  ... Just to show you guys what I mean, the module parameters for a 6-bit wide ALDDIO_OUT looks like this:  module ALTDDIO_OUT_6 (  aclr,  datain_h,  datain_l,  outclock,  dataout);   input aclr;  input [5:0] datain_h;  input [5:0] datain_l;  input outclock;  output [5:0] dataout;  Surely the _h and _l 's should be outputs?  Q: Will the FPGA accept an aysnchronous LVDS input clock signal to drive DDR latching operations on the other LVDS input lines?  using: Cyclone III FPGA.  I sorry that this is a really big post. I'd really appreciate any help you guys can offer me with this one, I've been left scratching my head for days over it.

[Altera_Forum]

To understand the component, think about what is happening; if the LVDS is clocking out data at double-data-rate, then you need double the data in at the clock rate, eg., lets say the clock is 100MHz, then data_l and data_h are inputs that change every 100MHz clock period, however, the dataout LVDS signal changes at 200Mbps, i.e., on both the rising and falling edges of the clocks. 

 Create a Modelsim simulation with the components you are trying to use. That always helps me visualize what is going on.  The Cyclone III devices do not have hard-IP serializers, only DDR registers, so using the altddio component and defining the pin standard as LVDS is adequate for what you want to do. The altlvds component would use logic cells to implement a serdes on the Cylone III, whereas on the Stratix series it uses a hard-IP block.  Cheers, Dave

[Altera_Forum]

That's a great way of explaining it. 

 I'll try and create a testbench for my 6-bit wide ALTDDIO_OUT component and check out how it works.  So, just to check, these ALTDDIO functions require an input clock. Is it possible to drive the clock for the component from an external LVDS signal?  Thanks a lot for your help. Super-fast response!

[Altera_Forum]

--- Quote Start ---   So, just to check, these ALTDDIO functions require an input clock. Is it possible to drive the clock for the component from an external LVDS signal?   --- Quote End ---  Unless the LVDS link is designed for clock-and-data recovery, the data leaving the FPGA and the data being capture at the other end of the LVDS link need to be synchronous.  When LVDS is used in a source synchronous mode, the LVDS data is sent with an LVDS clock. In that case, you also use an altddio to send a clock, data_l is zero and data_h is one, and so the serialized data is just a single-data-rate clock, however, it has a known timing relation to the data.  You can also use an external clock, but you'll need to take care to perform a timing analysis to check that you meet the timing requirements of the external device. You can use the TimeQuest timing analysis tool to get th e FPGA timing information (and the external device data sheet for its timing). If you cannot meet timing when using an external clock directly, you can route the external clock to a PLL internal to the FPGA (depending on the device) and phase-shift that clock to meet external timing.  Check out the TimeQuest users guide by Rysc on the Altera Wiki.  http://www.alterawiki.com/wiki/timequest  Cheers, Dave

[Altera_Forum]

Hi again, Dave. 

 Luckily, there is no concurrent LVDS data that I need to transmit, other than a source LVDS clock from the FPGA. I just need to get a hold of data which is transmitted from the device I need to control.  The LVDS clock I generate gets passed into the device I'm trying to interface with, then back out alongside LVDS data on four other parallel lines. So, what I'll need to do is try and clock in the data based on a phase shifted version of the original clock I'm generating from the FPGA. Hopefully that means that we're working with just source-synchronous data from the device and nothing more (Unless source-synchronous implies that devices on each end need to be configured for synchronous TX/RX).  Thanks for the resources. I'll look for examples of someone using the LVDS block for clock generation and that should be a good starting point. I'm sure all of this stuff is in the ALTDDIO documentation, I'm probably just not taking it all in!  Using a PLL to clock in the external data is a great idea, if it's supported.   You've been extremely helpful. Thank you.

[Altera_Forum]

--- Quote Start ---   Luckily, there is no concurrent LVDS data that I need to transmit, other than a source LVDS clock from the FPGA. I just need to get a hold of data which is transmitted from the device I need to control.  The LVDS clock I generate gets passed into the device I'm trying to interface with, then back out alongside LVDS data on four other parallel lines. So, what I'll need to do is try and clock in the data based on a phase shifted version of the original clock I'm generating from the FPGA.   --- Quote End ---    Why use the original clock, when the device sends a clock with the data? The clock sent with the data will have the same process-voltage-temperature (PVT) variation as the data, so would be the more useful clock to use. If you need the data in the clock domain of the original clock, then since you know they are phase-locked, you can use a shallow FIFO to cross from the rx_data+rx_clock into the tx_clock domain.    --- Quote Start ---   Hopefully that means that we're working with just source-synchronous data from the device and nothing more (Unless source-synchronous implies that devices on each end need to be configured for synchronous TX/RX).   --- Quote End ---    Since the two devices use a common clock, they are synchronous. However, the clocks can have a phase shift, and at high-frequencies, the pair of clocks may shift phase slightly with respect to each other.  Cheers, Dave