Welcome to Puneet’s World

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.

How do I do a mass search and replace in a directory?

How can I search for a string in all my files and replace it with a text?

Are there any spiffy shortcuts for search/replace in a directory using command line Perl?

How do I load a list of replace patterns from a file in a one-liner?

Use this my all time favorite one line scripts ....:)

Assuming you are in the directory where you want to effect this search and replace

perl -pi -e 's/lookFor/replaceWith/' *.fileExtension

perl -pi -e 's/lookFor/replaceWith/g' *.fileExtension

perl -pi -e 's/lookFor/replaceWith/gi' *.fileExtension

Explanation :

- lookFor is the word you wish to look for.

- replaceWith is the word you wish to replace your original word with

- g stands for global, it will basically replace all the occurences of lookFor with replaceWith in all your files in a directory

- i stands for case insensitive

To load a series of replace expressions from a text file:

perl -pi -e "`/path/to/replace-patterns.txt`" *.fileExtension

s/lookForPatternOne/replaceWithOne/;

s/lookForPatTwo/replaceWithTwo/g;

s/lookForPatThree/replaceWithThree/gi;

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.

Two most popular boot loaders on linux systems are LILO and GRUB. If there are more then I dont know ;). First question is what is a boot loader ?

Boot loader loads the operating system to memory. When the system boots it reads the MBR(master boot record) of your system and You can store the boot record of only one operating system in a single MBR, so a problem becomes apparent when you require multiple operating systems. Hence the need for more flexible boot loaders and here comes LILO and GRUB in picture. Here are the main differences between these two.

• LILO has no interactive command interface, whereas GRUB does.
• LILO does not support booting from a network, whereas GRUB does.
• LILO stores information about the location of the kernel or other operating system on the Master Boot Record (MBR). Every time a new operating system or kernel is added to the system, the Stage 1 LILO bootloader has to be manually overwritten, otherwise there is no way to boot the new OS or kernel. This method is more risky than the method used by GRUB because a mis-configured LILO configuration file may leave the system unbootable (a popular way to fix this problem is to boot from Knoppix or another live CD, chroot into the partition with mis-configured lilo.conf and correct the problem). On the other hand, correcting a mis-configured GRUB is comparatively simple as GRUB will default to its command line interface where the user can boot the system manually. This flexibility is probably the main reason why many users nowadays prefer GRUB over LILO.

I always see lots of directories in /etc/rc.d/ like rc.0, rc.1, rc.2, rc.3, rc.4, rc.5, and rc.6. Once I tried to find out what are all these. Then I came to know these are runlevels. Then the question came how do they get triggered and whats the difference between these runlevels. Here is what I found :

When you turn on the system following things happens :

1. Boot loader finds the kernel image from disk and loads it in to memory.

2. Kernel initializes the devices and its drivers

3. Kernel mounts the root file system

4. Kernel starts a program called init.

5. init start all the rest processes.

init

There is nothing special about init. It is a program just like any other on the Linux system, and you'll find it in /sbin along with other system binaries. The main purpose of init is to start and stop other programs in a particular sequence. All you have to know is how this sequence works.

Most linux system are System V (derived from AT&T System V) based . Another is based on BSD (Berkeley Software Distribution). What's the difference between the two? Basically BSD doesn't have any runlevels. This means that System V are more flexible

Most Linux distros put startup scripts in the rc subdirectories (rc1.d, rc2.d, etc.), whereas BSD systems house the system scripts in /etc/rc.d. Slackware's init setup is similar to BSD systems, though Slackware does have runlevels and has had System V compatibility since Slackware 7.

Runlevels :

At any given time on a Linux system, a certain base set of processes is running. This state of the machine is called its runlevel, and it is denoted with a number from 0 through 6. The system spends most of its time in a single runlevel.
You will also find a file named /etc/inittab. The system uses these files (and/or directories) to control the services to be started. If you look in the file /etc/inittab you will see something like:

id:5:initdefault:

l0:0:wait:/etc/rc.d/rc.0

l6:6:wait:/etc/rc.d/rc.6

x1:4:wait:/etc/rc.d/rc.4

First line means that the default runlevel on the system is 5. All lines in the inittab file take this form, with four fields separated by colons occurring in the following order:

Run Level	Generic	Linux/Fedora Core	Slackware	Debian
0	Halt	Halt	Halt	Halt
1	Single-user mode	Single-user mode	Single-user mode	Single-user mode
2	Basic multi-user mode (without networking)	User definable (Unused)	User definable - configured the same as runlevel 3	Multi-user mode
3	Full (text based) multi-user mode	Multi-user mode	Multi-user mode - default Slackware runlevel
4	Not used	Not used	X11 with KDM/GDM/XDM (session managers)	Multi-user mode
5	Full (GUI based) multi-user mode	Full multi-user mode (with an X-based login screen) - default runlevel	User definable - configured the same as runlevel 3	Multi-user mode
6	Reboot	Reboot	Reboot	Reboot