Scribd
Upload
52 views3 pages

Assertion Interview Part 1 1728124740

Uploaded by

jqz4bnq5nf
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
52 views3 pages

Assertion Interview Part 1 1728124740

Uploaded by

jqz4bnq5nf
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Q1.

What is an assertion and what are the benefits of using assertions in


Verification?
An assertion is a description of a property of the design as per specification and is used to
validate the behavior of the design. If the property that is being checked for in a
simulation does not behave as per specification, then the assertion fails.
Similarly, if a property or rule is forbidden from happening in the design and occurs
during simulation, then also the assertion fails. Following are some of the benefits of
using Assertions in Verification:
a) Assertions improve error detection in terms of catching simulation errors as soon a
design specification is violated.
b) Assertions provide better observability into design and hence help in easier debug
of test failures.
c) Assertions can be used for both dynamic simulations as well as in formal
verification of design
d) Assertions can also be used to provide functional coverage on input stimulus and
to validate that a design property is in fact simulated.
In Short:
a) Verify design functionality.
b) Detect bugs early.
c) Improve design reliability.
d) Reduce simulation time.

Q2. What are different types of assertions?


There are two types of assertions defined by SystemVerilog language –
a) immediate assertion
b) concurrent assertion
c) Deferred assertion
Q3. What are the differences between Immediate and Concurrent assertions?
Immediate assertions use expressions and are executed like a statement in a procedural
block. They are not temporal in nature and are evaluated immediately when executed.
Immediate assertions are used only in dynamic simulations.
Following is an example of a simple immediate assertion that checks “if a and b are
always equal”:
always_comb
begin
a_eq_b: assert (a==b)
else
$error (“A not equal b“);
end
Concurrent assertions are temporal in nature and the test expression is evaluated at clock
edges based on the sampled values of the variables involved. They are executed
concurrently with other design blocks. They can be placed inside a module or an
interface.
Concurrent assertions can be used with both dynamic simulations as well static (formal)
verification.
Following is a simple example of a concurrent assertion that checks “if c is high on a
clock cycle, then on next cycle, value of a and b is equal”:
ap_a_eq_b : assert property((@posedge clk) c |=> (a == b));

Q4. What is the difference between simple immediate assertion and deferred
immediate assertions?
Deferred assertions are a special type of immediate assertions. Simple immediate
assertions are evaluated immediately without waiting for variables in its combinatorial
expression to settle down. Hence, simple immediate assertions are very prone to glitches
as the combinatorial expression settles down. This can cause the assertions to fire
multiple times and some of them could be false.
To avoid this, deferred assertions are defined which gets evaluated only at the end of time
stamp when the variables in the combinatorial expression settles down. This means they
are evaluated in the reactive region on the timestamp.

Q5. What are the different ways to write assertions for a design unit?
Certain types of checkers are better written using SVA rather than procedural code. The
languages support rich constructs to implement sequence and property specifications and
this becomes easier than using procedural code or writing class based checkers.
The other added benefit is that the same assertions can also be used in static checking
tools like a Formal Verification tool as well as in providing functional coverage.
Some examples where SVA can be used better are following:
a) Checking of internal design structures like FIFO’s overflowing or underflowing.
b) Checking of internal signals and interfaces between modules can be easier done
with embedded assertions in design.
c) Checkers for standard interface protocols like PCIE, AMBA, Ethernet, etc. can
also be easily developed using the temporal expressions.
d) Checks for arbitration, resource starvation, protocol deadlocks, etc. are normally
candidates for
Formal Verification in any design and hence writing assertions for these will help them to
be used in both static and dynamic simulations.

You might also like