Understanding SystemVerilog Assertions (SVA)

1. Definition. An assertion is basically a piece of code that is continuoiusly monitoring and checking, a functionality of the SoC. It is not triggered by the stimuli being applied to the SoC, but only by the SoC response to the stimuli. As such, an assertion can be written in usual verilog or even verilog-A/AMS (for example using an always statement).
2. SystemVerilog Assertions (SVA). SystemVerilog provides a set of concise syntax constructs that makes assertion coding much simpler (hence less error-prone) than in traditional HDLs. SVA are split into two categories : immediate assertions and concurrent assertions.
3. Immediate assertions. An immediate assertion is evaluated at the instant it is called. It is basically similar to an "if" statement. The difference being that its result (pass or fail) is recorded in the coverage results created by the simulator.
4. Concurrent assertions. Concurrent assertions check SoC behaviors that span over time. The expected behavior can be represented by usual combinarotial boolean equations. But SystemVerilog provides higher-level constructs : sequences and properties.
5. Sequences. A sequence is basically a time-organized list of boolean expressions. The sequence is true if all the successive expressions are true. The time is discrete and depends on a clock. A clock can be any eexpression that becomes true, or the start or end of execution of a named block, a task, a function or a class method. Several sequences can be made successive. Several new operators are used to describe sequence: the "cycle delay" noted ##,  the "same-cycle implication" noted |->, the "next-cycle implication" noted |=>, the "consecutive repetition" noted [*, the "non-consecutive repetition" noted [=, and the "goto repetinio" noted [->. Some system functions such as $rose(), $fell(), $stable(), $past() are also available to access sampled values of an expression.

Understanding Coverage Metrics

There are different types of coverage.

1. Test or Scenario Coverage. It is a simple PASS/FAIl metric telling you if a specific simulation (test/schenario) was successfull.
2. Code Coverage. Originally in the digital world.. This metric tells you about the completeness of your test. It tells you what part of the (digital) code was exercised. As such, it is implementation-dependant. The code coverage is generally split into several "sub-metrics" : block/line, expression, toggle, plus two specific metrics related to Finite State Machine (FSM) coverage : the state and the arcs reached. It does not need any specific coding efforts.
3. Functional Coverage. The Functional Coverage was mainly introduced by VERA (from Synopsys), Specman/e (from Cadence) and PSL/Sugar from IBM.It has then been introduced into SystemVerilog. It is meant to track which functionality of the SoC was exercised.It does not depend on the implementation. It does need some extra coding and is closely linked to the specification and the Verification Plan. The Functional Coverage is commonly split into two categories : control-oriented and data-oriented. The control-oriented Functional Coverage defines SoC's properties which are then checked (asserted). These assertions can be immediate or concurrent (sequences). Systemverilog provides specific operators to specify sequences. The data-oriented Functional Coverage tracks the number of times a design variable reaches a specified set of values or value-transitions.

Welcome to my new blog on AMS SoC Verification

Let's start presenting myself.

I've been working in the semiconductor industry since 1994.
I started as an Applications Engineer at LSI LOGIC.
Then I became a Digital Designer, writing RTL code in VHDL.


In 1998 I joined a small company called CSTI but the company collapsed.
I then joined a Mixed-Signal team at Motorol, which became Freescale.

Since 2003 I started to work full time on the verification of our Mixed-Signal ASICs;
The first SoC's I've been responsible of the verification of were dedicated to Power-Management, User Interface and Audio.

Since 2 years, I've been in charge of the verification of sensor ASICs.

The progresses of the methodology allowed us to go to production with a bunch of first-pass successes.

The methodology I'm using is based on ePlanner to track the coverage progresses and achievements.

The testbench is a mixture of SystemVerilog and Verilog-AMS code.

The SoC itself is simulated at a mixed-level, including transistors and a mix of RTL, wreal and AMS models.