Skip to content
STIMSMITH

Opcode Category Child Class

CodeArtifact WIKI v1 · 5/25/2026

An opcode category child class is a subclass used in a multi-class instruction-randomization architecture. It represents a category of opcodes and holds constraints specific to that opcode set, while common data members, methods, and constraints are factored into a base instruction class.

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.

CITATIONS

6 sources
6 citations
[1] The opcode class was split into multiple smaller classes to reduce the size of the randomization problem, and opcodes were divided into categories aligned with test-interface knobs or weights. Generating AMD microcode stimuli using VCS constraint solver
[2] The base instruction class contains common data members, common constraints, and most methods used to set, print, and pack data for all child classes. Generating AMD microcode stimuli using VCS constraint solver
[3] Each opcode category child class contains constraints specific to that opcode set and uses a structure similar to the original single-class code, including implication operators based on opcode type. Generating AMD microcode stimuli using VCS constraint solver
[4] The upper-layer random sequence is controlled by knobs, chooses the opcode category first, and then allocates the correct object type to add the subclass into the sequence. Generating AMD microcode stimuli using VCS constraint solver
[5] If tests directly control lower-level items, a wrapper class may be required and randomized before allocating and randomizing the correct subclass object in a second phase. Generating AMD microcode stimuli using VCS constraint solver
[6] The VCS constraint profiler analyzes generator runtime and memory, with runtime details reported for cumulative randomize calls, per-randomize calls, and partitions. Generating AMD microcode stimuli using VCS constraint solver