Interview Question Bank

Verification is typically considered complete when all the specified verification goals and requirements have been met and demonstrated through testing and analysis of the design. This means that all of the verification tests have been run and that the design has passed all of the necessary functional and performance requirements. Verification is a continuous process that starts early in the design cycle and continues until the final stages of the design and development process. Throughout this process, different verification techniques and methodologies are used to ensure that the design is free from errors.

Verification completeness is typically determined using a set of predefined metrics and criteria that are used to evaluate the overall quality and reliability of the design. Such metrics may include functional coverage, code coverage, and timing analysis. Ultimately, the decision to declare verification complete is based on the verification team's confidence in the design's functionality and reliability to be used in the intended application and environment.

Read more on Verification Plan.

System tasks are pre-defined functions or built-in functions in SystemVerilog that are used to execute certain tasks related to the simulation and verification of a design. Some common system tasks in SystemVerilog include:

• $display: Used to display formatted output to the console or log file.
• $time: Used to retrieve the current simulation time.
• $finish: Used to end the simulation after a specific amount of time or when a specific condition is met.
• $random: Used to generate random values for variables or signals.

The preferred array type for memory declaration is an associative array because it is more efficient in storing data at random address locations. It does not require all addresses in memory to be pre-allocated before usage unlike a dynamic array.

Read more on SystemVerilog Associative Array.

In SystemVerilog, seed is used as a starting point or initial value for the random number generator. The advantage of using the seed in randomization is that it allows for a more deterministic and reproducible behavior of the randomized simulation.

By setting a seed, a specific set of randomized values can be generated consistently, making it easier to replicate specific test scenarios and debug issues that arise during simulation. It also allows for better verification of the design as specific tests can be rerun with the same seed to ensure that issues have been resolved and that the behavior of the design is as expected.

Yes, assertions using assert and assume are used to check the correctness of the design, and they can be written in any of the SystemVerilog constructs including modules, interfaces, programs or classes.

In SystemVerilog, assertions can be written using the assert and assume keywords. These keywords can be used directly inside a SystemVerilog class, with the assertion check being triggered when the appropriate method of the class is called.

Read more on SystemVerilog Immediate Assertions and Concurrent Assertions.

A clocking block is a SystemVerilog construct that provides a way to model clock-related events that occur in a design. It is specifically used to define the timing and synchronization of signals that are driven by a clock. The clocking block can be used to drive and sample signals using the clock signal, with the signals being synchronized at specific edges of the clock.

Read more on SystemVerilog Clocking Blocks.

An abstract class is a class in object-oriented programming that cannot be instantiated, meaning it cannot be used to create objects. Instead, it is used as a superclass to other classes, providing a common set of properties and methods that subclasses can inherit and implement as necessary.

Read more on SystemVerilog Abstract Class.

Covergroups and coverpoint weight can be disabled by setting its weight to zero.

covergroup cg_ahb @ (posedge hclk);
	cp_haddr  : coverpoint haddr;
	cp_htrans : coverpoint htrans;
	...
endgroup

cg_ahb m_cg_ahb = new();
m_cg_ahb.cp_htrans.option.weight = 0;  // disable coverpoint by setting weight to 0

The super keyword in SystemVerilog or even any OOP language refers to the superclass of a class. It is used to access methods and variables of the superclass from within a subclass.

Read more examples in SystemVerilog super Keyword.

Block-level verification checks one IP in isolation, with a testbench that drives its interfaces directly and checks it against its specification in depth. SoC verification assumes the blocks are already verified and focuses on how they work together: the interconnect and address map, connectivity between blocks, interrupts, clocks and resets, power modes, shared memory and the interaction with software running on the processors.

Because the full chip is large and slow to simulate, SoC tests are more scenario-based and less exhaustive. Bugs found at SoC level are usually integration bugs, such as wrong connections, wrong address decoding or wrong reset sequencing, rather than bugs inside a block.

Read more on Introduction to SoC Verification.

• The DUT is the full chip or a subsystem, often with the real processor model running test software.
• External interfaces are driven by verification IPs (UVCs) and memory models, for example DDR, PCIe, USB and serial ports.
• Block-level monitors and scoreboards are reused in passive mode on internal interfaces.
• A register model mirrors the SoC address map, and a top-level environment and virtual sequencer coordinate everything.
• A test layer combines C code running on the processor with SystemVerilog sequences driving the external VIPs.

Read more on SoC Testbench Structure.

In a real chip the processor configures and controls the other blocks through software. Running C tests on the processor model inside the simulation exercises the real paths: instruction fetch through the interconnect, register accesses with real bus timing, interrupt handling and software sequences similar to the drivers that will run on silicon.

C tests can also be reused later on emulation, FPGA prototypes and silicon, which a UVM sequence cannot. Their weaknesses are less randomization and harder debug, so most SoC environments combine C tests with SystemVerilog stimulus.

Read more on Directed vs Self-Checking C Tests.

1. Cross-compile the C code with the processor's toolchain, together with startup code that sets up the stack and jumps to main.
2. Link it with a linker script that places code and data at the addresses of the SoC's boot memory and RAM.
3. Convert the resulting ELF file into a memory image (for example a hex file).
4. Load the image into the memory model at time zero, usually with $readmemh or a backdoor write.
5. Release reset, so the processor fetches from its reset vector and runs the test.

Read more on Getting a C Test Running in the DUT and Linker Scripts and Memory Maps.

They communicate through shared memory or dedicated registers that both sides can access. The C test writes a value to a mailbox address, for example "configuration done" or a test ID, and the testbench watches that address with a monitor or backdoor peek and starts the matching sequence on an external VIP. The testbench can answer the same way, by writing a flag that the C code polls.

// Testbench side: wait for the C code to signal it is ready
wait (mem.read_word(MAILBOX_ADDR) == 32'h0000_0001);
uart_seq.start(env.uart_agent.sequencer);

The same mechanism reports the final pass or fail status, so the simulation ends with a clear result.

Read more on Co-ordinating C Tests with SystemVerilog Sequences.

Interfaces that are internal at SoC level are no longer driven by the testbench, so the block-level agents on them are switched to passive mode. Their monitors still observe the traffic, and the block-level scoreboards and assertions keep checking the block in its real surroundings.

Agents on interfaces that are still external to the chip stay active. This reuse only works if the block environments were built to be configurable, for example with active and passive settings, configurable addresses and no hard-coded hierarchy paths.

Read more on Importing VIPs in SoC Testbench and Testbench Configurability.

The SoC register model is built by instantiating each block's register model at its base address in a top-level address map. The same register can then be accessed by name, while the model works out the full address.

Accesses can go front door through the real bus, either from a bus VIP or from the processor, or back door directly into the RTL for fast setup and checking. The model also mirrors expected values, which allows checking register state at the end of a test.

Read more on Register Model at SoC Scale.

• Access the first and last address of every region from every master that is allowed to reach it, and check the right target responds.
• Access holes in the map and check the interconnect returns a decode error instead of hanging or aliasing.
• Check that masters without permission to a region are blocked, for secure or protected regions.
• Check aliasing and remapping, for example a boot ROM mapped at address zero before remap.

Most of this is generated from the address map specification, so that a change in the map automatically updates the tests.

Read more on Address Map and Decode Verification.

Connectivity verification checks that signals are wired correctly between blocks: interrupt lines to the interrupt controller, DMA request lines, pin multiplexing, clock and reset connections and debug signals. A wrong connection inside a correct block passes every block-level test.

It is often done with formal connectivity checks generated from a spreadsheet or specification of expected connections, which prove each connection exhaustively, combined with simulation tests for the important paths.

Read more on Connectivity Verification.

For each interrupt source, a test makes the block raise its interrupt, checks that it reaches the interrupt controller on the correct line, that the processor takes the right handler, and that clearing the source clears the interrupt. Masking, priority, edge versus level behaviour and interrupts during low-power states are checked as well.

Interrupts are a cross-block concern because they involve the source block, the wiring, the interrupt controller, the processor and the software handler, so a bug can be in any of them.

Read more on Interrupt Verification as a Cross-Block Concern.

Coherency tests make several cores, and other masters such as DMA, read and write the same addresses so that cache lines move between states and between caches. Tests use small address ranges to create many conflicts, and include false sharing, where different data shares one cache line.

Checking uses a memory scoreboard that tracks the expected latest value of each address, protocol assertions on the coherent interconnect, and self-checking software patterns such as locks and producer-consumer queues. Coverage of cache line state transitions shows which scenarios were reached.

Read more on Cache Coherency Verification.