Unit3 Concepts

MHCAD. UNIT 3.
Functional Verification
María José Avedillo 1

MHCAD. UNIT 3. Functional Verification

We start introducing basic concepts about design verification.

An important task in any digital design is design verification. The designer checks
his design for any design flaw that may have occurred in the design process.
Or in other words as it is stated above.

It is important to clarify following considerations:
Design verification is different from testing.

From the previous definition, design verification aims at checking that the circuit will
work correctly assuming perfect manufacturing, while test, which is carried out after
the circuit has been fabricated, has as a primary goal detection of physical defects.
Design verification target is validation of the design flow.
The term design verification is wider than verification of the functionality

This unit focuses on this (Functional Verification) but in Unit 5 we will come back to
deal with other aspect of design verification.
Design verification tools include simulation tools but are not limited to them
Clearly, simulating a gate network or HDL code (design models) is a way to check if
they do what we intent, but more and more, simulation is not enough and other
approaches are required to cope with current design complexity.

Design verification is a wide concept which includes many different tasks. It is

possible to get a picture of them on the basic of What, When and How questions.
As previously mentioned, functionality is not the only design specification that has to
be verified. In addition, questions like will the circuit work at the required clock
frequency? should be answered before the circuit is fabricated. Also power or signal
integrity are a concern in many current applications.
Design verification tools are not only used to validate design specifications. For
example, the analysis performed to validate timing constraints (like operating
frequency) can be also used for design exploration. That is, different designs could
be compared using design verification (or analysis) tools.

There are two main types of approaches concerning how the verification is carried out. It is
distinguished between tools and methodologies based on simulation, which is called dynamic
verification, and static verification methods which are not.
Simulation
Basically, what a simulation does is providing the output of a design model for a given set of inputs
(simulation stimulus or stimulus in the following). From this output, the design parameter of interest is
extracted.
For example, if maximum propagation delay is the target, the simulator is used to obtain the output
response, delays are measured by identifying when output changes with respect to the input change
causing it, and the highest one is selected.
The stimulus to be applied depend on what we want to verified. That is, on the design parameter that
we are going to extract from the simulation.
The design model and the stimulus can be described at different levels of abstraction defining
different types of simulations.
Static
The main characteristic of static methods is that they are input independent. No stimulus generation
is required. This is attractive because selecting/generating suitable stimulus for a simulation can be
difficult in complex designs.
There are static approaches which work with a single design representation and others that work with
two representations (usually with different level of abstraction: RTL behavioral HDL code versus
synthesized circuit, schematic versus layout…) to determine whether they are coherent.
An example of static tool is Static Timing Analysis (STA). It can be used to evaluate the maximum
propagation delay. Unlike the simulation approach to this task, previously described, neither stimulus
need to be provided by the designer, nor a measuring step is required. STA is covered in Unit 5.

Design verification can be hardware assisted. Basically two sceneries are identified.
Hardware support to speed up functional simulation

Hardware linked with HDL simulator. The design is completely or partially fitted into
the hardware. In this way the simulation can be significantly accelerated
Hardware support for ASIC emulation

For example, the design can be prototype into FPGAs prior to fabrication. In this
way it can be tried into the application board and/or environment

We identified several design verification tasks in the digital flow described in Unit 1. These verification
activities occur in different moments of the design flow:
• Functional verification is carried out after HDL coding
• Both functional and timing verification have sense after logic synthesis or after physical design
(place & route) has been realized.
• In addition, analysis tools are also applied inside optimization tools.
In the rest of this unit, we focus on functional verification, a major component of digital design
projects. It is time-consuming for today complex systems and it is reported, in various industry
surveys to be the largest step in completing a new design.
Three different approaches to functional verification are addressed in the following:
1.- Simulation based which requires stimulus generation and inspection of results.
2.- Formal Verification which eliminates problems associated with stimulus generation. The
designer writes properties the design must fulfil and the tool comes up with a Yes/No answer
for every property the design is being checked for.
3.- Assertion based verification which adds monitors to the design to increase its
observability and/or controllability

Three different approaches to functional verification are addressed in the following:
1.- Simulation based which requires stimulus generation and inspection of results.
2.- Formal Verification which eliminates problems associated with stimulus generation. The designer
writes properties the design must fulfil and the tool comes up with a Yes/No answer for every
property the design is being checked for.
3.- Assertion based verification which adds monitors to the design to increase its observability and/or
controllability.
Assertions can be validate either dynamically (in a simulation environment) or statically (using formal
tools)


This section focuses on simulation based verification from the point of view of methodology.
Material on how it is implemented using Verilog is also available (see Writing Verilog Testbenches in the
Examples and Tutorial Section).
The goal of functional verification can be simply stated: to prove that the design functionality is the intended
one. To achieve this goal four components are required:
1. Determine what the design has to do according to its specification (the intent)
In some cases, when it is possible to specify the functions that the device must perform, the intent may be
obvious. For complex digital systems, even the intent may not be clear.
2. Determine what the design does

In fact a model of the design.
3. Compare the two

The issue is how we model the intent.
4. Estimate the level of confidence of the verification effort

Generally the design model may never be fully tested (2100 states to verify in a design with only one hundred
flip-flops), and in many cases complete intent of the system is unknown. One can not shown that there are no
more errors to be found.
So, the challenge is determining the completeness criteria of the verification.
In simulation based verification, these four components are carried out into a simulation environment.
A more operative vision is:

1 Select a set of specific input stimulus
2 Simulate a model of the design with those stimulus
3 Analyse the results

A main question is which stimulus should be applied.
From the point of view of how they are defined different approaches are:
Exhaustive
Apply all input combinations for a combinational circuit or checking experiment
(travels every state and state transition) for a sequential circuit.
Directed test
For example, write test to exercise the complete set of operations intended for a
register.
Random
Captured

These notes summarize evolution concerning stimulus generation.

This figure from synopsys clearly shows that constrained random verification is
much more efficient than writing directed tests.
Time savings in verification is achieved using the former.
Higher fraction of functionality verified (higher design quality) with constrained
random stimulus generation versus directed approach with same time effort.

A closely related question is how good the applied stimulus are.

These notes summarize the status of Verification coverage metrics.
The critical role of coverage metrics is now well recognized and a coverage-driven
verification methodology has arose.
The outstanding point is that well known code coverage metrics are not longer
considered enough. The main drawback is that they do not prove that a design is
correct as it can be easily understand by means of this simple example consisting in
the statement a <= b op c.
Two other types of coverage metrics are being used.

Functional Coverage
The basic idea under this concept is:
Assertions are used as monitors looking for bad behaviour, but they may be used
to create an alert for desired behaviour as well.
Assertion Coverage
Going back to FSM used as a first example of using assertions. In order to prove in
simulation that, assertion “When reset is activated, state must be idle within two
cycles” is false, the stimulus would need to put the state machine into St4 and then
activated the reset condition for multiple cycles. If the assertion does not fail, it may
mean that the logic is valid, or it may mean that there was insufficient stimulus.


They are as good as they have been written:

For example, if there are 20 features in the specification but you write only
functional coverage code for 15.

There is also a key question concerning output analysis.

This slide provide a general overview to be completed in following Sections.


This Section focuses on Equivalence Checking (EC). The first two slides place EC
in the general context of design verification methods.
EC is a formal verification approach. Formal techniques mathematically prove the
functional correctness of a design.

The two more advanced formal verification methods are EC and Property Checking.
See also Tutorial B. Verification using equivalence checking Section

The material on EC has been mostly taken from “Equivalence Checking” by

Andreas Kuehlmann and Fabio Somenzi, EDA for IC Implementation, Circuit
Design, and Process Technology, Chapter 4. Available as e-book at the University
Library.



EC fits into a design process exactly the same way a logic simulator fits when it is
used for regression testing. Specifically, any time you make a non functional change
to a design, you can use EC to prove that the implementation is still functionally
equivalent to the reference.



Determining that M1 and M2 are equivalent is formulated as determining that

lambda is 1.




Introduction
In this Section, we introduce a new approach to addressing the functional
verification challenge, known as assertion-based verification, which provides a
unified methodology for unambiguously specifying design intent across multiple
verification processes.
A little bit more on assertions

Assertions may specify internal design behaviours (such as a specific FIFO
structure) or external design behaviour (such as protocol rules for a design’s
interfaces or even higher-level requirements that span across design blocks).
One key characteristic of assertions is that they allow the engineer to specify what
the design is supposed to do at a high level of abstraction, without having to
describe the details of how the design intent is to be implemented.
Thus, this abstract view of the design intent is ideal for the verification process
whether we are specifying high-level requirements or lower-level internal design
behaviour.

The description of a simple state machine is shown. It represents a synchronous

design with a single clock. It shows how it may take several clock cycles for the
state machine to be reset, since it must travel through several states to reach
the idle state.
Assertions for this design using English could look like this:
When reset is activated, state must be idle within four cycles

This assertion is true if one assumes that only the five states in the diagram are
possible. Clearly, from any state, if reset is activated for four cycles, the idle
state will be reached.
When reset is activated, state must be idle within two cycles

This second assertion is false. From state 3, Reset would need to be activated
for three cycles to reach the idle state.
This example is somewhat odd, since the assertion statement is wrong if one
assumes that the state diagram is correct. However it is usually the other way
around: the assertion is true for the intended hardware and the target is to
determine if it is also true for the design under verification. That is, assuming the
assertion is true, it would be said that the design violated it. This represents an
error in the design.

Reset Sequences
The previous slide showed an example in which the reset behaviour of the design was checked.
As in that example, often controllers have a resetting sequence that with certain sequence of inputs,
the machine ends up in a certain state regardless of what state it starts from. Assertions can be used
to verify these reset sequences.
There are other design features that are typically verified using assertions:
Initial resetting
For verification of many sequential circuits, it becomes necessary to check for resetting the circuit
using a synchronous or asynchronous reset input.
Implication
There are many assertions that can be made about the relationship of signals. Some examples are:
For a finite state machine.- if current state is state3 and input x is 1, the z output is 1 (1)
For a bus protocol.- Grant must be activated within n cycles of a request (2)
Note that in the previous statements used as examples of assertions there are both logical and
temporal components. We can think in logical components as equations (boolean equations). For
example, in (1), if current state is state3 and input x is 1 is a logical component.
Temporal components specifies under what time constraints the equation is expected to hold true.
For example in (2), within n cycles is a temporal component.
Valid states
In sequential circuit, testing it often becomes necessary to check for the machine´s valid states. In
other words, check that the machine never enters invalid states.

Comments on observability improvements

Assertions added to monitor conditions that are otherwise hard to check using
simulation makes the design more observable.
Assertion monitors can be thought of as internal software test points that wait for a
particular problem to happen and then alert the designer when it does. In these
cases, assertions are used to improve observability, which means the ability to
observe bugs once they are triggered by a simulation vector. Without assertions,
test vectors have to be much longer to ensure that triggered bugs are propagated to
observable outputs, else the errors remain undetected.

Once having introduced the concept of assertion, the next question is how can we implement them.
Designers historically had the ability to craft assertions using both the Verilog and VHDL design
languages. Lacking an assertion statement, the Verilog designer used a conditional statement to
trigger the output of an error message. The VHDL designer used the assert statement inherent in
VHDL to check for the violation of a condition and to output a message.
However a public, HDL library of pre-packaged and pre-verified assertions is now available.
This initiative began with the realization that:
• An standard method of defining more complex assertions was needed.
• A method was needed that could be used and understood by designers in different groups, at
different sites, and at different companies.
• Furthermore, a consistent specification mechanism was needed for both simulation and formal
tools.
This Open Verification Library (OVL) started as a donation by Verplex Systems of an assertion library
for open source standardization.
Why using standard assertions ?

In its simplest form, an assertion consists of the function to be monitored. This assertion can be
easily implemented in Verilog or VHDL by the designer, in a few lines of code. In addition to the
functional check itself, OVL assertions are structured so they will not affect design behaviour or
synthesis results. Additional mechanisms are provided so the assertions can be disabled, a level of
severity for the error can be easily specified or the number of failures counted. It quickly becomes
apparent that a well-conceived and well-defined library of assertions has notable benefit. By selecting
an assertion from a library, a standardized set of functionality and user options is provided.

Concerning assertion based verification there has been a very significative

development.
Assertions have been used in HDL verification for many years. This may seem
confusing to some people, since they may have never realized they were using
what are now called assertions. They were used in simulation, generally as a
backup to other methods.
The promise of assertion-based verification goes far beyond this early usage to
establish assertions as an enabler of much more efficient verification, simplified
analysis, and the synergistic use of simulation and formal verification methods.
This development translates in that the responsibility of verification is also shifting
from verification team to involve designers as well and in that design knowledge
becomes now critical.





Assert can be:

Immediate: Independent of clock or reset
immediate_assertion_name: // assertion name
assert (current_state != 0) // expression to be checked
else // (optional) custom error message
$error("%m checker failed");
Check current_state is never 0. Equivalent to:

always @*
if (current_state != 0) // do nothing
else $error(“fail”);
Concurrent: describe more complex expressions that span time and are triggered relative to a clock
edge
Check at each clock Edge that a y b are not both equal to 1. It is equivalent to:
Implication operators
LHS |-> RHS Overlapping implication - The RHS is evaluated from the same cycle LHS is true
LHS |=> RHS Non-overlapping implication - The RHS is evaluated one clock cycle after LHS is true

Example of “covergroup”
Taken from https://www.chipverify.com/systemverilog/systemverilog-covergroup-coverpoint

Mode can take 4 different values. Two of them (0 and 1) have been reached during the simulation.
Since covergroup monitorizes mode (coverpoint), Coverage is 50%

In the following example, addr is constrained to be between 0 and 11
This is a very simple example many more sophisticate ones can be creted in SV
(weighted distributed, bidirectional constraints…)
In the following example variable data is randomized uniformly

Assert can be immediate (
This 2 codes are equivalent
Validates b is1, one clock cycle after a is 1
Validates d is be 1, two clock cycle after c is 1
Validates s-cd is on one clock cycle after s-ab is on

This is an example of an interface. Signals associated to this interface are clk, data
and enable. Modport indicates the direction. Since they passed to different
components (DUT and TB in the code below), different direction can be defined for
each signal.
This is an example of how an interface is created in a testbench and passed to the

DUT.
This is an example of a clocking block. Input enable is sampled 3ns before clock
event (positive edge) and output data is driven 2ns after the posedge of clk

In comparison with typical view of a Verilog or VHDL testbench
Of course, it is posible to somehow approach the more elaborated verification

enviroment but witha great coding effort.
As described in assertion section, the first step to solve that problem using a open
source library (OVL). The next step was extending Verilog.
The next was development of a Universal Verification Methodology (UVM) on

top of System Verilog

UVM class Hierarchy:

uvm_object: main class. Common functions to print, copy, compare
There are two branches in the hierarchy:
uvm_component to créate verification components (those in green)
uvm_transaction define data objects consumed and operated by verification
components (those in black)

tb_top is a module. Static container for everything else

The UVM test is responsable for:
• Configuring the testbench
• Initiate the testbench components construction process
• Initiate the stimulus by starting the sequence.
UVM enviroment
It is a container groping components like agents and scoreboard.
There is only one agent in the example, although there can be many agents
UVM agent
Groups the uvm_components associated to an interface or protocol.
Also not shown, Agents have configuration parameters
Those components are:
UVM sequence ítem: defines the pin level activity generated by agent (to drive
to DUT through the driver) or the activity has to be observed by agent
UVM driver: responsible for driving the packet level data inside
sequence_item into pin level (to DUT)
UVM sequence: defines the sequence in which the data items need to be
generated and sent/received to/from the driver.
UVM sequencer: responsible for routing the data packet’s(sequence_item)
generated in sequence to the driver or vice verse.
UVM monitor: observes pin level activity on interface signals and converts
into packet level which is sent to components such as scoreboards.

UVM scoreboard:
Receives data item’s from monitor’s and compares with expected values.


Unit3 Concepts

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit3 Concepts

Uploaded by

Copyright:

Available Formats

MHCAD. UNIT 3.

María José Avedillo 1

María José Avedillo 2

We start introducing basic concepts about design verification.

Or in other words as it is stated above.

María José Avedillo 3

It is important to clarify following considerations:

Design verification is different from testing.

The term design verification is wider than verification of the functionality

María José Avedillo 4

Design verification is a wide concept which includes many different tasks. It is

María José Avedillo 5

María José Avedillo 6

Hardware support to speed up functional simulation

Hardware support for ASIC emulation

María José Avedillo 7

Three different approaches to functional verification are addressed in the following:

María José Avedillo 8

Three different approaches to functional verification are addressed in the following:

María José Avedillo 9

María José Avedillo 10

2. Determine what the design does

3. Compare the two

4. Estimate the level of confidence of the verification effort

A more operative vision is:

María José Avedillo 11

A main question is which stimulus should be applied.

María José Avedillo 12

These notes summarize evolution concerning stimulus generation.

María José Avedillo 13

María José Avedillo 14

A closely related question is how good the applied stimulus are.

María José Avedillo 15

These notes summarize the status of Verification coverage metrics.

Two other types of coverage metrics are being used.

María José Avedillo 16

María José Avedillo 17

María José Avedillo 18

They are as good as they have been written:

María José Avedillo 19

There is also a key question concerning output analysis.

María José Avedillo 20

María José Avedillo 21

María José Avedillo 22

María José Avedillo 23

The material on EC has been mostly taken from “Equivalence Checking” by

María José Avedillo 24

María José Avedillo 25

María José Avedillo 26

María José Avedillo 27

María José Avedillo 28

María José Avedillo 29

Determining that M1 and M2 are equivalent is formulated as determining that

María José Avedillo 30

María José Avedillo 31

María José Avedillo 32

María José Avedillo 33

A little bit more on assertions

María José Avedillo 34

The description of a simple state machine is shown. It represents a synchronous

When reset is activated, state must be idle within four cycles

When reset is activated, state must be idle within two cycles