Welcome to Puneet’s World

Hi All,

I have moved the my blog to address http://blog.asicguru.com/. For new articles please visit the new address.

Visit new Blog @ AsicGuru

Thanks,
Puneet

Diffing the files and merging them is one of the very common task we do everyday. Following are few very useful commands to view the diff using vim and merge them using the vimdiff commands instead of copying and pasting from one file to another.

To diff two files using vim :

vimdiff file1 file2
or
vim -d file1 file2

Ofcourse you can use gvim also but I don't prefer using GVIM.

gvimdiff file1 file2

Commands :

[c : Jump to previous diff
]c : Jump to the next diff

do or :diffget : Diff obtain (get the changes to the current buffer/file from the other buffer)
dp or :diffput : Diff Put (Put the changes from the current buffer/file to the other buffer)

As this being one of very command task I do, I have mapped them to single keys for the easy access.

nmap <F7> [czz
nmap <F8> ]czz
nmap <F2> do
nmap <F3> dp

The zz in the end of the command [c will center at the point of the diff so that we can view the diff clearly.

~Enjoy Vim

Here is the example. How you can change the seed for a class and generate different pattern with randc.
If you comment the line "obj.srandom(seed)" it will generate the same pattern again after the cycle.
Try compiling it again with commenting above line.

class randctest;
randc bit [1:0] randbit;
task print;
$display("Rand C = %d", randbit);
endtask
endclass

program main;

randctest obj;

initial begin
obj = new();
for (int i=0; i<12; i++) begin
if (i % 4 == 0) begin
obj.srandom(236+i);
$display("==============");
end
if (obj.randomize()) begin
obj.print();
end
else begin
$display("Randomization failed \n");
end
end
end
endprogram : main

Output :
==============
Rand C = 0
Rand C = 1
Rand C = 2
Rand C = 3
==============
Rand C = 2
Rand C = 1
Rand C = 3
Rand C = 0
==============
Rand C = 1
Rand C = 0
Rand C = 2
Rand C = 3

A good thought :

The difference between a smart person and a wise person is that a wise
person knows how not to get into situations that a smart person knows
how to get out of.

Reference Page :

http://simeons.wordpress.com/2008/09/04/smart-entrepreneurs-vs-wise-entrepreneurs/

Page has few more thoughts out of which the last one i don't agree :

• Be different, not best
• Do less, not more
• Go around a wall, not through it
• It is better to figure out how not to have to solve a problem as opposed to having to solve the problem.

A lot of times we require to source the shell variables or shell script into the perl environment. One way to do this is you add very variable into the perl script something like :

$ENV{"SOME_VAR"} = "SOME_VAL";

The other best way to do this task is parse the shell file and source all the environment variables in to perl script environment. This way we don't need to modify your perl script every time the shell script is modified.

my ($envar, $enval);
open IN, ". ./3rdParty.env; env |"
or die "Could not run shell: $!\n";
while ( <IN> ) {
print $_;
chomp;
($envar,$enval) = split /=/,$_,2;
$ENV{$envar} = $enval;
}
close IN;

This is very useful if the shell script is changed very frequently by the users.

Run a perl script using libraries in nonstandard locations.
======================================

Use perl -V to see the include paths @INC array
I will be something like :
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl

1. Using the module lib
===============
The standard module lib can be used to specify an explicit path to include. It must be stated at the
top of the script:
#!/usr/bin/perl
#
use lib "/opt/special/plib";
use strict;
use warnings;

2. Using the switch -I at the command line
============================

The switch I can be used to specify additional library locations when invoking the interpreter.
perl -I /opt/special/plib script.pl

3. Using the switch -I in the first line of the script
=================================
The same I switch can be added to the interpreter specification.
#!/usr/bin/perl -I /opt/special/plib
#
use strict;
use warnings;
..

This works when invoking the script via the shell (which will run the interpreter with full
options and arguments as specified in the first line) and also when invoking the interpreter
directly: It apparently scans the first line for options.

4. Manipulating @INC directly
====================
The array @INC can be manipulated directly using array operations :

#!/usr/bin/perl
#
BEGIN {
unshift(@INC, "/opt/special/plib");
}
use strict;
use warnings;

5. Using the environment variable PERL5LIB
==============================
The environment variable PERL5LIB can be used to specify additional include directories whe
running a perl script.
> export PERL5LIB=/opt/special/plib

6. Changing @INC at compile time
=======================

When running Configure to compile the perl interpreter itself, there are several possibilities to add
additional library path elements:
· Using the variable vendorprefix
· Using the variable otherlibdirs
Both must be specified when calling Configure as a define, eg
> sh Configure -Dotherlibdirs=/opt/special/plib
The variable otherlibdirs is preferred, as it can hold mutliple values separated by a colon just like
the familiar PATH environment variable.
Details about compiling perl can be found on the CPAN network :
http://search.cpan.org/~nwclark/perl5.8.3/INSTALL.

Sometimes we need to change the case of the letters in vim. Here is how you can do it with vim. Search and replace it with "\U&" or "\L&" or upper and lower letters.

changing to CAPITAL LETTERS :

:%s/^.*$/\U&/g

Changing to lower letters :

:%s/^.*$/\L&/g

Enjoy Power of VIM

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.

From last few days I am thinking what I did in my last one year. I have almost stopped reading. Earlier at least I used to try. But from last more than one year I just stopped it. I used to try out new things, learn new things thats also stopped now. I used to go to office on weekends work late hours in office that's also almost stopped now. Now I go only when someone call me for work.

Actually I worked on implementing a new idea. Which dint worked out. I learned a lot in the last one year but there was not use full results. I will write down my my learning/experiences later on. Its too late for that now.

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.