Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
As I know, the assertion exits in C for long time.
In debuging software, you see the output of function that is wrong.
This cause may be the bug in implementation of this function.
But sometime, it is already wrong in the input.
The garbag in, the garbag out.
You spent a lot of time to debug your function but it is right.
Finally, you find the bug is not in this function. What you think?
In C(as I know), you can use assert function to check input of function is valid.
If it is not valid, display some message!
In this way, you almost locate which function has bug.
Recently, this idea is used in hdl.
Since the hw is parallel working, the thing to check is not only valid of data range but also the sequence of signals.
It is suit to check the protocol of bus.
In the past days, you must write a monitor to monite the validation of bus protocol.
It may be write in hdl or other language, the effort to write this monitor is most equal to design a module.
Using PSL(assertion language), the bus protocol can be desribed in few lines.
It is just like to describe the timing diagram.
This is a kind of usage of assertion.
It is more powrful with formal to do static verification.(no test pattern required)
Assertions are non-synthesizable portions of your code (either RTL or behavioral). They have only pre-silicon verification significance.
What you generally do in an assertion is a small check with your set of signals. As all simulators or hardware description languages support assertion based verification, they generally give you a set of keywords or library functions to key in your assertion.
Examples could be that you expect two signals to always be mutex.
Or you expect a condition of (A AND B AND C) never to happen at any given point of time.
Later when you run your functional simulation vectors and regress it enough, the assertions will quit simulation saying either your mutex or your forbidden assertions were not held true. You then re-simulate to find where and which signal was the culprit
Briefly -
Consider that we have a system. We can describe it using it's properties (to put it more precisely - we what our system to have such properties). And then we assert that property is maintain within designed project. Using different tools we can verify is the assertion really TRUE. If it is then our project was designed correctly.
For example: system - 2and-gate (out = a and b). One of the properties of that system is - "when at least one input is 0 then the output is 0 to". We make corresponding assertion. And our tools check it. During modeling if we get wrong output (in respect to the assertion) the tool will alarm.
The following example shows the benefit of using assertion in addition to digital
simulation. Assertion uses a symbolic language to infer the rules applaying to
a design. Lets decribe the rules for a RAM interface using assertions:
1) CS must be active during READ or WRITE
2) READ and WRITE are mutually exclusive
3) WRITE must be active for two clocks
Let suppose WRITE has a bug and is implemented three clocks long.
Functional simulation will not see the bug because a longer WRITE
pulse is OK for the RAM and the functionality is not affected.
The WRITE assertion will immediatly detect this bug.
This bug will have show up later as a performance issue in the final product.
to add assertion verifies in two ways
static (without simulation) and dynamic while simulation.
static or formal verificatin can be done in case of control logic where verification state space is not expanding too fast. otehrwise tool capicity will be over loaded.
cadence IFV tool does formal verification using Assertions. That is it checks the design with random values for those assertions specified in the design.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
