Overview

assertSE is used in the VAMP microprocessor test-generation case study as a state-exception primitive for expressing test post-conditions on the final state of an automaton. In the shown specifications, an instruction sequence is executed with mbind ... execVAMP, and assertSE checks a predicate over the resulting state, typically comparing that state with the result produced by the system under test (SUT) for the same initial state and instruction sequence. [C1]

Typical form

The evidence shows assertSE embedded after execution of an instruction list:

σ0 |=(s ←mbind [Isw 0 1 8, Ilbu 1 0 -3, Ilbu 3 2 8] execVAMP;
       assertSE (λσ. σ =k SUT σ0[Isw 0 1 8, Ilbu 1 0 -3, Ilbu 3 2 8]))

The same pattern is used for arithmetic and control-flow sequences, for example:

σ0 |=(s ←mbind [Isub 2 1 0, Iadd 1 5 2, Iadd 1 0 4] execVAMP;
       assertSE (λσ. σ=k SUT σ0[Isub 2 1 0, Iadd 1 5 2, Iadd 1 0 4]))

and:

σ0 |=(s ←mbind [Ij 1, Ijalr 0] execVAMP;
        assertSE (λσ. σ=k SUT σ0[Ij 1, Ijalr 0]))

These examples indicate that assertSE is applied to a lambda over the final state σ, and that the predicate can use the =k state-conformance comparison against the SUT result. [C2]

Role in generated tests

In the load/store testing scenario, schematic test cases are generated first and then instantiated with concrete values by gen_test_data. The resulting concrete test program executes a sequence such as store followed by loads and then uses assertSE to check the final state. [C3]

The same final-state assertion style is also used in generated sequence tests for arithmetic operations and branch operations. Arithmetic sequence generation can produce a subtraction followed by additions, while branch sequence generation can produce jump-related instruction sequences; in both cases, the generated test specification ends with assertSE. [C4]

Observability limitation

The cited study explicitly notes a limitation of this testing scenario: post-conditions expressed with assertSE are final-state post-conditions, but this is “not very realistic” for hardware processors because the final state—especially internal processor registers—may not be directly observable. [C5]

Alternative mentioned in the source

The source names the state-exception primitive return as an alternative for scenarios that perform step-by-step checking of output values. Such output might be retrieved from an updated memory cell, but the approach requires a modified VAMP in which individual steps are wrapped into trusted code that makes internal register content explicit. [C6]

Practical interpretation

Within the evidence, assertSE should be understood as the assertion combinator used at the end of state-exception computations to validate final-state properties of generated tests. It is suitable for model-level test specifications where the final state can be compared, but the cited source cautions that direct final-state checking may not match the observability constraints of real hardware processors. [C1] [C5]