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

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

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.

$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.

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.

changing to CAPITAL LETTERS :

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

Changing to lower letters :

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

Enjoy Power of VIM

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.

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.

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.

]]> http://puneetworld.com/archives/25/feed http://puneetworld.com/archives/26 http://puneetworld.com/archives/26#comments Tue, 13 Mar 2007 07:40:44 +0000 er.punit http://puneetworld.com/archives/26 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.

]]> http://puneetworld.com/archives/26/feed