Skip to practice questions

Part 2 · Scheduler and DPI

Program scheduling and foreign-language boundaries

Place testbench execution in the correct event region and cross the DPI boundary without losing type, lifetime, or ownership guarantees.

Reading path
2 of 3
Concept chapters
2
Practice links
8

Question-first preparation

Practice the mechanisms on this page.

Each question maps directly to one of the chapters below, so you can test the contract before reading the explanation.

Recommended start

One representative prompt from each major mechanism. Open any card in the live question bank.

  1. Q001Blocking and nonblocking assignmentSystemVerilog · EasyPractice
  2. Q934Procedural delaysSystemVerilog · EasyPremium
  3. Q1092Nonblocking assignment (NBA) evaluation and updateSystemVerilog · EasyPremium
  4. Q403Inactive, nonblocking assignment (NBA), and postponed regionsSystemVerilog · HardPremium
  5. Q409Delayed nonblocking assignmentsSystemVerilog · HardPremium
  6. Q943Choose Blocking and Nonblocking Assignments by Process TypeComputer Architecture · EasyPremium
Complete question directoryFilter every stable practice link by mechanism.8 questions

03 · Program, clocking, and scheduler regions

Race freedom comes from explicit sampling and driving contracts.

Program blocks and clocking blocks were designed to separate testbench activity from RTL updates. Modern environments still need to understand the event regions even when they use interfaces, classes, and UVM instead.

Rule to say firstSample and drive through a clocking-block contract or an equivalent explicit discipline; do not treat program as a universal race-elimination switch.

One simulation time slot

Observe first, update deliberately

RTL
evaluate#0NBA commitstable
always_ff evaluates before its nonblocking update.
Assertion
sampleevaluate
Testbench
clocking samplereact / drive by skew
  1. 01Preponedsample

    Concurrent assertions capture values before current-slot design updates.

  2. 02Active / Inactiveblocking / #0

    Design evaluation and zero-delay rescheduling; order within a region can race.

  3. 03NBAcommit

    Deferred nonblocking LHS updates apply.

  4. 04Observed / Reactivecheck / react

    Assertions evaluate and program/testbench reactions can follow stabilized design state.

Preponedsample

Concurrent assertions capture values before current-slot design updates.

#0
Inactive
It runs before NBA and is not a substitute for nonblocking assignment.
Program
Reactive domain
Useful historical construct, but uncommon in current UVM architectures.
Completion
Explicit
A program does not automatically solve end-of-test coordination.

Source order is not a synchronization primitive. The event region and edge-relative skew are the actual temporal contract.

01

Observe

Trace each read and write through Preponed, Active, Inactive, NBA, Observed, Reactive, and postponed behavior at the same simulation time.

02

Decide

Put RTL in design regions, assertions in their sampling/reactive flow, and testbench access behind a clocking or synchronization boundary.

03

Failure

Two blocks that read and write the same signal in the Active region can race even when source order looks deterministic.

04

Prove

Use sampled-value functions, scheduler-aware assertions, randomized compilation order, and tests that drive exactly on a clock edge.

Program blocks are one tool, not a magic partition

A program executes testbench activity in Reactive regions after design and assertion work for the slot. It restricts some design constructs and was intended to reduce DUT/testbench races. Modern UVM usually uses modules, interfaces, clocking blocks, and explicit objections instead.

  • A program may instantiate classes and call tasks, but should not be used to model synthesizable hardware.
  • Reactive scheduling does not fix two testbench threads racing with each other.
  • End-of-simulation still needs an explicit completion protocol.
  • Use one disciplined interface boundary rather than mixing direct signal access and clocking-block access.

Clocking blocks define sampling and drive skew

A clocking block names a clocking event and direction for each signal. Input skew chooses when values are sampled relative to the event; output skew chooses when drives occur. Assignments to clocking outputs follow clocking-drive semantics, so a universal rule such as “always use =” is incomplete.

Edge-relative testbench accesssystemverilog
interface bus_if(input logic clk);
  logic valid, ready;
  logic [31:0] data;

  clocking drv_cb @(posedge clk);
    default input #1step output #0;
    input  ready;
    output valid, data;
  endclocking

  clocking mon_cb @(posedge clk);
    default input #1step;
    input valid, ready, data;
  endclocking
endinterface

Explain it out loud

Interview reasoning checkpoints

Strong answer

No. They schedule program activity in Reactive regions relative to design activity, but they do not resolve races among testbench threads or replace a clear clocking, ownership, and completion protocol.

Reason it through
  1. Identify which competing operations live in which regions.
  2. Separate DUT-versus-testbench races from testbench-versus-testbench races.
  3. Use clocking blocks and explicit synchronization for the remaining boundaries.
Interviewer lens

A nuanced answer acknowledges the feature without presenting it as the modern UVM default.

Common trap

Claiming program automatically makes any testbench deterministic.

Strong answer

It defines a named edge-relative sampling and driving contract, including input and output skew, so monitors and drivers do not depend on same-region execution order.

Reason it through
  1. Choose the clocking event.
  2. Set input sampling before or at the edge as the protocol requires.
  3. Set output drive timing and access signals only through that contract.
Interviewer lens

Look for sampling versus driving skew and the reason it removes ambiguity.

Common trap

Treating a clocking block as only a namespace for interface signals.

04 · DPI

Treat the language boundary as an ABI, ownership, and state-domain contract.

DPI makes C calls convenient, not free. Direction, type mapping, open-array representation, scope, reentrancy, and context all affect correctness and performance.

Rule to say firstKeep DPI adapters narrow, copy or pin data according to documented lifetime, and preserve four-state information when the C side must observe X or Z.

Foreign-function boundary

SystemVerilog value → adapter → C ABI

  1. 01SV declarationtyped import/export

    Direction and state domain start the contract.

  2. 02DPI adapteropen-array / vector API

    Simulator-defined handles preserve shape and four-state bits.

  3. 03C implementationowned storage

    Copy if data must survive beyond the call.

  4. 04Validationround trip

    Compare size, order, values, and error behavior.

SV declarationtyped import/export

Direction and state domain start the contract.

pure
No side effects
Enables optimization only when the promise is true.
context
Simulator scope
Needed for calls that use context-dependent simulator services.
Cost
Non-zero
Marshalling and call frequency matter; batch where appropriate.

One explicit adapter is easier to validate than many call sites that each guess at C and SystemVerilog representation.

01

Observe

List every imported or exported symbol, data direction, state domain, array shape, callback, simulator-service call, and ownership transition.

02

Decide

Use pure for side-effect-free calls, context only when simulator context is required, and open-array APIs for portable array access.

03

Failure

Assuming native struct layout or retaining a temporary simulator pointer can corrupt data even when the call signature compiles.

04

Prove

Round-trip boundary values, X/Z vectors, empty arrays, callbacks, and repeated calls; profile large transfers rather than assuming zero overhead.

Map semantics, not only syntax

Simple 2-state scalars often map naturally to C integer types. Four-state packed vectors require separate value and unknown masks. Open arrays should be accessed with the DPI API because range direction and representation are simulator-managed.

DPI review checklist
BoundaryQuestionProof
2-state scalarWidth and signedness?Min/max and negative tests
4-state vectorAre aval and bval preserved?0/1/X/Z round trip
Open arrayShape and direction?Every dimension and empty case
StringEncoding and lifetime?Copy and termination checks
chandleWho owns the object?Create/use/free lifecycle
CallbackDoes it need context?Scope and reentrancy test

Batch work at the boundary

A DPI call crosses runtimes and may marshal data. Small calls in a hot per-cycle loop can dominate model time. Move stable policy into C only when it improves clarity or performance, pass larger batches, and keep cycle-accurate synchronization on the SystemVerilog side.

State-domain-aware declarationssystemverilog
import "DPI-C" pure function int crc32_2state(
  input byte unsigned data[]
);

import "DPI-C" context task inspect_4state(
  input logic [127:0] value,
  output int unknown_bits
);

export "DPI-C" task report_error;

Explain it out loud

Interview reasoning checkpoints

Strong answer

A four-state packed value crosses with separate value and unknown-state representation, commonly aval and bval words. Mapping it to a plain C integer would lose X/Z.

Reason it through
  1. Classify the SystemVerilog source as 2-state or 4-state.
  2. Use the DPI vector representation appropriate to that domain.
  3. Round-trip all four logic values.
Interviewer lens

The answer should identify information loss and a validation strategy.

Common trap

Casting a logic vector pointer to uint32_t and assuming portable layout.

Strong answer

No. It is lightweight compared with many alternatives, but call transitions, marshalling, context, and array handling still cost time. Measure and batch hot-path work.

Reason it through
  1. Estimate call frequency and transferred bytes.
  2. Separate pure computation from cycle synchronization.
  3. Profile before moving more logic across the boundary.
Interviewer lens

A practical answer balances interoperability with performance and ownership.

Common trap

Assuming convenience syntax means no runtime or copying cost.