Timing constraints for ALTLVDS I/O

[Altera_Forum]

How do I constrain ALTLVDS I/O? :confused: 

  chik  "in the abundance of water, the fool is thirsty."  - Bob Marley

[Altera_Forum]

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.

[Altera_Forum]

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

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

[Altera_Forum]

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

[Altera_Forum]

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? :(

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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

 Cheers, The Flying Scotsman

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

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]

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]

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]

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

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]

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]

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]

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]

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.

[Altera_Forum]

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! =)