- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How do I constrain ALTLVDS I/O? :confused:
chik "in the abundance of water, the fool is thirsty." - Bob MarleyLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm interested in timing constraints for ALTLVDS I/O.
-------------------- “Herb is the healing of a nation, alcohol is the destruction.” - Bob Marley- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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? :(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I couldn't see anything either. Let me know if someone finds it.
Cheers, The Flying Scotsman- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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 ---
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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! =)- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page