A Prototype Embedding of Bluespec Systemverilog in the PVS Theorem Prover Dominic Richards and David Lester the University of Manchester Manchester, U.K
Total Page:16
File Type:pdf, Size:1020Kb
https://ntrs.nasa.gov/search.jsp?R=20100018540 2019-08-29T19:03:36+00:00Z View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by NASA Technical Reports Server A Prototype Embedding of Bluespec SystemVerilog in the PVS Theorem Prover Dominic Richards and David Lester The University of Manchester Manchester, U.K. [email protected], [email protected] Abstract Bluespec SystemVerilog (BSV) is a Hardware Description Language based on the guarded action model of concurrency. It has an elegant semantics, which makes it well suited for formal reasoning. To date, a number of BSV designs have been verified with hand proofs, but little work has been conducted on the application of automated reasoning. We present a prototype shallow embedding of BSV in the PVS theorem prover. Our embedding is compatible with the PVS model checker, which can automatically prove an important class of theorems, and can also be used in conjunction with the powerful proof strategies of PVS to verify a broader class of properties than can be achieved with model checking alone. 1 Introduction Bluespec SystemVerilog (BSV) [Nik04] is a language for high-level hardware design, and produces hard- ware that’s competitive with hand-written Register Transfer Level designs in terms of time and area for many applications [WNRD04, Nik04]. It developed from research using Term Rewriting Systems (TRS) to produce hardware specifications that could be synthesised and formally verified [AS99]; in common with TRS, BSV is semantically elegant, which makes it well suited for formal reasoning [ADK08]. However, only one previous investigation has been made into the mechanised verification of BSV de- signs [SS08], which concentrated on direct model checking of BSV designs in the SPIN model checker [Hol03], without the capacity for interactive reasoning or abstraction. In this paper we present a prototype shallow embedding of BSV in the PVS theorem prover [ORS92]. Our embedding is compatible with the PVS model checker [ORR+96], which can automatically prove an important class of theorems. Furthermore, the PVS model checker can be used in combination with the powerful proof strategies of PVS to verify a far broader class of properties than can be achieved with model checking alone. We use a novel application of monads to capture the complex state-encapsulation mechanisms of BSV in a concise and readable way. Our embedding supports several advanced language features of BSV, including module instantiation, side-effecting methods and rule composition from side-effecting methods. In this work we present an embedding strategy: we have yet to build a BSV-to-PVS compiler, which will be developed in conjunction with our related research into automated abstraction of BSV designs. The material in this paper is presented at length in the principal author’s PhD thesis [Ric10a], and the associated code is available online [Ric10b]. Throughout the paper we present code fragments in BSV and PVS; to make the difference clear, all BSV code is presented in Courier font and surrounded by frames labeled ‘BSV’. All PVS code is presented in Times New Roman, without surrounding frames. 2 Bluespec SystemVerilog BSV is a language for high-level hardware design. For an in-depth introduction, see the online lecture series at [Blu]. In BSV, hardware is specified in terms of ‘modules’ that associate elements of state with Proceedings of NFM 2010, April 13-15, 2010, Washington D.C., USA. 139 A Prototype Embedding of Bluespec SystemVerilog in PVS Richards and Lester ‘rules’ (guarded actions) that transform the state and ‘methods’ that can be called by other modules to return values from the state, and possibly transform it in the process. A simple example of a module is Reg, which specifies a register with one element of state, no internal rules and two methods, _read and _write. Other modules can create instances of Reg, and use the methods _read and _write in their own rules and methods. For example, the following rule uses two registers, request and acknowledge, both of which hold elements of type Bool1: rule request_rl (!(request._read() || acknowledge._read())); request._write(True); endrule BSV The rule has a guard, which is a predicate on the state of the registers, and an ‘action’, which transforms the state of the request register. In general, a rule has the form: rule my_rule (rl_guard); statement_1; statement_2; ... endrule BSV The statements in the rule body are individual actions that transform the state in some way. The set of statements are applied in parallel to the state; each statement is applied to the state as it was immediately before the rule was activated, so that the changes made by statement_1 aren’t seen by statement_2, or any other statement. The BSV compiler ensures that the statements in a rule don’t conflict with each other by simultaneously attempting to write to the same elements of state. 3 The Challenges of Embedding BSV in PVS BSV uses guarded actions to express concurrency, which makes it similar to the guarded action lan- guages that were developed for the formal study of concurrency; these include UNITY [CM88], Promela [Hol03], the SAL language [dMOR+04] and the model checkable subset of the PVS language [ORR+96]. There is a rich body of literature on the use of model checkers and, to a lesser extent, theorem provers for verifying systems expressed in these languages. However, BVS is a more complex language in some respects, being intended for hardware design rather than abstract specification: 1. Complex encapsulation of state. As seen in 2, BSV has a ‘module’ construct that allows el- § ements of state to be associated with ‘rules’ and ‘methods’. Rules can be composed from the methods provided by other modules; in this way, the execution of a rule in one module can alter the state in another. 2. Widespread presence of data paths. Model checking is a useful tool for efficiently verifying finite state concurrent systems, but can be confounded by the presence of data paths (circuits that hold elements of data). Data paths can have very large state spaces, which can cause state space explosions in model checkers; for this reason, model checking has been more widely used to verify control-based systems. When abstract specification languages such as UNITY are used for hardware verification, a model can be constructed that only specifies the control-based components 1BSV users will notice that we’ve de-sugared the method calls for Regs; we do this throughout the paper to simplify the semantics, and also to emphasize the use of methods inside rules. Proceedings of NFM 2010, April 13-15, 2010, Washington D.C., USA. 140 A Prototype Embedding of Bluespec SystemVerilog in PVS Richards and Lester of a design (when the data path is irrelevant to the properties being verified), or specifies some abstract interpretation of the data path. With an embedding of BSV, however, the hardware design is the specification; we can’t chose to omit data paths from our formal model. Because of this, we must find a tractable way to abstract away from data path complexity within our proof environment. So, in order to produce a usable general purpose embedding of BSV in a formal guarded action language, we must first bridge the semantic gap by expressing the constructs of BSV with the more limited constructs of our target specification language, preferably in such a way that equivalence between the two can easily be established [CDH+00]. When we have achieved this, we must also bridge the abstraction gap, to obtain abstract specifications that can be efficiently verified [SS99, CDH+00]. In this paper we concentrate on the first of these two steps. We offer an embedding strategy that bridges the semantic gap between BSV and the model checkable subset of PVS with a novel use of mon- ads [Bir98]. In further work, we hope to employ automatic abstraction [SS99] to our PVS specifications in order to bridge the abstraction gap. We actually introduce two embedding strategies with different strengths and weaknesses, and com- bine them in a hybrid technique that preserves the strengths of both. In 5 we introduce an embedding § strategy that we call ‘primitive embedding’, where we specify BSV modules with ‘primitive transition relations’. Primitive transition relations can be efficiently model checked, but bear little resemblance to the BSV modules they represent, and we discuss the problems that this creates. In 6 we introduce an § embedding strategy that we call ‘monadic embedding’, where we specify BSV modules with ‘monadic transition relations’. Monadic transition relations are syntactically similar to the BSV modules they rep- resent, which cleanly bridges the semantic gap. However, verification is demanding in terms of CPU time. We go on to introduce a hybrid technique that allows us to perform proofs over monadic tran- sition relations with the efficiency normally associated with proofs over primitive transition relations. We demonstrate the practical applicability of our approach in 7 with a hand embedding of a BSV fair § arbiter, for which we verify deadlock freedom, mutual exclusion and fairness properties. 4 The Semantics of a BSV Module The behavior of a BSV module can be understood in terms of a simple semantics called Term Rewriting System (TRS) semantics, also called ‘one-rule-at-a-time’ semantics. According to TRS semantics, a module evolves from a given state by choosing one rule for which the guard is true and applying the associated action to transform the state. If more than one guard is true, a nondeterministic choice is made. When actual hardware is generated from BSV designs, a number of optimisations are applied (for example, a clock is introduced and multiple rules are executed per clock cycle) but the behavior is guaranteed to comply with the TRS semantics.