LVDS clock and data signals, interfacing to LVDS DAC

[Altera_Forum]

Hello, 

 I have designed a system for the generation of signals to be reconstructed with an ADC evaluation module (TSW30SH84EVM form TI). I am currently using a Terasic TR4 board, based on STRATIXIV (EP4SGX530KH40C2). My DAC board has an HSMC connector where I can send both LVDS data and the LVDS data clock, and I can read out a LVDS clock signal which I can use in order to generate the clocking for my FPGA design.  The question now is if I am using the LVDS signals in the right way. On some posts on the forum I was reading that in order to use LVDS signals is enough to declare the pins as LVDS, and that Quartus II takes care about defining the correspondent differential pin. Somewhere I have read that then I can just connect for instance the positive pin in my design.   The point is that in my design I have a ALTPLL, reading the LVDS clock reference out of the DAC board (737,28 MHz), and generating a 737,28 MHz clock for my NCO which delivers a complex sinusoid at 10 MHz, and a 92 MHz sync signal for the DAC as well.  Basically I see no data being converted from my DAC board, just some noise. I am suspecting that I should handle the LVDS signals in a different way.  I have tried to route the DAC reference clock signal to the SMA_CLKOUT connector of my development board, in order to measure the waveform which I want to use as input for the ALTPLL block, i think that due to the maximum speed of the clock output connector, I am not able to see a square waveform. What I measure is a sinusoidal wave but with the right frequency. This could even be right I suppose.  Somewhere on other posts I have read that I should handle those differential clocks using the ALTDDIO_OUT megacore, connecting its inputs to logic levels '0' and '1', and drive the block using the LVDS positive clock signal read out of the DAC board. But I am afraid that if I drive an ALTDDIO_OUT driven with such a signal, I would just get a single ended clock with double speed (1500 MHz)......  Would be really helpful if someone could help me to understand which one is the correct way to handle LVDS clocks and signals.  How do I read them out?  How do I menage them inside the design, am I reading them and convert them to single ended and then just convert them again to differential? How do I send them out again in LVDS format?  Thanks in advance for your help!  Giovanni.

[Altera_Forum]

You need to separate the IO standard from the logic behind it. (Altera doesn't do a good job of this in its naming).  

- If you make an LVDS IO standard assignment, then you only need the P pin. If you look in the fitter report, Input/Output Pins section, you should see they have the correct I/O standard and you should see an n pin has been created. Naturally, make sure it's hooked up where you want. - Inside the FPGA, you can use DDR I/O, but you will need to enter timing constraints. I wrote a source-synchronous timing constraint document on alterawiki: http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest It's long, but there are some examples you can probably cut and paste from. - Is the data rate 737Mbps, i.e. the same as the clock? I only ask because most interfaces usually have the clock run at half the data rate(which is where DDIO functionally works). Assuming it is 737Mbps, it is going to be difficult to meet timing with DDR I/O. Stratix IV has dedicated LVDS hardware, which can be instantiated with the altlvds_rx and altlvds_tx megafunctions. It runs really fast, so I would suggest using that. It's timing analysis is also greatly simplified. You don't create timing constraints, and instead run Report TCCS and Report RSKM in TimeQuest. It's actually too simplified, i.e. Report TCCS will just say 100ps, i.e. there's 100ps of channel-to-channel skew, but it won't even say what pins it's talking about, and it won't say the clock/data relationship, i.e. if it's center-aligned or edge-aligned, so you need to be sure to set that up correctly in the megafunction.

[Altera_Forum]

--- Quote Start ---  You need to separate the IO standard from the logic behind it. (Altera doesn't do a good job of this in its naming).  - If you make an LVDS IO standard assignment, then you only need the P pin. If you look in the fitter report, Input/Output Pins section, you should see they have the correct I/O standard and you should see an n pin has been created. Naturally, make sure it's hooked up where you want.  --- Quote End ---    So shortly resuming, when I define for example that my HSMA_CLKIN_p1 pins is LVDS (the DAC board itself is throwing out an LVDS clock on two signals), Quartus is creating automatically the differential couple (HSMA_CLKIN_p1(n)) which corresponds exactly to the dual PIN normally defined as HSMA_CLKIN_n1. I have seen on the pin planner that they(HSMA_CLKIN_n1 and HSMA_CLKIN_p1(n)) are exactly the same pin. So at this point, if I use just the positive pin, Quartus takes care somewhay to handle the differential to single ended convesion inside my design? Does the same work even for the conversion back to LVDS on the output pins? So if I just send the single ended produced signal, it will be sent as LVDS on the two dual output pins? In this case I would have solved already a lot of problems.    --- Quote Start ---   - Inside the FPGA, you can use DDR I/O, but you will need to enter timing constraints. I wrote a source-synchronous timing constraint document on alterawiki: http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest It's long, but there are some examples you can probably cut and paste from.  --- Quote End ---    I wil have a look at this, I do use a DDR I/O just at the output in order to interleave the data, while my ADC is accepting interleaved baseband data streams (generated through an NCO megacore) for each component(baseband signal, sine and cosine components). From the simulation it looks ok, but I still need to get how I can verify the time constraints.    --- Quote Start ---   - Is the data rate 737Mbps, i.e. the same as the clock? I only ask because most interfaces usually have the clock run at half the data rate(which is where DDIO functionally works). Assuming it is 737Mbps, it is going to be difficult to meet timing with DDR I/O. Stratix IV has dedicated LVDS hardware, which can be instantiated with the altlvds_rx and altlvds_tx megafunctions. It runs really fast, so I would suggest using that. It's timing analysis is also greatly simplified. You don't create timing constraints, and instead run Report TCCS and Report RSKM in TimeQuest. It's actually too simplified, i.e. Report TCCS will just say 100ps, i.e. there's 100ps of channel-to-channel skew, but it won't even say what pins it's talking about, and it won't say the clock/data relationship, i.e. if it's center-aligned or edge-aligned, so you need to be sure to set that up correctly in the megafunction.  --- Quote End ---    The data rate is the same as the clock I am using. Basically my DAC board is accepting LVDS center aligned data. So what I have thought to do was to use the DDR block in order to reach the wanted interleaving. If I´m not wrong the DDR block is being driven by my data clock (737.28 MHz). I send 2 couples of baseband channels (16 bits each) to my DAC, interleaved for each channel between sine and cosine component, so they reach 1.5 GSPS per channel. I still didn´t try to use the altlvds_tx and altlvds_rx block, I suppose they should have the same effect, but I don´t think they are right when I just want to generate a differential clock. So basically what I could try is, treating the clock pins as LVDS, and just connect the positive signal inside my design, and substitute the ALTDDIO with the LVDS transmitter to send the data to the daughter board with the DAC. At this point, should I menage the interleaving myself?  Greeting,   Giovanni

[Altera_Forum]

Yes, just the LVDS IO standard takes care of it for you. Much easier than instantiating primitives. 

One thing I almost forgot is the altlvds megafunctions will just instantiate DDR if you use them in /2 SERDES. If your core clock rate is really /2 the data rate, i.e. ~370MHz, then it might be a problem. What I've done is generate the altlvds and say the SERDES is /4, and then just present the data to the transmitter 4 bits at a time, or read the data from the receiver with my own DDR implementation.

[Altera_Forum]

Hi Rysc,  

 I am reading throught the time quest guides and I have figured something out. Basically it seems like my design cannot respect the time constraints when handling the 737.28 MHz PLL output. I have been able to write my sdc file, correcting the constraints for some other signals inside my circuit, but i still see not effect on this clock output. Time quest is showing me always a negative slack value for this signal, and I cannot manage to get it better. The only thing I could try was compiling the project, optimizing it for speed, in this way I have reached a 10 percent more for the slack variable, but it is still negative (-0.600).  Now my questions are the following, according to my small experience:   1) Can the ALTPLL Megacore handle my 737.28 MHz clock signal?  2) Of course I get even warnings about the fact the the PLL megacore function outputs are feeding non dedicated clock pins, and this is effecting on the jitter, so the time performances are degradated....On the time quest analyzer I see that for the PLL output c0 there is a maximum frequency of about 460 MHz.....The pins I am actually feeding are just clock output pins on a specific HSMC connector on my development board. Let´s assume that I cannot drive those pins correctly with the ALTPLL megacore, the warning says that in zero-delay buffer mode the jitter could be compensated. Now I don´t know how this exactly works, I have read a short explanation on the guide but an example could be much more illuminating for me. Is there a source where I can see how I can use this PLL configuration? I have seen that two new pins are added (fbin, fbout) to the block but I don´t know how I should connect them.  3) About the usage of LVDS dedicated megacore functions, I see difficult to reach my interleaving in that way. Let´s say I transmitt 32 bits and I apply a serialization factor of 2, I then have my interleaved data in output, but an output data clock which is the half of the original. If I would like to go for this implementation I suppose I should double the data rate before this block, in order to get the interleaved data with the right frequency, but then I would have to manage 1.5 GHz, which I suppose it´s not internally reachable.  Just in order to give you an overview of my design, I attach here the data format to be delivered to my DAC board, and a schematic of my design.