SV Part-8 Assertions

Assertions

• assertions are pin point checkers

Why Assertions are required :

• in traditional TB based(functional verification) reference model and checker, the design issues are caught in the checker during design output comparison with reference output, meaning that using scoreboard.

  • Benefit :

    • if reference model and checker is coded properly, design issues will be surly caught.

  • Drawback:

    • Checker only gives transaction mismatch error message.

      • it does’t tell exact location of the issue in the design.

    • it takes time to debug to pinpoint the issue in the design.

      • is the reference model wrongly implemented ?

      • is the Monitor wrongly implemented?

      • is the Slave model wrongly implemented ?

      • is the Interface is wrongly implemented ?

      • model-based is the DUT wrongly implemented ?

        • DUT can have many sub blocks where we may have to look in to.

      • This approach takes a lot of time to pin point what is causing test to fail.

    • Summary:

      • Reference model-based TB offer less observability.

    • Assertion based verification (ABV) is developed to solve the issue of ‘less observability’

What is Assertion Based Verification :

• Concept of using assertions to implement the design behaviour checks.

• Assertions are developed at all important points of the design.

  • Assertions can be developed at both design external and internal interfaces.

• Assertions are always active.

  • fail whenever design deviates from expected behaviour.

  • Assertions exactly pin point what piece of code is failing, it improves the observability of the design issues.

  • Directly go and debug that part of design code.

Running assertions with Questasim

Note: it is a run. do file actually, after you have to executing run. do file

• do run. do, go to view→ coverage → assertions→ add assertions to wave form

• and save this wave as wave. do

Types of assertions

• 1. immediate assertions

     • it will be perform the check at that point of time .

     • it is mostly used in data checks and randomization is happened or not.

       syntax: assert(condition)

     2. concurrent assertions

        • it will perform the check at a specified time.

        • it is mostly used for performing the assertion based verification.

          syntax:

          property <property_name> ;

          @(clocking_event) (antecedent_expression)(implication operator)(consequent);

          endproperty

          clocking event:

          • we need to specify the time, that will done in the clocking event.

          • modtly the clocking event will be considered @(posedge clk)

antecedent:

• it is the starting point of check.

consequent:

• it is also known as main checking main checking part.

implication operator:

it is used to separate the antecedent part and consequent part.

we have 2 types of implication operators.

1. overlapping implication operator

2. non overlapping implication operator

overlapping implication operator:

• when ever antecedent was passed at the same posedge onwards it will start checking the consequent part.

• overlapping implication operator can be represented as (|→)

non overlapping implication operator:

• when ever the antecedent was passed from the next posedge of clock onwards it will start checking the consequent part.

• non overlapping implication operator can be represented as (|=>)

  • Note: when ever we consider antecedent as 1 throughout the simulation my antecedent was passed. so we need to verify the consequent part at every posedge clock.

  • if we did’t mentioned implication operator between the antecedent and consequent, both the things will be consider as antecedent.

Assertions abstraction layers

we have 4 assertions abstraction layers

• Boolean layer

• sequence layer

• property layer

• assertion directive layer

Boolean layer

we need to consider the signals for which we need to develop the assertions

sequence layer

we will develop the sequence for the Boolean layer signals syntax: sequence_name; //sequence endsequence

Property Layer

we will develop the properties for the sequence, which are developed in the sequence layer.

syntax: property property_name; //sequence endproperty

//by using the sequence layer

Q. same question (Q2)

Colour Coding in assertions:

• Blue colour Box - - > assertion point.

• Yellow colour arrow - -> antecedent was passed.

• Green colour up ward arrow - - > assertion passed.

• red colour downward arrow - - > assertion failed.

Practice makes men/women perfect

in the above snippet, ready is happened when assertion was started and antecedent was passed. but assertion was not pass according to the consequent, assertion was pass next within 2 clock cycles why because assertions are executed in preponed region and after assignments are executed in active region. so is data is given some before the assertion was started then it can take that data.

Here, ready is given before the assertion started that’s why first posedge assertion was stared.

commonly used system task and function

• $rise > it will detect the o to 1 transition.

• $fell > it will detect the 1 to 0 transition.

• $isunknown > it will tells that the data will be unknown or not.

• $past > it will provide previous clock edge values of the signal.

• $stable > it will tells the data will stable or not basing on the previous posedge data.

• $continous > returns the current value of a continuous signal (like a real, logic [n:0], etc.) at the exact moment of sampling, even inside concurrent assertions.

• $onehot > it will detect only one bit should be high or not.

• $onehot0 > it is same as $onehot but it will include all one’s possibilities.

common assertions

• time checking for a wave

• frequency checking for a wave