Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Puzzle Bank
  • SystemVerilog Language Puzzles25
  • Difficulty Guide
  • Full Topic Map
  • Interview-Day Tips
  • Study Route: One Week Before the Interview
  • Study Route: Two Weeks
  • Study Route: Four Weeks (Full Course)4
  • OOP & Testbench Puzzles25
    • Handle and Copy Puzzles
    • Virtual Method Puzzles
    • Parameterized Class Puzzles
      • Global Static vs Per-Specialization Static
      • Same Specialization via typedef Alias
      • $cast Between Specializations via a Common Base
      • Unrelated Specializations Cannot Be Assigned
      • Static Function Counters Per Specialization
      • Wrong UVM Macro for Parameterized Object
    • Factory Override Puzzles
    • OOP & Testbench Puzzles: Tricky Q&A
  • Concurrency & Timing Puzzles25
  • Randomization & Constraint Puzzles25
  • SVA Assertion Puzzles25
  • Functional Coverage Puzzles25
  • Logic & Aptitude Puzzles25
  • Scenario & Debug Puzzles25
  • UVM Testbench Puzzles25
  • Clock, Reset & CDC Puzzles25
  • Bus and Interface Protocol Puzzles25
  • Interview Prep: Puzzle Rounds7
  • DV Puzzle Cheatsheet
Loading lesson

←Parameterized Class Puzzles
  1. Topics
  2. DV Interview Puzzles
  3. OOP & Testbench Puzzles
  4. Parameterized Class Puzzles
  5. $cast Between Specializations via a Common Base
On this page

    VLSI DV Interview PuzzlesAll levels

    $cast Between Specializations via a Common Base

    A handle of a non-parameterized base holds an `agent#(int)`. Predict each `$cast` result and the final line.

    Puzzle

    Difficulty: Medium · Puzzle 3 of 6 · Topic: Parameterized Class Puzzles

    A handle of a non-parameterized base holds an `agent#(int)`. Predict each `$cast` result and the final line.

    Code

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    class base_agent; endclass
    
    class agent #(type T = int) extends base_agent;
      T last;
    endclass
    
    initial begin
      base_agent b;
      agent#(int)  ai, ai2;
      agent#(byte) ab;
      bit ok;
      ai = new();
      b = ai;
      $display("to_byte=%0d", $cast(ab, b));
      ok = $cast(ai2, b);
      $display("to_int=%0d same=%0d", ok, (ai2 == ai));
      b = new();
      $display("plain_base_to_int=%0d", $cast(ai2, b));
    end

    Hint

    `$cast` checks the runtime object type. Each specialization is its own class, and they only share the non-parameterized parent.

    Step-by-step solution

    Diagram
    1) `b` holds an `agent#(int)` object. `agent#(byte)` is a different class that merely shares the parent `base_agent`, so the cast to it fails: `to_byte=0`, and `ab` is not assigned.
    2) The cast to `agent#(int)` matches the runtime type, so it succeeds and `ai2` holds the same object: `to_int=1 same=1`. The cast is a separate statement (`ok = $cast(ai2, b);`) because a `$display` that both performs the cast and reads `ai2` in its arguments depends on argument evaluation order, which the LRM does not define.
    3) After `b = new()` the object is a plain `base_agent`, which is not an `agent#(int)`, so the cast fails: `plain_base_to_int=0`.
    4) Used as a function, `$cast` returns 0 on failure and does not stop the run; as a task (`$cast(ai2, b);`) a failure is a runtime error.

    Answer

    Answer: Prints `to_byte=0`, `to_int=1 same=1`, `plain_base_to_int=0`. A cast succeeds only to the exact specialization of the runtime object (or its parents); sibling specializations share a base but are unrelated to each other.

    How this was checked

    Checked by running the code in Verilator 5; the printed output supports the answer above. The shown code run in Verilator: $cast succeeds only to the exact specialization of the runtime object.

    Why candidates get it wrong

    A common base lets you store both specializations in one handle type, but it does not make them interchangeable: casting to the wrong specialization fails at run time, not compile time.

    Interviewer follow-up

    Why is a `$cast` to `agent#(byte)` useless even though both are `agent`? Model answer: because `agent#(int)` and `agent#(byte)` are two unrelated classes with the same parent, so no object is ever both. If you need common behaviour, put it in virtual methods of `base_agent`, not in a cast.

    Say it out loud

    It prints to_byte equals 0, to_int equals 1 with same equal to 1, and plain_base_to_int equals 0. A cast succeeds only to the exact specialization of the runtime object, or to its parents. The int and byte agents merely share a base and are unrelated to each other, and a plain base object is not an int agent. The trap is expecting a shared base to make siblings castable, so I would check the runtime type of the object.

    Related topics

    • Casting with $cast

    • Parameterized Classes

    • Back to Parameterized Class Puzzles

    • OOP & Testbench Puzzles section

    Previous

    50 / 293

    Next: Unrelated Specializations Cannot Be Assigned

    Up next

    Up nextUnrelated Specializations Cannot Be Assigned

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Global Static vs Per-Specialization Static
    • Static Function Counters Per Specialization
    • Wrong UVM Macro for Parameterized Object