Choosing a Reference Model

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

What IfProve ItBreak ItCompareScale It

1. Choosing a Reference Model
2. CompareComparing an Untimed Model with Timed RTLL3 Senior

   An untimed model produces results at once, but the DUT takes many cycles. How do you compare them?

   Reveal the Model Answer

   Compare at sync points that both sides define: the end of a transaction, a frame or an interrupt. The model pushes its expected result into a queue as soon as it sees the input. The scoreboard compares when the DUT's output for that point appears. Nothing between sync points is compared.

   1. 15 ns

      The data beat 10 is answered in mode 0 at once: 11 waits in the queue.

      Follow the calls, values and waits

      1. call step(10): Data beat taken → alu_model
      2. data prediction 11: alu_model → expected[$]
   2. 25 ns

      The beat 20 is answered the same way: 21 joins 11 in the queue.

      Follow the calls, values and waits

      1. call step(20): Data beat taken → alu_model
      2. data prediction 21: alu_model → expected[$]
   3. 35 ns

      The mode beat reaches the model at the same event the design acts on. Earlier answers are already queued.

      Follow the calls, values and waits

      1. call set_mode(1): Mode beat taken → alu_model
   4. 45 ns

      The result for 10 pops 11, which was computed in mode 0. With late = 1 the model would be asked now, in mode 1, and say 20.

      Follow the calls, values and waits

      1. data observed y=11: Result seen → write_out
      2. data prediction 11: expected[$] → write_out

   Read the diagram as text

   • Data beat taken: 10 at 15 ns, 20 at 25 ns
   • Mode beat taken: mode 1 at 35 ns
   • alu_model: step(x) or set_mode(m), no time
   • expected[$]: 11, 21 waiting
   • Result seen: 11 at 45 ns
   • write_out: Pop the oldest, compare

   • Data beat taken → alu_model: step(x)
   • Mode beat taken → alu_model: set_mode
   • alu_model → expected[$]: push
   • Result seen → write_out: write
   • expected[$] → write_out: pop

   Data and mode reach the model in the order the design took them; the queue carries answers across the 30 ns latency.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Compare at sync points that both sides define: the end of a transaction, a frame or an interrupt. Key point 2 The model pushes its expected result into a queue as soon as it sees the input. Key point 3 The scoreboard compares when the DUT's output for that point appears. Key point 4 Nothing between sync points is compared.

   • Lesson U9.2An Untimed Model and the Sync Point
3. Break ItA Sync Point That Hides a BugL3 Senior

   How does a badly chosen sync point hide a bug?

   Reveal the Model Answer

   Say you compare only at the end of a frame. A wrong value in the middle, later overwritten by the DUT, is never seen. Choose sync points where the value is visible to software or to the next block. Add assertions for the rules between them.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Say you compare only at the end of a frame. Key point 2 A wrong value in the middle, later overwritten by the DUT, is never seen. Key point 3 Choose sync points where the value is visible to software or to the next block. Key point 4 Add assertions for the rules between them.

   • Lesson U9.2An Untimed Model and the Sync Point
   • Lesson A2.1Delays and Ranges: One Attempt, Many Threads
4. Prove ItSolve U9.3.1: Three Channels and a Model That DisagreesSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem U9.3.1

5. What IfWhat Breaks at the DPI BoundaryL3 Senior

   Asked if they choose a C model

   What breaks most often at the DPI boundary of a C reference model?

   Reveal the Model Answer

   Type mapping and memory ownership. A 4-state value passed to an int argument loses its X and Z bits. A C function that keeps a pointer to SystemVerilog data after the call may read freed memory. Keep the interface to simple 2-state types or packed arrays, and copy data during the call.

   1. SystemVerilog side65 ns (illustrative)

      The scoreboard calls the wrapper exactly as it called the SV model.

      Follow the calls, values and waits

      1. data op_item x = 200 (c8): Input monitor → write_in
      2. call model.step(200): write_in → SV wrapper
   2. The boundary65 ns (illustrative)

      input byte is signed: c8 crosses as -56. The call takes no simulation time.

      Follow the calls, values and waits

      1. call alu_model_step(h, 8'hc8): SV wrapper → input byte
      2. call step(h, x = -56): input byte → model.c
   3. Back again65 ns (illustrative)

      C halves -56 to -28 and returns it as the unsigned value 228. The wrapper narrows it to e4, and the scoreboard queues that prediction.

      Follow the calls, values and waits

      1. return returns 228, queued as e4: model.c → expected[$]
      2. Waiting: expected[$] — e4 waits for the result
   4. The result appears95 ns (illustrative)

      The design's 100 meets the queued e4: a mismatch, although each model is right about its own input.

      Follow the calls, values and waits

      1. data expected e4: expected[$] → write_out
      2. Released: expected[$]

   Read the diagram as text

   • Input monitor: op_item x = 200 (c8)
   • write_in: model.step(t.x)
   • SV wrapper: alu_model_step(h, x)
   • input byte: c8 arrives as char -56
   • model.c: mode 2: -56 >> 1 = -28
   • expected[$]: int 228 narrowed to e4
   • write_out: design y = 100: mismatch

   • Input monitor → write_in: write
   • write_in → SV wrapper: call
   • SV wrapper → input byte: import call
   • input byte → model.c: C call
   • model.c → expected[$]: return
   • expected[$] → write_out: pop, 30 ns later

   Both models are right about their own inputs; the hand-off type is wrong.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Type mapping and memory ownership. Key point 2 A 4-state value passed to an int argument loses its X and Z bits. Key point 3 A C function that keeps a pointer to SystemVerilog data after the call may read freed memory. Key point 4 Keep the interface to simple 2-state types or packed arrays, and copy data during the call.

   Misconception

   "The C model can keep a pointer to the SystemVerilog array for the next call."

   Pointers to argument data are valid only during the call. The simulator may move or reuse that memory afterwards.

   Source IEEE 1800-2017 Annex H, C layer rules for pointers to actual arguments

   • Lesson U9.3A C Reference Model Behind DPI
   • Lesson D1.1Your First DPI-C Call
6. Scale ItOne Reference Model from Block to ChipL3 SeniorL4 Staff

   Scale it: how do you reuse the same model from block level up to the full chip?

   Reveal the Model Answer

   Keep the model behind a transaction interface with no pins and no clocks. At block level, the block's monitors feed it. At chip level, the same model listens to monitors on the chip boundary or to an internal passive agent. Only the connections change, so the model's own bugs are found once.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Keep the model behind a transaction interface with no pins and no clocks. Key point 2 At block level, the block's monitors feed it. Key point 3 At chip level, the same model listens to monitors on the chip boundary or to an internal passive agent. Key point 4 Only the connections change, so the model's own bugs are found once.

   What Interviewers Listen For (Staff)

   A good staff answer defines the model's transaction interface before the block bench exists. Then reusing the model at chip level costs only wiring.

   • Lesson U9.5Virtual Platforms and Refine-and-Reuse
   • Lesson U12.2Vertical Reuse: A Block Environment Inside a Subsystem