Hardware Architecture Validity Rules

Hardware Architecture Validity Rules are constraints that describe valid behavior imposed by a hardware architecture during model-based random stimuli generation. In the cited IBM/AAAI context, these rules are distinguished from user requests and expert knowledge: user requests describe desired scenarios, expert knowledge expresses probabilistic or coverage-oriented preferences, and architectural validity rules encode requirements that generated tests must satisfy to be architecturally meaningful.

Role in model-based stimuli generation

In a model-based stimuli generator, the input model describes the hardware architecture and expert knowledge, while a generic engine generates tests for the architecture. The evidence describes a generator partitioned into a generic engine and an input model, where the model captures the hardware architecture at hand and expert knowledge. One stated technical challenge is ensuring that all user-defined and validity rules, and as many expert-knowledge rules as possible, are satisfied.

The application architecture places the declarative architectural description of the design under test in a knowledge base, alongside the expert-knowledge repository. The generic engine accepts the architecture model, expert knowledge, and test template, then generates batches of tests containing hardware transactions for simulation.

Examples of architectural validity rules

The evidence gives three examples under “Architectural Validity”:

Memory-address computation: memory address = base-register data + offset.
Aligned Load-Word atomicity: if a memory address is aligned to 4 bytes, then a Load-Word instruction is atomic.
Privileged-instruction exception behavior: a privileged instruction executed when the user-mode bit is on results in an exception.

These examples show that validity rules may constrain address calculation, instruction atomicity, and exception semantics.

Distinction from other rule classes

The same evidence contrasts architectural validity with two other inputs:

User requests, such as requiring at least one operand in an Add instruction to be larger than 9999, or requiring the same processor in a multiprocessor system to issue 10 subsequent Load instructions to consecutive addresses.
Expert knowledge, such as distributional goals: for example, 30% of Add instructions should result in c = 0, 20% of Load and Store instructions should cross page boundaries, another 20% should be exactly aligned to page boundaries, and 70% of transactions should contend on the same bus.

Architectural validity rules therefore function as correctness constraints, while expert-knowledge rules express desired statistical characteristics or scenario emphasis.

Use during generation and simulation

Generated tests contain hardware transactions that are sent to a design simulator. During generation, the system uses a functional reference model to calculate resource values after each transaction. Those values are needed to generate subsequent transactions and to compare against simulator results; a mismatch indicates a design bug. Within this process, validity rules help keep generated transaction sequences consistent with the architecture model before and during simulation.