Most of the verification engineers start their career as an HVL expert. They reaslise the importance of Assertion Based Verification, only when they become seasoned verification engineers, especially when they take the complete ownership of RTL sign-off.
We all know that assertions are good for implementing the protocol checkers. But only very few in the industry knows how to use assertions to debug the design issues. I am writing this article mainly to motivate the designers to learn ABV and help the verification folks to debug the design easily.
Whether you are a desgn or verification engineer, you should know "Debugging the testcase failures becomes nightmare, if there are no assertions embedded in the design".
Let us take a look at controller verification. A complex controller is usually implemented as FSM, composed of many states. It's very important to make sure that the FSM does not get into any dead lock condition. Dead lock means FSM loops into a particular state/states forever due to an unexpected condition. How can you debug when the simulator hangs due to FSM dead lock?
You would get only timeout error,only if your testbench is really smart enough to kill the simulation, using some watch dog timers. But still it does not tell you why it happens.
But one can easily identify even this kind of FSM dead lock issue using assertion. Assertion languages have the feature called 'Eventually' and using the strong flavour of the same one can easily write the assertion and capture this bug.
PSL Example:
Property_Dead_Lock_Check : assert always ( (INIT_STATE) -> eventually! (INIT_STATE) ) @ (negedge clock);
Since the simulator hangs, you have to kill the simulation process which is running forever. The easiest way is 'CTRL+C'. This assertion fails and produces error message beautifully when the OS terminates your simulation and more importantly it tells you exactly which IP, which cluster and which instance of the FSM module has the issue. What else you want to debug your SoC?
