How does one verify timing constraints?

Code will often have bugs that need to be found and fixed. While there are obvious ways in how to verify VHDL and C/C++ programmes, what method exists to verify and debug timing constrainints e.g expressed in SDC format in Altera TimeQuest?

syntax errors will throw an error in the synthesis tool
incorrect net names will throw warnings about nets not existing.
As for the timing, thats something you need to specify.

matrixofdynamism said:

Code will often have bugs that need to be found and fixed. While there are obvious ways in how to verify VHDL and C/C++ programmes, what method exists to verify and debug timing constrainints e.g expressed in SDC format in Altera TimeQuest?

Click to expand...

there are tools that help you manage design constraints. I have never used one myself but they do exist. This is a big issue for SoC type of chips, where someone has to take ownership of all the SDCs used in all different scenarios and different blocks. It's more of a data management problem than anything else.

One verification step for timing constraints is to check the unconstrained paths and make sure it is empty or the paths that do exist are there on purpose, e.g. a static output pin that is driven to 1 or 0 only.

ads-ee said:

One verification step for timing constraints is to check the unconstrained paths and make sure it is empty or the paths that do exist are there on purpose, e.g. a static output pin that is driven to 1 or 0 only.

Click to expand...

agreed. this is like a sanity check that can be done very early. but then things get complicated really fast. you can have constraints that set the same property twice but with different values. if two different designers wrote them, it is going to be a nightmare to debug.

ThisIsNotSam said:

agreed. this is like a sanity check that can be done very early. but then things get complicated really fast. you can have constraints that set the same property twice but with different values. if two different designers wrote them, it is going to be a nightmare to debug.

Click to expand...

Its not just the same property with different values, different properties on the same path have a preference order.
1. False Paths
2. Min/Max delays
3. Multicycle constraints

So no matter what order you specify them, a false path always wins. But compile order comes into effect when you specify two max delays for example.

matrixofdynamism said:

Code will often have bugs that need to be found and fixed. While there are obvious ways in how to verify VHDL and C/C++ programmes, what method exists to verify and debug timing constrainints e.g expressed in SDC format in Altera TimeQuest?

Click to expand...

I prefer the following:
1.) Include the timing score in the FPGA programming file. My designs use 1 BRAM (4kB) to store either a 4kB text file, or a 4kB compressed text file. I then include whatever build/design info I want within this BRAM.
2.) Perform some sanity checks in the sdc/xdc file where possible. For example, ensure some constraints constrain a non-zero number of paths. Basically, if a clock is renamed/removed you should be able to detect it. This means writing something in TCL. (sarcastic) Yay!
3.) Check logs to ensure constraints are not ignored. Ideally this gets moved to #2 over time.
4.) Ensure clock names and other constraints are human-readable and assumptions are well commented.
5.) Where possible, avoid set_false_path. In tools supporting set_data_check, you almost always want that. I'm not sure if Altera has this. I attempted to check, but the documentation site hangs when I try to access it.
6.) Avoid set_multicycle_path unless a testbench can verify this AND the design makes it clear where multicycle paths exist. Either by having clock enabled that are periodically generated, or by having the entire multi-cycle path within a module.
7.) For any high-speed IO interface, provide a mechanism to report on IO status at runtime. Many interfaces can be placed into a test mode for this purpose. Inputs can usually use IO features to measure these things.
8.) Understand the IO requirements of any device you connect to and follow interface requirements. For example, you can have interfaces with a negative setup time. You can have interfaces where hold time is longer than a half-cycle.

I dont use TimeQuest, hopefully it has kinda report or messages saying about XDC file mistake.
Vivado has it. Easy to follow and correct the constraints which are missing.

Since you dont use a verification tool for XDC, you need to handle manually:
1/ Take care of your over constraint of set_false_path and set_multicycle.
2/ Clocks definition, master and generated
3/ Boundary constraint - input/output delay with correct delay number.
4/ Assynchronous paths with false_path or not
5/ Derate, margin, clock uncertainty

Those things basically cover almost quality of a SDC file.

I see, the nature of constraints is that they are arbitrary and as thing stand are to be checked by humans. They cannot be generated from tools expect in few cases where we can derive_pll_clocks derive_clock_uncertainity and things like that which basically reduce the number of commands we have to enter ourself.

matrixofdynamism said:

I see, the nature of constraints is that they are arbitrary and as thing stand are to be checked by humans. They cannot be generated from tools expect in few cases where we can derive_pll_clocks derive_clock_uncertainity and things like that which basically reduce the number of commands we have to enter ourself.

Click to expand...

For the majority of designs, this should cover just about everything (except any IO constraints you need).
With a clock set up, derive_pll_clocks then genreates te correct setup for the other clocks which can then check all the synchrnous logic in your design.
Complicate SDC files are usually only needed when you start getting timing problems or lots of clock domains you need to cross.