A Packet Passed as a String

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

WhyWhat IfBreak ItCompare

1. A Packet Passed as a String
2. WhyWhy a String Has No Zero ByteL1 Junior

   Why can a SystemVerilog string not hold a zero byte?

   Reveal the Model Answer

   The standard says so: a string never contains the 0 character, and writing 0 into one character is ignored. That keeps it compatible with C strings, which end at the first zero.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 The standard says so: a string never contains the 0 character, and writing 0 into one character is ignored. Key point 2 That keeps it compatible with C strings, which end at the first zero.

   Misconception

   "s[1] = 8'h00; cuts the string short at index 1."

   The write is ignored instead. Our probe kept "AB" with length 2.

   Source ASIC Point engine notes (Verilator 5.052 DPI probe, 2026-11-08: s = "AB"; s[1] = 8'h00 left s as AB, length 2)

   • Lesson D1.5Strings Cross as Borrowed Pointers
3. Break ItA C Model That Kept a String PointerL2 Mid-Level

   A C model stores the const char* it receives for a test name and prints it at the end of the test. Sometimes it prints garbage. Why?

   Reveal the Model Answer

   A string argument reaches C as a pointer to memory the simulator owns, valid only while the call runs. After the call returns, the simulator may reuse or free that memory, so the stored pointer can point at anything. Copy the text into storage the C side owns during the call.

   1. Pass

      The testbench calls protocol_code(cfg). C gets a pointer to the bytes A X I and a terminating zero, nothing more.

      Follow the calls, values and waits

      1. data AXI: string cfg → const char* name
   2. Read during the call

      strcmp reads the bytes and the function returns 2. The pointer has done its job.

      Follow the calls, values and waits

      1. data AXI: const char* name → protocol_code
      2. return 2: protocol_code → const char* name
   3. Copy what you must keep

      remember_name copies the bytes into kept, storage the model owns. After this the model never touches name again.

      Follow the calls, values and waits

      1. data AXI: const char* name → kept[32]
   4. The call returns

      The testbench assigns a new value to cfg. A kept name pointer would now read whatever the simulator put there; kept still says AXI.

   Read the diagram as text

   • string cfg: "AXI" in the simulator's own buffer
   • const char* name: points at that buffer while the call lasts
   • protocol_code: strcmp during the call, returns 2
   • kept[32]: remember_name copies the bytes; the model keeps this
   • cfg = "changed…": after the call the simulator reuses its buffer

   • string cfg → const char* name: passes
   • const char* name → protocol_code: read now
   • const char* name → kept[32]: copied now
   • cfg = "changed…" → const char* name: stale pointer

   Borrow during the call, copy to keep. A pointer that outlives the call points at memory the simulator may have changed, moved or freed.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A string argument reaches C as a pointer to memory the simulator owns, valid only while the call runs. Key point 2 After the call returns, the simulator may reuse or free that memory, so the stored pointer can point at anything. Key point 3 Copy the text into storage the C side owns during the call.

   Misconception

   "The string lives as long as the SystemVerilog variable does."

   The pointer refers to the simulator's copy for that call, not to the variable, so a later change or reuse invalidates it.

   Source IEEE 1800-2017 Annex H.7.2 (argument passing: ownership of string storage)

   • Lesson D1.5Strings Cross as Borrowed Pointers
4. What IfCopying an Object That Holds a ChandleL2 Mid-Level

   Asked if the C object sits in a transaction class

   What if a model class holds a chandle, and someone copies the object with new this or a copy() method?

   Reveal the Model Answer

   The copy gets the same address, so both objects drive one C model. An update through either is seen by both. If the copy needs its own state, call a C clone function that allocates a new struct. Then decide which object deletes which model.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 The copy gets the same address, so both objects drive one C model. Key point 2 An update through either is seen by both. Key point 3 If the copy needs its own state, call a C clone function that allocates a new struct. Key point 4 Then decide which object deletes which model.

   Misconception

   "The copied object now has its own C model."

   A shallow copy copies field values, and a chandle's value is an address. The twin adds 100 through the copy and the original shows 105.

   Run It

   A model object with a C accumulator, copied after adding 5.

   RUNVerilator + C/C++ over DPI · simulator service

   Edit the code, then run it

   OutputWaves

   RunReset codeExpected: a=105 b=105 FAIL: the copy shares one C model, because copying a chandle copies only the address

   See the Fix

   module tb;
     import "DPI-C" function chandle acc_new();
     import "DPI-C" function chandle acc_clone(input chandle h);
     import "DPI-C" function int acc_add(input chandle h, input int v);
     class model;
       chandle h;
       function new(); h = acc_new(); endfunction
       function model copy();
         model c = new this;              // a shallow copy of every field
         c.h = acc_clone(h);              // the fix: the copy gets its own C state
         return c;
       endfunction
     endclass
     model a = new, b;
     initial begin
       void'(acc_add(a.h, 5));
       b = a.copy();
       void'(acc_add(b.h, 100));
       $display("a=%0d b=%0d", acc_add(a.h, 0), acc_add(b.h, 0));
       if (acc_add(a.h, 0) != 5) $display("FAIL: the copy shares one C model, because copying a chandle copies only the address");
       else $display("PASS: each object owns its own C state");
       $finish;
     end
   endmodule
   

   Prints: a=5 b=105 PASS: each object owns its own C state

   • Lesson D1.6A Model with State Behind a Handle
5. CompareWhy a Chandle and Not an IntegerL2 Mid-Level

   Why store the C pointer in a chandle rather than in a longint?

   Reveal the Model Answer

   A chandle always has the size of a pointer on the machine that runs the simulation. The language only lets you assign it, compare it with null and pass it to C. That stops SystemVerilog code from doing arithmetic on it or inventing values. A longint would work by accident on a 64-bit host and offer none of those guarantees.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A chandle always has the size of a pointer on the machine that runs the simulation. Key point 2 The language only lets you assign it, compare it with null and pass it to C. Key point 3 That stops SystemVerilog code from doing arithmetic on it or inventing values. Key point 4 A longint would work by accident on a 64-bit host and offer none of those guarantees.

   Misconception

   "You can read the struct fields through the chandle in SystemVerilog."

   It is opaque: only C code can dereference it, through accessor functions you import.

   Source IEEE 1800-2017 §6.14

   • Lesson D1.6A Model with State Behind a Handle