Timing Constraints Material

[Altera_Forum]

Hi, 

 I was wondering if anyone could direct me to material that goes into more detail about timing constraints in QII. As my designs get larger and more complex, I run into more and more timing closure failures. Specifically, things like:  1) how to best to choose global constraints like Tsu, Th and Tco 2) how to deal with small sections of problem logic that doesn't meet global timing 3) how to deal with IP like NIOS or MegaFunctions that don't meet timing 4) how to best manage multiple clock domains  Altera's literture does little more than tell you what menu items to use.:confused: I need more detailed explanations of when, why and how to determine the numbers.  Thanks!

[Altera_Forum]

The quick answer is the QuartusII handbook, volume 3 - Verification, section II - timing analysis. 

http://www.altera.com/literature/lit-qts.jsp  The whole handbook is 31 MB and has plenty of detail. Keep in mind the synthesis, place and route engines have plenty of discussion about meeting timing, because much of that is timing driven. Timing Analysis is separate. Also be mindfull that there are two paths to go down for timing analysis, classic and TimeQuest. Choose up front which way to go. If you only want some basics, like global clock domains, clock-to-out's, and Tsu's, Classic is fast and easy. If you want more in depth, TimeQuest has the power.

[Altera_Forum]

To answer more specific points: All of my IP meets timing. I would recommend that to be a good goal. [Although I'm not using NIOS] If your multiple timing domains are giving plentiful invalid errors, I would recommend first put more effort into clock bridges, and if you still need to switch to TimeQuest. By clock bridging I mean if you have a signal that goes from one clock domain to another and you have verified it is OK because the design tolerates the signal captured to the new clock domain on no particular clock edge, then sample the signal to the new clock domain, or edge detect (as a minimum). Then you will have a single register in the old domain going to a single register in the new domain, which will be easy to give a different timing assignment that works for you, ignore or min for example. If you can't relax timing requirements, that implies you need dual clock fifo's or the like. 

If this isn't clear, shoot me an email and I'll find the right chapter in a VHDL/verilog book for some good reading about clock domains... The Quartus handbook has enough reading to cure a month's worth of insomnia.:)

[Altera_Forum]

--- Quote Start ---  [T]here are two paths to go down for timing analysis, classic and TimeQuest. Choose up front which way to go. If you only want some basics, like global clock domains, clock-to-out's, and Tsu's, Classic is fast and easy. If you want more in depth, TimeQuest has the power.  --- Quote End ---     If you are already familiar with the Classic Timing Analyzer and have only simple needs, then it's fine to stick with it for now.  If you aren't particularly experienced with the Classic Timing Analyzer already, then consider using TimeQuest no matter how simple your needs.  Even though "TimeQuest has the power," TimeQuest is easy to use if what you need to do is simple. (It can seem hard for simple things if you are already experienced with the Classic Timing Analyzer, but that's only because TimeQuest is new to you.) If you are learning an analyzer regardless of which one you choose, you might as well use TimeQuest because it will be the one to use for future device families and because it can handle more things that could come up in your designs even in current device families.

[Altera_Forum]

I like examples better than the manual. This link shows examples which make TimeQuest basics fast and easy for people who read like I do: 

http://www.altera.com/support/examples/timequest/exm-timequest.html  Recommendation: maintain your own SDC file and don't let TimeQuest overwrite it. Timeuest's outputs have horrible style.

[Altera_Forum]

--- Quote Start ---  1) how to best to choose global constraints like Tsu, Th and Tco 2) how to deal with small sections of problem logic that doesn't meet global timing  --- Quote End ---     1) You need to choose your I/O timing constraints based on the tco/min tco of the devices driving the FPGA, the tsu/th of the devices driven by the FPGA, clock skew on the board, and data delay on the board. (If you don't know the board delay numbers, then make your constraints a little tighter than they would be calculated from just the external device I/O timing.) I haven't looked at this in the Quartus handbook in a while and don't remember how much how-to detail is there, but I found some basic information with just a quick check. In the Volume 3, Section II mentioned in the other post, I found calculations of input and output delays (correspond to tsu and tco) using the board and external-device information in Chapter 8. This is the Classic Timing Analyzer chapter, but the calculation is the same for TimeQuest (Chapter 6 for TimeQuest might have the same thing). Chapter 7 has some information on how the input/output delay forms of these timing constraints correspond to the tsu/th/tco/min tco forms of the constraints.  2) If your timing constraints are correct (including any applicable timing exceptions like multicycles and false paths), then how to deal with timing violations is an issue separate from timing constraints, choice of timing analyzer, etc. The solution to your problem can range from simple to very complex. There is probably no document that tells everything on this subject, but there is some material in the Quartus Handbook in Volume 2, Section III, "Area, Timing and Power Optimization".

[Altera_Forum]

--- Quote Start ---  Recommendation: maintain your own SDC file and don't let TimeQuest overwrite it. Timeuest's outputs have horrible style.  --- Quote End ---     Expanding on that important point...   None of the following specifically addresses your original questions, but I wanted to cover this here since Randall brought up the write_sdc issue.  do not use write_sdc to overwrite your .sdc file. That's not what the command was meant for (even if you see it used that way in examples or tutorials). If you are starting off creating constraints in the GUI, then you might want to use write_sdc to create your initial .sdc file, but you will still get that "horrible style". More likely, you will want to copy the constraints you entered in the GUI (whether by typing in the Console or through dialog boxes) to the .sdc file you are creating yourself.  Rather than as a means to create an .sdc file you will subsequently use as an input to TimeQuest, think of write_sdc more as a way to see how TimeQuest is interpreting your constraints (how it is expanding wildcards, how it is converting derive_pll_clocks to generated clocks, etc.). If you just want to see how your constraints were interpreted, you will probably prefer "Report SDC" under "Tasks --> Reports" in the GUI. The result will be listed at "Report --> SDC Assignments".  When copying GUI-entered constraints to your .sdc file, copying them one by one from the Console has the advantage that you'll notice any warnings for problem constraints. If you've entered a lot of constraints, you can right click in the History tab and do "Save to File" to get them all at once in a form that makes it easy to copy to your .sdc file without having to strip out the extra Console lines. The History tab just won't flag the constraints where TimeQuest already found problems.  Even if you like to create your constraints in the GUI instead of typing them from scratch, give the SDC File Editor in TimeQuest a try. (Use version 7.1 to get the latest enhancements.) You can still use the dialog boxes like "Set Input Delay" from within this special text editor to create the constraints instead of typing them; the dialog boxes copy the constraint to the file automatically. After an SDC command is in the file, hover the mouse over the command to see a tooltip showing the command syntax. (The Quartus file editor will give you Tcl color coding for things like comments, but it won't create SDC constraints for you or display SDC tooltips.)  By the way, that History tab is also a good way to create the starting point for a Tcl script that does all the steps like project_open, create_timing_netlist, read_sdc, etc. After you have a script in the project directory, it will be listed on the "Script" pull-down menu where you can run it easily.

[Altera_Forum]

Thanks Gentlemen for your generous responses! I'll look again at the Altera literature, though I always found it to be slim on details. They tend to stick with things like "Enter Tsu and press return." 

 I am doing full handshakes between clock domains where the single word to be transferred is held until the receiving state machine acknowledges.   The problem is that I am getting no errors in QII in functional or timing sims. Then if I use SignalTap on chip, it works fine. Remove SignalTap and it fails ... meaning none of the signals respond. Very frustrating as I can't diagnose in the absence of signals.  I use the classic analyzer only to specify general Tsu, Th and clocks. I'll look into TimeQuest

[Altera_Forum]

That sounds like a solid design. The Ack from the receivng state machine should be the active no sooner than the clock cycle after the received word was used. When Signal tap breaks something, it very well could mean there is a timing boundary not covered. If the receiver is the slower clock, it would add robustness to edge detect the receiver's Ack back into the faster clock domain. It's harder to toss out usefull ideas without seing the whole picture, but those are a couple thoughts that come to mind.

[Altera_Forum]

I wonder if there are additional, maybe unintended, paths between clock domains that aren't covered by the handshaking. 

 "Report Clock Transfers" in TimeQuest reports the number of paths crossing between domains. Maybe this number would give a clue whether more is going between domains than the paths qualified by the handshaking and the handshaking signals themselves.  The intended cross-domain paths might have false-path settings. To check for additional, unintended paths for the same domain combination, the false-path setting will need to be removed temporarily to get a path quantity shown in the table.  Even though the design is currently using the Classic Timing Analyzer, the TimeQuest "Report Clock Transfers" command will probably work well enough with whatever the QSF2SDC utility produces. Open TimeQuest and let it run that conversion when it asks (or run "Constraints --> Generate SDC File from QSF" if it doesn't ask). Then double click "Report Clock Transfers" in the "Tasks" pane.  The Classic Timing Analyzer also might be failing to report timing on paths that either need the timing analyzed or need handshaking added for them. If that analyzer considers two clock domains to be unrelated, the default settings will not analyze timing on paths between those domains. TimeQuest by default will analyze timing on all cross-domain paths until the user explicitly adds false-path exceptions for them, so TimeQuest is more likely to report a timing violation on an unintended cross-domain path.

[Altera_Forum]

Hi all, 

 Just wondering what the default behavior of the timing analyzer would be when no constraints are specified ? , and how it would effect the fitter ?  Specifically i would like to know what happens in the case where i use the standard NIOS 2 design demo and add some custom logic to it . The standard design does specify some constraints and when i add my design ( a custom instruction ) to it , since it does not have any constraints it is reported as unconstrained. but there does not seem to be any other type of error.   if constraints are not specified for those paths does that mean that the timing analyzer skips them ?  any help is much appreciated ?