Verification Blog

Tutorial on Portable Stimulus for SoC and System Verification/Validation

2016-08-20T21:37:00.000+05:30

Portable Stimulus is one of the latest initiative by Accelerate to address stimulus reusability across the different axis like across different users (e.g. Architects, Design Engineer, Verification Engineer, Firmware development engineer), across different platforms (Simulation, Emulation, FPGA, Board) and across multiple integration level (IP, Subsystem, SoC, Firmware, OS). As the industry is adopting shift-left approach (i.e. bringing software development and testing early in the product cycle), portability of the stimulus id becoming more relevant and this is the need of an hour. If you are interested in knowing more about what's Cadence offerings in this exciting space, satay tuned for more as I am planning to write more on this in coming weeks.

DVCon India is here on 15-16 September, 2016 and I am going to talk about it in one of the tutorial "Using Portable Stimulus for SoC Verification as Applied on Mobile, Networking, and Server Designs". You can also explore Accellera tutorial "How Portable Stimulus Addresses Key Verification, Test Reuse, and Portability Challenges" for more on portable stimulus.

Einstein’s Five House Riddle - Solution in 'e'

2015-10-27T11:15:00.001+05:30

Over the weekend, I came across this riddle and thought of solving it using ‘e’. Later on I challenged our team members over the WhatsApp and they took up the challenge. They came up with their version of solution in SV and SVA. I thought of sharing this solution to show how constraints solver engine can solve these kind of riddles. During the course of solution, I observed specifics about constraint solving technology of Specman. But before that, let’s look at the riddle. It is called with different names like Zebra Riddle or Einstein’s Riddle. This riddle has different version of stories and none of it has any solid proof to prove its origin. I’ve taken this riddle from one of the student’s home page from Stanford University website. Here is his version of the riddle which we tried to solve.

Let us assume that there are five houses of different colors next to each other on the same road. In each house lives a man of a different nationality. Every man has his different favorite drink, his different favorite brand of cigarettes, and keeps different pets of a particular kind.

The Englishman lives in the red house.
The Swede keeps dogs.
The Dane drinks tea.
The green house is just to the left of the white one.
The owner of the green house drinks coffee.
The Pall Mall smoker keeps birds.
The owner of the yellow house smokes Dunhills.
The man in the center house drinks milk.
The Norwegian lives in the first house.
The Blend smoker has a neighbor who keeps cats.
The man who smokes Blue Masters drinks bier.
The man who keeps horses lives next to the Dunhill smoker.
The German smokes Prince.
The Norwegian lives next to the blue house.
The Blend smoker has a neighbor who drinks water.

The question to be answered is: Who keeps fish?

Now to solve this riddle, I started thinking these clues as constraints in ‘e’. Let’s go step by step how I approached this problem.

Here, we have 5 men who has different characteristics like they live in specific house number which has specific color. Each one has unique nationality, favorite drink, favorite brand of cigarettes and pet. So, based on these attributes, we can create a struct which can have these 5 attributes. These five attributes can be enumerated and ‘man’ struct can be defined as shown below.

type nationality_t : [english, swede, dane, norweigian, german];

type house_color_t : [red, green, yellow, blue, white];

type cigarette_t : [dunhill, blend, blue_masters, prince, pall_mall];

type pet_t : [dog, bird, cat, horse, fish];

type drink_t : [tea, coffee, milk, bier, water];

struct man {

nationality : nationality_t;

house_color : house_color_t;

cigarette : cigarette_t;

pet : pet_t;

drink : drink_t;

};

Here, I’ve not captured the house number as an attribute since I thought I can create list of struct which automatically will fix the house number of each object.

Now, I’ve categorized the clues in 2 category. One category which does not have house number order dependency and the other category which has house number dependency. Like, clue number 1 “The Englishman lives in red house” does not have any reference to the number of house, whereas clue no. 4 “The gree house is just to the left of the white one” has reference to the house number order. Since I have not captured the house number as an attribute, I’ve to split the clues into two different categories of constraints. One without the reference of the house number can be part of the original struct definition. One with the house number dependency can go to the place where list of struct is created so that we have notion of the house orders using index number of the list.

Let’s first capture the clues without house number ordering as global constraints as part of struct declaration. Here is what I’ve captured.

extend man {

//Englishman lives in the red house

keep nationality == english => house_color == red;

//Swede keeps dog

keep nationality == swede => pet == dog;

//dane drinks tea

keep nationality == dane => drink == tea;

//owner of the green house drinks coffee

keep house_color == green => drink == coffee;

//Pall Mall smoker keeps bird

keep cigarette == pall_mall => pet == bird;

//owner of the yellow house smokes dunhill

keep house_color == yellow => cigarette == dunhill;

//Man who smokes Blue Masters drinks bier

keep cigarette == blue_masters => drink == bier;

//German smokes prince

keep nationality == german => cigarette == prince;

};

Now let’s move on to declaring this struct as 5 objects as shown below.

extend sys

{

men : list of man;

keep men.size() == 5;

};

Now over here, we can capture the clues with house number ordering as different constraints involving different objects. Here, we’ll go by clues.

Let’s look at the first constraint which has dependency on the house number ordering. This clue is clue number 4 “The green house is just to the left of the white one”. This can be captured as shown below. Here I’ve assumed house numbers starts from 0 to 4 runs from left to right. Due to this assumption, house number 0 does not have any house on left side of it.

extend sys {

//The green house is just to the left of the white one.

keep men[1].house_color == white => men[0].house_color == green;

keep men[2].house_color == white => men[1].house_color == green;

keep men[3].house_color == white => men[2].house_color == green;

keep men[4].house_color == white => men[3].house_color == green;

};

Next clue which has dependency on the house number ordering is clue number 8 “The man in the center house drinks milk”. This can be captured easily as we know the house number 2 is in center.

extend sys {

//The man in the center house drinks milk.

keep men[2].drink == milk;

};

Next such clue is clue number 9 “The Norwegian lives in the first house”. Again it is simple to capture.

extend sys {

//Norweigian lives in the first house

keep men[0].nationality == norweigian;

};

Next such clue is clue number 10 “The Blend smoker has a neighbor who keeps cats”. This is how I captured it. It is obvious that man staying in house 0 or 4 have only one neighbor and rest men have 2 neighbour.

extend sys {

//The Blend smoker has a neighbor who keeps cats.

keep men[0].pet == cat => men[1].cigarette == blend;

keep men[1].pet == cat => men[0].cigarette == blend or men[2].cigarette == blend;

keep men[2].pet == cat => men[1].cigarette == blend or men[3].cigarette == blend;

keep men[3].pet == cat => men[2].cigarette == blend or men[4].cigarette == blend;

keep men[4].pet == cat => men[3].cigarette == blend;

};

Next clue is clue number 12 “The man who keeps horses lives next to the Dunhill smoker”. Again it is captured just like the above constraints for clue number 10.

extend sys {

//The man who keeps horses lives next to the Dunhill smoker.

keep men[0].pet == horse => men[1].cigarette == dunhill;

keep men[1].pet == horse => men[0].cigarette == dunhill or men[2].cigarette == dunhill;

keep men[2].pet == horse => men[1].cigarette == dunhill or men[3].cigarette == dunhill;

keep men[3].pet == horse => men[2].cigarette == dunhill or men[4].cigarette == dunhill;

keep men[4].pet == horse => men[3].cigarette == dunhill;

};

Next clue in this category is clue number 14 “The Norwegian lives next to the blue house”. Since it is already declared in clue number 9 “The Norwegian lives in the first house”, it is obvious that the blue house is house number 1. The Here is how I’ve captured it.

extend sys {

//The Norwegian lives next to the blue house.

keep men[1].house_color == blue;

};

If we do not want to capture it by interpreting it by ourselves and want tool to interpret for us, we can capture it just like we captured clue number 10 and 12. Here is how clue number 14 can be captured in alternate way.

extend sys {

//The Norwegian lives next to the blue house.

keep men[0].nationality == norweigian => men[1].house_color == blue;

keep men[1].nationality == norweigian => men[0].house_color == blue or men[2].house_color == blue;

keep men[2].nationality == norweigian => men[1].house_color == blue or men[3].house_color == blue;

keep men[3].nationality == norweigian => men[2].house_color == blue or men[4].house_color == blue;

keep men[4].nationality == norweigian => men[2].house_color == blue or men[4].house_color == blue;

};

Last clue that is clue number 15 “The Blend smoker has a neighbor who drinks water” is again captured the way we have captured clue number 10 and 12.

extend sys {

//The Blend smoker has a neighbor who drinks water.

keep men[0].cigarette == blend => men[1].drink == water;

keep men[1].cigarette == blend => men[0].drink == water or men[2].drink == water;

keep men[2].cigarette == blend => men[1].drink == water or men[3].drink == water;

keep men[3].cigarette == blend => men[2].drink == water or men[4].drink == water;

keep men[4].cigarette == blend => men[3].drink == water;

};

Now we have captured all the clues as constraints. But when we load this file into Specman and try to solve it, we get constraint error. The reason is that we have not capture an important piece of information into this solution, that is each man has unique values of each 5 attributes. Now capturing this and informing Specman to generate uniq values for all 5 objects of man struct is bit tricky in ‘e’. In system Verilog, randc operator helps us capture it very easily, but in ‘e’ we have to do it with lot of codes. Here is how I’ve done it.

extend sys {

//Let us assume that there are five houses of different colors next to each other on the same road. In each house lives a man of a different nationality. Every man has his favorite drink, his favorite brand of cigarettes, and keeps pets of a particular kind.

//Unique nationality, house_color, cigarette, pet and drink

keep men[0].nationality != men[1].nationality;

keep men[0].nationality != men[2].nationality;

keep men[0].nationality != men[3].nationality;

keep men[0].nationality != men[4].nationality;

keep men[0].house_color != men[1].house_color;

keep men[0].house_color != men[2].house_color;

keep men[0].house_color != men[3].house_color;

keep men[0].house_color != men[4].house_color;

keep men[0].cigarette != men[1].cigarette;

keep men[0].cigarette != men[2].cigarette;

keep men[0].cigarette != men[3].cigarette;

keep men[0].cigarette != men[4].cigarette;

keep men[0].pet != men[1].pet;

keep men[0].pet != men[2].pet;

keep men[0].pet != men[3].pet;

keep men[0].pet != men[4].pet;

keep men[0].drink != men[1].drink;

keep men[0].drink != men[2].drink;

keep men[0].drink != men[3].drink;

keep men[0].drink != men[4].drink;

keep men[1].nationality != men[2].nationality;

keep men[1].nationality != men[3].nationality;

keep men[1].nationality != men[4].nationality;

keep men[1].house_color != men[2].house_color;

keep men[1].house_color != men[3].house_color;

keep men[1].house_color != men[4].house_color;

keep men[1].cigarette != men[2].cigarette;

keep men[1].cigarette != men[3].cigarette;

keep men[1].cigarette != men[4].cigarette;

keep men[1].pet != men[2].pet;

keep men[1].pet != men[3].pet;

keep men[1].pet != men[4].pet;

keep men[1].drink != men[2].drink;

keep men[1].drink != men[3].drink;

keep men[1].drink != men[4].drink;

keep men[2].nationality != men[3].nationality;

keep men[2].nationality != men[4].nationality;

keep men[2].house_color != men[3].house_color;

keep men[2].house_color != men[4].house_color;

keep men[2].cigarette != men[3].cigarette;

keep men[2].cigarette != men[4].cigarette;

keep men[2].pet != men[3].pet;

keep men[2].pet != men[4].pet;

keep men[2].drink != men[3].drink;

keep men[2].drink != men[4].drink;

keep men[3].nationality != men[4].nationality;

keep men[3].house_color != men[4].house_color;

keep men[3].cigarette != men[4].cigarette;

keep men[3].pet != men[4].pet;

keep men[3].drink != men[4].drink;

};

Now we are ready to solve it. Let’s add some debug and solution print statements.

extend {

post_generate() is also

{

for i from 0 to 4 {

outf ("\n");

outf ("men[%d].nationality = %s\n", i, men[i].nationality);

outf ("men[%d].house_color = %s\n", i, men[i].house_color);

outf ("men[%d].cigarette = %s\n", i, men[i].cigarette );

outf ("men[%d].pet = %s\n", i, men[i].pet );

outf ("men[%d].drink = %s\n", i, men[i].drink );

};

outf ("===================================\n");

for i from 0 to 4 {

if (men[i].pet == fish)

{

outf ("\nAnswer to the quesiton 'Who keeps fish?' is %s who lives in house no %d with house color %s and smokes %s and drinks %s has %s as pet...\n", men[i].nationality, i, men[i].house_color, men[i].cigarette, men[i].drink, men[i].pet);

outf ("\n");

outf ("men[%d].nationality = %s\n", i, men[i].nationality);

outf ("men[%d].house_color = %s\n", i, men[i].house_color);

outf ("men[%d].cigarette = %s\n", i, men[i].cigarette );

outf ("men[%d].pet = %s\n", i, men[i].pet );

outf ("men[%d].drink = %s\n", i, men[i].drink );

};

}; //post_generate() is also

}; //extend sys

After loading it into Specman and solving it, we get following output.

Loading einsteins_puzle.e ...

Doing setup ...

Generating the test with IntelliGen using seed 1966611192...

men[0].nationality = norweigian

men[0].house_color = yellow

men[0].cigarette = dunhill

men[0].pet = cat

men[0].drink = water

men[1].nationality = dane

men[1].house_color = blue

men[1].cigarette = blend

men[1].pet = horse

men[1].drink = tea

men[2].nationality = english

men[2].house_color = red

men[2].cigarette = pall_mall

men[2].pet = bird

men[2].drink = milk

men[3].nationality = german

men[3].house_color = green

men[3].cigarette = prince

men[3].pet = fish

men[3].drink = coffee

men[4].nationality = swede

men[4].house_color = white

men[4].cigarette = blue_masters

men[4].pet = dog

men[4].drink = bier

===================================

Answer to the quesiton 'Who keeps fish?' is german who lives in house no 3 with house color green and smokes prince and drinks coffee has fish as pet...

men[3].nationality = german

men[3].house_color = green

men[3].cigarette = prince

men[3].pet = fish

men[3].drink = coffee

Starting the test ...

Running the test ...

No actual running requested.

Checking the test ...

Checking is complete - 0 DUT errors, 0 DUT warnings.

So the answer is “German keeps the Fish”. Now try to solve this solution multiple times with random seed and you will get the same answer. That way we can be sure that the constraints we’ve captured are correct.

One last observation I’ve made is that this solution can be solved in IntelliGen Specman solver only. It does not work with PGen Specman solver engine. The reason is quiet obvious. PGen depends on the order of constraints declaration whereas IntelliGen is truly bi-directional constraints solver which is natural way of solving all the constraints at the same time.

Hope you like this riddle and the solution. I am sure this is not the optimal way of solving the problem, but it’s my lazy weekend stuff, so I wrote whatever came to my mind first without thinking much about optimizing it. If you have any suggestion to improve it, please do comment. If you have solutions in other forms (XLS, Perl, tcl, python, C, C++, VB, PHP or any other your favorite language) then please do post it in the comment.

A Basic Course on "Functional Hardware Verification" from Udacity

2015-01-13T11:52:00.000+05:30

If you are new to Functional Verification and interested to learn about it, Udacity has a self paced online course available titled as "Functional Hardware Verification". Here is the link for the course.

Instructor Axel Scherer is a senior engineer and manager at Cadence Design Systems. Instructor Hannes Fröhlich is Member of Product Expert Team in Functional Verification R&D group of Cadence Design Systems.

UVM-Multi Language solution from Cadence

2013-09-26T18:43:00.000+05:30

Today's complex SoC level verification environment are based on advanced verification methodology standards. But these standards usually meant for single language domain. But fact of the life is that the these SoC level testbenches are made of mix of language domains like legacy Specman/e environment along with newly developed UVM-SV and SystemC or C++. Usually, when these scenario arrives, verification teams typically comes up with their own solutions which is mainly short term solution keeping existing needs in to the consideration. To develop this kind of inter operable solutions, there are quite a few challenges involved. Few are listed below.

1) Connecting different components of different domains
2) Transferring data/events from different domains
3) Synchronizations of major phases

Having said that, industry standard solution is the need of an hour. Cadence's Multi Language solution also known as UVM-ML addresses the above mentioned multi language integration challenges. UVM-ML is in existence for quite a sometime but least known. It was initially developed to take care of e-SV and e-SC integrations. UVM-ML is based on a back-plane library responsible for connecting two or more domains. Different language domain connect to back-plane library via language specific adapter layer. Currenty this solution supports integration of SystemC, UVM-SV, UVM-e.

Here is an example of how UVM-SV based producer can communicate to SystemC based consumer. You can refere more examples in the Incisiv installation area at $CDNS_HOME/tools/uvm/uvm_lib/uvm_ml/examples/sc/ and $CDNS_HOME/tools/uvm/uvm_lib/additions/uvm_ml_examples/ex_e_sv_sc_tlm/

//-----------------------------------------

//File : producer.sv
//System Verilog Producer
//-----------------------------------------

module topmodule;

import uvm_pkg::*;
`include "uvm_macros.svh"

//Declare basic packet which will be passed to SC consumer
class packet extends uvm_object;
   rand int data;
endclass

//Declare SV producer which will communicate with SC consumer through out port
class producer extends uvm_component;
   //Declare out port. This port will be connected to SC consumer
   uvm_analysis_port #(packet) out;

   //constructor
   function new(string name"producer", uvm_component parent=null);

super.new(name, parent);
out = new("out", this);

//Register out port with UVM-ML
ml_uvm::extnernal_if(out, "packet");

   endfunction : new

   //Generate dummy packet and pass it to out port
   task run_phase (uvm_phase phase);
      packet pkt = packet::type_id::create("pkt");

      phase.raise_objection(this);
      for (int i=0; i<5 br="" i="">      begin
         bit res = pkt.randomize();
         `uvm_info("TEST", $sformatf("producer.pkt.data='h%h", pkt.data), UVM_LOW)

         //Send the generated packet to out port
         out.write(pkt);
         #10;
      end

      phase.drop_objection(this);
   endtask : run_phase
endclass : producer

endmodule

//-----------------------------------------
//File : consumer.cpp

//SystemC Consumer

//-----------------------------------------
#include "ml_uvm.h";
#include "uvm.h";

using namespace tlm;
using namespace uvm;

class packet : public uvm_object
{
   UVM_OBJECT_UTILS(packet)
   public:
      int data;
};

UVM_OBJECT_REGISTER(packet)

//System C Consumer with templated with data type T
template <typename T>
class consumer : public uvm_compnent, public tlm_analysis_if
{
   public:
      sc_export > in;

   //constructor
   consumer(sc_module_name nm) : uvm_component(nm), in("in")
   {
      in(*this);
      //Register the export for mixed language communication
      ml_uvm::ml_uvm_register(&in);
   }

   UVM_COMPONENT_UTILS(consumer)

   //export implementation
   virtual void write( const T& t )
   {
      cout << sc_time_stamp() << " SystemC consumer receive a packet with data " << t.data << endl;
   }
};

UVM_COMPONENT_REGISTER_T(consumer, packet)

//System C testbench

SC_MODULE(TB)
{
   consumer c;
   SC_CTOR(TB) : c("consumer")
   {
      //Connect multi language port and export
      ml_uvm::ml_uvm_connect("producer.out", cons.in.name());
   }
};

Output Log:

UVM_INFO producer.sv(55) @ 0: producer [TEST] producer.pkt.data='h00000008
0 s SC consumer got a packet with data 8
UVM_INFO producer.sv(55) @ 10: producer [TEST] producer.pkt.data='h00000008
10 ns SC consumer got a packet with data 8
UVM_INFO producer.sv(55) @ 20: producer [TEST] producer.pkt.data='h00000003
20 ns SC consumer got a packet with data 3
UVM_INFO producer.sv(55) @ 30: producer [TEST] producer.pkt.data='h00000005
30 ns SC consumer got a packet with data 5
UVM_INFO producer.sv(55) @ 40: producer [TEST] producer.pkt.data='h00000006
40 ns SC consumer got a packet with data 6

UVM bidirectional port example using uvm_tlm_b_initiator_socket and uvm_tlm_b_target_socket ports

2013-09-25T15:35:00.000+05:30

In your System Verilog UVM environment, sometimes you want few components to communicate to each other in both ways. For example, a master component can request a memory component to pass over the memory content of specific address. So, how can you impelent such a communication channel between two components? Well, there are multiple ways. You can have two one-directional ports like uvm_get_ports and uvm_put_ports. Initator can send the address through output port and receives the data from another input port. Or it can be implemented through mailbox. The other way to implement is to use uvm_tlm_b_initiator_socket and uvm_tlm_b_target_socket ports. Using this port, you initiator can send a packet with specific address. Same packet can be updated with data by the memory element and later on can be read by initiator. Thus, by using single port and packet, two elements can communicate with each other in bidirectional way. Since this is a blocking port, request information and response information should come in a single shot. Here is an example to illustrate it. You can download the full examples by clicking uvm_bidirectional_port_example.tar.gz

//Memory cell definition

class mem_cell extend umv_sequence_item;

rand bit [1:0] addr;

rand bit [31:0] data;

endclass: mem_cell

//Memory component definition

class memory extends uvm_component;

//Define local memory

local bit [31:0] mem [3:0];

function new(string name = "memory", uvm_component parent = null);

super.new(name, parent);

socket = new("socket", this);

//Initialize the local memory

mem[0] = 32'h00000000;

mem[1] = 32'h11111111;

mem[2] = 32'h22222222;

mem[3] = 32'h33333333;

endfunction : new

//Declare blocking target socket port

uvm_tlm_b_target_socket #(memory, mem_cell) socket;

//Need to write implementation of b_transport() task

task b_transport(mem_cell req, uvm_tlm_time delay);

//Based on the req.addr, update the req.data which will be later read back by initiator

case (req.addr)

2'h0 : begin req.data = mem[0]; end

2'h1 : begin req.data = mem[0]; end

2'h2 : begin req.data = mem[0]; end

2'h3 : begin req.data = mem[0]; end

endcase

   endtask : b_transport

endclasss : memory

class initiator extend uvm_component'

   //Declare blocking transport socket port
   uvm_tlm_b_transport_socket #(mem_cell) socket;

   virtual task run_phase(uvm_phase phase);

      //instantiate a mem_cell
      mem_cell req;

      uvm_tlm_time delay = new;

      phase.raise_objection(this);

      //Create mem_cell
      req = mem_cell::type_id::create("req", , get_full_name());

      //set address and sent it across to memory component
      req.addr = 2'h0;
      socket.b_transport(req, delay);
      //memory element has now updated the req.data accordingly. it can be used now
      `uvm_info("TEST", $sformat(f("For req.add='h%h, received req.data='h%h", req.addr, req.data), UVM_LOW);

      //same object can be reused.
      //set address and sent it across to memory component
      req.addr = 2'h1;
      socket.b_transport(req, delay);
      //memory element has now updated the req.data accordingly. it can be used now
      `uvm_info("TEST", $sformatf("For req.add='h%h, received req.data='h%h", req.addr, req.data), UVM_LOW);

      phase.drop_objection(this);
   endtask : run_phase

endclass : initator

class env extends uvm_component;

initiator init;

memory mem;

//Connect two ports

function void connect_phase(uvm_phase phase)

init.socket.connect(mem.socket);

endfunction

endclass : env

Log Output:

UVM_INFO initiator.sv(22) @ 10: env.init [TESTCASE] For req.add='h0 received req.data='h00000000
UVM_INFO initiator.sv(26) @ 20: env.init [TESTCASE] For req.add='h1 received req.data='h11111111

You can refer UVM User Guide 1.1 from http://www.accellera.org/community/uvm for more details about these ports.

Automatic Coverage Weight Calculator Utility

2012-02-29T16:25:00.007+05:30

If you want to get Specman coverage number in linear fashion (i.e. coverage numbers = (total buckets hit) / (total buckets in valid space) ), then you need to set the weight of individual items and coverage groups properly. Updating the code for proper weights to each item and cover group is tedious and error prone task. Maintaining the code is also a problem. What if you can do it automatically by using Coverage API? I hope people, who are looking such kind of solution will benefit from this post.

Specman overall coverage grade is calculated in hierarchical manner by default. It means that coverage is calculated from leaf level to the top level in following manner. I've assumed that weight is not set manually and default weight value 1 is applied here.

Individual item grade is calculated by dividing buckets hit by total bucket for that item.
Individual cover group grade is calculated by dividing total of all items grade by total number of items
Overall coverage grade is calculated by dividing total of all cover groups graade by total number of cover groups

Take a look at the following example code.

extend sys

{

config : config_s;

};

struct config_s

{

a : uint(bits: 3);

b : uint(bits: 3);

c : bool;

event cov1_e;

event cov2_e;

cover cov1_e is

{

item a using ignore = (a in [0, 1, 7, 8]);

item b using ignore = (b in [0, 1, 7, 8]);

cross a, b using

ignore =

(a in [2] and b in [4]) or

(a in [4] and b in [2] );

};

cover cov2_e is

{

item a using ignore = (a in [0, 1, 7, 8]);

item c using ignore = (c == TRUE);

cross a, c;

};

keep soft a == select

{

40 : 2;

10 : 3;

40 : 4;

10 : 5;

10 : 6;

};

keep soft b == select

{

40 : 2;

10 : 3;

40 : 4;

10 : 5;

10 : 6;

};

keep soft c == TRUE;

run() is also

{

for i from 1 to 10

{

gen a; gen b; gen c;

emit cov1_e;

emit cov2_e;

outf ("a=%d b=%d c=%s\n", a, b, c);

};

When you run the above code with Intelligen with seed 1, Specman generates following combinations of a, b and c.

a=4 b=4 c=TRUE
a=4 b=4 c=TRUE
a=4 b=3 c=TRUE
a=2 b=2 c=TRUE
a=6 b=2 c=TRUE
a=2 b=4 c=TRUE
a=2 b=2 c=TRUE
a=2 b=4 c=TRUE
a=2 b=2 c=TRUE
a=4 b=6 c=TRUE

Let's analyze the coverage now.

Item	Hit	Valid Space	Grade
a	3	5	60.00% (hit/valid space)
b	4	5	80.00% (hit/valid space)
cross_a_b	5	23	21.74% (hit/valid space)

So, cov1_e cover group's grade = (grade of item a*weight + grade of item b*weight + grade of item cross_a_b*weight)/3 = 1.6174/3 = 53.91 %

Item	Hit	Valid Space	Grade
a	3	5	60.00% (hit/valid space)
c	1	1	100.00% (hit/valid space)
cross_a_c	3	5	60.00% (hit/valid space)

So, cov2_e cover group's grade = (grade of item a + grade of item c + grade of item cross_a_c)/3 = 2.20/3 = 73.33 %

So, overall grade = (cov1_e grade + cov2_grade)/2 = 1.2725/2 = 63.62 %

But, if you need the linear coverage, it should be
(Total number of hit buckets) / (Total number of buckets in valid space) = ((3+4+5) + (3+1+3))/((5+5+23) + (5+1+5)) = 43.18 %

This can be achieved by adjusting the weitage of individual item and cover group. If you set the weight of each item equal to the total number of valid buckets, linear coverage is achieved. Let's see how it works.

Item	Hit	Valid Space	Weight	Grade
a	3	5	5	60.00 % (hit/valid space)
b	4	5	5	80.00 % (hit/valid space)
cross_a_b	5	23	23	21.74 % (hit/valid space)

So, cov1_e cover group's grade = (grade of item a*weight + grade of item b*weight + grade of item cross_a_b*weight)/(weight of a + weight of b + weight of cross_a_b) = (3 + 4 + 5) / (5 + 5 + 23) = 36.36 %

Item	Hit	Valid Space	Weight	Grade
a	3	5	5	60.00 % (hit/valid space)
c	1	1	1	80.00 % (hit/valid space)
cross_a_c	3	5	5	21.74 % (hit/valid space)

So, cov2_e cover group's grade = (grade of item a*weight + grade of item c*weight + grade of item cross_a_c*weight)/(weight of a + weight of c + weight of cross_a_c) = (3 + 1 + 3) / (5 + 1 + 5) = 63.64 %

So, overall grade = (cov1_e grade*weight + cov2_grade*weight)/(weight of cov1_e + weight of cov2_e) = (12+7)/(33+11) = 43.18%

This number looks linear as we can see we've calculated the coverage based on the number of buckets hit divided by total number of bucket for whole of the coverage space. So, setting the weight of the items based its number of buckets, it gives us the correct result.

Setting the weight manually is tedious process as you need to check the exact number of valid buckets of each item and coverage groups by keeping ignores and ranges into the mind. And even you do that, if you want to change the coverage model again, you might need to calculate the valid space again which is tedious and error prone. So, why not automate it using Coverage API calls?

You can use this small utility which uses coveage API to change the weight of all the items and cover group. It gives you the linear overall grade which is total number of buckets hit in valid coverage space divided by total number of buckets in valid coverage space. This utility can also be used in the post processing of coverage database. This utility uses coverage API to recursively parse the whole coverage space of a given unit which can be sys. It counts the total number of buckets of each item and coverage group and uses covers.set_weight() to set the weight of items and cover groups recursively.

You can use it after loading the linear_coverage.e. It defines a specman command using "define as" macro. Example is given below

Specman>load linear_coverage.e
Specman>adjust weight sys (for whole coverage space)
Specman>adjust weight config_s (for coverage space defined in config_s struct)

I hope this will help you. Your comments and thoughts are welcome.

-------------------------------------------

liner_coverage.e

-------------------------------------------

define "adjust weight " as {

sys.adjust_weight = new;

sys.adjust_weight.main("<1>");

};

struct cover_info

{

item_name : string;

num_of_buckets: uint;

weight : uint;

};

struct bucket_cover_struct like user_cover_struct

{

collect: bool; // flag to skip specific item

cover_info : list (key: item_name) of cover_info;

main(items: string) is

{

if scan_cover(items) == 0 {

error("Adjust Weight Error: no cover items matching ", items," exist");

};

scan_bucket() is

{

if ((collect) and (cross_level == sub_items.size()-1)) then

{

var full_item_name := appendf ("%s.%s.%s", struct_name, group_name, item_name);

if (status in [hole, normal])

{

if cover_info.key_exists(full_item_name)

{

cover_info.first(.item_name == full_item_name).num_of_buckets = cover_info.first(.item_name == full_item_name).num_of_buckets + 1;

}

else

{

var temp_cov_info : cover_info = new;

temp_cov_info.item_name = full_item_name;

temp_cov_info.num_of_buckets = 1;

cover_info.add(temp_cov_info);

};

// Output a line of text for item:

end_item() is

{

if collect then

{

var full_item_name := appendf ("%s.%s.%s", struct_name, group_name, item_name);

var num_of_buckets := cover_info.first(.item_name == full_item_name).num_of_buckets;

outf ("%s - %d (weight=%d)\n", full_item_name, num_of_buckets, item_weight);

covers.set_weight(full_item_name, num_of_buckets, FALSE);

};

start_group() is

{

collect = (struct_name != "session");//skip session struct

if collect then

{

outf ("\n------------------------------------\n");

};

end_group() is

{

if collect then

{

var group_total : uint;

for each (cov_info) in (cover_info)

{

group_total = group_total + cov_info.num_of_buckets;

};

outf ("------------------------------------\n");

outf ("Group and Total Buckets ---> %s - %d (weight=%d)\n", group_name, group_total, group_weight);

covers.set_weight(appendf("%s.%s", struct_name, group_name), group_total, FALSE);

outf ("------------------------------------\n");

cover_info.clear();

};

// Define an instance of bucket_cover_struct:

extend sys

{

!adjust_weight: bucket_cover_struct;

init() is also { adjust_weight = new; };

setup() is also { set_config(cover, show_sub_holes, TRUE); };

};

Cadence's Labs on Cloud

2010-06-24T22:35:00.002+05:30

Have you ever wanted to try out any Cadence tools or VIPs evaluation without going through the process of getting evaluation licenses, software download and installation and all that logistic stuff? Now you can do all that without all that hassles. Cadence has tied with Xuropa for their cloud computing platform so that all you need is high speed broadband for any Cadence tools/VIPs evaluation.

Using Xuropa Online Labs, you can run an evaluation using the Incisive Enterprise simulator, following instructions for a self-paced demo. All the software runs on Xuropa servers, and there is nothing to purchase, license, install, download, or upload.

You can read more about it at at Cadence's Community Blog Post

Generic/Parameter support in Mixed HDL Hierarchy Code Generator

2010-05-08T16:40:00.002+05:30

I hope this small utility is helpful. I've thought one small enhancement to it. Now, you can select whether you need VHDL Generic or Verilog Parameterized examples code by selecting the checkbox. Please feel free to comment/enhancement. You can visit http://www.sandipgor.com/hdl_gen.html

Mixed HDL Hierarchy Code Generator

2010-04-09T18:38:00.004+05:30

Sometime back, I wanted to experiment Specman environment with Mixed HDL (Verilog + VHDL) design. I wanted to have a simple 4 level hierarchical design with simple port connections. It took some time for me to build it as I need to refer VHDL and Verilog syntax. That time one thought came to my mind to have simple utility which can build this env very quickly so that I don't need to invest time to clean up the compilation errors.

Keeping this simple requirement in mind, I decided to build such a simple online tool which can be used by everybody.

I've created one Javascript based tool which can generate Mixed HDL Hierarchical design.Its link is http://www.sandipgor.com/hdl_ gen.html

I've tried to keep it simple. You can use "Add VHDL" and "Add Verilog" buttons to add VHDL or Verilog instance into hierarchy. "Level Up" and "Level Down" buttons can be used to increase/decrease current level where you want to add instances. Finally "Generate" button can be used to dump the hierarchical HDL code into the two text box placed right side of the window. I've also kept "Clear Code" and "Clear Hierarchy" buttons to clean up the relevent data. "Undo" button is useful to undo the last change. Remember, there is no "Redo" button though.

I hope you will find it useful. Please feel free to use it.

Any suggestion/feedback is welcome.

DigitalVerification Blog is noticed by Verification Community

2009-07-10T11:30:00.002+05:30

I am glad and thankful to the verification community for appreciating my small contribution towards the verification world. This blog has been noticed by Cadence Team Specman and recoginized as useful resource.
ChipDesignMag.com also recognized this blog saying "if you live and breathe in this world, here’s an additional resource"
I'll keep posting and contributing to the verification world.

IntelliGen - Introduction

2009-06-25T12:50:00.015+05:30

IntelliGen is around for quite a while, but I've observed that most of the Specman users are less interested in/aware of it. Probably they are very comfortable with old generation engine known as PGen. Even I am quite comfortable with PGen and I am used to think generation in PGen way. But, when I went through IntelliGen, it also looked conviencing. But it will take some time to penetrate and Cadence has to push it hard so that people start thinking about generation IntelliGen way. :)

IntelliGen is a new generation engine introduced in Specman 6.1 version onwards. It is a new generation engine which uses different generation algorithm from Specman's original generation engine PGen. Though PGen remains default generation engine, user can switch to IntelliGen by setting a configuration flag before loading any code.

Specman>config gen -default_generator=IntelliGen

IntelliGen is easier to use as there is no generation dependencies on the fields declaration order. In PGen, fields which are declared first are generated first unless there are specific generation order mentioned using "keep gen before" or "readonly()". With a new and powerful debugger, its very easy to debug generation errors for IntelliGen. The messages which are displayed when any generation errors occur are more informative than whatever is displayed for PGen. Cadence also claims that performance can be increased by 2 to 5 times compared to PGen. IntelliGen solves some constraint more logically and intelligently compared to PGen. We will see all these in few examples.

Generation Order Independence

In the code shown below, we want to generate addr based on addr_hi_lo value. So you put constraint over addr_hi_lo and addr. But since addr is declared first, it will be generated first in PGen generation engine. Due to that, there are very little chance that it is either equal to addr_hi or addr_lo. So, either of the constraint on addr_hi_lo does not satisfy and PGen will not be able to solve it. Though the constraint is bidirectional, since addr is declared first, it is generated first and that makes constraint unidirectional.

Same code will not cause any generation error if IntelliGen is used because, there is not generation dependency on declaration order.

define addr_hi 0xFF;

define addr_lo 0x05;

type addr_kind : [LO, HI];

extend sys

{

addr : list of uint (bits: 8);

addr_hi_lo : addr_kind;

keep addr.size() == 10;

keep for each in (addr)

{

addr_hi_lo == HI => it == addr_hi;

addr_hi_lo == LO => it == addr_lo;

};

post_generate() is also { print addr; };

};

Results with PGen:

*** Error: Contradiction:
A contradiction has occurred when generating sys-@0.addr_hi_lo :
Previous constraints reduced its range of possible values,
then the following constraint contradicted these values:
addr_hi_lo == LO => it == addr_lo; at line 20 in @temp
Reduced: sys-@0.addr_hi_lo into []
To see details, reload and rerun with "collect gen"

Results with IntelliGen:

addr = (10 items, dec):
5 5 5 5 5 5 5 5 5 5 .0

Better Solvability

Further to that, IntelliGen takes good care of soft and soft select constraints. When soft select constraints are added for a field which already has soft constraint defined previously, PGen will ignore all the previously defined soft constraints even there are no contradiction between soft and soft select constraints. Whereas IntelliGen takes care of both constraints as long as they do not contradict. If they contradict, then IntelliGen ignores soft constraint over soft select. Take a look at the following example and results generated using PGen and IntelliGen.

type addr_kind : [LO, HI, OTHERS];

struct operation_s

{

addr_hi_lo : addr_kind;

keep soft addr_hi_lo in [HI, LO];

};

extend operation_s

{

keep soft addr_hi_lo == select

{

10 : LO;

80 : OTHERS;

10 : HI;

};

extend sys

{

op : list of operation_s;

keep op.size() == 10;

post_generate() is also { print op; };

};

Results with PGen:

op =
item type addr_hi_lo

0. operation* OTHERS
1. operation* OTHERS
2. operation* OTHERS
3. operation* OTHERS
4. operation* HI
5. operation* OTHERS
6. operation* OTHERS
7. operation* HI
8. operation* HI
9. operation* OTHERS

Results with IntelliGen:

op =
item type addr_hi_lo

0. operation* LO
1. operation* LO
2. operation* HI
3. operation* HI
4. operation* LO
5. operation* HI
6. operation* HI
7. operation* LO
8. operation* LO
9. operation* LO

Better Distribution

Because of improved constraint solving ability, IntelliGen gives better distribution of generated values within the range.

define addr_hi 0xFF;

define addr_lo 0x05;

type op_kind : [LO, HI, OTHERS];

struct operation_s

{

addr : uint (bits: 8);

op_hi_lo : op_kind;

keep op_hi_lo == HI => addr == addr_hi;

keep op_hi_lo == LO => addr == addr_lo;

keep op_hi_lo == OTHERS => addr in [addr_lo+1..addr_hi-1];

};

extend sys

{

op : list of operation_s;

keep op.size() == 10;

post_generate() is also { print op; };

};

Results with PGen:

op =
item type addr op_hi_lo

0. operation* 0x57 OTHERS
1. operation* 0x12 OTHERS
2. operation* 0x80 OTHERS
3. operation* 0xbe OTHERS
4. operation* 0x7f OTHERS
5. operation* 0x64 OTHERS
6. operation* 0x0f OTHERS
7. operation* 0xab OTHERS
8. operation* 0x6e OTHERS
9. operation* 0xcd OTHERS

Results with IntelliGen:

op =
item type addr op_hi_lo

0. operation* 0xff HI
1. operation* 0xc3 OTHERS
2. operation* 0xff HI
3. operation* 0x05 LO
4. operation* 0x05 LO
5. operation* 0x05 LO
6. operation* 0x1d OTHERS
7. operation* 0x6a OTHERS
8. operation* 0x1a OTHERS
9. operation* 0xff HI

Better Debug Information

When any generation error occurs, IntelliGen issues elaborated generation error message which is very useful to pin point the problematic area of the code. Look at the below code.

type addr_kind : [LO, HI, OTHERS];

struct operation_s

{

addr_hi_lo : addr_kind;

keep addr_hi_lo in [HI, LO];

};

extend sys

{

op : list of operation_s;

keep op.size() == 10;

keep for each in (op)

{

index in [0] => it.addr_hi_lo == LO;

index in [1..8] => it.addr_hi_lo == OTHERS;

index in [9] => it.addr_hi_lo == HI;

};

post_generate() is also { print op; };

};

Error Message with PGen:

*** Error: ERR_GEN_OR_WITH_NO_GEN_ALT: After static analysis, the following constraint
consists of non-enforceable constraints only:
index in [1..8] => it.addr_hi_lo == OTHERS; at line 19 in @temp

Error Message with IntelliGen:

*** Error: Contradiction when generating sys

No set of values exists for:
op[0x0..0xffffffff].addr_hi_lo

that obey the constraints:
keep addr_hi_lo in [0x0..0x1] at line 7 in @temp ,
index in [0x1..0x8] => it.addr_hi_lo == OTHERS at line 19 in @temp

with the input:
index = 0x1

By now, you might have realized the improvement of IntelliGen over PGen. I hope this is useful basic information about IntelliGen. I'll cover IntelliGen Technical Concepts in my next post.

Specman/Verification Books

2009-06-15T10:57:00.009+05:30

Specman Books

Design Verification with e
Author :	Samir Palnitkar
ISBN	0131413090
Publisher	Prentice Hall Professional Technical Reference
Publish Date	Auguts, 2003
Page	416
Preview

The e-Hardware Verification Language
Author :	Sasan Iman and Sunita Joshi
ISBN	1402080239
Publisher	Kluwer Academic Publishers
Publish Date	May, 2004
Page	349
Preview

Aspect-Oriented Programming with the e Verification Language: A Pragmatic Guide for Testbench Developers
Author :	David Robinson
ISBN	0123742102
Publisher	Morgan Kaufmann Publishers
Publish Date	August, 2007
Page	244
Preview

Verification Books

Metric Driven Design Verification: An Engineer's and Executive's Guide to First Pass Success
Author :	Hamilton B. Carter; Shankar G. Hemmady
ISBN	0387381511
Publisher	Springer Verlag
Publish Date	May, 2007
Page	361
Preview

Writing Testbenches: Functional Verification of HDL Models
Author :	Janick Bergeron
ISBN	1402074018
Publisher	Kluwer Academic Publishers
Publish Date	February, 2003
Page	512
Preview

Effective Functional Verification: Principles and Processes
Author :	Srivatsa Vasudevan
ISBN	0387286012
Publisher	Springer Verlag
Publish Date	June, 2006
Page	256
Preview

Principles of Functional Verification
Author :	Andrea S. Meyer
ISBN	0750676175
Publisher	Newnes
Publish Date	November, 2003
Page	240
Preview

SystemVerilog Books

Step-by-step Functional Verification with SystemVerilog and OVM
Author :	Sasan Iman
ISBN	0981656218
Publisher	Hansen Brown Publishing
Publish Date	May, 2008
Page	520
Preview

SystemVerilog for Verification: A Guide to Learning the Testbench Language Features
Author :	Spear, Chris
ISBN	0387270361
Publisher	Springer
Publish Date	June, 2007
Page	429
Preview

Verification Methodology Manual For Systerm Verilog
Author :	Andy Nightingale, Alan Hunter, Eduard Cerny and Janick Bergeron
ISBN	0387255389
Publisher	Springer-Verlag New York Inc
Publish Date	2005
Page	503
Preview

Writing Testbenches Using SystemVerilog
Author :	Janick Bergeron
ISBN	0387292217
Publisher	Springer-Verlag New York Inc
Publish Date	2006
Page	412
Preview

A Practical Guide for System Verilog Assertions
Author :	Srikanth Vijayaraghavan and Meyyappan Ramanathan
ISBN	0387260498
Publisher	Springer Verlag
Publish Date	2005
Page	334
Preview

Hardware Verification With SystemVerilog: An Object-oriented Framework
Author :	Mike Mintz and Robert Ekendahl
ISBN	0387717382
Publisher	Springer
Publish Date	May, 2007
Page	314
Preview

randc kind of implementation in e

2009-05-25T16:38:00.004+05:30

When I went through SystemVerilog constructs, one of the unique construct I found out was randc. Cyclic randomization sometimes helps you generating all unique combinations before repeating it. One classic usage example of randc is to inject all the sequences into DUT at least once without repeating it again. So, I was wondering if it is possible to implement it in e. I realized that though you can not generate the item based on its previously generated values, you can have some workaround for that using list psudo methods. There are all_values() and is_a_permutation() psudo methods which can be used for this purpose.

Let me explain the logic to implement that classic usage example to inject all the sequences into DUT without repeating it. If we somehow generate a list of unique sequence kinds randomly, we can take that list items one-by-one and generate the sequence based on that kind. So, to generate the unique yet random list of sequence kind, we can use above mentioned two list psudo methods. Take a look at the following code snippet.

type seq_type_t : [SEQ_A, SEQ_B, SEQ_C, SEQ_D, SEQ_E, SEQ_F, SEQ_G];

extend MAIN my_sequence_s

{

seq_randc : list of seq_type_t;

keep seq_randc.is_a_permutation(all_values(seq_type_t));

!seq : my_sequence_s;

body() @driver.clock is only

{

gen_seq_randc();

for i from 0 to seq_randc.size() - 1

{

do seq { keeping .kind == seq_randc[i]; }

};

all_values(seq_type_t) statement will return a list which will have all the unique values of scaler type seq_type_t. is_a_permutation() will make sure that seq_ranc list has random but all the fields of the list returned by all_values(seq_type_t) statement. Thus, we have a list which has all the random values of the sequence kind. Now, we can loop through this list one by one and generate a seq and push it to the DUT.

Less known and less used Specman commands

2009-05-22T14:27:00.024+05:30

There are quite a few Specman commands which are handy when it comes to debugging. Here I tried to summarize few less known but useful Specman commands. Here we go.

If you have verification environment loaded on Specman and one method is extended in multiple files and you want to see all the extension of that method in a single place, "collect" command is what you are looking for.

Specman> collect sys.mystruct.monitor

Specman> collect sys.run

File temp.erld - created by collecting:

sys.run (after module specman)

----------------------- Reset sys.run:

extend sys {

run(

) is as was after specman;

};

----------------------- From temp.e at line 6:

extend sys {

run() is also

{

var x : mystruct_s;

gen x;

};

----------------------- End of sys.run

If you want to debug temporal expression, you would like to visualise how different events are triggered. Event chart is basic but sometimes useful for debugging temporal expressions. To see the events you first have to collect events you are interested in by using "collect events" Specman command.

Specman> collect events *.*
Specman> collect events sys.mystruct.* //collects all events for the instance sys.mystruct
Specman> collect events mystruct_s.* //collects all the events of struct mystruct_s

If you want to see the events triggered during simulation, you can use Specman command "show events" after collecting the events as mentioned above.

Specman> show events
Specman> show events 100 //This command shows events since time 100
Specman> show events 100..150 //This command shows events in the time range 100..150
Specman> show events -chart //Pops up event chart

If you want to have a summarized report about the events count, if it is associated with cover group, its source etc, you can use "show events def" command.

Specman> show events def sys.any

count echo col covr name source
------------------------------------------------------------------
0 10000 FALSE TRUE FALSE sys.any @sn_te_tick

Executing actions on command line. You can define variables or call methods or start a TCMs. (you can not call a TCM on command line). Remember, you can not give "gen" action on command line, but you can call a method which has gen action in it.

Specman> var x : uint(bits: 4) = 5;
Specman> var y : uint = x + 10;
Specman> print x + y;
Specman> sys.non_tcm()
Specman> start sys.tcm()
Specman> sys.non_tcm_with_arg(4, TRUE)

You can search/grep within the loaded files using "search" command

Specman> search mystruct_s

You can open a file (known as "module" in Specman terms) in source browser by using "source" command. It will open a source browser with that perticular line number into focus.

syntax: source

Specman> source mystruct.e 50

You can run unix commands using "shell" command.

syntax: shell

Specman> shell echo $SPECMAN_PATH
Specman> shell pwd

You can also get the value of define by issuing "show define" command.

syntax: show define [-v] [-e]

Specman> show define -v "*WIDTH*"

If you want to know what are the modules that are loaded you can use "show modules" command.

Specman> show modules

You can get unix environment variables value within your e code by using get_symbol() method.

my_method() is

{

outf ("SPECMAN_PATH=%s",get_symbol("SPECMAN_PATH"));

};

12. If you wish to execute specman command in e code, then you can use specman() method as shown below.

pre_generate() is

{

specman("break on error");

};

If you wish to execute unix command from your e code, you can use output_from() method.

my_method() is

{

var list_of_files: string;

list_of_files = output_from("ls");

print list_of_files;

};

If you want to uderstand port binding in Specman, use "show ports" command.

You can use "trace bind' to follow the binding process

If you have executed a set of commands and want to see the history of executed commands, you can use "show redo" command.

Specman> show redo
show redo
The redo buffer (default is 'redo 0..') =
0. "restore specman.esv"
1. "load temp.e"
2. "test"
3. "clear screen; restore; reload; test"

Once you know the hisotry of executed command, you can reexecute them by issueing "redo" Specman command.

Specman> redo 3 //this will execute command 3 (clear screen; restore; reload; test)
Specman> redo 0..2 //this will execute command 0 to 2 (restore specman.esv, load temp.e, test)

If you have wave command executed to view e fields into waveform and want to dump all these wave tracing commands into a file, you can use "write wave" command.

syntax: write wave to

Specman> write wave to trace_wave.ecom

19. To debug, packing and unpacking, you can use "show pack" and "show unpack" command as shown below.

Specman> var x : uint (bits: 3) = 3
Specman> var y : uint (bits: 7) = 5
Specman> show pack(packing.low, x, y);

|9 8 7 6 5 4 3|2 1 0| +0
+-------------+-----|
|0 0 0 0 1 0 1|0 1 1|
+-------------+-----|
|y |x |

Specman> var x : packet_s
Specman> var data : list of bit = {1;1;0;1;0;0;0;1;1;1;0;1}
Specman> show unpack(packing.low, data, x)

|1 0 9 8 7 6 5 4|3 2 1 0| +0
+---------------+-------|
|1 0 1 1 1 0 0 0|1 0 1 1|
+---------------+-------|
|x.addr |x.len |

Debugging packing and unpacking in Specman

2009-05-21T13:03:00.014+05:30

Hello readers, I am back after a loooooong break. It has been quite a some time since I posted something here as I was too busy with my personal life and responsibilities. I try to be regular now. So with this note, let me start something from today itself.

While using packing/unpacking in your environment, you might have gone through some debugging troubles due to silly mistakes. So here are few tips to avoid errors for packing and unpacking.
So starting with Unpacking, there can be 2 kind of problems you may face while unpacking a list into struct

You run out of data while unpacking (i.e. list is shorter than total length of physical fields of a struct)
Unpacking is finished but you have bits/bytes left over (i.e. list is bigger than total length of physical fields of struct)

If you have situation 1, it will be flagged as run-time error by Specman. But, if you have situation 2, you might not even aware of it as Specman does not issue even a warning for this. For situation 1, if you want to suppress run-time error, you can use 'try' action.

tcm() @clk is {

try {

unpack(packing.low, my_list, my_struct);

} else {

message (LOW, "Unpacking failed");

};

To debug packing/unpacking issues, you can use Specman command 'trace packing'. It shows how packing/unpacking is performed. Following example shows the result of 'trace packing' command performed for unpacking.

Following example shows the result of 'trace packing' command performed for packing

If unpacking is unsuccessful (ran out of data in the list), you normally get following message on Specman STDOUT.

*** Error: Ran out of data while trying to unpack (use 'trace packing' for further details)
at line 19 in @packing_unpacking_debug
unpack(packing.low, lob_u, x);

But if you use 'trace packing' Specman command, you see where unpacking stopped.

> ----- Starting an unpack() at line 19 in @packing_unpacking_debug ----

> ----------- Unpacking 'x': x_s
> Unpacking 'x.a': uint (bits: 4)
8 .0
> 'x.a': uint (bits: 4) = 8
> Unpacking 'x.b': uint (bits: 8)
0 5 .0
> 'x.b': uint (bits: 8) = 5
> Unpacking 'x.c': list of byte
*** Error: Ran out of data while trying to unpack into 'x.c'
at line 19 in @packing_unpacking_debug
unpack(packing.low, lob_u, x);

One of the very common cause of the unpacking failure is the unsized list. If the target struct has unsized list as a physical field, all the bits/bytes of the source list will be absorbed by this unsized list and there will be no data left for the next physical field and Specaman will issue an error. So it is always advisable not to have unsized list in the target struct.

Another reason for unpacking failure could be subtype physical fields. If you have few physical fields defined under 'when' subtype of a struct, your need to make sure which subtype to pick while unpacking.

One more reason for the unpacking to give errorneous result is the order of the physical fields in a struct. If physical fields of a struct is defined in the multiple files, then import order of that file becomes crucial because based on the order, physical fields will be treated differently during unpacking. Take a look at the following example.

Job openings at Cadence Design Systems, India (Bangalore and Noida)

2008-12-17T12:19:00.003+05:30

In this tough time, there are some openings at Cadence Design Systems for its India centers (Bangalore and Noida). Please have a look at the openings for more details here.

Verification Engineer required for Cadence Design Systems, Bangalore or Noida

2008-10-15T12:29:00.004+05:30

Experience: 4 to 5 years

Location: India, Bangalore or Noida

Job Requirement:

This engineer’s primary role will be to work in a team oriented environment to deliver digital logic design and verification methodologies, customised design environments and design implementation solutions that align with client goals. He/she will interact and work with other engineers on the worldwide D&V VCAD delivery team.
Responsibilities will include creating and customising design environments, design and verification methodologies.
Ideally the canddate should be able to assist with the optimisation of acceleration and emulation technologies using the Cadence Incisive verification flows including the Palladium and Xtreme hardware.
The engineer must have a solid background in logic design and verification experience with Cadence technology in the digital domain.
The client should have at least a basic understanding of modeling (e.g. Architecture or system), and both block and system level verification experiance, preferably with coverage driven methodologies.
The candidate should possess the necessary engineering and consultancy skills, i.e. that he/she is technically mature with the necessary communication skills to be able to consult effectively with clients, e.g. to talk to, coach and advise Customers.
The engineer must have a solid background in the electronics industry with at least 4 to 5 years experience, and should be willing to learn new technical and consulting skills.

Key Accountabilities:

Execution on VCAD Customer support projects, e.g. Implementation and functional verification of design systems.
Development of customer specific verification environments including components, methodology support, operation and maintenance.
Be prepared to provide design and verification support in VCAD Customer design projects, both remotely and onsite.
Ability to handle all design environment implementation tasks and architectural tasks with the minimum support or through working in a joint team of Cadence and Customer engineers.
Work on multi person projects of varying complexity, working especially in a multi-site/multi-cultural project. The latter requires excellent communication skills in English.
Acquire a basic understanding of the (service) business environment of Cadence within 6 months including pre sales support.

Contact: getjobsinindia2007@gmail.com

DFT Engineer required for Cadence Design Systems, Bangalore

2008-10-15T12:16:00.004+05:30

Experience: 3 to 6 Years

Location: Bangalore, India

Skill Sets: Scan, Jtag, Atpg, Tester interface.

Good to have skills: Exposure to ATPG tools like Encounter Test

Job Description:

This engineer’s primary role will be to work in a team oriented environment to deliver DFT activities for implementation services. He/she will interact and work with other engineers on the worldwide delivery team.
This engineer is expected to provide services using the following technical skills: Scan, JTAG, ATPG, Logic Synthesis, Static Timing Analysis, and to interface with designers / testing team.
In addition to the technical skills they will be expected to operate effectively in project teams delivering the design of leading edge. Additional responsibilities include customer interactions and pre-sales activities.

Key Accountabilities:

Ability to handle all design environment implementation tasks assigned, either personally or through supervising other Cadence and Customer engineers.
Work on multi person projects of varying complexity, working especially in a multi-site/multi-cultural project. The latter requires excellent communication skills in English.
Acquire a basic understanding of the (service) business environment of Cadence including pre sales support.

Contact: getjobsinindia2007@gmail.com

OVM 2.0 Webinar on 16th Oct, 2008

2008-10-15T11:57:00.005+05:30

There is a OVM 2.0 Webinar organized on 16th Oct, 2008.

Details of webinar is mentioned below.

Date : Thursday, October 16th, 2008
Time : 10:00 AM - 11:00 AM (Pacific Daylight Time)
Location : Online via Microsoft Office Live Meeting (details provided upon registration)

For more information and registration, please click here.

OVM 2.0 update contains some technical advances. Few of are listed bellow

Unified sequence mechanism
OVM User Guide
Improved debugging and expanded use of parametrized classes
Driver/sequencer communication enhancements

IEEE Working Group Announces Updated e Language Standard

2008-05-26T12:22:00.002+05:30

The e Functional Verification Language Working Group (eWG) was formed to define a standard for the e language, and the initial 1647-2006 standard was published in September 2006. And now, IEEE has approved a revision to IEEE 1647, Standard for the Functional Verification Language e. This revision is called 1647-2008 e Language Standard

Please see following link for more details.
http://standards.ieee.org/announcements/IEEE1647_eLanguageStandard.html

OVM Seminars at Hyderabad and Bangalore

2008-03-13T10:57:00.008+05:30

There is an OVM semniar held at Hyderabad on Thursday, March 25, 2008 between 8:30 am to 2:30 pm (IST) and at Bangalore on Thursday, March 27, 2008 between 8:30 am to 2:30 pm (IST).

For registeration, please visit http://www.ovmworld.org/seminars.php

Here are the topics covered in the seminar.

OVM Overview

Planning for Verification
Testbench Architecture
Transaction-Level Modeling (TLM) in Verification

Stimulus and Coverage

Transaction-Level Stimulus
Decoupling Stimulus from the Design
Sequential Stimulus Specification
Layered Stimulus
Transaction-Level Layered Coverage

Planning for Verification Reuse

Flexible Instantiation – Using the Factory
Configuring Verification Components for Reuse
Hierarchical Encapsulation & Reuse

Putting it All Together

OVM Moving Forward

About generation of do-not-generate fields

2008-02-13T16:08:00.020+05:30

Say a parent struct is having two fields inside it. One is an ungenerated (with do-not-generate sign) child struct and another ungenerated field is of pre defined data types (like uint, bool etc.).

When this parent struct is generated

1) ungenerated field of pre defined data types will get their initial value (0 for scalars, NULL for structs, empty list for lists).

2) ungenerated field whose value is a range (such as [0..100]) gets the first value in the range.

3) ungenerated field of user defined data types (like sturcts) will not be allocated and none of the fields in it will be generated.

Take a look at following code.

struct child_s

{

!a : uint (bits: 4);

b : uint (bits: 4);

};

struct top_s

{

!child : child_s;

!x : uint (bits: 3);

!y : uint (bits: 3);

keep x in [2..5];

};

extend sys

{

top : top_s;

};

In this example, top_s struct has one ungenerated struct and two ungenerated fields of uint (bits: 3). When top is generated inside the sys

1) y will be generated and will get any random value between 0 and 7

2) x will be generated with value of 2 as it is a range bound ungenerated field.

3) child field will not be generated as it is defined as ungenerated struct. So, the fields a and b of child struct will not be generated as well.

By default MAIN sequence is not empty

2008-02-12T16:30:00.000+05:30

By default, body method of MAIN sequence is not empty. It contains a loop which executes random number of times creating the sequence field (randomly unless constrained). The generated/created driver contains an instance of the MAIN sequence, which is started automatically upon run().

So, in your environment, if body method of MAIN sequence of any eVC is not made empty, it will start executing some random sequences at 0 simulation time. This might have adverse effect on the behavior of the stimulus given to the design if you are using virtual sequence, because user defined sequence (executed inside virutal sequence) and MAIN sequence might be running parallely and might be driving same signals and causing undesirable stimulus.

Debugging this will become difficult. You might be wondering why some other sequences are being executed even though you are calling perticular sequence only in virtual sequence?

So, if you are an eVC developer, always provide sequence library with body of MAIN sequence made empty. And if you are verifying any DUT and if you are using virtual sequence and not using MAIN sequence of any eVC, make body method of all MAIN sequences empty.

Take a look at this e code to check that how MAIN sequence is executing a loop which creates and executes the random sequence. Load this e code and give test command with random seed. You will see that even though body method of MAIN sequence is not extended, MAIN sequence is executing random sequneces (TEST1, TEST2, SIMPLE).

OVM available on its new site

2008-01-14T15:00:00.000+05:30

Open Verification Methodology (OVM) is now available on its new site http://www.ovmworld.org

Checker implementation dilema

2008-01-08T12:14:00.000+05:30

Ever encountered the checker implementation dilemma? How to implement it? Using temporal expressions or using methods? Once in a lifetime, every verification engineer comes to a stage where they have to take decision about the implementation of a checker. Once, I made a wrong decision and implemented a complex event-based checker in temporal expressions using "expect" statement. After that I was introduced to the hell of debugging temporal expressions in Specman. Event chart is a junk feature in the Specman. Filtering of the events, having full path of the events are not so easy to see in the events chart. Even, when-subtypes' events can not be viewed separately.

After having a lot of trouble debugging temporal expressions, I re-wrote the entire checker in the methods format using "check that" and "if else" construct. Debugging of method based checker is such an easy task in Specman, as Specman has a beautiful and reliable debugger. Lot of features, though might be basic, are quiet useful when it comes to debug the method based checkers. In Specman debugger, one can put conditional and unconditional breakpoints, can see the hierarchy of the threads, can add watch points on e fields and a lot more. I will discuss about debugging in Specman for the beginners in the separate post.

After that experience, I concluded following things for the checker implementation.

Write down the checker in the simple english to understand its complexity.
If checker is simple, I mean, just contains 2 to 3 basic events to check, then go for temporal expressions for the checker implementation.
If checker is even a bit complex having more than 3 events, just go for the method based checker implementation. You will save a hell lot of time which might be lost in the debugging temporal expressions.

Method based checker implementation looks more readable, even though it requires extra codes to implement and it's a bit slower than temporal expressions based checkers. But at the end, you are going to save lot of time having clean checker.