$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 http://puneetworld.com/archives/24 http://puneetworld.com/archives/24#comments Mon, 12 Mar 2007 11:30:30 +0000 er.punit http://puneetworld.com/archives/24 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;

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.

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.