Enumerated Types in Formal Modeling

Concept

In the provided UCLID5 verification evidence, enumerated types are used to model fields with a small number of possible values, such as instruction codes, function codes, register identifiers, and exception codes. They are part of a broader modeling strategy that chooses data types at an abstraction level sufficient for verification while avoiding irrelevant detail for the SMT solver.

First seen 5/26/2026

Last seen 5/26/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

In the provided formal-verification setting, enumerated types are one of several data-type choices available when constructing a model. The evidence describes UCLID5 models for Y86-64 processor verification, where different data types are selected to control the abstraction level of the model and the precision required by the verification task. A stated modeling rule is to use the most abstract model that still captures the system properties needed for correctness. [C1]

Role in processor models

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

UCLID5 ← uses 100% 1e

UCLID5 uses enumerated types to model fields with small numbers of possible values such as instruction codes.

LINKED ENTITIES

3 links

UCLID5 used_in_context The evidence describes UCLID5 generating verification conditions from formal models and using SMT solvers.

Z3 example_solver The evidence states that the work used the Z3 solver developed at Microsoft Research.

Uninterpreted Functions used_with The evidence describes an uninterpreted branch-decision function that takes an enumerated function-code argument.

CITATIONS

7 sources

7 citations — click to expand

[1] C1: Formal modeling in the evidence uses data-type choices to set the abstraction level, with a general rule of using the most abstract model that still captures correctness-relevant properties. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5

[2] C2: Fields with a small number of possible values, including instruction codes, function codes, register identifiers, and exception codes, were modeled as enumerated types. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5

[3] C3: Branch-decision logic was modeled as an uninterpreted Boolean-valued function with arguments including an enumerated function-code type and an uninterpreted condition-code type. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5

[4] C4: The described models also used uninterpreted instruction types, uninterpreted instruction-field extraction functions, configurable word_t data/address types, and uninterpreted condition-code modeling. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5

[5] C5: Different PIPE variants required different precision in ALU modeling, restrictions on initial pipeline state, and numbers of flushing steps. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5

[6] C6: UCLID5 generates verification conditions as formulas in logics supporting multiple data types and invokes an SMT solver; the cited work used Z3. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5

[7] C7: The SMT solver outcomes described are unsatisfiable, satisfiable, and indeterminate; satisfiable results can yield concrete values and counterexamples. Formal Verification of Pipelined Y86-64 Microprocessors with UCLID5