Override a virtual method in three subclasses, so a scoreboard holding base handles gets each subtype’s answer.
Hardware context: Polymorphic response prediction and checking policies. Predict response length from the actual request subtype.
A scoreboard keeps every request as a response_operation handle and asks each one how many response bytes to expect. If the call runs the base version for every object, the scoreboard expects nothing from reads and fails every correct response.
The base class models a fence: response_bytes() returns 0. Add response_bytes() to the three subclasses: a read returns its width_bytes; a write returns 0 when posted and 1 (a status byte) when not; a burst, which extends read, returns width_bytes times beats.
The scoreboard must not check a kind field or cast. Calling through any handle, base or derived, must give the object’s own answer.
Signals in the timeline
| Signal | Width | Role |
|---|---|---|
operation_kind | 2 | input of each check |
width_bytes | 4 | input of each check |
beat_count | 5 | input of each check |
posted | 1 | input of each check |
packet_id | 8 | input of each check |
Full specification
class response_operation;
byte unsigned id;
function new(input byte unsigned tag);id=tag;endfunction
virtual function int response_bytes();return 0;endfunction
endclass
class read_operation extends response_operation;
int width_bytes;
function new(input byte unsigned tag,input int width);super.new(tag);width_bytes=width;endfunction
endclass
class write_operation extends response_operation;
bit posted;
function new(input byte unsigned tag,input bit is_posted);super.new(tag);posted=is_posted;endfunction
endclass
class burst_operation extends read_operation;
int beats;
function new(input byte unsigned tag,input int width,count);super.new(tag,width);beats=count;endfunction
endclass
Each case builds one object, calls response_bytes() through its own class handle, through a response_operation handle and through a second base handle to the same object, and reports all three, the id and whether the two base handles name the same object.
Examples
Example 1
A read through three handles- Input
read, width 4, id 7
- Output
direct_bytes = 4, base_bytes = 4, alias_bytes = 4, id = 7, same_object = yes
Every call returns 4.
Example 2
A posted write- Input
posted write, id 9
- Output
direct_bytes = 0, base_bytes = 0, alias_bytes = 0, id = 9, same_object = yes
A posted write expects no response bytes, through every handle.
Example 3
Two levels of inheritance- Input
burst, width 8, beats 16, id 255
- Output
direct_bytes = 128, base_bytes = 128, alias_bytes = 128, id = 255, same_object = yes
8 x 16 = 128, even when called through the top-level base handle.
Constraints and contract
- Widths and beat counts are small positive ints.
- All three calls must return the same number.
- Keep the class names and constructors.
Hints
Hint 1
A call through a base handle runs the base method unless the method is declared in a particular way. Which keyword is that, and where does it go?
Hint 2
Once a method is virtual in the base, each subclass only needs a method with exactly the same signature.
Hint 3
A burst extends read, so it inherits width_bytes; its own override multiplies by beats.
What this judge verifies: Every subtype is built with seeded widths, beat counts and posted flags, and called through its own handle and two base handles. Passing shows dispatch reaches each override.
131 checks on Verilator · local server. Run the examples first, then check the full regression. The suite is local and inspectable. A passing result establishes the tested cases, not a proof for all possible inputs.
See all 5 steps and the final capstone