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.