Verification

Que 11: Write a code to generate a 100MHz clock.
Ans 11: To generate a 100MHz clock, which is a 10ns time period. We can write the below code.

module clk_100M ;
reg clk ;
initial begin
clk = 0;
forever #5ns clk = !clk ;
end 
endmodule

Que 12: What is a clocking block, What are the uses of a clocking block?
Ans 12: A clocking block is a set of signals synchronized on a particular clock. It basically separates the time-related details from the structural, functional, and procedural elements of a test bench. It helps the designer develop test benches in terms of transactions and cycles.

Que 13: Write a code to generate a 10MHz clock with a 60% duty cycle.
Ans 13: To generate a 10MHz clock, which is a 100ns time period. We can write the below code.

module clk_10M_60D ;
reg clk ;
initial begin
clk = 0 ;
forever begin
40ns clk = !clk ;
60ns clk = !clk ; end
end endmodule

Que 14: Write a code to generate two clocks of 10Mhz with 90o Phase shift.
Ans 14: To generate a 10MHz clock, which is a 100ns time period. To shift the 90o phase of the second clock we can delay the second clock by 100ns x 360o/ 90o.

module clk_10M_90d ;
reg clk1 , clk2 ;
initial begin
clk1 = 0 ;
forever
50ns clk1 = !clk1 ;
end
initial begin
clk2 = 0 ;
25ns ;
forever
50ns clk2 = !clk2 ;
end endmodule

Que 15: What are the steps in digital verification flow?
Ans 15: The main steps involved in digital verification are as follows:

  • Verification Plan: The verification plan involves the feature extraction from the DUT and plans test cases to verify each feature. It also specifies the coverage goals and checker’s definitions.
  • Testbench/environment creation: As per the DUT we need to create the interfaces, driver, monitor, agents, and create the environment as per requirements.
  • Writing Tests: This step involves writing sequences and tests for each feature as specified in the plan.
  • Writing checkers/assertions: in this step, we need to create a model or checkers/assertions. To check the expected behavior of the DUT and if the actual response of the DUT is matching with the expected response.
  • Coverage analysis: The goal of this step is to analyze code coverage and functional coverage and meet the 100% coverage.

Que 16: What it mean that functional coverage is 100% and code coverage is not 100%? and what can we do to meet a 100% coverage goal?
Ans 16: There might be several possibilities to have 100% functional coverage and not 100% code coverage. Functional coverage tells us what kind of stimulus, configuration, and all the combinations of possible features have been covered but code coverage tells us how much code is exercised by the test cases. So the possibilities are :
There might be a missing feature in the functional coverage plan. This can be fixed using updating features or cross features in the Verification plan.
There is some redundant/unreachable code in the design. This can be excluded from the code coverage goal.

Que 17: What It mean that code coverage is 100% and functional coverage is not 100%? and what can we do to meet a 100% coverage goal?
Ans 17: Yes, there are several possibilities to have 100% code coverage and not 100% functional coverage :
There are some features which is missing in the design implementation. We can ask the designer to implement the code.
Some of the sequence/property may not be getting cover. We can write more test cases to hit those sequences or modify those sequences if it is unreachable.

Que 18: what are the properties of object-oriented programming? Explain each property.
Ans 18: System Verilog introduces classes as the foundation of the testbench automation language.
A class is a user-defined data type. Classes consist of data (called properties) and tasks and functions to access the data (called methods).
In System Verilog, classes support the following aspects of object-orientation:
Encapsulation(Data hiding): In System Verilog, we can define how properties and methods are visible/access to the other class. By default, all the members of the class have public access. This can be changed by local and protected keyword. “Local” data/methods can only be access within the same class and “protected” data/methods can be use by the same class or extended class only.
Inheritance: Inheritance is the ability to create new classes that are based on existing classes. A derived class by default inherits the properties and methods of its parent class.
However, the derived class may add new properties and methods, or modify the inherited properties and methods.
Polymorphism: Polymorphism in System Verilog provides an ability to an object to take on many forms. Method handle of super-class can be made to refer to the subclass method, this allows polymorphism or different forms of the same method. We use the keyword “virtual”, virtual data/methods can be changed or override in the extended class.

Que 19: What is the difference between Logic and Reg?
Ans 19: Reg is a data storage element in System Verilog. It’s not an actual hardware register but it can store values. Reg retains its value until the next assignment statement. System Verilog added this additional datatype, It extends the reg/wire type so it can be driven by a single driver such as gate or module. The main difference between logic datatype and reg/wire is that a logic datatype can be driven by both continuous assignment, or blocking/non-blocking assignment.

Que 20: What are the features you will verify for a FIFO?
Ans 20: We need to verify the following features for a FIFO verification :
We need to verify if we can verify “write” and “read” of the FIFO.
We need to verify the FIFO depth by writing the number of bytes equal to the depth.
We need to verify FIFO full and FIFO empty conditions to hit corner cases.
We need to verify the reset condition of the FIFO.

<< Previous | Next >>

Verification

Que 1: What is the difference between Verilog and System Verilog?
Ans 1:
– Verilog is an HDL(Hardware Description Language) while System Verilog(SV) is both HDL and HVL(Hardware Verification Language).
– Verilog has mainly 2 data types Reg and Wire which are 4-state logic 0, 1, x, and z, while SV is enriched with a wide variety of data types like int, shortint, longint, logic, bit, real, realtime, reg, user-defined data type, etc which are both combination of 4 and 2 valued logic.
– Memories and arrays declaration on Verilog are static in nature while in the case of SV, it’s dynamic in nature means declaration can be changed during compile time.
– The whole event queue in Verilog is subdivided into 4 regions which are active, inactive, NBA, and postponed regions while in the case of SV, it is divided into 17 regions and the introduction of program block which has an inbuilt method race-free testbench and used as a separation between DUT and TB unlike Verilog.
– FSM implementation in SV is much easier in SV with the use of an enum data type that has a number of methods like number, first, last, next, and previous which helps in debugging purposes unlike using parameters in Verilog which is hard coded.
– System Verilog uses interface construct which is used for bunching of all the signals along with clocking block which is used for synchronization, unlike Verilog in which instantiation with the DUT becomes tedious because of a large number of signals.
– Verilog uses a module-level testbench while SV uses a class based testbench which is dynamic in nature.

Que 2: When we can say the verification of a DUT is completed?
Ans 2: In the beginning of the verification phase, we need to define the verification plan, which lists all the features needed to cover, functional coverage. Once all the features get verified and we achieve 100% functional coverage, Apart from these we need to achieve 100% code coverage. If we achieve all these conditions we can say verification of a DUT is completed.

Que 3: What is the difference between functional coverage and code coverage?
Ans 3: Code coverage measures how much of the “design Code” is exercised. This includes the execution of design blocks, Number of Lines, Conditions, FSM, Toggle, and Path. The simulator tool will automatically extract the code coverage from the design code. Functional coverage is a user-defined metric that measures how much of the design specification has been exercised in verification.
There are two types of functional coverage,
Data-oriented Coverage – Checks combinations of data values that have occurred. We can get Data-oriented coverage by writing Coverage groups, and coverage points and also by cross-coverage
Control-oriented Coverage – Checks whether sequences of behaviors have occurred. We can get assertion coverage by writing System Verilog Assertions.

Que 4: What is constraint random verification?
Ans 4: Constrained Random Verification (CRV) is a methodology that is supported by System Verilog which has a built-in constraint solver. This allows you to constrain your stimulus to better target a design function, thereby allowing you to reach your coverage goal faster with accuracy. From that sense, coverage and CRV go hand in hand. You check your coverage and see where the coverage holes are. You then constrain your stimulus to target those holes and improve coverage.

Que 5: What is the need for regression, what kind of tests are included in regression?
Ans 5: Regression is the method to run multiple tests together which was previously passed, It includes both random test cases and directed test cases. The regression run ensures the changes in design don’t impact the functionality. We need to keep running regression on a regular basis whenever there are design changes.

Que 6: What is the difference between “rand” and “randc” keywords?
Ans 6: “rand” is a standard System Verilog keyword for random variables. This variable randomize with different values defined in range or constraint and it is uniformly distributed over the range until defined in constraint. “randc” is a keyword for the random cyclic variable that randomly iterates over all the values in the range and no value is repeated within an iteration until every possible value has been assigned.

Que 7: What is the difference between function and task?
Ans 7: Functions: It cannot have time-controlling statements or delays, and executes in the same simulation time unit. It cannot enable a task. The function should have at least one input argument and cannot have output or inout arguments. It can return only a single value.
Task: It can have time-controlling statements or delay and completes at some other time. It can enable other tasks and functions. It can have zero or more arguments of any type. It cannot return a value but can achieve the same effect using output arguments.

Que 8: What is the virtual interface? How it is different from real interface?
Ans 8: A virtual interface is a pointer to an actual interface in System Verilog. It is most often used in classes to provide a connection point to allow classes to access the signals in the interface through the virtual interface pointer.
An interface is a bundle of signals or nets through which a testbench communicates with a design. A virtual interface is a variable that represents an interface instance.

Que 9: Why do we need a virtual interface?
Ans 9: The System Verilog interface is static in nature, whereas classes are dynamic in nature. because of this reason, it is not allowed to declare the interface within classes, but it is allowed to refer to or point to the interface. A virtual interface is a variable of an interface type that is used in classes to provide access to the interface signals.

Que 10: Can we generate the clock of 30Mhz in System Verilog? if yes, write the code to generate a 30MHz clock.
Ans 10: If we calculate the time period of 30MHz we will get 33.333ns, which is an infinite fraction, which can not be represented in the System Verilog variable. Hence, a 30MHz clock is not possible to generate in System Verilog.

<< Previous | Next >>