LVDS clock and data signals, interfacing to LVDS DAC

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.

--- 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

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.

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.