How do I constrain ALTLVDS I/O? :confused: chik "in the abundance of water, the fool is thirsty." - Bob Marley

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

Thanks for the suggestion. But I can't find anything about this in Altera's documentation. What am I missing? There's nothing in ALTLVDS user's guide or the timing sections in the Quartus II handbook. Is there any documentation on this? :(

Timing constraints for ALTLVDS I/O | Altera Community

21 Replies

Altera_Forum
Honored Contributor
19 years ago
--- Quote Start ---
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
--- Quote End ---

If you want to make a request for documentation enhancement request or edits, you can always file a Service Request on MySupport and it will reach the appropriate "powers" within Altera.
Altera_Forum
Honored Contributor
19 years ago
That's all very nice, But with a Cyclone 1 or 2 device we don't have all that luxury and everything needs to be built from soft logic. And that's where STA and TimeQuest could have their use. And that's where you need to tweak Tco and Tsu times .

Best regards,

Ben
Altera_Forum
Honored Contributor
19 years ago
Guys,

Great info! :D Luv it! :D :D :D But where is it in the documentation?

“Emancipate yourselves from mental slavery. None but ourselves can free our minds Won't you help to sing The songs of freedom?”
- Bob Marley
Altera_Forum
Honored Contributor
19 years ago
All of the information from this thread is in the documentation. To your point, however, it isn't at all clear and it is spread across multiple documents.

"Don't worry bout a thing, cause every little thing gonna be all right" if you follow the guidlines outlined in this thread.

I would file a Mysupport case asking for clearer documentation on this topic. I will do the same.
Altera_Forum
Honored Contributor
18 years ago
--- Quote Start ---
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.
--- Quote End ---

As Jim's complete post said, TimeQuest has enhancements for this in version 7.1. However, the Classic Timing Analyzer has supported this since years before it became "classic". It's just not obvious because you use a constraint that usually has a different purpose.

From the QII 7.1 on-line help page entitled "Input Maximum Delay timing assignment":

--- Quote Start ---
In designs that use the LVDS I/O standard, you should specify the appropriate Input Maximum Delay to the LVDS receiver megafunction. This input delay should equal the transmitter channel-to-channel skew (TCCS) plus any board skew.
--- Quote End ---
Altera_Forum
Honored Contributor
18 years ago
that help page i quoted is out of date. I was told that there was a change to the Classic Timing Analyzer that might make what the Help page says to do no longer work, so I did a quick check. If I did it correctly, the input maximum delay setting does not work for this purpose anymore. "List Paths" for the reported RSKM still said, "Info: LVDS transmitter channel-to-channel skew is 0.000 ns". It should have listed the external device TCCS that I put in my setting.

If you are using the Classic Timing Analyzer for a design containing an LVDS hard-silicon SERDES receiver, you can manually adjust the reported RSKM values for the TCCS at the FPGA inputs.

if you want rskm to be fully calculated by the tool, then the following procedure might be good enough to keep you from having to convert to TimeQuest for everything just to report RSKM. It worked easily enough for my little test case, but it's more trouble than a manual calculation. If you're starting a new design with an LVDS receiver and care about this, I'd recommend using TimeQuest for everything from the beginning.

Run the Classic Timing Analyzer.

With the project open in Quartus, open TimeQuest.

If TimeQuest doesn't ask for permission to create an .sdc file, run "Constraints --> Generate SDC File from QSF".

Optional step to check your TimeQuest setup: Run "Tasks --> Report RSKM". The values at "Report --> RSKM" should match those in the "RSKM (Receiver Input Skew Margin)" table in the Classic Timing Analyzer report. TimeQuest can do a more detailed analysis than the other analyzer does, so the margins might be slightly better in TimeQuest than in the other analyzer for Stratix III. The margins will be identical for some--I suspect all--other families.

Now you need to add set_input_delay constraints to tell TimeQuest the TCCS of your external transmitter adjusted by your board skew:
The Quartus on-line help page entitled simply "report_rskm" has an example (find the page using "report_rskm" on the Help Search tab).
You can use "Constraints --> Set Input Delay" in TimeQuest to do it with a dialog box. In the dialog box, "Clock name" should be the clock associated with the SERDES clock input device pin (it should be in the drop-down list). "Targets" should be the SERDES serial input device pins. These pin names are in the Classic Timing Analyzer "RSKM (Receiver Input Skew Margin)" table.
I think the absolute magnitude of these constraints doesn't matter, just the difference between them. If you know the delta you want but don't know the "real" max and min magnitudes, just make sure that the delta between the max and min constraints is the skew across your SERDES inputs right at the FPGA input pins (net effect of both the TCCS of the external device and the board skew).

Run "Tasks --> Report RSKM". The margin should be smaller by half the delta between the max and min values you entered for TCCS. (The report_rskm help page says, "RSKM = (TUI - SW - TCCS) /2".)
Altera_Forum
Honored Contributor
18 years ago
If the online Help says that the value of the set_input_delay -max is is equal to the TCCS, then it is incorrect. It is the relative difference between the set_input_delay -max and set_input_delay -min that is used for TCCS for the transmitting device. The absolute numbers used for these two settings do not matter.
Altera_Forum
Honored Contributor
18 years ago
The Help page wasn't clear whether to use the Input Maximum Delay setting alone (what I thought it meant for this purpose) or in combination with Input Minimum Delay to create a delta that equals TCCS like with TimeQuest. I tried both ways--neither worked. I tried only QII 7.1, but what I was told sounded like Classic Timing Analyzer support for this was dropped a while back. I think TimeQuest is the only way to do it now without a manual calculation to account for the external TCCS.
Altera_Forum
Honored Contributor
18 years ago
Yes, I thought I stated that earlier. This method only works in TimeQuest and for version 7.1 and later. In TAN, to my knowledge it has never worked this way. You always had to manually subtract your TCCS from the RSKM value reported for the reciever.
Altera_Forum
Honored Contributor
18 years ago
This did work in the Classic Timing Analyzer in the past, but it might have been a long time since it last worked. The Help page is just out of date to still say it can be done with the Classic Timing Analyzer.

My previous post reworded for clarification about which Help page I referred to:

The Classic Timing Analyzer Help page wasn't clear whether to use the Input Maximum Delay setting alone (what I thought it meant for this purpose) or in combination with Input Minimum Delay to create a delta that equals TCCS like with TimeQuest. I tried both ways--neither worked. I tried only QII 7.1, but what I was told sounded like Classic Timing Analyzer support for this was dropped a while back. I think TimeQuest is the only way to do it now without a manual calculation to account for the external TCCS.

The TimeQuest Help page is clear that TCCS is the difference between the set_input_delay -max and set_input_delay -min values in that analyzer.

Forum Discussion

Timing constraints for ALTLVDS I/O

21 Replies

Recent Discussions

The quartus license works with version 25.0 but not with version 17.0

Quartus did not start

Docker image for Quartus Pro 26.1 missing ?

Timing analysis - long combinational path

timing violation fix