Interview Question Bank

In-line constraints are a way to specify constraints directly when randomized.

	bit [7:0] 	data;

	std::randomize(data) with { data > 7; }; 	// in-line constraint

Read more on SystemVerilog Inline Constraints.

Cross-coverage is a type of coverage measurement in SystemVerilog that combines coverage data for two or more variables or conditions. Here are some of the advantages of using cross-coverage:

• Better coverage granularity: Cross-coverage allows the user to define more specific coverage goals that combine multiple variables, instead of relying on individual coverage points. This provides better visibility into the overall behavior of the design, and helps to identify corner cases or unexpected interactions.
• Reduced verification effort: By combining coverage data for multiple variables or conditions, cross-coverage reduces the number of individual coverage points that need to be tested. This can save verification time and effort, especially for complex designs with many variables or conditions.
• Improved result analysis: Cross-coverage generates more detailed coverage reports that show the correlation between different variables or conditions. This helps the user to identify patterns or trends in the data, and to perform more targeted verification activities.

Read more on SystemVerilog Functional Coverage.

SystemVerilog constraints are used to control the values that are randomized for variables during simulation. Constraints provide a way to specify the valid range of values for a variable, as well as any relationships or conditions between variables.

	rand bit [7:0]  data;

	constraint myConstraint {
  		data inside {[0:10]};
	}

Read more on SystemVerilog Constraints.

$display format specifier can have %h or %H, and quite intuitively we assume that the latter is used to display it in uppercase. However, that is not the case and we need a workaround.

bit [31:0] y = 32'hCAFE_4BED;
string str;
 
str.hextoa(y);
$display(str.toupper);

module tb;
	bit [3:0] 	da [];
	bit [3:0] 	myq [$];

	initial begin
		repeat (10) myq.push_back($random);

		std::randomize (da) with {  da.size == 10;
									foreach (da[i]) { ! (da[i] inside {myq}); }
								 };
	end
endmodule

initial begin
	byte loop = 5;

	repeat (loop) begin
		$display("hello");
		loop -= 1;
	end
end

The repeat loop iterates a fixed number of times and the iteration count cannot be changed once in the loop. The output will be:

hello
hello
hello
hello
hello

Overriding refers to the process of providing a new implementation for an inherited method in a subclass. In other words, if a superclass defines a method, a subclass can override that method by providing its own implementation. When the subclass object calls the overridden method, the new implementation in the subclass is executed instead of the original implementation in superclass. The signature (name, return type, and parameters) of the method remains the same. The main purpose of method overriding is to implement a different behavior of the same method in a subclass.

On the other hand, overloading refers to defining multiple methods within the same class that have the same name but different parameters. This allows the same method name to be used for different operations. When the method is called, the system automatically selects the appropriate version of the method based on the parameters passed. The signature of the method is different in each overload due to the differing number or types of arguments.

Method overloading is not supported in SystemVerilog.

There are multiple types of verification approaches like simulation based verification, formal verification, emulation or FPGA prototyping.

Read more on Verification Techniques.

Here are a few key differences:

• always_comb is automatically triggered once at time zero, after all initial and always procedures have been started, whereas always @ (*) will be triggered first when any signal in the sensitivity list changes.
• always_comb is sensitive to changes of contents in a function where the latter is sensitive only to the arguments of the function when invoked inside it.
• always_comb cannot have statements that have delays or timing constructs in it.
• Variables used on the LHS inside an always_comb block cannot be assigned to in any other parallel process.

The `timescale directive is used to set the time units and precision for a design. It specifies the time scale used in the simulation and the unit of time for delays and times associated with signal assignments and other operations.

`timescale timeunit/precision

Read more on Verilog Timescale.

A basic testbench consists of the following components:

• Stimulus generation: Stimulus generation involves creating test vectors or other input signals that will be applied to the inputs of the design under test (DUT).
• Interface: The interface provides the communication between the testbench and the DUT. It includes input and output ports, which are connected to the corresponding signals in the DUT.
• Driver: The driver is responsible for converting stimulus into pin toggles appropriate to the bus protocol used by the DUT.
• Monitor: The monitor observes the output signals of the DUT and produces a stream of data that the testbench can analyze.
• Scoreboard: The scoreboard compares the output of the DUT with the expected output, and generates an error message or other notification if there is a mismatch.
• Coverage analysis: Coverage analysis measures how much of the design has been exercised during simulation, and helps identify parts of the design that may not have been tested thoroughly.

Read more on Testbench Evolution and SystemVerilog TestBench.

Circular dependency is a situation in which two or more components or entities of a system depend on each other in a circular way, creating a cycle. It can occur between modules, functions, or libraries that depend on each other in a way that creates a loop. This can lead to issues when trying to compile or link the code, as the dependencies cannot be resolved. This can be solved with forward declaration by typedef.

// Declaration beforehand that a class called B will be
// defined somewhere later in the same file
typedef class B;

class A;
	B 	b;

	... 
endclass

// For some reason an object of A is required in B causing 
// a dependency loop
class B;
	A 	a;

endclass

Read more on SystemVerilog Typedef Class.

Statements inside a program block are executed in the reactive region which is executed the last in a Verilog simulator event scheduler and hence can react on final state of design signals. It acts as an entry point for test stimulus to be executed by the testbench. It can contain functions, tasks and other supported constructs that enable user to create meaningful test stimulus.

Read more on SystemVerilog Program Blocks.

Scope randomization, invoked via std::randomize(), lets you randomize ordinary variables declared in the current scope — a module, program, or task — instead of rand properties inside a class. It's the counterpart to a class's built-in randomize() method, for use outside any class.

module tb;
	byte data;

	initial begin
		randomize(data) with { data > 0 };
		$display("data = 0x%0h", data);
	end
endmodule

Note that std:: is required if you need to call from within a class method to distinguish it from the class's built-in randomize method.

Read more on SystemVerilog Randomization.

A clocking block is a feature in SystemVerilog used to manage clock signals in a design. Input skew refers to when a signal defined as input to the clocking block should be sampled relative to the given edge of the clock. Output skew refers to when a signal declared as an output to the clocking block should be driven relative to the given edge of the clock.

clocking cb @(posedge clk);
	default input #1step output #1ns;
	input 	hready;
	output 	haddr;
endclocking

Read more on SystemVerilog Clocking Blocks.

Simulators typically comprises three simulation phases. These phases are:

1. Compilation Phase: This phase involves compiling the design and testbench files and checks the syntax, semantics, and hierarchy of the design, including all modules and interfaces.
2. Elaboration Phase: During this phase, the SystemVerilog compiler parses the design files and creates an internal representation of the design in memory. It reads the testbench code, generates object files, and links them together to create an executable file. It also includes the loading of any libraries, linking with external modules, and optimizing the executable file. Any issues found during elaboration must be resolved before simulation can proceed.
3. Simulation Phase: This is the actual running of the simulation. The simulation takes the compiled executable file and simulates the hardware design under test. The simulation initializes the testbench and DUT, applies stimulus to the DUT, and checks the expected output. The SystemVerilog simulation engine checks for timing, race conditions, and other errors and generates a log file during the simulation.

Casting is a fundamental concept in programming and refers to the process of converting one data type into another data type. In SystemVerilog, casting is mainly used for type conversion between numeric and non-numeric data types.

	real pi = 3.14;
	int  a = int'(pi) * 10; 	// Static cast: real into an integer number

	Base    b_h;
	Derived d_h = new();
	$cast(b_h, d_h); 			// Dynamic cast: assign a Derived handle to a Base handle with a run-time check

Read more on SystemVerilog Static Cast and Dynamic Cast.

This solution does not generate fully random numbers, however it does give unique values.

module tb;
	byte 	data_q [10];

	initial begin
		// Store numbers 0 through 9
		foreach (data_q [i])
			data_q[i] = i;

		// Shuffle the array
		data_q.shuffle();
	end
endmodule

Read more on SystemVerilog Array Manipulation.

An array of size 9 should contain any value from 1 to 9. Two values should be the same between indices 0 and 7.

module tb;
	bit [3:0] 	data_q [9];
	
	initial begin
		bit [2:0] idx_q [2];

		randomize(data_q, idx_q) with {
											// Let idx_q represent two random indices
											// which should contain same value
											unique { idx_q };
											solve idx_q before data_q;
	
											// When indices match, assign same value to data_q[i]
											// else follow general rule to keep between 1:9
											foreach (data_q[i]) {
												if (i == idx_q[1]) {
													data_q[i] == data_q[idx_q[0]];
												} else {
													data_q[i] inside {[1:9]};
												}
											}
										};

		$display ("idx_q  = %p", idx_q);
		$display ("data_q = %p", data_q);
	end
	
endmodule

SVA or SystemVerilog Assertions provides a syntax for expressing assertions that describe the expected behavior of a design, allowing for direct verification of its correctness.

Assertions expressed using SVA can be used to verify various types of design properties, such as proper data flow, correct timing constraints, and correct synchronization between different parts of the design. SVA can be used as a standalone language or in conjunction with other formal verification techniques such as model checking and theorem proving. It is an important tool for ensuring the correctness and reliability of digital designs in VLSI and other fields.

Read more on SystemVerilog Assertions.