UVM Interview Questions - 5

Q31: What is virtual sequencer and virtual sequence in UVM?

A virtual sequencer is a sequencer that is not connected to a driver itself, but contains handles for sequencers in the testbench hierarchy. It is an optional component for running of virtual sequences - optional because they need no driver hookup, instead calling other sequences which run on real sequencers.

A sequence which controls stimulus generation across more than one sequencer, coordinate the stimulus across different interfaces and the interactions between them. Usually the top level of the sequence hierarchy i.e. 'master sequence' or 'coordinator sequence'. Virtual sequences do not need their own sequencer, as they do not link directly to drivers. When they have one it is called a virtual sequencer.

Here is a good article which explains how to use virtual sequence and virtual sequencer.

http://www.learnuvmverification.com/index.php/2016/02/23/how-virtual-sequence-works-part-1/

Q32: How set_config_* works?

The uvm_config_db class provides a convenience interface on top of the uvm_resource_db to simplify the basic interface that is used for configuring uvm_component instances.

Configuration is a mechanism in UVM that higher level components in a hierarchy can configure the lower level components variables. Using set_config_* methods, user can configure integer, string and objects of lower level components. Without this mechanism, user should access the lower level component using hierarchy paths, which restricts re-usability.

This mechanism can be used only with components. Sequences and transactions cannot be configured using this mechanism. When set_config_* method is called, the data is stored w.r.t strings in a table. There is also a global configuration table.

Higher level component can set the configuration data in level component table. It is the responsibility of the lower level component to get the data from the component table and update the appropriate table.

following are the method to configure integer, string and object of uvm_object based class respectively.

function void set_config_int (string inst_name, string field_name, uvm_bitstream_t value)

function void set_config_string (string inst_name, string field_name, string value)

function void set_config_object (string inst_name, string field_name, uvm_object value, bit clone = 1)

Q33: What are the advantages of uvm RAL model ?

• The RAL (register abstraction layer) provides accesses to DUT and also keeps a track of register content of DUT.
• UVM RAL can be used to automate the creation of high level, object oriented abstraction model of registers and memory in DUT.
• Register layer makes the register abstraction and access of its contents independent of the bus protocol which is used to transfer data in and out of registers inside the design.
• Hierarchical model provided by RAL makes the reusability of test bench components very easy.
• The changes in initial configuration of registers or specifications can be easily communicated in the entire environment. RAL layer supports both front door and backdoor access. The backdoor access does not use the bus interface rather it uses the HDL defined paths for direct communication with the device. Thus in zero simulation time the registers of device can be reconfigured using the backdoor access and verification can be started.
• One more advantage of backdoor access is that it can be used for verify if the access through front door are happening correctly. To achieve this the front door, write is verified using backdoor read.

Q34: What are the different override types?

Two type of overriding is supported by UVM

1. Type overriding

Type overriding means that every time a component class type is created in the Testbench hierarchy, a substitute type i.e. derived class of the original component class, is created in its place. It applies to all the instances of that component type.

Syntax:

<original_type>::type_id::set_type_override(<substitute_type>::get_type(), replace);

where “replace” is a bit which is when set equals to 1, enables the overriding of an existing override else existing override is honoured.

2. Instance overriding

In Instance Overriding, as name indicates it substitutes ONLY a particular instance of the component OR a set of instances with the intended component. The instance to be substituted is specified using the UVM component hierarchy.

Syntax:

<original_type>::type_id::set_inst_override(<substitute_type>::get_type(), <path_string>);

Where “path_string” is the hierarchical path of the component instance to be replaced.

Q35: Explain end of simulation in UVM?

Different approaches to finish the UVM Test using the objection mechanism are

1. Raising & dropping objections

raise_objection() and drop_objection() are the methods to be used to do that.

2. phase_ready_to_end

phase_ready_to_end method is executed automatically by UVM once ‘all dropped’ condition is achieved during Run Phase.

3. set_drain_time

Another approach supported by UVM is setting the drain time for the simulation environment. Drain time concept is related to the extra time allocated to the UVM environment to process the left over activities e.g. last packet analysis & comparison etc after all the stimulus is applied & processed.

<< PREVIOUS        NEXT >>

UVM Interview Questions - 4

Q26: What is p_sequencer ? OR Difference between m_sequencer and p_sequencer?

m_sequencer is the default handle for uvm_vitual_sequencer and p_sequencer is the hook up for child sequencer.

m_sequencer is the generic uvm_sequencer pointer. It will always exist for the uvm_sequence and is initialized when the sequence is started.

p_sequencer is a typed-specific sequencer pointer, created by registering the sequence to the sequencer using macros (`uvm_declare_p_sequencer) . Being type specific, you will be able to access anything added to the sequencer (i.e. pointers to other sequencers, etc.). p_sequencer will not exist if we have not registered the sequence with the `uvm_declare_p_sequencer macros.

The drawback of p_sequencer is that once the p_sequencer is defined, one cannot run the sequence on any other sequencer type.

Q27: What is the difference between Active mode and Passive mode with respect to agent?

An agent is a collection of a sequencer, a driver and a monitor.

In active mode, the sequencer and the driver are constructed and stimulus is generated by sequences sending sequence items to the driver through the sequencer. At the same time the monitor assembles pin level activity into analysis transactions.

In passive mode, only the monitor is constructed and it performs the same function as in an active agent. Therefore, your passive agent has no need for a sequencer. You can set up the monitor using a configuration object.

Q28: What is the difference between copy and clone?

The built-in copy() method executes the __m_uvm_field_automation() method with the required copy code as defined by the field macros (if used) and then calls the built-in do_copy() virtual function. The built-in do_copy() virtual function, as defined in the uvm_object base class, is also an empty method, so if field macros are used to define the fields of the transaction, the built-in copy() method will be populated with the proper code to copy the transaction fields from the field macro definitions and then it will execute the empty do_copy() method, which will perform no additional activity.

The copy() method can be used as needed in the UVM testbench. One common place where the copy() method is used is to copy the sampled transaction and pass it into a sb_calc_exp() (scoreboard calculate expected) external function that is frequently used by the scoreboard predictor.

The clone() method calls the create() method (constructs an object of the same type) and then calls the copy() method. It is a one-step command to create and copy an existing object to a new object handle.

Q29: What is UVM factory? 

UCM Factory is used to manufacture (create) UVM objects and components. Apart from creating the UVM objects and components the factory concept essentially means that you can modify or substitute the nature of the components created by the factory without making changes to the testbench. 

For example, if you have written two driver classes, and the environment uses only one of them. By registering both the drivers with the factory, you can ask the factory to substitute the existing driver in environment with the other type. The code needed to achieve this is minimal, and can be written in the test.

Q30: What are the types of sequencer? Explain each?

There are two types of sequencers :

uvm_sequencer #(REQ, RSP) :

When the driver initiates new requests for sequences, the sequencer selects a sequence from a list of available sequences to produce and deliver the next item to execute. In order to do this, this type of sequencer is usually connected to a driver uvm_driver #(REQ, RSP).

uvm_push_sequencer #(REQ, RSP) :

The sequencer pushes new sequence items to the driver, but the driver has the ability to block the item flow when its not ready to accept any new transactions. This type of sequencer is connected to a driver of type uvm_push_driver #(REQ, RSP).

<< PREVIOUS    NEXT >>

UVM Interview Questions - 3

Q21: What is analysis port?

Analysis port (class uvm_tlm_analysis_port) — a specific type of transaction-level port that can be connected to zero, one, or many analysis exports and through which a component may call the method write implemented in another component, specifically a subscriber.

port, export, and imp classes used for transaction analysis.

uvm_analysis_port

Broadcasts a value to all subscribers implementing a uvm_analysis_imp.

uvm_analysis_imp

Receives all transactions broadcasted by a uvm_analysis_port.

uvm_analysis_export

Exports a lower-level uvm_analysis_imp to its parent.

Q22: What is TLM FIFO?

In simpler words TLM FIFO is a FIFO between two UVM components, preferably between Monitor and Scoreboard. Monitor keep on sending the DATA, which will be stored in TLM FIFO, and Scoreboard can get data from TLM FIFO whenever needed.

// Create a FIFO with depth 4

      tlm_fifo = new ("uvm_tlm_fifo", this, 4);

Q23: How sequence starts?

start_item starts the sequence

virtual task start_item ( uvm_sequence_item item,  

                                          int  set_priority =  -1,

                                        uvm_sequencer_base  sequencer =  null )

start_item and finish_item together will initiate operation of a sequence item.  If the item has not already been initialized using create_item, then it will be initialized here to use the default sequencer specified by m_sequencer. 

Q24: What is the difference between UVM RAL model backdoor write/read and front door write/read ?

Fontdoor access means using the standard access mechanism external to the DUT to read or write to a register. This usually involves sequences of time-consuming transactions on a bus interface. 

Backdoor access means accessing a register directly via hierarchical reference or outside the language via the PLI. A backdoor reference usually in 0 simulation time.

Q25: What is objection?

The objection mechanism in UVM is to allow hierarchical status communication among components which is helpful in deciding the end of test.

There is a built-in objection for each in-built phase, which provides a way for components and objects to synchronize their testing activity and indicate when it is safe to end the phase and, ultimately, the test end.

The component or sequence will raise a phase objection at the beginning of an activity that must be completed before the phase stops, so the objection will be dropped at the end of that activity. Once all of the raised objections are dropped, the phase terminates.

Raising an objection: phase.raise_objection(this);

Dropping an objection: phase.drop_objection(this);

<< PREVIOUS       NEXT >>

UVM Interview Questions - 1

Q11: Difference between module & class based TB?

Ans: A module is a static object present always during of the simulation.

A Class is a dynamic object because they can come and go during the life time of simulation.

Q12: What is uvm_config_db ? What is difference between uvm_config_db & uvm_resource_db?

Ans: uvm_config_db is a parameterized class used for configuration of different type of parameter into the uvm database, So that it can be used by any component in the lower level of hierarchy.

uvm_config_db is a convenience layer built on top of uvm_resource_db, but that convenience is very important. In particular, uvm_resource_db uses a "last write wins" approach. The uvm_config_db, on the other hand, looks at where things are in the hierarchy up through end_of_elaboration, so "parent wins." Once you start start_of_simulation, the config_db becomes "last write wins."

All of the functions in uvm_config_db#(T) are static, so they must be called using the :: operator

It is extended from the uvm_resource_db#(T), so it is child class of uvm_resource_db#(T)

Q13: What is the advantage and difference of  `uvm_component_utils() and `uvm_object_utils()?

Ans: The utils macros define the infrastructure needed to enable the object/component for correct factory operation. 

The reason there are two macros is because the factory design pattern fixes the number of arguments that a constructor can have. Classes derived from uvm_object have constructors with one argument, a string name. Classes derived from uvm_component have two arguments, a name and a uvm_component parent.  

The two `uvm_*utils macros inserts code that gives you a factory create() method that delegates calls to the constructors of uvm_object or uvm_component. You need to use the respective macro so that the correct constructor arguments get passed through. This means that you cannot add extra constructor arguments when you extend these classes in order to be able to use the UVM factory.

Q14: Difference between `uvm_do and `uvm_rand_send ?

Ans: `uvm_do perform the below steps:

1. create
2. start_item
3. randomize
4. finish_item
5. get_response (optional)

while `uvm_rand_send perform all the above steps except create. User needs to create sequence / sequence_item.

Q15: Difference between uvm_transaction and uvm_seq_item?

Ans: class uvm_sequence_item extends uvm_transaction

uvm_sequence_item extended from uvm_transaction only, uvm_sequence_item class has more functionality to support sequence & sequencer features. uvm_sequence_item provides the hooks for sequencer and sequence , So you can generate transaction by using sequence and sequencer , and uvm_transaction provide only basic methods like do_print and do_record etc .

<< PREVIOUS    NEXT >>

UVM Interview Questions - 2

Q16: Is uvm is independent of systemverilog ?

Ans: UVM is a methodology based on SystemVerilog language and is not a language on its own.  It is a standardized methodology that defines several best practices in verification to enable  efficiency in terms of reuse and is also currently part of IEEE 1800.2  working group.

Q17: What are the benefits of using UVM?

Ans: Some of the benefits of using UVM are :

• Modularity and Reusability – The methodology is designed as modular components (Driver, Sequencer, Agents , env etc) which enables reusing components across unit level to multi-unit or chip level verification as well as across projects.
• Separating Tests from Testbenches – Tests in terms of stimulus/sequencers are kept separate from the actual testbench hierarchy and hence there can be reuse of stimulus across different units or across projects
• Simulator independent – The base class library and the methodology is supported by all simulators and hence there is no dependence on any specific simulator
• Better control on Stimulus generation – Sequence methodology gives good control on stimulus generation. There are several ways in which sequences can be developed which includes randomization, layered sequences, virtual sequences etc which provides a good control and rich stimulus generation capability.
• Easy configuration – Config mechanisms simplify configuration of objects with deep hierarchy. The configuration mechanism helps in easily configuring different testbench components based on which verification environment uses it and without worrying about how deep any component is in testbench hierarchy
• Factory mechanism – Factory mechanisms simplifies modification of components easily. Creating each components using factory enables them to be overridden in different tests or environments without changing underlying code base.

Q18: Can we have user defined phase in UVM?

Ans: In addition to the predefined phases available in uvm , the user has the option to add his own phase to a component. This is typically done by extending the uvm_phase class the constructor needs to call super.new which has three arguments

• Name of the phase task or function
• Top down or bottom up phase
• Task or function

The call_task  or call_func and get_type_name need to be implemented to complete the addition of new phase.

Below is a simple example 

Example

class custom_phase extends uvm_phase;

   function new();

      super.new(“custom”,1,1);

   endfunction

   task call_task  ( uvm_component parent);

     my_comp_type comp;

     if ( $cast(comp,parent) )

             comp.custom_phase();

   endtask

   virtual function string get_type_name();

      return “custom”;

   endfunction

endclass

Q19: What is uvm RAL model ? why it is required ?

Ans: In a verification context, a register model (or register abstraction layer) is a set of classes that model the memory mapped behavior of registers and memories in the DUT in order to facilitate stimulus generation and functional checking (and optionally some aspects of functional coverage). The UVM provides a set of base classes that can be extended to implement comprehensive register modeling capabilities.

Q20: What is the difference between new() and create?

Ans: We all know about new() method that is use to allocate memory to an object instance. In UVM (and OVM), the create() method causes an object instance to be created from the factory. This allows you to use factory overrides to replace the desired object with an object of a different type without having to recode.

<< PREVIOUS      NEXT >>

UVM Interview Questions

Q1: What is UVM? What is the advantage of UVM?

Ans: UVM (Universal Verification Methodology) is a standardized methodology for verifying the both complex & simple digital design in simple way.

UVM Features:

• First methodology & second collection of class libraries for Automation
• Reusability through testbench
• Plug & Play of verification IPs
• Generic Testbench Development
• Vendor & Simulator Independent
• Smart Testbench i.e. generate legal stimulus as from pre-planned coverage plan
• Support CDV –Coverage Driven Verification
• Support CRV –Constraint Random Verification
• UVM standardized under the Accellera System Initiative
• Register modeling

Q2: UVM derived from which language?

Ans: Here is the detailed connection between SV, UVM, OVM and other methodologies. 

Q3. What is the difference between uvm_component and uvm_object?

                       OR

We already have uvm_object, why do we need uvm_component which is actually derived class of uvm_object?

Ans: 

uvm_component:

• Quasi Static Entity (after build phase it is available throughout the simulation)
• Always tied to a given hardware(DUT Interface) Or a TLM port
• Having phasing mechanism for control the behavior of simulation
• Configuration Component Topology

uvm_object:

• Dynamic Entity (create when needed, transfer from one component to other & then dereference)
• Not tied to a given hardware or any TLM port
• Not phasing mechanism 

Q4: Why phasing is used? What are the different phases in uvm?

Ans: UVM Phases is used to control the behavior of simulation in a systematic way & execute in a sequential ordered to avoid race condition. This could also be done in system verilog but manually.

1. List of UVM Phases:
2. buid_phase
3. connect_phase
4. end_of_elaboration_phase
5. start_of_simulation_phase       
6. run _phase  (task)
   Sub Phases of Reset Phase:
   pre_reset_phase
   reset_phase
   post_reset_phase
   pre_configure_phase
   configure_phase
   post_configure_phase
   pre_main_phase
   main_phase
   post_main_phase
   pre_shutdown_phase
   shutdown_phase
   post_shutdown_phase
7. extract_phase
8. check_phase
9. report_phase

Below figure makes it more clear

Q5: Which uvm phase is top - down , bottom – up & parallel?

Ans: Only build phase is a top-down & other phases are bottom-up except run phase which is parallel. The build phase works top-down since the testbench hierarchy may be configure so we need to build the branches before leafs

Q6: Why build phase is top – down & connect phase is bottom – up?

Ans: The connect phase is intended to be used for making TLM connections between components, which is why it occur after build phase. It work bottom-up so that its got the correct implementation all the way up the design hierarchy, if worked top-down this would be not possible

Q7: Which phase is function & which phase is task?

Ans: Only run phase is a task (time consuming phase) & other phases are functions (non-blocking)

Q8: Which phase takes more time and why?

Ans: As previously said the run phase is implemented as task and remaining all are function. run phase will get executed from start of simulation to till the end of simulation. run phase is time consuming, where the testcase is running.

Q9: How uvm phases initiate?

Ans: UVM phases initiate by calling run_test(“test1”) in top module. When run_test() method call, it first create the object of test top & then call all phases.

Q10: How test cases run from simulation command line?

Ans: In top module write run_test(); i.e. Don't give anything in argument.

Then in command line : +UVM_TESTNAME=testname

Next >>

What Is A 'Clocking Block'?

In Verilog, a module is the unit for any design entity. SystemVerilog extends this to include other design entities such as an interface, a program block and, last but not the least, a clocking block. An interface separates how a design interacts with the rest of the design from the design itself. A program block separates a test benching function from a silicon implementable design. And a clocking block specifies clock signals and the timing and synchronization requirements of various blocks. A clocking block is helpful in separating clocking activities of a design from its data assignments activities and can be used powerfully in test benching.

A clocking block assembles all the signals that are sampled or synchronized by a common clock and define their timing behaviors with respect to the clock. It is defined by a clocking-endclocking keyword pair. Perhaps an example will describe this best.

clocking clock1 @(posedge clk1);
   default input #2ns output #3ns;
   input a1, a2;
   output b1;
endclocking
In the above example,

1. The name of the clocking block is clock1. You can have as many clocking blocks in your environment as you want. Also, there may be multiple clocking blocks for the same clock, inputs or outputs in a single design.
2. The clock associated with this clocking block is clk1. Each clocking block must have at least one clock associated with it.
3. The default keyword defines the default skew for inputs (2 ns) and output (3 ns).
4. The input and output keywords define the input and output signals associated with the clock and the skew defined earlier.
5. One thing to note here is that input or output declarations inside a clocking module does not specify the data width.

A clocking block is both a declaration and an instance of that declaration and can only occur within a module, interface or program block (in the same scope as an always block). Variables inside a clocking block can be accessed specifying the full pathname. For instance, if the full pathname for clock1 above is top.test.clock1, the full pathname for variable a1 is top.test.clock1.a1.

A clocking block only describes how the inputs and outputs are sampled and synchronized. It does not assign a value to a variable. That is left to a module, interface or program that the clocking module is part of. While the parent block of a clocking module properly assigns a value to a variable, a clocking block defines how inputs are sampled and outputs are synchronized for its parent module. This is why an input or output declaration inside a clocking block does not need to specify any data width since it is only relevant if you assign a value to a variable or read from it.

Get free daily email updates!

Follow us!

SystemVerilog Interface

Interfaces are a major new construct in SystemVerilog, created specifically to encapsulate the communication between blocks, allowing a smooth refinement from abstract system-level through successive steps down to lower RTL and structural levels of the design. Interfaces also facilitate design re-use. Interfaces are hierarchical structures that can contain other interfaces.

There are several advantages when using an Interface:

• They encapsulate connectivity: an interface can be passed as a single item through a port, thus replacing a group of names by a single one. This reduces the amount of code needed to model port connections and improves its maintainability as well as readability.
• They encapsulate functionality, isolated from the modules that are connected via the interface. So, the level of abstraction and the granularity of the communication protocol can be refined totally independent of the modules.
• They can contain parameters, constants, variables, functions and tasks, processes and continuous assignments, useful for both system-level modelling and testbench applications.
• They can help build applications such as functional coverage recording and reporting, protocol checking and assertions.
• They can be used for port-less access: An interface can be instantiated directly as a static data object within a module. So, the methods used to access internal state information about the interface may be called from different points in the design to share information.
• Flexibility: An interface may be parameterised in the same way as a module. Also, a module header can be created with an unspecified interface instantiation, called a Generic Interface. This interface can be specified later on, when the module is instantiated.

At its simplest, an interface is a named bundle of wires, similar to a struct, except that an interface is allowed as a module port, while a struct is not.

// Interface definition
interface Bus;
  logic [7:0] Addr, Data;
  logic RWn;
endinterface

// Using the interface
module TestRAM;
  Bus TheBus();                   // Instance the interface
  logic[7:0] mem[0:7];
  RAM TheRAM (.MemBus(TheBus));   // Connect it

  initial
  begin
    TheBus.RWn = 0;               // Drive and monitor the bus
    TheBus.Addr = 0;
    for (int I=0; I<7; I++)
      TheBus.Addr = TheBus.Addr + 1;
    TheBus.RWn = 1;
    TheBus.Data  = mem[0];
  end
endmodule

module RAM (Bus MemBus);
  logic [7:0] mem[0:255];

  always @*
    if (MemBus.RWn)
      MemBus.Data = mem[MemBus.Addr];
    else
      mem[MemBus.Addr] = MemBus.Data;
endmodule

Interface Ports

An interface can also have input, output or inout ports. Only the variables or nets declared in the port list of an interface can be connected externally by name or position when the interface is instantiated, and therefore can be shared with other interfaces.  The ports are declared using the ANSI-style.

Here is an example showing an interface with a clock port:

interface ClockedBus (input Clk);
  logic[7:0] Addr, Data;
  logic RWn;
endinterface

module RAM (ClockedBus Bus);
  always @(posedge Bus.Clk)
    if (Bus.RWn)
      Bus.Data = mem[Bus.Addr];
    else
      mem[Bus.Addr] = Bus.Data;
endmodule

// Using the interface
module Top;
  reg Clock;

  // Instance the interface with an input, using named connection
  ClockedBus TheBus (.Clk(Clock));
  RAM TheRAM (.Bus(TheBus));
  ...
endmodule

Parameterised Interface

This is a simple example showing a parameterised interface:

interface Channel #(parameter N = 0)
    (input bit Clock, bit Ack, bit Sig);
  bit Buff[N-1:0];
  initial
    for (int i = 0; i < N; i++)
      Buff[i] = 0;
  always @ (posedge Clock)        
   if(Ack = 1)
     Sig = Buff[N-1];
   else
     Sig = 0;
endinterface

Tasks in Interfaces

Tasks and functions can be defined in interfaces, to allow a more abstract level of modelling.

The next example shows two tasks in an interface being used to model bus functionality. The tasks are called inside the testRAM module:

interface MSBus (input Clk);
  logic [7:0] Addr, Data;
  logic RWn;

  task MasterWrite (input logic [7:0] waddr,
                    input logic [7:0] wdata);
    Addr = waddr;
    Data = wdata;
    RWn = 0;
    #10ns RWn = 1;
    Data = 'z;
  endtask

  task MasterRead (input  logic [7:0] raddr,
                   output logic [7:0] rdata);
    Addr = raddr;
    RWn = 1;
    #10ns rdata = Data;
  endtask
endinterface

module TestRAM;
  logic Clk;
  logic [7:0] data;
  MSBus TheBus(.Clk(Clk));
  RAM TheRAM (.MemBus(TheBus));
  initial
  begin
    // Write to the RAM
    for (int i = 0; i<256; i++)
      TheBus.MasterWrite(i[7:0],i[7:0]);

    // Read from the RAM
    for (int i = 0; i<256; i++)
    begin
      TheBus.MasterRead(i[7:0],data);
      ReadCheck : assert (data === i[7:0])
        else $error("memory read error");
    end
  end
endmodule

SystemVerilog Virtual Interfaces

This is most common SystemVerilog interview question that is asked while you will appearing for the position of Verification Engineer.

As you know an interface encapsulate a group of inter-related wires, along with their directions (via mod-ports) , synchronization details (via clocking block) , functions and tasks.

The major usage of interface is to simplify the connection between modules.

But Interface can’t be instantiated inside program block, class (or similar non-module entity in System Verilog).

But we needed to be driven from verification environment like class.

To solve this issue virtual interface concept was introduced in System Verilog. A virtual interface is just a pointer to a physical interface. i.e. Virtual interface is a data type (that implies it can be instantiated in a class) which hold reference to an interface (that implies the class can drive the interface using the virtual interface).

Virtual interfaces provide a mechanism for separating abstract models and test programs from the actual signals that make up the design. A virtual interface allows the same subprogram to operate on different portions of a design and to dynamically control the set of signals associated with the subprogram. Instead of referring to the actual set of signals directly, users are able to manipulate a set of virtual signals. 

interface sample_if() ;  // SystemVerilog Interface
  logic a ;
  logic b ;

  modport TB(input a, output b) ; // Modport declaration 

endinterface

class Driver ;

  virtual sample_if inf ;           // Virtual Interface declaration in class

  function new (sample_if inf)
    this.inf = inf ;
  endfunction

  task main () ;
  inf.a =a ;
endtask

endclass

Draw AND gate using XOR gates only

Hi friends….

Do any one know how to design an AND gate using XOR gate.?

This was a good question for discussion among me and my friends during graduation. At last solution was quite impressive. I thought i would be good to discuss it here also as I had found this question is interviews for freshers.

Please let us know your comments and views.

Is it really possible to design AND gate using XOR gate.?
If yes, then HOW?
If no, then WHY?

Get free daily email updates!

Follow us!

Race condition in Verilog

In Verilog certain type of assignments or expression are scheduled for execution at the same time and order of their execution is not guaranteed. This means they could be executed in any order and the order could be change from time to time. This non-determinism is called the race condition in Verilog.

Verilog execution order:

If you look at the active event queue, it has multiple types of statements and commands with equal priority, which means they all are scheduled to be executed together in any random order, which leads to many of the faces..

Lets look at some of the common race conditions that one may encounter.

1) Read-Write or Write-Read race condition.

Take the following example :

always @(posedge clk)
x = 2;

always @(posedge clk)
y = x;

Both assignments have same sensitivity ( posedge clk ), which means when clock rises, both will be scheduled to get executed at the same time. Either first ‘x’ could be assigned value ’2′ and then ‘y’ could be assigned ‘x’, in which case ‘y’ would end up with value ’2′. Or it could be other way around, ‘y’ could be assigned value of ‘x’ first, which could be something other than ’2′ and then ‘x’ is assigned value of ’2′. So depending on the order final value of ‘y’ could be different.

How can you avoid this race ? It depends on what your intention is. If you wanted to have a specific order, put both of the statements in that order within a ‘begin’…’end’ block inside a single ‘always’ block. Let’s say you wanted ‘x’ value to be updated first and then ‘y’ you can do following. Remember blocking assignments within a ‘begin’ .. ‘end’ block are executed in the order they appear.

always @(posedge clk)
begin
x = 2;
y = x;
end

2) Write-Write race condition.

always @(posedge clk)
x = 2;

always @(posedge clk)
x = 9;

Here again both blocking assignments have same sensitivity, which means they both get scheduled to be executed at the same time in ‘active event’ queue, in any order. Depending on the order you could get final value of ‘x’ to be either ’2′ or ’9′. If you wanted a specific order, you can follow the example in previous race condition.

3) Race condition arising from a ‘fork’…’join’ block.

always @(posedge clk)
fork
x = 2;
y = x;
join

Unlike ‘begin’…’end’ block where expressions are executed in the order they appear, expression within ‘fork’…’join’ block are executed in parallel. This parallelism can be the source of the race condition as shown in above example.

Both blocking assignments are scheduled to execute in parallel and depending upon the order of their execution eventual value of ‘y’ could be either ’2′ or the previous value of ‘x’, but it can not be determined beforehand.

4) Race condition because of variable initialization.

reg clk = 0

initial
clk = 1

In Verilog ‘reg’ type variable can be initialized within the declaration itself. This initialization is executed at time step zero, just like initial block and if you happen to have an initial block that does the assignment to the ‘reg’ variable, you have a race condition.

There are few other situations where race conditions could come up, for example if a function is invoked from more than one active blocks at the same time, the execution order could become non-deterministic.

SystemVerilog Interview Questions

1. What is clocking block?
2. What are modports?
3. What are interfaces?
4. What are virtual interfaces? How can it be used?
5. What is a class?
6. What is program block?
7. What is a mailbox?
8. What are semaphores?
9. Why is reactive scheduler used?
10. What are rand and randc?
11. What is the difference between keywords: rand and randc?
12. What is the use of always_ff?
13. What are static and automatic functions?
14. What is the procedure to assign elements in an array in systemverilog?
15. What are the types of arrays in systemverilog?
16. What are assertions?
17. What is the syntax for ## delay in assertion sequences?
18. What are virtual classes?
19. Why are assertions used?
20. Explain the difference between data type?s logic and reg and wire.
21. What is callback?
22. What are the ways to avoid race condition between testbench and RTL using SystemVerilog?
23. Explain event regions in systemverilog?
24. What are the types of coverages available in systemverilog?
25. How can you detect a deadlock condition in FSM?
26. What is mutex?
27. What is the significance of seed in randomization?
28. What is the difference between code coverage and functional coverage?
29. If the functional coverage is more that code coverage, what does it means?
30. How we can have #delay which is independent of time scale in system verilog?
31. What are constraints in systemverilog?
32. What are the different types of constraints in systemverilog?
33. What is an if-else constraint?
34. What is inheritance and give the basic syntax for it?
35. What is the difference between program block and module?
36. What is final block?
37. What are dynamic and associative arrays?
38. What is an abstract class?
39. What is the difference between $random and $urandom?
40. What is the use of $cast?
41. What is the difference between mailbox and queue?
42. What are bidirectional constraints?
43. What is circular dependency and how to avoid this problem?
44. What is the significance of super keyword?
45. What is the significance of this keyword?
46. What are input and output skews in clocking block?
47. What is a scoreboard?
48. Mention the purpose of dividing time slots in systemverilog?
49. What is static variable?
50. In simulation environment under what condition the simulation should end?
51. What is public declaration?
52. What is the use of local?
53. Difference b/w logic & bit.
54. How to take an asynchronous signal from clocking block?
55. What is fork-join, types and differences?
56. Difference between final and initial blocks?
57. What are the different layers in Testbench?
58. What is the use of modports?
59. What is the use of package?
60. What is the difference between bit [7:0] and byte?
61. What is chandle in systemverilog ?
62. What are the features added in systemverilog for function and task?
63. What is DPI in systemverilog?
64. What is inheritance?
65. What is polymorphism?
66. What is Encapsulation?
67. How to count number of elements in mailbox?
68. What is covergroup?
69. What are super, abstract and concrete classes?
70. Explain some coding guidelines you followed in your environment ?
71. What is Verification plan? What it contains?
72. Explain how messages are handled?
73. What is difference between define and parameter?
74. Why ?always? block not allowed inside program block?
75. How too implement clock in program block?
76. How to kill process in fork/join ?
77. Difference between Associative and dynamic arrays?
78. How to check whether randomization is successful or not?
79. What is property in SVA?
80. What advantages of Assertions?
81. What are immediate Assertions?
82. What are Assertion severity system level task? What happens if we won?t specify these tasks?
83. What is difference between Concurrent and Immediate assertions?
84. In which event region concurrent assertions will be evaluated?
85. What are the main components in Concurrent Assertions?
86. What is Consecutive Repetition Operator in SVA?
87. What is goto Replication operator in SVA?
88. What is difference between x [->4:7] and x [=4:7] in SVA?
89. What are implication operators in Assertions?
90. Can a constructor qualified as protected or local in systemverilog?
91. What are advantages of Interfaces?
92. How automatic variables are useful in Threads?

Get free daily email updates!

Follow us!