This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Abstract. We present a SAT-based algorithm for assisting users of Symbolic Trajectory Evaluation (STE) in manual abstraction refinement. As a case study, we demonstrate the usefulness of the algorithm by showing how to refine and verify an STE specification of a CAM. 1

Abstract. We present a new SAT-based algorithm for Symbolic Trajectory Evaluation (STE), and compare it to more established SAT-based techniques for STE. 1

Abstract. Symbolic Trajectory Evaluation (STE) is a powerful technique for model checking. It is based on 3-valued symbolic simulation, using 0,1 and X (”unknown”). The X value is used to abstract away parts of the circuit. The abstraction is derived from the user’s specification. Currently the process of abstraction and refinement in STE is performed manually. This paper presents an automatic refinement technique for STE. The technique is based on a clever selection of constraints that are added to the specification so that on the one hand the semantics of the original specification is preserved, and on the other hand, the part of the state space in which the ”unknown ” result is received is significantly decreased or totally eliminated. In addition, this paper raises the problem of vacuity of passed and failed specifications. This problem was never discussed in the framework of STE. We describe when an STE specification may vacuously pass or fail, and propose a method for vacuity detection in STE. 1

Programmable logic devices (PLDs) are increasing in complexity and speed, and are being used as important components in safety-critical systems. Methods for developing high-integrity software for these systems are well-known, but this is not true for programmable logic. We propose a process for developing a system incorporating software and PLDs, suitable for safety critical systems of the highest levels of integrity. This process incorporates the use of Synchronous Receptive Process Theory as a semantic basis for specifying and proving properties of programs executing on PLDs, and extends the use of SPARK Ada from a programming language for safety-critical systems software to cover the interface between software and programmable logic. We have validated this approach through the specification and development of a substantial safety-critical system incorporating both software and programmable logic components, and the development of tools to support this work. This enables us to claim that the methods demonstrated are not only feasible but also scale up to realistic system sizes, allowing development of such safety-critical software-hardware systems to the levels required by current system safety standards. Declaration of originality I declare that no part of this work has previously been submitted to a university or other educational institution for a degree or other qualification. I further declare that this thesis is my original work, except for clearly indicated sections where the appropriate attributions and acknowledgements are given to work by other authors.

Abstract. Symbolic Trajectory Evaluation (STE) is a formal verification technique for hardware. The current STE semantics is not faithful to the proving power of existing STE tools, which obscures the STE theory unnecessarily. In this paper, we present a new closure semantics for STE which does match the proving power of STE model-checkers, and makes STE easier to understand. 1

Abstract. The paper seeks a perspective on the reality of Formal Methods in industry today. What has worked; what has not; and what might the future bring? We show that where formality has been adopted it has largely been benefical. We show that formality takes many forms, not all of them obviously “Formal Methods”. 1

Abstract. Understanding the roles that rigour and formality can have in the design of critical systems is critical to anyone wishing to contribute to their development. Whereas knowledge of these issues is good in software development, in the use of hardware – specifically programmable logic devices (PLDs) and the combination of PLDs and software – the issues are less well known. Indeed, even in industry there are many differences between current and recommended practice and engineering opinion differs on how to apply existing standards. This situation has led to gaps in the formal and rigorous treatment of PLDs in critical systems. In this paper we examine the range of and potential for formal specification and analysis techniques that address the requirements for verifiable PLD programs. We identify existing formalisms that may be used, and lay out the areas of contributions that academia and industry in collaboration can make that would allow high-integrity PLD programming to be as practicable as high-integrity software development. This paper also touches briefly on some important practical, technical, organisational, social, and psychological aspects of the introduction of formal methods into industrial practice for hardware and system design. It also provides an update and summary of the recent UK Defence Standard 00-56, as it relates to hardware.

Abstract. Effective formal verification tools require that robust implementations of automatic procedures for first-order logic and satisfiability modulo theories be integrated into expressive interactive frameworks for logical deduction, such as higher-order logic

the course of the project we learned a lot about the challenges of deploying FPV to an ASIC team. Overall our use of FPV in Blackford was very successful, having helped us find approximately 24 logic bugs, and significantly increased confidence in our design. We have a number of methodology recommendations for future ASIC projects, including early introduction of FPV; the assigning of central FPV owners; FPV-friendly RTL standards; leaving ownership primarily with each DE; and the encouragement of assertion development through density checks. We think that by learning from our experiences and following our recommendations, other ASIC teams will be able to expand their use of FPV as well, for a significant increase in design confidence. I.