Intermediate SystemVerilog & UVM test (Intermediate)

Sample questions

5 sample questions from the Intermediate SystemVerilog & UVM test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. In a UVM testbench, how does the driver interact with the sequencer and the monitor during the execution of a transaction?

   1. The driver calls get_next_item() on the monitor, drives the transaction on the DUT, and calls item_done() to signal completion.
   2. The driver calls get_next_item() on the sequencer, drives the transaction on the DUT, and calls item_done() to signal completion.
   3. The monitor calls get_next_item() on the sequencer and drives the transaction on the DUT.
   4. The driver sends transactions directly to the monitor, which then drives them on the DUT.

   Answer: B. The driver calls get_next_item() on the sequencer, drives the transaction on the DUT, and calls item_done() to signal completion.

   In the UVM framework, the driver interacts with the sequencer by calling get_next_item() to receive a transaction. After driving the transaction on the DUT, the driver calls item_done() to signal that the transaction is complete. This allows the sequencer to proceed with the next transaction in the sequence. The monitor, on the other hand, samples the DUT outputs and broadcasts the transactions through an analysis port for verification purposes.

2. Which of the following statements accurately describes the build_phase in UVM and how components are created during this phase?

   1. The build_phase runs top-down, and the component is created using new()
   2. The build_phase runs bottom-up, and the component is created using type_id::create()
   3. The build_phase runs bottom-up, and the component is created using new()
   4. The build_phase runs top-down, and the component is created using type_id::create()

   Answer: D. The build_phase runs top-down, and the component is created using type_id::create()

   In UVM, the build_phase runs top-down, ensuring that parent components are created before child components. Components should be created using type_id::create() to honor factory overrides, which is essential for reusability and customization. Other options are incorrect because they either describe the wrong phase order, use incorrect methods for component creation, or misunderstand the UVM factory registration mechanism.

3. Which of the following is the best choice for managing resource allocation in SystemVerilog when multiple processes need to access a shared resource in a controlled manner?

   1. Semaphore
   2. Covergroup
   3. Mailbox
   4. Assertion

   Answer: A. Semaphore

   A semaphore is the better choice for managing resource allocation when multiple processes need to access a shared resource in a controlled manner. It provides a way to limit the number of concurrent accesses to a resource by using a counter. A mailbox, on the other hand, is used for passing data between processes and does not provide the same level of control over resource allocation. Therefore, semaphore is the correct choice for managing resource allocation.

4. What is the correct scenario that causes a blocking put operation on a bounded mailbox to occur?

   1. The mailbox is unbounded, so the put operation never blocks.
   2. The mailbox is bounded and full, so the put operation blocks until space is available.
   3. The mailbox is unbounded and full, so the put operation blocks until space is available.
   4. The mailbox is bounded and empty, so the put operation blocks until the consumer retrieves an item.

   Answer: B. The mailbox is bounded and full, so the put operation blocks until space is available.

   When a mailbox is bounded and full, the put operation will block until there is space available. This is a common use case for ensuring that producers do not overwhelm consumers in a system. The other options describe scenarios that do not directly relate to the behavior of a blocking put operation.

5. What is the reason for the assertion passing vacuously in the given SystemVerilog code snippet if the reset condition is not properly handled with 'disable iff'?

   1. The assertion fails because the property is not defined correctly.
   2. The assertion passes because the reset signal is asserted correctly.
   3. The assertion fails because the reset signal is not connected properly.
   4. The assertion passes vacuously because the reset condition is not properly handled with disable iff.

   Answer: D. The assertion passes vacuously because the reset condition is not properly handled with disable iff.

   The assertion passes vacuously because the reset condition is not properly handled with disable iff. The 'disable iff' clause is used to disable the assertion during reset, but if it is not included or incorrectly implemented, the assertion may pass vacuously when it should not. This is a common mistake when using assertions in SystemVerilog.