No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Microcode Verification – Another Piece of the Microprocessor Verification Puzzle
Abstract
Despite significant progress in formal hardware verification in the past decade, little has been published on the verification of microcode. Microcode is the heart of every microprocessor and is one of the most complex parts of the design: it is tightly connected to the huge machine state, written in an assembly-like language that has no support for data or control structures, and has little documentation and changing semantics. At the same time it plays a crucial role in the way the processor works.
We describe the method of formal microcode verification we have developed for an x86-64 microprocessor designed at Centaur Technology. While the previous work on high and low level code verification is based on an unverified abstract machine model, our approach is tightly connected with our effort to verify the register-transfer level implementation of the hardware. The same microoperation specifications developed to verify implementation of teh execution units are used to define operational semantics for the microcode verification.
While the techniques used in the described verification effort are not inherently new, to our knowledge, our effort is the first interconnection of hardware and microcode verification in context of an industrial size design. Both our hardware and microcode verifications are done within the same verification framework.
... Large scale formal verification projects were first reported by hardware companies around ten years ago, e.g. Intel [28], IBM [36], ARM [34], and Centaur Technology [18,37]. Success stories of FV at software development companies followed. ...
... We do not expect this to be the case for all of them. In the past, we worked on some microcode stored in ROM that served other purposes [18]. This code had loops and jumps between loops and we were able to do invariant-style proofs. ...
Formal methods are becoming an indispensable part of the design process in software and hardware industry. It takes robust tools and proofs to make formal validation of large scale projects reliable. In this paper, we will describe the current status of formal verification at Centaur Technology. We will explain our challenges and our methodology—how various proofs and verification artifacts are interconnected and how we keep them consistent over the duration of a project. We also describe our main engine—a powerful symbolic simulator with rewriting capabilities that is integrated in a theorem prover and proven correct.
... The intended behaviour of microoperations is a part of the microarchitectural specification. This specification serves a dual purpose-to verify that the units responsible for the execution of individual microoperations are correct, and as an operational semantics for the formal microcode model (see [38] for microcode verification). ...
... In the case of microcode verification, the process is less automatic and the FV team focuses on the most critical code (no longer than several hundred lines). The key to Centaur's method is to symbolically simulate the microcode for a few steps, proving invariants about small blocks of code (with support for loop invariants [38]), and then compose those lemmas into a proof of an entire microcode routine. An important point is that the microcode model is based on the very ...
The ACL2 theorem prover has seen sustained industrial use since the mid-1990s. Companies that have used ACL2 regularly include AMD, Centaur Technology, IBM, Intel, Kestrel Institute, Motorola/Freescale, Oracle and Rockwell Collins. This paper introduces ACL2 and focuses on how and why ACL2 is used in industry. ACL2 is well-suited to its industrial application to numerous software and hardware systems, because it is an integrated programming/proof environment supporting a subset of the ANSI standard Common Lisp programming language. As a programming language ACL2 permits the coding of efficient and robust programs; as a prover ACL2 can be fully automatic but provides many features permitting domain-specific human-supplied guidance at various levels of abstraction. ACL2 specifications and models often serve as efficient execution engines for the modelled artefacts while permitting formal analysis and proof of properties. Crucially, ACL2 also provides support for the development and verification of other formal analysis tools. However, ACL2 did not find its way into industrial use merely because of its technical features. The core ACL2 user/development community has a shared vision of making mechanized verification routine when appropriate and has been committed to this vision for the quarter century since the Computational Logic, Inc., Verified Stack. The community has focused on demonstrating the viability of the tool by taking on industrial projects (often at the expense of not being able to publish much).
This article is part of the themed issue ‘Verified trustworthy software systems’.
... The key is chosen to match the key used by the call, the value is chosen to match the existing binding of the key in the record, and the record is just the input record itself. By the record property s-same-g, (equal (s a (g a r) r) r), this reduces to the input record, satisfying obligation 1. 2 The shape specifiers for the arguments (key val rec) also cover the values, satisfying Obligation 2: the keys are equal constants; the value shape specifiers are each 10-bit integers, which by the unsigned-byte-p hypotheses suffice to cover the specified components, and the g-var construct used as the innermost record can cover any object. The coverage proof completes with the help of the :cov-theory-add argument, which enables the listed rules during the proof of the coverage obligation. ...
... The GL features discussed here have been used in proofs about microcode routines at Centaur Technology [2]. The proof framework was based on specifying the updates to the machine state computed by small code blocks, then composing these blocks together to specify the resulting machine state from a whole microcode routine. ...
GL is a verified tool for proving ACL2 theorems using Boolean methods such as BDD reasoning and satisfiability checking. In its typical operation, GL recursively traverses a term, computing a symbolic object representing the value of each subterm. In older versions of GL, such a symbolic object could use Boolean functions to compactly represent many possible values for integer and Boolean subfields, but otherwise needed to reflect the concrete structure of all possiblealues that its term might take. When a term has many possible values that can't share such a representation, this can easily cause blowups because GL must then case-split. To address this problem, we have added several features to GL that allow it to reason about term-like symbolic objects using various forms of rewriting. These features allow GL to be programmed with rules much like the ACL2 rewriter, so that users may choose a better normal form for terms for which the default, value-like representation would otherwise cause case explosions. In this paper we describe these new features; as a motivating example, we show how to program the rewriter to reason effectively about the theory of records.
... Defstructure has long been used in ACL2 developments, including recent work such as the modeling by Hardin, et al. [13] of the LLVM compiler project's intermediate form in ACL2, and the formalization by van Gastel and Schmaltz [9] of the xMAS language for communication networks on multi-core processors and systems-on-chip. For many years, we used defaggregate and other std/util macros at Centaur as the basis for our VL library, microcode model [7], and other internal applications. In our experience, porting these libraries to FTY was not difficult and has helped to simplify our code. ...
When using existing ACL2 datatype frameworks, many theorems require type
hypotheses. These hypotheses slow down the theorem prover, are tedious to
write, and are easy to forget. We describe a principled approach to types that
provides strong type safety and execution efficiency while avoiding type
hypotheses, and we present a library that automates this approach. Using this
approach, types help you catch programming errors and then get out of the way
of theorem proving.
The open and royalty free nature as well as the extendable design of the RISC-V Instruction Set Architecture (ISA) has lead to a sprawling ecosystem of RISC-V software and hardware. One of the domains explored by the RISC-V community are processors with minimal area footprints. To reduce the area footprint to the minimum, typically performance is traded for a much more compact design. A promising approach to realizing very small RISC-V processors is to base them on a single instruction, such as SUBLEQ, and using a microcode layer. However, the minimalism of SUBLEQ makes writing correct microcode procedures challenging.In this paper, we target the formal verification of SUBLEQ microcode procedures. We present our verification framework and show that we can handle complex SUBLEQ procedures in practical times. In our experiments we consider a set of SUBLEQ procedures which implements the RV32I ISA and passes all official RISC-V compliance tests. However, based on our approach we found 9 intricate bugs in the SUBLEQ procedures.
Construction of a formal model of a computing system is a necessary practice in formal verification. The results of formal analysis can only be valued to the same degree as the model itself. Model development is error-prone, not only due to the complexity of the system being modeled, but also because it involves addressing disparate requirements. For example, a formal model should be defined using simple constructs to enable efficient reasoning but it should also be optimized to offer fast concrete simulations. Models of large computing systems are themselves large software systems and must be subject to rigorous validation. We describe our formal, executable model of the x86 instruction-set architecture; we use our model to reason about x86 machine-code programs. Validation of our x86 ISA model is done by co-simulating it regularly against a physical x86 machine. We present design decisions made during model development to optimize both validation and verification, i.e., efficiency of both simulation and reasoning. Our engineering process provides insight into the development of a software verification and model animation framework from the points of view of accuracy, efficiency, scalability, maintainability, and usability.
We describe the formal methodology we are using to verify components of a commercial 64-bit, x86-compatible microprocessor design at Centaur Technology. This methodology is based on the ACL2 theorem prover. In this methodology, we mechanically translate the RTL design into a formal HDL for which we have an interpreter in ACL2. We use AIG-and BDD-based symbolic simulation and theorem proving techniques to show that the hardware models satisfy their specifications, which are ACL2 functions. Completed verifications yield theorems admitted by ACL2, ensuring that the verification is based on sound reasoning. We have used this methodology to verify instructions such as SIMD floating-point addition and subtraction, integer and floating-point multiplication, comparisons, bit-wise logical operations, and integer/float conversions. We discuss our floating-point addition verification as a case study.
Today's microelectronics industry is increasingly confronted with the challenge of developing and validating software that closely interacts with hardware. These interactions make it difficult to design and validate the hardware and software separately; instead, a verifiable co-design is required that takes them into account. This paper demonstrates a new approach to co-validation of hardware/software interfaces by formal, symbolic co-execution of an executable hardware model combined with the software that interacts with it. We illustrate and evaluate our technique on three realistic benchmarks in which software I/O is subject to hardware-specific protocol rules: a real-time clock, a temperature sensor on an I2C bus, and an Ethernet MAC. We provide experimental results that show our approach is both feasible as a bug-finding technique and scales to handle a significant degree of concurrency in the combined hardware/software model.
In recent years, leading microprocessor companies have made huge investments to improve the reliability of their products. Besides expanding their validation and CAD tools teams, they have incorporated formal verification methods into their design flows. Formal verification (FV) engineers require extensive training, and FV tools from CAD vendors are expensive. At first glance, it may seem that FV teams are not affordable by smaller companies. We have not found this to be true. This paper describes the formal verification framework we have built on top of publicly-available tools. This framework gives us the flexibility to work on myriad different problems that occur in microprocessor design.
Security-critical applications at the highest Evaluation Assurance Levels (EAL) require formal proofs of correctness in order to achieve certification. To support secure application development at the highest EALs, we have developed techniques to largely automate the process of producing proofs of correctness of machine code. As part of the Secure, High-Assurance Development Environment program, we have produced in ACL2 an executable formal model of the Rockwell Collins AAMP7G microprocessor at the instruction set level, in order to facilitate proofs of correctness about that processor's machine code. The AAMP7G, currently in use in Rockwell Collins secure system products, supports strict time and space partitioning in hardware, and has received a U.S. National Security Agency (NSA) Multiple Independent Levels of Security (MILS) certificate based in part on a formal proof of correctness of its separation kernel microcode. Proofs of correctness of AAMP7G machine code are accomplished using the method of "compositional cutpoints", which requires neither traditional clock functions nor a Verification Condition Generator (VCG). In this paper, we will summarize the AAMP7G architecture, detail our ACL2 model of the processor, and describe our development of the compositional cutpoint method into a robust machine code proof framework.
Microcode is used to facilitate new technologies in Intel CPU de- signs. A critical requirement is that new designs be backwardly compatible with legacy code when new functionalities are disabled. Several features distinguish microcode from other software systems, such as: interactio n with the external environment, sensitivity to exceptions, and the complexit y of instructions. This work describes the ideas behind MICROFORMAL, a technology for fully auto- mated formal verification of functional backward compatibi lity of microcode.
We present a method to convert (i) an operational semantics for a given machine language, and (ii) an o-the-shelf theorem prover, into a high assurance verification condition generator (VCG). Given a program annotated with assertions at cutpoints, we show how to use the theorem prover directly on the operational semantics to generate verifi- cation conditions analogous to those produced by a custom-built VCG. Thus no separate VCG is necessary, and the theorem prover can be em- ployed both to generate and to discharge the verification conditions. The method handles both partial and total correctness. It is also composi- tional in that the correctness of a subroutine needs to be proved once, rather than at each call site. The method has been used to verify several machine-level programs using the ACL2 theorem prover.
Microcode is a critical component in modern microprocessors, and substantial effort has been devoted in the past to verify its correctness. A prominent approach, based on symbolic execution, traditionally relies on the use of boolean SAT solvers as a backend engine. In this paper, we investigate the application of Satisfiability Modulo Theories (SMT) to the problem of microcode verification. We integrate MathSAT, an SMT solver for the theory of Bit Vectors, within the flow of microcode verification, and experimentally evaluate the effectiveness of some optimizations. The results demonstrate the potential of SMT technologies over pure boolean SAT.
Bruns has proposed a version of value-passing CCS in which an agent language, based on that proposed by Milner, is augmented with a rich data language. The data language can be used to describe sets, tuples and sequences etc. constructed from integer, boolean and string constants. Z is a widely used formal specification language in which sets, tuples and sequences can be described, but also additional constructs such as free types and bindings. In addition, Z has a rich structuring mechanism -- its schema calculus. Z is frequently used to specify the operations of a system on its state, and has a refinement calculus and formal semantics. This article introduces ZCCS, a version of value-passing CCS in which the data language used to describe the action /agent parameters and conditions is Z. We introduce the style and syntax of ZCCS and illuminate this with a small example. In addition, we present an operational semantics for ZCCS. 1 Introduction When Milner defined value-passing CCS ...
We have formally described a substantial subset of the MC68020, a widely used microprocessor built by Motorola, within the mathematical logic of the automated reasoning system Nqthm, a.k.a. the Boyer-Moore Theorem Prover [6]. Using this formal description, we have mechanically checked the correctness of MC68020 object code programs for binary search, Hoare's Quick Sort, twenty-one functions from the Berkeley Unix C string library, and other well-known algorithms. The object code for these examples was generated using the Gnu C, the Verdix Ada, and the Gnu Common Lisp compilers. We have mechanized a mathematical theory to facilitate automated reasoning about object code programs. We describe a two stage methodology we use to do our proofs.
Analysis of binary programs is important to ensure correct execution of corresponding higher-level programs, especially because it accounts for bugs introduced by compilers. Moreover, source code may not always be available for correctness analysis. Proving correctness of binaries often involves significant user expertise and time-consuming manual effort. We describe an approach to automatically verify some X86 binary programs using symbolic execution on an executable formal model of the X86 instruction set architecture. Our approach can reduce the time and effort involved in the proof development process for complex programs.
High-speed simulation models are routinely developed during the design of complex hardware systems in order to predict performance, detect design flaws, and allow hardware/software co-design. Writing such an executable model in ACL2 brings the additional benefit of formal analysis; however, much care is required to construct an ACL2 model that is both fast and analyzable. In this chapter, we develop techniques for the construction of high-speed formally analyzable simulators in ACL2, and demonstrate their utility on a simple processor model.
This paper attempts to provide an adequate basis for formal definitions of the meanings of programs in appropriately defined programming languages, in such a way that a rigorous standard is established for proofs about computer programs, including proofs of correctness, equivalence, and termination. The basis of our approach is the notion of an interpretation of a program: that is, an association of a proposition with each connection in the flow of control through a program, where the proposition is asserted to hold whenever that connection is taken. To prevent an interpretation from being chosen arbitrarily, a condition is imposed on each command of the program. This condition guarantees that whenever a command is reached by way of a connection whose associated proposition is then true, it will be left (if at all) by a connection whose associated proposition will be true at that time. Then by induction on the number of commands executed, one sees that if a program is entered by a connection whose associated proposition is then true, it will be left (if at all) by a connection whose associated proposition will be true at that time. By this means, we may prove certain properties of programs, particularly properties of the form: ‘If the initial values of the program variables satisfy the relation R
l, the final values on completion will satisfy the relation R
2’.
And-Inverter Graphs (AIGs) are a popular way to represent Boolean functions
(like circuits). AIG simplification algorithms can dramatically reduce an AIG,
and play an important role in modern hardware verification tools like
equivalence checkers. In practice, these tricky algorithms are implemented with
optimized C or C++ routines with no guarantee of correctness. Meanwhile, many
interactive theorem provers can now employ SAT or SMT solvers to automatically
solve finite goals, but no theorem prover makes use of these advanced,
AIG-based approaches.
We have developed two ways to represent AIGs within the ACL2 theorem prover.
One representation, Hons-AIGs, is especially convenient to use and reason
about. The other, Aignet, is the opposite; it is styled after modern AIG
packages and allows for efficient algorithms. We have implemented functions for
converting between these representations, random vector simulation, conversion
to CNF, etc., and developed reasoning strategies for verifying these
algorithms.
Aside from these contributions towards verifying AIG algorithms, this work
has an immediate, practical benefit for ACL2 users who are using GL to
bit-blast finite ACL2 theorems: they can now optionally trust an off-the-shelf
SAT solver to carry out the proof, instead of using the built-in BDD package.
Looking to the future, it is a first step toward implementing verified AIG
simplification algorithms that might further improve GL performance.
We have verified floating-point addition/subtraction instructions for the media unit from Centaur’s 64-bit, X86-compatible microprocessor. This unit implements over one hundred instructions, with the most complex being floating-point addition/subtraction. This media unit can add/subtract four pairs of floating-point numbers every clock cycle with an industry-leading two-cycle latency.
Using the ACL2 theorem proving system, we model the media unit by translating its Verilog design into an HDL that we have deeply embedded in the ACL2 logic. We specify the addition/subtraction instructions as integer-based ACL2 functions. Using a combination of AIG- and BDD-based symbolic simulation, case splitting, and theorem proving, we produce a mechanically checked theorem in ACL2 for each instruction examined stating that the hardware model yields the same result as the instruction specification.
In pursuit of these verifications, we implemented a formal HDL and symbolic simulation framework, including formally verified BDD and AIG operators, within the ACL2 theorem proving system. The HDL includes an extensible interpreter capable of performing concrete and symbolic simulations as well as non-functional analyses. We know of no other symbolic simulation-based floating-point verification that is performed within a single formal system and produces a theorem in that system without relying on unverified external tools.
This paper is concerned with the relationship between the correctness of programs and the satisfiability (or unsatisfiability) of certain formulas of the first-order predicate calculus. Results on the equivalence of programs are also included.
In this paper I shall discuss the prospects for a mathematical science of computation. In a mathematical science, it is possible to deduce from the basic assumptions, the important properties of the entities treated by the science. Thus, from Newton’s law of gravitation and his laws of motion, one can deduce that the planetary orbits obey Kepler’s laws.
This paper presents a new HOL4 formalization of the current ARM instruction set architecture, ARMv7. This is a modern RISC
architecture with many advanced features. The formalization is detailed and extensive. Considerable tool support has been
developed, with the goal of making the model accessible and easy to work with. The model and supporting tools are publicly
available – we wish to encourage others to make use of this resource. This paper explains our monadic specification approach
and gives some details of the endeavours that have been made to ensure that the sizeable model is valid and trustworthy. A
novel and efficient testing approach has been developed, based on automated forward proof and communication with ARM development
boards.
We relate two well-studied methodologies in deductive veri-fication of operationally modeled sequential programs, namely the use of inductive invariants and clock functions. We show that the two method-ologies are equivalent and one can mechanically transform a proof of a program in one methodology to a proof in the other. Both partial and total correctness are considered. This mechanical transformation is com-positional; di erent parts of a program can be verified using di erent methodologies to achieve a complete proof of the entire program. The equivalence theorems have been mechanically checked by the ACL2 the-orem prover and we implement automatic tools to carry out the trans-formation between the two methodologies in ACL2.
This paper describes an automatic method for proving equivalence of implementations of block ciphers (and similar cryptographic algorithms). The method can compare two object code implementations or compare object code to a formal, mathematical specification. In either case it proves that the computations being compared are bit-for-bit equivalent. The method has two steps. First the computations are represented as large mathematical terms. Then the two terms are proved equivalent using a phased approach that includes domain-specific optimizations for block ciphers and relies on a careful choice of both word-level and bit-level simplifications. The verification also relies on STP [5], a SAT-based decision procedure for bit-vectors and arrays. The method has been applied to verify real, widely-used Java code from Sun Microsystems and the open source Bouncy Castle project. It has been applied to implementations of the block ciphers AES, DES, Triple DES (3DES), Blowfish, RC2, RC6, and Skipjack as well as applications of the cryptographic hash functions SHA-1 and MD5 on fixed-length messages.
We have verified the FM9801, a microprocessor design whose features include speculative execution, out-of-order issue and completion of instructions using Tomasulo's algorithm, and precise exceptions and interrupts. As a correctness criterion, we used a commutative diagram that compares the result of the pipelined execution from a flushed state to another flushed state with that of the sequential execution. Like many pipelined microprocessors, the FM9801 may not operate correctly if the executed program modifies itself. We discuss the condition under which the processor is guaranteed to operate correctly. In order to show that the correctness criterion is satisfied, we introduce an intermediate abstraction that records the history of executed instructions. Using this abstraction, we define a number of invariant properties that must hold during the operation of the FM9801. We verify these invariant properties, and then derive the proof of the commutative diagram from them. The proof has been mechanically checked by the ACL2 theorem prover.
In this paper an attempt is made to explore the logical founda- tions of computer programming by use of techniques which were first applied in the study of geometry and have later been extended to other branches of mathematics. This in- volves the elucidation of sets of axioms and rules of inference which can be used in proofs of the properties of computer programs. Examples are given of such axioms and rules, and a formal proof of a simple theorem is displayed. Finally, it is argued that important advantages, both theoretical and prac- tical, may follow from a pursuance of these topics.
Interactive theorem proving requires a lot of human guidance. Proving a
property involves (1) figuring out why it holds, then (2) coaxing the theorem
prover into believing it. Both steps can take a long time. We explain how to
use GL, a framework for proving finite ACL2 theorems with BDD- or SAT-based
reasoning. This approach makes it unnecessary to deeply understand why a
property is true, and automates the process of admitting it as a theorem. We
use GL at Centaur Technology to verify execution units for x86 integer, MMX,
SSE, and floating-point arithmetic.
This paper reports on the formal proof of correctness of a compiler from a substantial subset of Java source language to Java bytecode in the proof environment Isabelle. This work is based on extensive previous formalizations of Java, which comprise all relevant features of object-orientation. We place particular emphasis on describing the e#ects of design decisions in these formalizations on the compiler correctness proof.
We present a formal operational semantics for Stateflow, the graphical Statecharts-like language of the Matlab/Simulink tool suite that is widely used in model-based development of embedded systems. Stateflow has many tricky features but our operational treatment yields a surprisingly simple semantics for the subset that is generally recommended for industrial applications. We have validated our semantics by developing an interpreter that allows us to compare its behavior against the Matlab simulator. We have used the semantics as a foundation for developing prototype tools for formal analysis of Stateflow designs.
In the past we have verified a variety of different hardware circuits using different verification systems. In this paper we report on one such verification. The verification is that of a simple pipelined microprocessor first verified in [8]. We use this example as a vehicle for exploring a general methodology of verifying state machine systems in the PVS verification system. It is our hope that such a methodology can be extended to verify the correctness of actual commercial microprocessors. Contents 1 Introduction 5 2 The General Methodology 7 2.1 The State Machines : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 2.2 The Correctness Condition : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 2.3 Adding Time Explicitly : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 3 The Trip Meter 14 3.1 Informal Specification : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14 3.2 The Specification State Machine : : : : : : : : : : : : : : ...
ii Table of Contents iii List of Tables ix List of Figures x 1. Introduction 1 1.1 The Thesis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 1.2 Related Work : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 1.3 Outline of the Thesis : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 2. Formal Specification and Machine Code Verification 10 2.1 An Instruction Set Specification of the MC68020 : : : : : : : : : : : : 10 2.1.1 The Interpreter Semantics : : : : : : : : : : : : : : : : : : : : : 10 2.1.2 The Specification : : : : : : : : : : : : : : : : : : : : : : : : : : 12 2.2 Machine Code Verification : : : : : : : : : : : : : : : : : : : : : : : : : 14 2.2.1 Machine Code Programs : : : : : : : : : : : : : : : : : : : : : : 14 2.2.2 The Correctness Statement : : : : : : : : : : : : : : : : : : : : 16 2.3 The Automated Reasoning System Nqthm : : : : : : : : : : : : : : : : 19 2.3.1 The Logic : : : : : : : : : : : : : : : : : : : : : : : : : : ...
ly every instruction will have an opcode and two arguments, a and b. (defun opcode (ins) (nth 0 ins)) (defun a (ins) (nth 1 ins)) (defun b (ins) (nth 2 ins)) Because nth, like put, extends its list argument with nils, we can write instructions in three formats: (op), (op a), and (op a b) and omitted arguments default to nil. For example, the constant (times (movi 2 0) ; 0 mem[2] / 0 (jumpz 0 5) ; 1 if mem[0]=0, go to 5 (add 2 1) ; 2 mem[2] / mem[1] + mem[2] (subi 0 1) ; 3 mem[0] / mem[0] - 1 (jump 1) ; 4 go to 1 (ret))) ; 5 return to caller defines one program in our language. The constant is a list of seven elements. The first, times, is the name of the program and the other six elements are the 8 Chapter 4 instructions. For example, the first instruction is (movi 2 0), which has an opcode of movi, an a argument of 2 and a b argument of 0; the last instruction is (ret), which has an opcode of ret and a and b arguments of nil. A typical code memory will contain many such ...
Use of Formal Verification at Centaur Technology Design and Verification of Microprocessor Systems for High-Assurance Applications
- Hunt Jr
- W A Swords
- S Davis
- J Slobodova
Formal verification of partition management of the AAMP7G microprocessor
- M Wilding
- D Greeve
- R Richards
- D Hardin
Wilding, M., Greeve, D., Richards, R., Hardin, D.: Formal verification of partition
management of the AAMP7G microprocessor. In Hardin, D., ed.: Design and
Verification of Microprocessor Systems for High-Assurance Applications. Springer
(2010) 175-192
High-speed, analyzable simulators
- D Greeve
- M Wilding
- D Hardin
Greeve, D., Wilding, M., Hardin, D.: High-speed, analyzable simulators. In Kaufmann, M., Moore, J.S., Manolios, P., eds.: Computer-Aided Reasoning: ACL2 Case
Studies. Kluwer Academic Publishers (2000) 89-106
Formal co-validation of low-level hardware/software interfaces
- A Horn
- M Tautschnig
- C Val
- L Liang
- T Mehlham
- J Grundy
- D Kroening
Automated reasoning and its applications: essays in honor of Larry Woss
- R Boyer
- J Moore
Boyer, R., Moore, J.: Mechanized formal reasoning about programs and computing
machines. Automated reasoning and its applications: essays in honor of Larry Woss
(1996) 141-176
Design and Verification of Microprocessor Systems for High-Assurance Applications
- M Wilding
- D Greeve
- R Richards
- D Hardin