This paper describes Hume: a novel domain-specific language whose purpose is to explore the expressibility/costability spectrum in resource-constrained systems, such as real-time embedded or control systems.

Various languages have been proposed to describe synchronous hardware at an abstract, yet synthesisable level. We propose a uniform framework within which such languages can be developed, and combined together for simulation, synthesis, and verification. We do this by embedding the languages in Lava --- a hardware description language (HDL), itself embedded in the functional programming language Haskell. The approach allows us to easily experiment with new formal languages and language features, and also provides easy access to formal verification tools aiding program verification.

www.dcs.gla.ac.uk/∼jtod/ Hydra is a computer hardware description language that integrates several kinds of software tool (simulation, netlist generation and timing analysis) within a single circuit specification. The design language is inherently concurrent, and it offers black box abstraction and general design patterns that simplify the design of circuits with regular structure. Hydra specifications are concise, allowing the complete design of a computer system as a digital circuit within a few pages. This paper discusses the motivations behind Hydra, and illustrates the system with a significant portion of the design of a basic RISC processor.

Abstract. This chapter describes Hume: a functionally-based language for programming with bounded resource usage, including time and space properties. The purpose of the Hume language design is to explore the expressibility/costability spectrum in resource-constrained systems, such as real-time embedded or control systems. It is unusual in being based on a combination of λ-calculus and finite state machine notions, rather than the more usual propositional logic, or flat finite-state-machine models. The use of a strict, purely functional programming notation allows the construction of a strong cost model for expressions, which can then be embedded into a simple cost model for processes. In this chapter, we introduce Hume, describe the Hume Abstract Machine implementation, and show how a high-level cost model can be constructed that relates costs from the abstract machine to Hume source programs. We illustrate our approach with an example adapted from the literature: a simple vending machine controller. 1

We demonstrate some simple but powerful methods that ease the problem of describing and generating circuits that exhibit a degree of regularity, but are not as beautifully regular as the text-book examples.

This paper describes ongoing work aimed at the construction of formal cost models and analyses that are capable of producing verifiable guarantees of resource usage (space, time and ultimately power consumption) in the context of real-time embedded systems. Our work is conducted in terms of the domain-specific language Hume, a language that combines functional programming for computations with finite-state automata for specifying reactive systems. We describe an approach in which high-level information derived from source-code analysis can be combined with worst-case execution time information obtained from abstract interpretation of low-level binary code. This abstract interpretation on the machine-code level is capable of dealing with complex architectural effects including cache and pipeline properties in an accurate way. It has been applied to several large-scale commercial safety-critical systems, including the flight control system for the Airbus A380. 1

In property-based formal verification, a natural question that often arises is 'Have we specified enough properties?' In this paper, we provide a way of approximating an answer to this question. We present a relatively cheap analysis that, given the interface of a design under verification, plus a formal safety property list, identifies cases where some outputs of the design are not constrained at all by the properties. For practical reasons, we also provide an easy way for the verification engineer to explicitly state that certain outputs are allowed to be underconstrained.

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.

1 Introduction There are two essentially different ways of describing hardware. One way is structural description, where the designer indicates what components should be used and how they should be connected. Designing hardware at the structural level can be rather tedious and time consuming. Sometimes, one affords to exchange speed or size of a circuit for the ability to design a circuit by describing its behaviour at a higher level of abstraction which can then be automatically compiled down to structural hardware. This way of describing circuits is usually called synthesisable behavioural description. Examples of behavioural languages that can be synthesised are Esterel [1], Occam [7], SAFL [8], and even the traditional hardware design languages such as Verilog and VHDL include a behavioural description language. Teaching hardware synthesis techniques to students can be quite problematic. As in teaching compilation techniques, one has to choose between one of two avenues: either plough through the theory and techniques, hoping the students are sufficiently mature and motivated to explore the ideas, and risking that a number of fine points of the synthesis procedures are lost since the students would have no means of trying variations (and see why they do not work so well), or implement a simple synthesis tool as the course goes on which allows students to experiment with alternative solutions, add new constructs, etc. The latter is obviously desirable, but leads to a lot of lecture time dedicated to going through the implementation, and a lot of student time to understand the fine points in the implementation to be able to change, and enrich it.

Abstract Algebraic verification techniques manipulate the structure of a circuit while preserving its behavior. Algorithmic verification techniques verify properties about the behavior of a circuit. These two techniques have complementary strengths: algebraic techniques are largely independent of the size of the state space, and algorithmic techniques are highly automated. It is desirable to exploit both in the same verification. However, algebraic techniques often use stream-based models of circuits, while algorithmic techniques use state-based models. We prove the consistency of stream- and state-based interpretations of circuit models, and show how stream-based verification results can be used hand-in-hand with state-based verification results. Our approach allows us to combine stream-based algebraic rewriting and state-based reasoning, using SMV and SVC, to verify a pipelined microarchitecture with speculative execution. 1 Introduction Hardware verification techniques can be broadly grouped into those that reason about both the behavior and structure of circuits, and those that reason just about the behavior. Algebraic techniques, such as retiming (e.g., [29,18]), manipulate the structure of the circuit while preserving its behavior. They have the advantage of being largely independent of the size of the state space. Algebraic techniques often manipulate stream-based models of circuits, i.e., they treat circuits as functions (streams of values). Algorithmic verification techniques, such as model checking [10,30], verify properties about the behavior of a state-based model, i.e., a state transition system, and have the advantage of being highly automated. In this work, we bridge the gap between these two forms of models by proving that verification results in the stream-based world correspond to correctness criteria of state-based models. We use O'Donnell's method to provide both streamand state-based interpretations of circuit descriptions [24]. We use the notation f[\Delta]g for the stream-based interpretation, and [[\Delta]] for the state-based interpretation.