Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

How does one verify the SDC constraints?

Altera_Forum
Honored Contributor II
2,443 Views

When one writes VHDL it is possible to use testbench to determine if the code functions as intended, with C/C++ program one can also use test cases. How does one verify timing constraints? How does one know if they have bug in them?

0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
1,373 Views

You can't "verify" in that way. You must be careful and considered when you apply timing constraints. I suggest peer review - get someone else to look over your constraints to ensure they make sense. 

 

Quartus should identify invalid constraints - i.e. constraints that make no sense or have no relevance to the code you're compiling. Always address these warnings as it, almost certainly, means party of your design is not constrained. 

 

Also pay particular attention to constraints that are not met. This may simply point to an area of your logic Quartus is having difficulty with. However, it may point at an 'error' in a constraint - one that is poorly thought through and could never be achieved. 

 

Cheers, 

Alex
0 Kudos
Altera_Forum
Honored Contributor II
1,373 Views

Good question. I think there are some tools that can do some verification(spyglass cdc) but I don't think they can fully test all cases. (If your data coming in changes every other clock cycle, a multicycle may be appropriate, but 3rd party tools can't know that). One thing I think that should be done is a random delay assignment, so if a path is is false path'd it can have some random delay throughout the simulation, and if it's a multicycle it can vary over the multicycle range. I don't create simulations so don't know how this is done, but curious if others do it. I've never heard anyone say they added a multicycle and the modified their testbench to test for this.

0 Kudos
Altera_Forum
Honored Contributor II
1,373 Views

One simple thing I do to "verify" timing constraints is to constrain the design in a way that I know WON'T meet timing (for example, set an input or output delay to a value that can't possibly be met). Then constrain the design in a way that can easily be met. In each case TimeQuest should indicate a pass or fail condition. If it doesn't, you know something is amiss. This won't catch everything, of course, but I've uncovered a number of errors this way, including errors in my own thinking about how a particular timing constraint works.

0 Kudos
Altera_Forum
Honored Contributor II
1,373 Views

After some bad experiences with temperature dependent timing bugs we started to do full temperature cycle test over a limited (not full) industrial temperature range for each firmware release. When it fails you know you probably have a bug in the SDC constraints. Unfortunately when it passes you only know that this specific firmware build works on this specific board. We have not yet reached a confidence level in our SDC files that we can skip the temperature tests once a release passes. We had a case where small internal changes on a previously successfully tested design passed the STA but failed the temperature test. Temperature testing each release is expensive but still magnitudes cheaper than discovering it in the field.

0 Kudos
Altera_Forum
Honored Contributor II
1,373 Views

 

--- Quote Start ---  

One simple thing I do to "verify" timing constraints is to constrain the design in a way that I know WON'T meet timing (for example, set an input or output delay to a value that can't possibly be met). Then constrain the design in a way that can easily be met. In each case TimeQuest should indicate a pass or fail condition. If it doesn't, you know something is amiss. This won't catch everything, of course, but I've uncovered a number of errors this way, including errors in my own thinking about how a particular timing constraint works. 

--- Quote End ---  

 

 

I am not sure I understand what your method means. The idea of i/o timing constraints or any internal constraints is that they must be correct first for your design then see if the design passes timing. correct constraints entry is designer's responsibility and the tool can not know that. If you imply that you just enter some random i/o constraints until timing passes then that defeats the purpose completely and it could be either a false pass (or false failure). 

Thus timing closure is only as much correct as your entry is.
0 Kudos
Altera_Forum
Honored Contributor II
1,373 Views

 

--- Quote Start ---  

When one writes VHDL it is possible to use testbench to determine if the code functions as intended, with C/C++ program one can also use test cases. How does one verify timing constraints? How does one know if they have bug in them? 

--- Quote End ---  

 

 

if you mean sdc syntax check then the tool kindly stops with a strange message saying "cannot fit design" if it encounters syntax error. 

additionally it warns if it doesn't find a path in sdc command. 

 

If you mean checking sdc commands functionally then it is your responsibility as designer to specify the correct constraints. 

most difficult ones are multicycle and io 

 

multicycle can be checked by adding after statement for one clock delay or more if feasible in your functional simulation provided you have a pass/fail flag. 

But it needs to be random as well across various registers and this by itself could be too laborious but is ok for few registers case. 

 

The alternative to STA(static timing analysis) is timing simulation but still you need sdc constraints for the design to get correct delays. You then need pass/fail flag against a reference mode just as functional simulation. But timing simulation is way too length to be practical for any project. Even then your io behaviour depends on some other variables such as temperature/voltage and a check over all corners is not realistic with timing simulation.
0 Kudos
Reply