Static Members of a Parameterized Class

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

WhyWhat IfProve ItCompareScale It

1. Static Members of a Parameterized Class
2. WhyWhy Each Specialization Is Its Own ClassL2 Mid-Level

   Why doesn't the language share statics across all specializations of a parameterized class?

   Reveal the Model Answer

   A type parameter can change the type and size of members, including statics declared with T. So box#(int) and box#(string) may not even have compatible statics. The language therefore treats every specialization as a separate class, generated from one template, and the statics follow.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A type parameter can change the type and size of members, including statics declared with T. Key point 2 So box#(int) and box#(string) may not even have compatible statics. Key point 3 The language therefore treats every specialization as a separate class, generated from one template, and the statics follow.

   Tool as Truth

   "It is a simulator optimisation and tools differ."

   The rule is in the standard: a specialization is a distinct type with its own static members.

   Source IEEE 1800-2017 §8.25

   • Lesson 4.6Parameterized Classes and Static Members
3. What IfOne Counter for Every SpecializationL2 Mid-Level

   What if you want one counter shared by every specialization, such as a global transaction ID?

   Reveal the Model Answer

   Put the static in a base class without parameters, and derive the parameterized class from it. Derived classes share the static properties of their base class. So every specialization then updates the same counter. Reach it through the base class name, such as item_base::next_id.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Put the static in a base class without parameters, and derive the parameterized class from it. Key point 2 Derived classes share the static properties of their base class. Key point 3 So every specialization then updates the same counter. Key point 4 Reach it through the base class name, such as item_base::next_id.

   Misconception

   "Declare it static in the parameterized class; static means one copy."

   Each specialization is its own class with its own statics. box#(int) and box#(string) then count separately.

   Source IEEE 1800-2017 §8.25

   • Lesson 4.6Parameterized Classes and Static Members
   • Problem 4.6.1Typed Value Box
4. What IfTwo Agents, One Static SettingL1 JuniorL2 Mid-Level

   Asked if they use statics for configuration

   Port 0's agent writes to 2004 although it was configured with base address 1000. Port 1 was configured with 2000. The agent stores its base address in a static int. What happened?

   cfg: port0 base_addr=1000
   cfg: port1 base_addr=2000
   port0: write addr=2004   <-- expected 1004

   Reveal the Model Answer

   A static member is one variable per class, shared by every instance. Configuring port 1 overwrote the value port 0 had set. Make the setting an instance member, or pass a per-instance configuration object.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A static member is one variable per class, shared by every instance. Key point 2 Configuring port 1 overwrote the value port 0 had set. Key point 3 Make the setting an instance member, or pass a per-instance configuration object.

   Misconception

   "Each agent object keeps its own static value."

   There is only one, no matter how many objects exist. The twin configures two agents and port 0 ends up with port 1's address.

   Run It

   Two agents configure a static int base_addr in turn.

   RUNVerilator · simulator service

   Edit the code, then run it

   OutputWaves

   RunReset codeExpected: port0 writes to 00002004 FAIL: a static is shared by every instance, so port1 overwrote port0's address

   See the Fix

   class agent;
     int base_addr;                // the fix: per-instance configuration
     function void configure(int a); base_addr = a; endfunction
     function int target(int off); return base_addr + off; endfunction
   endclass
   module tb;
     agent port0, port1;
     initial begin
       port0 = new; port0.configure('h1000);
       port1 = new; port1.configure('h2000);
       $display("port0 writes to %h", port0.target(4));
       if (port0.target(4) == 'h1004) $display("PASS: each agent kept its own address");
       else $display("FAIL: a static is shared by every instance, so port1 overwrote port0's address");
     end
   endmodule
   

   Prints: port0 writes to 00001004 PASS: each agent kept its own address

   • Lesson 4.6Parameterized Classes and Static Members
   • Lesson 6.4Virtual Interfaces and Driver Configuration
   • Problem 6.4.3The Monitors That Watched One Bus
5. Prove ItSolve 6.4.3: The Monitors That Watched One BusSimulator-graded

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

   Open Problem 6.4.3

6. CompareForward Class DeclarationsL1 JuniorL2 Mid-Level

   A driver class holds a handle to a sequencer, and the sequencer holds a handle back to the driver. Compare typedef class with reordering the file to make this compile.

   Reveal the Model Answer

   Reordering cannot work, because each class names the other before it is declared. typedef class sequencer; declares the name first, so driver can hold a sequencer handle. The full class can follow later in the same scope. Reordering is enough only when the dependency runs one way.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Reordering cannot work, because each class names the other before it is declared. Key point 2 typedef class sequencer; declares the name first, so driver can hold a sequencer handle. Key point 3 The full class can follow later in the same scope. Key point 4 Reordering is enough only when the dependency runs one way.

   Misconception

   "typedef class copies the class definition earlier in the file."

   It only declares the name as a class type; the definition must still appear later in the same scope.

   Source IEEE 1800-2017 §6.18

   • Lesson 4.6Parameterized Classes and Static Members
7. Scale ItType Parameters vs a Common Base ClassL3 Senior

   You are designing a reusable scoreboard. Do you parameterize it by transaction type, or write it against a common base transaction class?

   Reveal the Model Answer

   A type parameter gives full type safety and needs no casts. But scoreboard#(axi_txn) and scoreboard#(apb_txn) share no type, so they cannot sit in one array. A base-class design can hold any transaction and swap types at run time. The price is a cast wherever code needs derived fields. Many teams combine them: a parameterized class that extends a non-parameterized base holding the common interface.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A type parameter gives full type safety and needs no casts. Key point 2 But scoreboard#(axi_txn) and scoreboard#(apb_txn) share no type, so they cannot sit in one array. Key point 3 A base-class design can hold any transaction and swap types at run time. Key point 4 The price is a cast wherever code needs derived fields. Key point 5 Many teams combine them: a parameterized class that extends a non-parameterized base holding the common interface.

   What Interviewers Listen For (Senior)

   A good senior answer names what each choice makes impossible. It picks the mixed design only after saying what must be shared while the test runs.

   Half-Truth

   "Parameterize everything; it is more reusable."

   Unrelated specializations cannot be stored or handled together, which hurts reuse when an environment needs to treat many scoreboards alike.

   • Lesson 4.6Parameterized Classes and Static Members
8. Prove ItSolve 4.6.1: Typed Value BoxSimulator-graded

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

   Open Problem 4.6.1