Timing constraints for ALTLVDS I/O

Actually, there's no need to constrain the LVDS blocks in Altera devices. This is a hard IP block that has been characterized and guaranteed to work. The timing information is contained in a marco model... This simply means the individual delays within the LVDS block is lumped into a few large delays. Unlike the individual logic and interconnect delays you would get in the FPGA core.

TimeQuest does provide two timing reports that allow you to report LVDS specific info: report_rskm and report_tccs.

Input into the LVDS block - report_rskm

This command works when a hard LVDS has been instatinated in the design.

In designs that use the LVDS I/O standard, receiver input skew margin (RSKM) is the time margin available before the LVDS receiver megafunction fails to operate. RSKM is defined as the total time margin that remains after subtracting the sampling window (SW) size and the transmitter channel-to-channel skew (TCCS) from the time unit interval (TUI), as expressed in the following formula:

RSKM = (TUI - SW - TCCS) /2

The time unit interval is the LVDS clock period (1/fMAX). The sampling window is the period of time that the input data must be stable to ensure that the data is successfully sampled by the LVDS receiver megafunction. The sampling window size varies by device speed grade. TCCS is the difference between the fastest and slowest data output transitions, including the tCO variation and clock skew. In order to obtain an accurate analysis of an LVDS circuit, you should assign an appropriate Input Delay to the LVDS receiver megafunction. TCCS will be equal to the difference between max input delay and min input delay. If no input delay is set, TCCS will default to zero. So, to set the TCCS parameter, above, use the set_input_delay -max and set_input_delay -min => TCCS = delay_max - delay_min.

Output of the LVDS block - report_tccs

In designs that use the LVDS I/O standard, transmitter channel-to-channel skew (TCCS) is the timing difference between the fastest and slowest output transitions, including tCO variations and clock skew.

Also, this is a pretty cool feature in Quartus.... go to the command prompt and type: quartus_sh --qhelp. You'll get a nice dialog box listing all Command Line and API info. Take a look at the sta and sdc packages! =)

Location constraint? You can do that by just setting a location constraint to either one of the differential pins. Quartus will hook up the other half of the differential pair to the complement pin automatically. (Actually, this is evolving a bit. Altera has traditionally treated a differential assignment as any other I/O standard assignment and you never even saw the "two-pins" aspect of this until you got the pinout report. That's changing with recent Quarts versions where a differential I/O buffer primative has been introduced).

If you're asking about constraining in a more general "how do I set this up" sort of sense, then the answer is to run the Megawizard. There are a lot or parameters for the ALTLVDS function and there are enough dependencies and limitations that just calling out the primative in your HDL is asking for trouble. Just run the wizard and instantiate the generated wrapper file in your HDL project.

I'm interested in timing constraints for ALTLVDS I/O.

--------------------

“Herb is the healing of a nation, alcohol is the destruction.”

- Bob Marley

My technique is simple:

For LVDS inputs, first set a Tsu constraint of 0.1ns and compile. Thus will give you Tsu violations on the LVDS pins. Look at the longest actual Tsu delay, and remember it. Then, go back to the Assignment Editor, and change the 0.1ns Tsu constraint to this longest actual delay you just memorized (round up to the nearest 100ps, if you want) and compile again. This makes sure that all Input Delay Chain lengths are set to 0 on all LVDS inputs you have constrained this way.

For LVDS outputs I use the same technique: put a Tco constraint of 0.1ns on the outputs, compile, remember longest Tco delay, then set Tco to this delay (again, round up to 0.1ns) and you should be all set.

Hope this helps,

Ben

hippi_chik,

I am absolutely sure that all of this can be officially be backed through the documentation, but I'll be darned if I'm going to search for it in the 2800 pages of Quartus, and 1300 pages of Cyclone/CycloneII/CycloneIII documentation ;-)

As such, I think that it's usually easier to build a quick stub design and look at the results Quartus gives you. Given that you've built a stub design it'll be quick to compile if you're toying with assignments or alternative logic constructs.

Dude,

Chill-out. You're deg-ging my spliff. There was no expectation for you to search the documentation. I was simply stating my truth. Jah!

ie no info in the Timing Sections of the Quartus handbook and no info in the ALTLVDS user guide.

“I've been here before and will come again, but I'm not going this trip through.”

-BoB Marley

Hopefully the powers at Altera will see to fix this.:p

“The more people smoke herb, the more Babylon fall.”

-BoB Marley

I couldn't see anything either. Let me know if someone finds it.

Cheers,

The Flying Scotsman

Hippi Chik,

THis is a frustration for me as well. When using ALT_LVDS you need to use the following equation.

RSKM = UI - TCCS - SW - tEXT

UI = Unit Interval

TCCS = Channel-to-channel skew

SW = sampling window

tEXT = Trace mismatch

TCCS and SW are numbers that Altera provides in their data sheet. You can not use Tsu and Th numbers when using ALT_LVDS receiver. The ALT_LVDS receiver uses special circuitry to balance the sampling window in the middle of data. When you configure the ALT_LVDS block you are configuring a lot of hidden "stuff" in the block that ensures that the SW is within the published spec. SW has been characterized across PVT and is a 'guaranteed' number.

You can think of SW as a balanced Tsu and Th number.

Remember that these equations apply to the whole interface, but they can be used on a bit by bit basis.

This is a complicated issue so if I didn't answer the question let me know. I have spent a lot of time with Altera applications on this question because it is very confusing.

This only deals with the ALT_LVDS receiver. If you are in a mixed system with other devices the answer can be a little different. THis is all documented in teh various device handbooks under "High-Speed Interfaces".

FPGA Guy is correct. Let me expand upon this a little however.

First of all, I assume you are talking about timing the ALTLVDS when DPA is not enabled. If DPA is enabled, the clock is centered in the data valid window dyanamically, therefor timing analysis doesn't make sense and cannot be performed.

You cannot use traditional setup/hold analysis on ALTLVDS I/Os. This is not supported in the Classic Timing Analyzer, nor in TimeQuest, nor are there any plans to support this in the future. RSKM analysis must be used instead as FPGA Guy pointed out and showed the formula for.

The problem (currently) with this method is that there is no way to specify the channel-to-channel skew from an external transmitting device when the Altera FPGA is the receiving device. You will notice that for the receiver, TCCS is reported as 0. This is currently true for both timing analysis engines.

The good news is that in the next release of Quartus II software (7.1), TimeQuest will support two new STA Tcl commands, report_rskm (for receivers) and report_tccs (for transmitters). For the recievers, it will use the difference between the set_input_delay -max and the set_input_delay -min constraints as the TCCS value, allowing you to specify the skew on your input data bus. Very cool. For the transmitters, report_tccs will return the transmit channel skew at the output ports.

Jim