Definition
In the provided processor-verification context, a mapping function is an abstraction function used to describe the design-under-verification state in terms of a higher-level architectural state. This architectural state corresponds to the programmer-visible view of the processor, such as visible registers, rather than the detailed implementation registers. [C1]
Role in abstraction
Mapping functions allow operation properties to be written as high-level specifications instead of reimplementing detailed circuit logic in the verification language. The evidence describes this as an abstraction technique: the processor state is represented by architectural state, and that abstraction is achieved through mapping functions. [C1]
A specific example is the mapping function vreg, which represents the architectural register file of a pipelined processor. Because implementation register behavior can depend on multiple instructions currently in the pipeline, vreg hides or captures the pipeline forwarding logic while presenting the architectural register-file view. [C2]
Role in equivalence proofs
In the equivalence proof structure described in the evidence, the abstraction function vstate maps the implementation state of the CPU to the ISA state. The proof objective is to show that applying vstate to the implementation state after the CPU transition corresponds to applying the ISA next_state function at the architectural level. [C3]
More concretely, the evidence describes a correspondence between two paths: applying the transition relation T on the CPU and then mapping the resulting implementation state to the architectural state, versus using next_state to compute the next ISA state. [C4]
Relationship to ISS generation
Mapping functions are important for verification, but they are not required to automatically generate the instruction set simulator (ISS) in the described method. The evidence states that finding appropriate mapping functions for the architectural state is one of the more sophisticated parts of verification, yet those mapping functions are not needed to automatically generate the ISS. [C5]
Similarly, the ISS can be generated without carrying out the full equivalence proof between ISA and RTL upfront and without identifying the mapping functions between architectural and implementation state. Instead, the ISA can be developed early and used to generate the ISS; full confidence that the ISS complies with the design is obtained later through verification. [C6]
Practical significance
Mapping functions separate architectural reasoning from implementation detail. They make operation properties compact and readable, especially for pipelined processors where the visible architectural state may depend on hidden implementation mechanisms such as forwarding. At the same time, the cited workflow keeps ISS generation independent of those mapping functions by generating the simulator from an architectural-style ISA description based on explicit architectural state and a next_state function. [C2] [C5]