Monday 14 March 2011

Summary of Chapter 2: Fundamentals of Object Oriented Programming: Part 2

Object Relationships
The true power of OOP becomes apparent when objects are connected in various relationships. There are many kinds of relationships that are possible. We will consider two of the most fundamental relationships HAS-A and IS-A.

HAS-A
HAS-A refers to the concept of one object contained or owned by another. Members represent the HAS-A relationship. The figure below illustrates the underlying memory model for a HAS-A relationship. Object A contains a reference or a pointer to object B.
                                                                     Has - A Relationship

Object A owns an instance of object B. Coding a HAS-A relationship in SystemVerilog involves instantiating one class inside another or in some other way providing a handle to one class that is stored inside another.
class B; 
endclass
class A; 
   local B b;
   function new(); 
      b = new();
            endfunction 
          endclass
 
class A contains a reference to class B. The constructor for class A, function new(), calls new() on class B to create an instance of it. The member b holds a reference to the newly created instance of B.

IS-A
The IS-A relationship is most often referred to as inheritance. A new class is derived from a previously existing object and inherits its characteristics. Objects created with inheritance are composed using IS-A. The derived object is considered a sub-class or a more specialized version of the parent object.
                                                                       Is A Relationship

To express IS-A using UML, we draw a line between objects with an open arrowhead pointing to the base class. Traditionally, we draw the base class above the derived classes, and the arrows point upward, forming an inheritance tree. SystemVerilog uses the keyword extends to identify an inheritance relationship between classes:
class A;
   int i;
   float f;
endclass
class B extends A;
    string s;
endclass

Class B is derived from A, so it contains all the attributes of A. Any instance of B not only contains the string s, but also the floating point value f and the integer i.

Summary of Chapter 2: Fundamentals of Object Oriented Programming: Part 1

The central idea of OOP is that programs are organized as a collection of interacting objects, each with its own data space and functions. Objects can be made reusable because they encapsulate everything they need to operate, can be built with minimal or no external dependencies, and can be highly parameterized.

Classes and Objects
Class- refers to a class declaration or an uninstantiated object
Object- object refers to an instance of a class.

class register;
   local bit[31:0] contents;
   function void write(bit[31:0] d)
       contents = d;
   endfunction
   function bit[31:0] read();
       return contents;
   endfunction
endclass

This very simple class has one member, contents, and two methods, read() and write(). To use this class, you create objects by instantiating the class and then call the object’s methods, as shown below

module top; register r;
   bit[31:0] d;
   initial begin
       r = new();
       r.write(32’h00ff72a8);
      d = r.read();
   end
endmodule

The local attribute on class member contents tells the compiler to strictly enforce the boundaries of the class. If you try to access contents directly, the compiler issues an error. You can only access contents through the publicly available read and write functions. This kind of access control is important to guarantee no dependencies on the internals of the class and thus enable the class to be reused.

Thursday 10 March 2011

Verification Principles: Summary from OVM Cookbook. Chapter 1:Part 2: Example

Let have an example of most fundamental device, an AND gate. Figure 1 shows the schematic symbol for a two-input AND gate. The gate has two inputs, A and B, and a single output Y. The device computes the logical AND of A and B and puts the result on Y.
Our mission is to prove that our design, the AND gate, works correctly. To verify that it does indeed perform the AND function correctly, we first need to list the questions. The truth table helps us create the set of questions we need to verify the design. Each row of the table contains an input for A and B and the expected output for Y. Since the table is exhaustive, our generator question is, for each row in the truth table, when we apply the values of A and B identified in that row, does the device produce the expected output for Y? To answer the are-we-done question, we determine whether we have exercised each row in the truth table and received a yes answer to the does-it- work question for that row. Our are-we-done question is Do all rows work?
To automate answering both the does-it-work and are-we-done questions, we need some paraphernalia, including the following:
·      A model that represents the DUT (in this case, the AND gate)
·      The design intent in a form we can codify as a reference model
·      Some stimuli to exercise the design
·      A way to compare the result to the design intent

While our little testbench is simple, it contains key elements found in most testbenches at any level of complexity. The key elements are the following:
·      DUT
·      Stimulus generator—generates a sequence of stimuli for the DUT
·      Scoreboard—embodies the reference model

DUT circuit
The DUT is our two-input AND gate. We implement the AND gate as a module with two inputs, A and B, and one output Y.
module and2 ( output bit Y, input A, B);
initial Y = A & B;
always @* Y = #1 A & B;
endmodule

Stimulus Generator
This example generates directed stimulus. Each new value emitted is computed in a specific order. The purpose of the stimulus generator is to produce values as inputs to the DUT. stimulus, a two-bit quantity, contains the value to be assigned to A and B. After it is incremented in each successive iteration, the low-order bit is assigned to A, and the high-order bit is assigned to B.
module stimulus(output bit A, B);
bit [1:0] stimulus_count = 0;
always #10 {A,B} = stimulus_count++;
endmodule

Scoreboard Module
The scoreboard is responsible for answering the does-it-work question. It watches the activity on the DUT and reports whether it operated correctly.1 One important thing to notice is that the structure of the scoreboard is strikingly similar to the structure of the DUT. This makes sense when you consider that the purpose of the scoreboard is to track the activity of the DUT and determine whether the DUT is working as expected. The scoreboard pins are all inputs. The scoreboard does not cause activity on the design. It passively watches the inputs and outputs of the DUT.
module scoreboard(input bit Y, A, B);
reg Y_sb, truth_table[2][2];
initial begin
truth_table[0][0] = 0;
truth_table[0][1] = 0;
truth_table[1][0] = 0;
truth_table[1][1] = 1;
end

always @(A or B) begin
Y_sb = truth_table[A][B];
#2 $display(“@%4t - %b%b : Y_sb=%b, Y=%b (%0s)”,
$time, A, B, Y_sb, Y,
((Y_sb == Y) ? “Match” : “Mis-match”));
end
endmodule

The top-level module, shown below, is completely structural; it contains instantiations of the DUT, the scoreboard, and the stimulus generator, along with the code necessary to connect them.
module top;
wire A, B, Y;
stimulus s(A, B);
and2 a(Y, A, B);
scoreboard sb(Y, A, B);
initial #100 $finish(2);
endmodule

When we run the simulation for a few iterations, here is what we get:
# @ 22 - 01 : Y_sb=0, Y=0 (Match)
# @ 32 - 10 : Y_sb=0, Y=0 (Match)
# @ 42 - 11 : Y_sb=1, Y=1 (Match)
# @ 52 - 00 : Y_sb=0, Y=0 (Match)
# @ 62 - 01 : Y_sb=0, Y=0 (Match)
# @ 72 - 10 : Y_sb=0, Y=0 (Match)
# @ 82 - 11 : Y_sb=1, Y=1 (Match)
# @ 92 - 00 : Y_sb=0, Y=0 (Match)

Each message has two parts. The first part shows the stimulus being applied. The second part shows the result of the scoreboard check that compares the DUT’s response to the predicted response. We use a colon to separate the two parts. This simple testbench illustrates the use of a stimulus generator and a scoreboard that serves as a reference. Although the DUT is a simple AND gate, all the elements of a complete testbench are present.

Verification Principles: Summary from OVM Cookbook. Chapter 1:Part 1

General principles of verification to establish a framework for designing a testbenches based on two questions - Does it works? And Are we done?
Does It Work?
Each design will have its own set of does-it- work questions whose role is to determine functional correctness of the design. Functional correctness questions ask whether the device behaves properly in specific situations. We derive these questions directly from the design intent, and we use them to express design intent in a testbench.
And then we formulate the entire question so that they can be answered yes or no. At the end of the day, a design either works or not depends on question than you answered. Keep in mind that more specific questions tell you more about the machinery.
As is often the case, it is not practical to enumerate every single does-it-work question. To verify that every word in a 1 Mb memory can be written to and read from, it is neither practical nor necessary to write one million questions
Number
Does-It-Work Questions
1
Does a packet arriving at the input port addressed to output port 0 arrive at port 0?
2
Does a packet arriving at the input port addressed to output port 1 arrive at port 1?
3
Does a packet arriving at the input port addressed to output port 2 arrive at port 2?
4
Does a packet arriving at the input port addressed to output port 3 arrive at port 3?

Are We Done?
To determine the answer to Are we done?, we need to know if we have answered enough of the does-it-work questions to claim that we have sufficiently verified the design. We begin this task by prioritizing all the does- it-work questions across two axes:

Easy to answer
Hard to answer
Most critical functionality
No-brainer.
Get to work!
Least critical functionality
Probably can omit.
Don’t waste the time

Are-we-done questions are also called functional coverage questions, questions that relate to whether the design is sufficiently covered by the test suite in terms of design function. As with does-it-work questions, we can also decompose functional coverage questions into more detailed questions. And just like functional correctness questions, functional coverage questions must also be answerable in terms of yes or no.
In summary, the art of building a testbench begins with a test plan. The test plan begins with a carefully thought out set of does-it-work and are-we-done questions.

Wednesday 9 March 2011

OVM - Open Verification Methodology.

salam,
Frankly speaking i have zero knowledge about this OVM thing. but i need to understand this OVM for my next project. The objective of using this methodology is to make sure you verify the system effectively. Next few days, ill be extract OVM cookbook. what exactly you need in order to develop you own verification. For those who a new with OVM, you may try google "ovmworld" website and search around there. A lot of useful stuff there for you to learn.