Verification Blog: December 2007

Thursday, 27 December 2007

IEEE standard draft for e available for review

Individuals interested in functional verification languages are invited by eWG (e Work Group) to take part in the standardizing the e functional verification language. The eWG is sponsored by the IEEE Design Automation Standards Committee called DASC.

Read more about eWG and its activity here.

IEEE Standard P1647 draft for functional verification language e is also available for review. Click here to see the draft..

Monday, 24 December 2007

My Toon

Raised Objection Report

Any raised objection will prohibit your simulation to stop. And In large environments, it may be painfull to find the one objection still raised using the SN commands 'show objections' or 'trace objections'.

You may just load follwoing e-code in your test and you'll be able to get a short report of all raised objections by typing 'sys.report_raised_objections(TEST_DONE)'

extend sys

{

report_raised_objections(kind : objection_kind) is

{

// usage: sys.report_raised_objections(TEST_DONE)

var obj_units : list of any_unit = get_all_units(any_unit).all(.get_objection_counter(kind) > 0);

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

outf("Objection Report:\n");

outf("Counter Total Env e path\n");

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

for each (u) in obj_units

{

outf("%-7d %-5s %-7s \n", u.get_objection_counter(kind), u is an any_env ? u.short_name() : "", u.e_path());

};

// just to print the command in the sn window

run() is also

{

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

outf("REPORT_RAISED_OBJECTIONS loaded\n");

outf("usage: sys.report_raised_objections(TEST_DONE)\n");

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

};

Friday, 14 December 2007

Are You Reporting Wrong Coverage Number?

If you are not giving weight to your items in your coverage groups, the overall functional coverage number you get on Specman coverage report might be wrong. Let me explain it using an example. Take a look at following code.

struct coverage_example

{

event cover_e;

a : bool;

b : uint (bits: 2);

cover cover_e is

{

item a;

item b;

cross a, b;

};

run() is also

{

emit cover_e;

};

extend sys

{

cov_ex : coverage_example;

keep soft cov_ex.a == TRUE;

keep soft cov_ex.b == 0;

};

If you load above code, issue a test command and see the coverage report, it will show you 28%, which is wrong in fact. Specman calculates the overall coverage numbers hierarchical. For the above code, it calculates as following.

For item a:
total bucket = 2
total hit = 1
So, coverage number = 50%

For item b:
total bucket = 4
total hit = 1
So, coverage number = 25%

For cross a, b:
total bucket = 4*2 = 8
total hit = 1
So, coverage number = 12.5%

For Overall:
total bucket = 3 (item a, item b and cross a,b)
total hit = (50 + 25 + 12.5) = 87.5
So, coverage number = 29.166% (87.5/3)

But, in fact, it should be calculated as following.

Total bucket in the coverage group = 2 + 4 + 8 = 14
Total hit = 1 + 1 + 1 = 3
So, overall coverage should be (3*100/14 = 21.4285%)

This wrong calculation can be avoided by doing following modification in the code. See highlighted "green" code below.

struct coverage_example

{

event cover_e;

a : bool;

b : uint (bits: 4);

cover cover_e is

{

//Weight is total number of buckets

item a using weight=2;

item b using weight=4;

cross a,b using weight=8;

};

run() is also

{

emit cover_e;

};

extend sys

{

cov_ex : coverage_example;

keep soft cov_ex.a == TRUE;

keep soft cov_ex.b == 0;

};

But, all the time, applying weight to every item is not possible, as some code may be imported from third party vendor or some code might be read-only to the user. Also whenever the number of buckets change, user needs to update the weight of particular item. This might not be feasible sometimes.

To avoid this, there is a utility called bucket_counter which was delivered by Clemens Mueller from Cadence. This e code will report total number of buckets in each item and total number of bucket hits. This simple utility will help you calculate the exact number of functional coverage you have.

Please click here to download the code.

Just load the ecode along with your environment and read the coverage file. Then issue "sys.report_buckets()". It will report total number of buckets in each item, and total number of hits, as shown below.

Valid Space size for item a is 2 buckets
Valid Space size for item b is 4 buckets
Valid Space size for item cross__a__b is 8 buckets
total coverage buckets: 14
total coverage buckets hit: 3

Thursday, 13 December 2007

Nice Papers on AOP and Verification

Here are 3 nice paper written by David Robinson from Verilab on following topics.

1) An Introduction to Aspect Oriented Programming in e
2) Simplify SoC Verification using a Generic Approach
3) Simplify SoC Verification using a Generic Approach - NMI

eToolkit from Verilab

Here is a very useful toolkit from Verilab to understand somebody else's e environment. It is especially useful when you want to have an overview and detailed view of the e code.

http://www.verilab.com/resources/e-toolkit/

Using this toolkit, you can find like inheritance hierarchy of classes and also find declaration and extension of classes, enumtypes, methods and coverage groups.

ASIC and VLSI design companies in India

I've listed all semiconductor companies in India registered with India Semiconductor Assosiation. I got this list from ISA itself. You can visit their page to get updated list.

Specman Interview Questions - Part II

Follwing questions are taken from http://www.specman-verification.com/index.php?entry=entry061218-182034. Pleaser refer this page for all the answers.

1) What are the differences between structs and units?
2) What are the special unit related fields and methods?
3) How can you pass a struct by reference in e?
4) How do you pass basic types by reference?
5) What is the use of coverage per instance?
6) How can you use it to prevent the creation of fake coverage holes?
7) What logical structure (object structure) and physical structure (file structure) are defined by the eRM?
8) Which conventions are defined by the eRM?
9) What type of object is used as a container for an eVC?
10) What would you change in Specman?
11) What would you say are the main differences between work as an employee and as an independent consultant?
12) What do you normally do when you end a project?

Wednesday, 12 December 2007

Cover "check that" and "expect" statement

If you want to write a checker coverage grid, Cadence Specman team has come up with a solution to put "check that" and "expect" statement in the coverage grid.

Please find this shareware at following link. This works for Specman 6.0 onwards.

http://sandipgor.googlepages.com/shr_chkcov_1.1.tar.gz

Verification books available on Google Books

Some of the best verification guides are available online at Google Books. For example, try following.

http://www.google.com/books?q=janick+bergeron

VLSI Jobs

For VLSI jobs, please refer http://vlsi-jobs.blogspot.com. There are quite a few good job openings listed.

Specman Interview Questions

Following questions are taken from http://www.specman-verification.com/static.php?page=WorkInterviewQuestions. Please refer this page for all the answers.

1) What are the differences between directed testbench and random testbench?
2) Draw the structure of a typical random testbench, describing each of the parts in detail.
3) Why is it important to keep code for generators/scoreboards and code for BFMs separated?
4) Is it a must to have an automatic checker (a scoreboard) in a directed testbench? Is it a must in a random testbench?
5) What is the difference between "protocol checking" and "data checking"? In which part of the testbench should each be done?
6) Which of the parts in the testbench should add data to the scoreboard?
7) What are the advantages and disadvantages of taking scoreboard data from the generator?
8) What are the advantages and disadvantages of taking scoreboard data from the BFM?
9) Suppose you have a scoreboard for a specific block inside the DUT. Will that scoreboard be useful during end to end (or full chip) tests as well? What for?
10) What is the use of the test file? Is it supposed to make the data that is generated by the testbench more or less random?
11) What is the difference between the constraints that are added through the test file, and those constraints that are placed in the environment files themselves?
12) Please explain the difference between declarative code (also known as static code), and sequential code, and give an example of each. What is the major advantage of controlling generation via declarative code? Which of the two is harder to debug?
13) What are test scenarios (also known as sequences)? What are they used for? Do the use of test scenarios makes the testbench more or less random?
14) Please give an example of when a test scenario should be used.
15) At which phase the use of sequences is more common at the beginning, at the middle, or at the end of the verification process?

Tuesday, 11 December 2007

Access Multi Language Signals using Ports

Ever came across the issue where one unit's signal map uses different signals from multi language design (VHDL and Verilog)? Take following example.

As shown in the diagram, top_wrapper is in vhdl and DUT is in verilog. Corresponding to this design, in e domain, two units are defined, one is top_wrapper_u and another dut_u.

Now, somewhere in dut_u unit, if you want to use clk from dut (verilog) and reset_n from top_wrapper (vhdl ), you can not do it using computed names (using strings). To achieve this, you have to use e external ports. Once ports are defined, using .agent() attribute of the units and ports, you can define, which unit/port is belonged to which design unit (vhdl/verilog).

As shown in the following code, refer the last line. reset_n.agent() is constrained to vhdl so that reset_n will be taken from vhdl module and rest of the ports in the dut_u will be taken from verilog module as dut_u.agent() is constrained to verilog.

<' unit dut_u
{
clk : in simple_port of bit is instance;
reset_n : in simple_port of bit is instance;

keep bind (clk, external);
keep bind (reset_n, external);

keep clk.hdl_path = "clk";
keep reset_n.hdl_path = "reset_n";

};

unit top_wrapper_u
{
dut : dut_u is instance;
};

extend sys
{
top : top_wrapper_u is instance;

keep top.hdl_path() == "~/top_wrapper";
keep top.dut.hdl_path() == "~/top_wrapper/dut";

keep top.agent() == "vhdl";
keep top.dut.agent() == "verilog";
keep top.dut.reset_n.agent() == "vhdl";

};
'>

TechToons

Interview Questions

1) What will be the output when following code is loaded and "test" command is issued? (Easy)

extend sys {

x : uint;

keep x <>

keep x in [0, 45, 190, 255];

run() is also

{

outf ("x = %d\n", x);

};

2) Write a temporal expression to verify that if event rdy_e has emitted then 3 clock cycles before, event req_e should have been triggered. The purpose of the check is to verify that rdy_e is not triggered without valid req_e. This should not be confused with "rdy_e should occur within 3 clock cycles of req_e". (Medium)

3) Write Sudoku solver in e. (Hard)

For more interview questions, please refer following links.
http://www.specman-verification.com/static.php?page=WorkInterviewQuestions

Friday, 7 December 2007

100% functional coverage is not enough

Let me address this age old question once again. As we all know that 100% functional coverage does not mean bug free design, but it surely adds to the confidence of the designer. It is one of the criteria for verification completion. So, what are the other criteria people use for their verification completion. Most of us will answer that 100% code coverage achievement and few of us will also add that closing all the pending review items derived from verification review. But is it enough? We still feel that it is not enough. Deep inside our hearth, we still feel the need of some more testing/verification.

Well, this feeling will be there because of the nature of the verification task. But, let me come to the technical aspect of the 100% functional coverage. If we ask our self, what is the functional coverage, we will be scratching our head to find exact wordings to explain the functionality. Let me try to explain it in my words. For me, Functional Coverage Points are nothing but the measure of all possible combinations of inputs which can be applied to the design. So, in our functional coverage grid, we always cover all the input stimulus parameters and we assume that the output behaviour will be checked somewhere else in the verification environment. So, 100% functional coverage means we have stimulated the design with all possible stimulus. But this does not guarantee that all outputs and behaviors of the design are checked. So, 100% functional coverage does not mean bug free design. But, if we also have one more coverage grid which could be checker coverage grid, then, we can definitely say that we have applied all possible combinations of inputs and we have also checked all possible combinations of outputs. Even we need co-relation between these two grids. I mean, for each functional coverage point (one possible combination input), there should be at lease one checker coverage point (one possible output checker). And for each checker coverage point, there should be at least one functional coverage point. Thus co-relating these two grids will definitely help to improve the confidence in the design.

So, in my opinion, verification completion declaration should be based on following criteria.

1) All test cases passed.
2) 100% Code Coverage (of course with some waivers)
3) 100% Functional Coverage (and again, with some waivers)
4) 100% Checker Coverage
5) Correlation between Functional Coverage Grid and Checker Coverage Grid.

Thursday, 6 December 2007

Hello

Hi everyone,

This is my first blog ever. I have created this blog to discuss different aspects of verification of digital circuits. You will find lot of useful information about verification especially for Specman and e. You will also have fun as I am planning to have TechToons to share few cartoons about the Techies and their life (some created by me). Keep visiting this site for more updates.