Functional Verification Blog

Its great to hear that Mentor has release a customized version of VMM that runs on Questa, Modelsim. I hope it will complie on NCsim as well. In the release we have a PDF which describes how the VMM is not compliant with ths System verilog LRM. Thats seems to be true to me, because we also faced some similar issues with vcs when we were porting the environment which was written for VCS to modelsim. We also complied VMM with modelsim with some ugly fixes just to meet the deadlines.

There are a lot of different things we found which LRM says should not be supported in SV but VCS supports. I will sortly add few examples on this. There is also a reaction from the synopsis on this and one of the synopsis author says “I’d venture to say that despite all the posturing, Mentor’s support of
VMM demonstrates the solidity and broad industry acceptance of VMM.”

For the users of these methodologies its good that the different vendors support different methodologies. I hope synopis also follow the same in future. Then the life of verificaton engineers like us who needs to port the environment to different simulators will be easier.

Code coverage and function coverage tells the verification engineer if the test plan goals have been met or not.

Thare are following types of code coverage :

1. Line Coverage

2. Toggle Coverage

3. FSM Coverage

4. Combinational coverage

1. Line Coverage :

Line coverage is answer the the simple question whether this line is covered or not. It is recommended that the line coverage for all modules in a design receive 100% coverage. If a line of logic is not executed during simulation, the design has not been fully exercised. Line coverage is useful for determining holes in the test suite.

2. Toggle Coverage :

Toggle Coverage is answer to the question “Did this bit of register or wire changed from 0 to 1 and 1 to 0 during simulation”. A bit is covered if it changes from 0 to 1 and 1 to 0 during simulation.

For a design to pass full coverage, it is recommended that the toggle coverage for all modules in a design received 100% coverage. If a bit is never changes value, it is usually an indication that a mode is not being exercised in the design or a datapath has a stuck-at issue.

3. Combinational Coverage:

Combinational logic coverage answers the question, “What values did an expression (or subexpression) evaluate to (or not evaluate to) during the course of the simulation?”

This type of coverage is extremely useful in determining logical combinations of signals that were not tried during simulation, exposing potential holes in verification.

example :

assign c = a I b;

The expression “a | b” can result in two values, 0 and 1, but can do so in four combinations:

1. a = 0, b = 0, c = 0
2. a = 0, b = 1, c = 1
3. a = 1, b = 0, c = 1
4. a = 1, b = 1, c = 1

Noticing the values assigned to a and b during simulation, shows that combinations (2) and (4) were hit during execution while combinations (1) and (3) were not (2 out of 4 – 50%).

it is recommended that the combinational logic coverage for all modules be 80% or higher. If the expression coverage for an expression is not 100%, it is recommended that the verification engineer closely examine these missed cases to determine if more testing is required. Sometimes certain combinations of signals are unachievable due to design constraints, keeping the expression coverage from ever reaching a value of 100% but still can be considered fully covered.

4. Finite State Machine (FSM) Coverage:

Finite state machine (FSM) coverage answers the question, “Did I reach all of the states and traverse all possible paths through a given state machine?”

There are two types of coverage detail for FSMs that Covered can handle:

1. State coverage – answers the question “Were all states of an FSM hit during simulation?”
2. State transition coverage – answers the question “Did the FSM transition between all states (that are achievable) in simulation?”

It is recommended that the FSM coverage for all finite state machines in the design to receive 100% coverage for the state coverage and 100% for all achievable state transitions. Since Covered will not determine which state transitions are achievable, it is up to the verification engineer to examine the executed state transitions to determine if 100% of possible transitions occurred.

In Verilog, the way that you create the VCD dumpfile is by using two types of Verilog system calls (1) $dumpfile and (2) $dumpvars. The following example shows how to create and generate a dumpfile called “test.vcd” that will dump the submodule called “foo”.

initial
begin
$dumpfile( “test.vcd” );
$dumpvars( 1, test.foo );
end

foo_mod foo();

endmodule

module foo_mod;

…

endmodule

$dumpfile :

The $dumpfile system call takes in one parameter that is a string of the name of the dumpfile to create, in this case the dumpfile we want to create is called “test.foo”. The purpose of this function to create the file (open it for writing) and outputs some initialization information to the file.

$dumpvars:

The $dumpvars system call takes in two parameters. The first is the number of levels of hierarchy that you want to dump. In the example, we want to only dump the module instance called “foo” which is why the dump level was set to 1. To dump foo and the level of submodules just beneath it, you would set the dump level to 2 and so on. To dump a module and all submodules beneath it, set the dump level value to 0 (this means the level specified and all levels below it). The second parameter is a Verilog hierarchical reference to the top-level module instance that you want to dump.

The $dumpfile system call may only be called once within a Verilog design. Typically, it is called in the top-most level of the design (or testbench as it is commonly referred to as); however, the language allows you to call it from anywhere in your design as long as it precedes any calls to $dumpvars.

The $dumpvars system call may be called as many times as necessary to dump the Verilog that you need. For example, if you want to get coverage results for several modules scattered around the design, you may make several $dumpvars calls to dump exactly those modules that you want to see coverage for.

Yesterday I was reading some article about AOP and OOP concepts. Article has some discussion about Observer pattern, then I thought lets read about this first and then move further. I found this small example and one line definition on wiki which helped me.
In observer pattern “one or more objects (called observers or listeners) are registered (or register themselves) to observe an event which may be raised by the observed object (the subject). (The object which may raise an event generally maintains a collection of the observers.)”.

I always like the learn from practicals rather than to read tons for theory pages. Following is the the small code which cleared my concepts about this pattern :

Simple Pseudo code for Observer Pattern In Python :

class Listener:

def initialise (self, subject):

subject.register(self)

def notify (self, event):

event.process()

class Subject:

def initialise (self):

self.listeners = []

def register (self, listener):

self.listeners.append(listener)

def unregister (self, listener):

self.listeners.remove(listener)

def notify_listeners (self, event):

for listener in self.listeners:

listener.notify(event)
subject = Subject()

listenerA = Listener()

listenerB = Listener()

subject.register(listenerA)

subject.register(listenerB)

#the subject now has two listeners registered to it.