Overview
An opcode category child class is part of a multi-class randomization architecture for an instruction generator. In the described design, a formerly larger opcode class was split into multiple smaller classes to reduce the size of the randomization problem. Opcodes were divided into categories that aligned with knobs or weights exposed through the test interface.
Role in the class hierarchy
The architecture separates common instruction behavior from category-specific opcode behavior:
- A base instruction class contains data members common to all child classes.
- The base class also contains most methods used to set, print, and pack data.
- Data members and constraints common to every opcode are placed in the base class.
- Each opcode category child class contains constraints specific to its opcode category.
Within each opcode category child class, the structure remains similar to the earlier single-class implementation: constraints are organized around implication operators based on opcode type.
Randomization flow
The instruction generator is controlled by knobs or switches that allow a test writer to generate constrained stimulus. In the described architecture, the test layer does not directly constrain fields inside the subclass. Instead, the upper-layer random sequence is controlled only by knobs and chooses the opcode category first. Once the category is selected, the generator can allocate the correct child-class object type and add it to the sequence.
If a test layer directly controls lower-level subclass variables, the design may require a wrapper class. In that alternative flow, the wrapper constrains variables controlled by tests, is randomized first, and then the correct subclass object is allocated and randomized in a second generation phase.
Performance context
The multi-class split is motivated by reducing randomization problem size. The source also describes using the VCS constraint profiler to analyze generator runtime and memory behavior. The profiler reports runtime information by cumulative randomize calls, individual randomize calls, and partitions, helping identify which randomization sites or partitions dominate CPU time.