ASIC Point Explore

← Design Verification Interviews

Interview Question · Project Defence

Integrating a C Model into a UVM Bench

L3 SeniorL4 Staffdpiuvmreference models

The interviewer asks

Walk me through integrating an existing C reference model into a UVM bench, from the first build to sign-off.

Reveal the Model Answer

First agree the C interface with the model owners: transaction in, prediction out, a handle per instance, reset, delete and status codes. Put every import in one package behind a thin wrapper that verification owns. A predictor calls the model for each accepted input transaction and sends predictions to the scoreboard. Reset the model with the DUT, and fail on predictions left at the end. Sign off only after a known DUT bug makes the scoreboard fail.

  1. Agree the C interface

    Transaction in, prediction out. One handle per instance, with create, reset and delete. Status codes, and no exception ever crosses.

  2. Wrap it once

    A verification-owned C wrapper and one SystemVerilog package hold every import. No other file calls C directly.

  3. Predict from the input monitor

    A predictor component calls the model for each accepted transaction and sends predictions to the scoreboard.

  4. Compare in SystemVerilog

    The scoreboard compares in order or by ID, and reports through UVM, so counts and severities stay in one place.

  5. Follow the DUT's life

    Reset the model with the DUT. Drain before the last objection drops. Fail on predictions left over at the end.

  6. Show it can fail

    Run a test with a known DUT bug, and a sanitizer build of the C, before calling the integration done.

Self-Check

Tick each key point you covered in your answer.

What Interviewers Listen For (Senior)

Gives the interface contract before any UVM class names, and ends with how the check is shown to fail.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItBreak ItScale It

  1. Integrating a C Model into a UVM Bench
  2. WhyWhy All Imports Live in One PackageL3 Senior

    Why put every DPI import in one package instead of next to the code that calls it?

    Reveal the Model Answer

    The import lines are the contract with C. In one place, a reviewer checks every type, pure and context together. A model change edits one file, and the build fails at once wherever a caller disagrees. It also gives one place to swap in a stub model for unit tests.

    Self-Check

    Tick each key point you covered in your answer.

    Misconception

    "Imports in a package cannot be context imports."

    They can. But their context is the package, so callbacks to module exports need care. Keep those few context imports in the module.

    Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §12.8.5

  3. What IfAn Untimed Model Against a Timed DUTL3 Senior

    What if the C model is untimed, but the DUT has latency, backpressure and a pipeline?

    Reveal the Model Answer

    Let time stay in the bench. The model predicts once per accepted input, in zero time, and the prediction waits in the scoreboard. The comparison happens when the output monitor reports, so latency does not matter. Where the model and the DUT may legally order things differently, compare by key, not by cycle.

    Self-Check

    Tick each key point you covered in your answer.

    Wrong Altitude

    "Add delays to the C model to match the DUT's latency."

    C cannot consume simulation time, and cycle accuracy is not the model's job. The scoreboard's queue absorbs the latency.

    Source IEEE 1800-2017 §35.5.1

  4. Prove ItSign-Off for a C Model IntegrationL3 Senior

    Prove it: what evidence do you need before you call the C model integration done?

    Reveal the Model Answer

    A test with a known DUT bug must fail in the scoreboard with the right message. Prediction and response counts must match in every passing test, with nothing left at the end. A sanitizer build of the C must run clean on a subset. The model version must be printed in every log.

    Self-Check

    Tick each key point you covered in your answer.

    What Interviewers Listen For (Senior)

    Lists evidence that can be checked in the logs, not opinions.

    Misconception

    "Our regression is green, so the integration is signed off."

    A green regression also comes from a model that never sees the transactions. The evidence must include a failure you caused.

    Source Lesson D2.3 key points (show that a broken design makes the check fail)

  5. Break ItWhen the Model and the DUT Share a BugL3 SeniorL4 Staff

    Break it: the model writer and the RTL designer read the same unclear spec line the same wrong way. What catches it?

    Reveal the Model Answer

    The scoreboard does not, because model and DUT agree. Catch it with checks that someone else writes straight from the spec. Use assertions, directed tests with hand-worked values, and spec reviews of the unclear lines. Log the question to the spec owner, and fix both sides.

    Self-Check

    Tick each key point you covered in your answer.

    What Interviewers Listen For (Staff)

    Names model independence as a sign-off risk and plans independent checks for the unclear parts of the spec.

    Buzzword Without Mechanism

    "A golden model cannot be wrong."

    It is code written from the same document. Independence comes from who wrote it and from what, not from its name.

  6. Scale ItIntegrating an Architecture Model at Subsystem LevelL3 Senior

    Asked if they mention a subsystem model

    The architecture team owns a C++ model of the whole subsystem. How do you use it as the scoreboard's reference without forking it?

    Reveal the Model Answer

    Wrap it behind a thin, versioned DPI layer owned by verification: transaction in, predicted transactions out, one handle per instance, plus reset. Feed it from monitors, never drivers, so it predicts from what the DUT actually received. Agree on where the model is untimed, such as ordering between independent streams, and compare there by key rather than by cycle.

    Self-Check

    Tick each key point you covered in your answer.

    What Interviewers Listen For (Senior)

    A good senior answer separates the shared model from the wrapper that verification owns. It says exactly where the comparison must allow differences in order.

    Wrong Altitude

    Copies the model into the verification repository and patches it to match the RTL.

    The model then stops being independent: it quietly learns the RTL's bugs, and the architecture fixes never arrive.

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Missed Corner

"No mismatches means the test passed."

Predictions that never meet a response are failures too. The twin's DUT loses two items, and the test still says passed.

Run It

Six accepted items, four delivered. The scoreboard checks only what arrives.

RUNVerilator + C/C++ over DPI · simulator service
Edit the code, then run it

        
Expected: matched=4 errors=0 left=2 TEST PASSED FAIL: two predictions were never matched, and the test still passed

        
        
        
      

      
See the Fix
module tb;
  import "DPI-C" function chandle model_new();
  import "DPI-C" function int model_predict(input chandle h, input int data);
  import "DPI-C" function void model_delete(input chandle h);
  class scoreboard;
    chandle model;
    int exp_q[$];
    int errors = 0, matched = 0;
    function new(); model = model_new(); endfunction
    function void write_in(int d); exp_q.push_back(model_predict(model, d)); endfunction
    function void write_out(int d);
      int e = exp_q.pop_front();
      if (d != e) errors++; else matched++;
    endfunction
    function void check_end();        // the end-of-test check
      errors += exp_q.size();       // the fix: a prediction never matched is a failure
      model_delete(model);
      model = null;
    endfunction
  endclass
  scoreboard sb = new;
  initial begin
    for (int i = 0; i < 6; i++) sb.write_in(i);         // the DUT accepted six items
    for (int i = 0; i < 4; i++) sb.write_out(i * 2);    // but delivered only four
    sb.check_end();
    $display("matched=%0d errors=%0d left=%0d", sb.matched, sb.errors, sb.exp_q.size());
    if (sb.errors == 0) $display("TEST PASSED"); else $display("TEST FAILED");
    if (sb.errors == 0 && sb.exp_q.size() != 0) $display("FAIL: two predictions were never matched, and the test still passed");
    else $display("PASS: the two leftover predictions failed the test");
    $finish;
  end
endmodule

Prints: matched=4 errors=2 left=2 TEST FAILED PASS: the two leftover predictions failed the test

    

  

    
Wrong Altitude

    
"Each component imports the C functions it needs."

    
Then the C interface is spread over many files. A model change means hunting every call site, and nobody owns the boundary.

  

    
Half-Truth

    
"Always take the model team's latest version."

    
A silent model change can turn a pass into a fail, or worse, the reverse. Pin a version, log it at start of test, and update on purpose.

  

    
Delivery

    
Lists uvm_subscriber, uvm_tlm_analysis_fifo and the factory, but never says what is compared or how it is signed off.

    
Class names are not a design. The interviewer wants the contract, the data flow, the end-of-test rule and the evidence.

  

    
Learn It, Then Prove It