Design Understanding with Fast Prototyping from

Design Understanding with Fast Prototyping from Assertions Katell Morin-Allory, Fatemeh (Negin) Javaheri and Dominique Borrione Univ. Grenoble Alpes, TIMA Laboratory, F-38031 Grenoble CNRS, TIMA Laboratory, F-38031 Grenoble [email protected]

Abstract—Asserted declarative properties are usually intended for design verification, using simulation or model checking. This paper presents a new tool that is able to generate synthesizable models from assertions, in an efficient and scalable way. This tool allows to investigate a design response to test cases, and to check one’s understanding without the need to develop complex and time consuming environment benchmarks. Index Terms—PSL, assertion-based design, automatic synthesis, fast prototyping.

I. I NTRODUCTION In the context of assertion-based design [1], properties about the behavior of a component (Assertions) or its environment (Assumptions) specify the input-output functional characteristics of the modules and the communications between system parts. Once refined down to the register transfer level (RTL), a complete set of assertions unambiguously characterizes how a module reacts to signals sent to it, logically and temporally. It is thus a natural idea to automatically produce verification IP’s from assertions to check the design correctness, either by simulation or emulation. A large variety of tools are now available to compile assertions into monitors that are connected to the system modules, and check if the properties are violated (see [2] for an overview). Monitors observe the operands of the assertions, and output the truth value of the property. All the operand variables are inputs of the monitor. A more recent view point considers the direct production of compliant (control and communication) modules from a set of assertions. A property is seen as the specification of the module to be designed. The objective is then to directly produce the synthesizable RTL design from its assertions. This is what we call fast prototyping from assertions (FPA). We call reactant the module that results from FPA. A reactant may be used to replace a non available module by a fast prototype of it, to check a more comprehensive design; it may also replace the (complex) environment of a designed module by a fast prototype of just the part of the environment that interacts with it. Contrary to monitors, reactants input some of the operands variables of the assertions, and output other variables, or some of the same variables at a future time point. They react to waveforms on their inputs and produce waveforms on their outputs, in compliance with the assertions. Although not really a new idea, FPA has not yet delivered production quality automatic tools. It is not expected to

automate the traditional design flow in a near future. However, thanks to recent advances, new applications of the method can be considered. • Communication between the design and the verification engineers. Few designers are comfortable writing temporal declarative assertions. Conversely, conventional HDL’s are considered too wordy and clumsy for who wants to reason and prove a design correct. Whether preparing a library of general purpose verification IP’s, or writing properties for a particular design, the verification engineer has to make sure the assertions correctly capture the behavioral specification provided to him/her. Automatically generating one or several compliant reactants that can be simulated is a solution for the verification engineer to exhibits his/her understanding to the design engineer. • Understanding someone else’s (white box) design. Whether in charge of reading another designer’s code for verification purposes, or needing to modify an existing design, fully understanding a large HDL model is a formidable task. Simulation certainly comes to the rescue, but tools do not easily allow to prepare test benches that react to the internal events of the design. In order to answer the many ”what if...?” questions about the design behavior, the designer must prepare, debug, and scrutinize the resulting waveforms for all the scenarios. Assertions for all these scenarios are much faster to write. Compiling assertions into reactants, and checking the compliance of the reactant behavior with the design, either by dynamic simulation or formal bi-simulation, is an elegant and efficient alternative. The adoption of these new uses of assertion based design requires: • a fast and scalable reactant generator from assertions, • producing reasonably small reactants . We believe the second version of our SyntHorus FPA tool fulfills these requirements. A. State of the art Most of the early works are based on either language theory [3]–[5] or automata theory [6]–[9], and suffer from the combinational explosion of the recognizer/automaton internal representation. More recently, the specifications have been written in a a synthesizable subset of a standard assertion language, PSL

[10] or SVA [11]. For instance, a “Generalized Reactivity(1)” subset of PSL was defined in [12], from which properties are translated to automata; improved algorithms were implemented in the tool Acaccia [13]. Other closely related approaches can be found in [14], [15]. The recent works formalize the synthesis as a two-player game between the environment (that provides the inputs) and the system that responds on its outputs [13], [16], [17]. The specifications are realizable if the system can always win the game.

interacts with the senders and receivers through a 4-phase handshake protocol. Signals take a default value 0. For reasons of space, we only look at the specification of the signals exchanged between GenBuf and senders S0 and S1 . The properties of Fig. 2, limited in the text to their first two discriminating letters, have the following meaning: • •

B. SyntHorus2 Our FPA method starts from properties written in the simple subset of PSL formulas within the subset can be interpreted forward along an execution path: simulation, emulation, test cases generation etc. In contrast to the previous works, our method is modular: it is based on the interconnection of elementary library modules for the operators of the property, according to the syntactic structure of the property, a technology that we initially introduced to compile assertions into monitors [18]. Two benchmarks have been used in the literature [19], [20] to illustrate FPA on realistic size circuits: the AMBA AHB bus, and the Generalized Buffer. We have executed SyntHorus2 and the tools that we could install on these benchmarks and on the same computer. For the purpose of FPA alone, SyntHorus2 performs better. The rest of this article is organized as follows: Section 2 presents the subset of the Generalized Buffer used as running example; Section 3 recalls the principles of the modular synthesis of reactants; Section 4 exposes the need for signal resolution and explains the construction of solvers; Section 5 reviews related works and analyses some practical results; Section 6 concludes the paper.

• • • •

P1: Once low, the acknowledge to S0 remains low as long as S0 sends no request. P2: Once high, the acknowledge to S0 remains high as long as S0 keeps its request high. P3: A new request may be raised by S0 only if its the acknowledge signal is low. P4: At most one acknowledge signal is high. P5: If signal ENQ is high, at least one acknowledge signal is high. P6: If signal ENQ is low, all acknowledge signals must be low.

Analogous properties P1 and P2 exist for sender S1 . III. R EACTANT S YNTHESIS Each property written in the specification of GenBuf defines a piece of the circuit behavior, for which some signals are considered inputs (they are observed or monitored), and some signals are outputs (they are generated). For instance, in Property P2, BtoS ACK 0 is both an input and an output, and StoB REQ 0 is an input signal. The reactant synthesis for P2 is the automatic production of a RTL design that conforms to the property. It is based on a library of primitive components, and an interconnection scheme directed by the abstract syntax tree of the property. We reuse the principles described in [18].

II. RUNNING E XAMPLE : G ENERALIZED B UFFER A. IBM Generalized Buffer [21]

A. Primitive Library Elements

The generalized buffer GenBuf is an arbiter that sequentializes requests coming from nbsend senders, and transmits them one at a time to nbrec receivers (nbsend and nbrec are generic parameters). A FIFO stores the incoming data waiting to be sent to the receivers. A controller communicates with all the modules and the FIFO: it enforces a round-robin selection policy, both on the senders and receivers side, it blocks the senders when the FIFO is full, and blocks the receivers when the FIFO is empty. Fig. 1 displays the system architecture and the communication interface control signals. • From each sender Si , GenBuf receives a request input StoB REQ i and replies with an acknowledge output BtoS ACK i. • To each receiver Rj , GenBuf outputs a request BtoR REQ j and gets an acknowledge RtoB ACK j . • GenBuf gets the FULL and EMPTY signals from the FIFO and provides the ENQ, DEQ, and SLC signals for writing (reading) appropriate data to (from) the FIFO. The complete set of properties that specify the GenBuf controller (the pink box in Fig. 1) are taken from [12]. GenBuf

A primitive elementary reactant has been defined for each PSL temporal operator. All these IP’s have a common interface depicted on the left side of Fig. 3. The control inputs are the two synchronization signals Clk and Reset n, and a Start activation signal. The output Trigger is intended to be connected to the Start input of a successive IP, and Pending has a meaning that depends on the operator. The input cond is connected to the signal being observed. When an output signal or expression needs to be generated, the reactant IP triggers a Signal IP (right side of Fig. 3) that outputs the signal value Value sig and its associated validity control Gen sig instead of Trigger and Pending. B. Construction of a Property Reactant The reactant for a property has a generic interface taking as inputs the observed and synchronization signals, and providing on its outputs the generated signals. For instance, Fig. 4 shows the result for property P2. The reactant for a property is built in three main steps.

StoR_ACK_0

StoB_REQ_0

StoB_REQ_i

RtoS_REQ_0

(automatically generated by Synthorus2)

receiver#0

StoR_ACK_i

receiver#i

DEQ

BtoR_REQ_i

ENQ

BtoS_ACK_i

FULL

sender#i

GenBuf Controller

BtoS_ACK_0

EMPTY

sender#0

FIFO Fig. 1.

GenBuf circuit interface

P1 no ack without req 0 : a l w a y s ( ( n o t BtoS ACK 0 ) and ( n o t StoB REQ 0 ) −> n e x t ! ( n o t BtoS ACK 0 ) ) ; P2 keep ack 0 : a l w a y s ( ( BtoS ACK 0 and StoB REQ 0 ) −> n e x t ! ( BtoS ACK 0 ) ) ; P3 ack after req : a l w a y s ( r o s e ( StoB REQ 0 ) −> n o t BtoS ACK 0 ) ; P4 one sender : a l w a y s ( n o t BtoS ACK 0 or n o t BtoS ACK 1 ) ; P5 gen ack : a l w a y s (ENQ −> BtoS ACK 0 or BtoS ACK 1 ) ; P6 gen not ack : a l w a y s ( n o t ENQ −> n o t BtoS ACK 0 and n o t BtoS ACK 1 ) ; Fig. 2. Reactant

Signal

Clk Reset_n Start

Clk CONTROL

Reset_n Start

Trigger [Cond]

PSL Specification of GenBuf communication with sender #0

EVALUATION GENERATION

Fig. 3.

[Pending]

CONTROL

Value_sig

[Cond] GENERATION

Gen_sig

Architectures and Interfaces for the verification IPs

Fig. 4.

Reactant Architectures for P1

1) Construction of the property abstract syntax tree: This is a classical binary non directed tree AST: the leaves are the design variables, that may be observed or generated; the other nodes are the temporal operators, for which one library IP is selected, and the logical operators. We denote AST = (V, E), where: •

V is the set of nodes (or vertices) of the tree. L is the set

of leaves (the operands of the property), and N = V \ L is the set of internal nodes (the operators). • E ⊂ V × V is the set of edges of AST. (v1 − v2 ) denotes an edge between two nodes v1 and v2 ; v1 is the parent and v2 is a child. Three partial functions defined on V : P(v), Lch(v), Rch(v) return the parent, the left child and the right child of node v. 2) Construction of the directed abstract syntax tree: For each PSL operator, one or more dependency rules have been defined between its operands, in accordance with the formal semantics of the operator (see [22]). In order to determine which variables are read by a property, and which are generated, the translator makes use of • the input/output direction of the module interface signals, • the implementation of the dependency rules as a direction between the node for an operator and its children. Let DAST= (V, E 0 ) be the Directed Abstract Syntax Tree of AST. Each edge in E 0 is a directed edge of E. Let v denote the sub-property extracted from node v in DAST and l denote the Boolean expression of a leaf l. • A down edge from a parent to its child (P(v) → v) means that v is constrained to a definite value (0 or 1), and thus generated, when the trigger signal of its parent is asserted. • An up edge to a parent from its child (P(v) ← v) means that the value of v is not constrained by its parent. If v

always

always

or

ENQ

and

next!

not

not

StoB_REQ_0

BtoS_ACK_0

BtoS_ACK_0

not

Fig. 6.

Fig. 5.

BtoS_ACK_1

the directed abstract syntax tree of P5 gen ack

BtoS_ACK_0

the directed abstract syntax tree of P1

is a leaf it will be observed, otherwise this ingoing edge needs to be propagated to v from all its children. • If there is a directed path between the two children of a node v, e.g. Lch(v) → v → Rch(v), the value of the left child constrains the value of the right child. The direction of an edge is built recursively according to the parent operator direction set. When the two directions may occur, the edges are marked unsettled (denoted with dash arrows). A node is unsettled if the edges to both its children are unsettled. When a node is unsettled, all its subtree is unsettled. Conversely, when a node is settled, the path from the node to the root is settled. Fig. 5 illustrates the DAST of property P1. 3) Construction of the property reactant: When the DAST for a property is fully settled, the reactant can be directly generated (the opposite case is discussed in section IV-A). In the DAST, each non-terminal node is replaced by a fresh instance of the primitive reactant (for a temporal operator) or logic gate (for a Boolean operator) interconnected to its children. For a logic gate, the interconnection is obvious. For a primitive reactant: • if the direction is (P(v) → v), the Trigger output of P(v) is connected to the Start input of v. • if the direction is (P(v) ← v), the observed signal (for a leaf) or the Trigger output of v (for an internal node) is connected to the cond input of P(v). All primitive reactant instances are connected to the same master Clk and Reset n signals. Non connected cond inputs are tied to ground. IV. R ESOLVING U NSETTLED S IGNALS A. Unsettled Signal Directions Figures 5 and 6 show the DAST for properties P1 and P5. In the P1 DAST, all the edges are settled, thanks to the direction of StoB REQ 0, and the dependency rules of operators ⇒ and next!. For the reactant of P1, it can be decided that the first occurrence of signal BtoS ACK 0 is read, and the second one is generated.

In contrast, the P5 DAST is unsettled, which is shown by the dotted lines between node or and its two children. This is due to the fact that several dependency rules apply for operator or. Intuitively, Property P5 states that whenever the ENQ signal is 1, there should be an acknowledgement to a sender, but is does not say which sender. Considering Property P5 in isolation cannot suffice to decide which of BtoS ACK 0 and BtoS ACK 1 must be generated. All the properties that generate these signals must be considered together. B. Constraints computed from UNSETTLED We partition the set of property DASTs into • •

SETTLED: the set of fully settled DASTs UNSETTLED: the set of DASTs that hold at least some unsettled edges.

In the example of Fig. 2, SETTLED = {P 1, P 2, P 3, P 6} and UNSETTLED = {P 4, P 5}. For each DAST of SETTLED, the reactant is built as in Section III-B. For each DAST of UNSETTLED, the unsettled subtrees are pruned, and the reactant is built likewise. We denote Etrigj the output trigger signal of the reactant, and Exprj the Boolean expression represented by the pruned subtree. Let (Z1 , . . . , Zn ) be the vector made of the n operands of the expressions Expr1 , . . . , Exprm triggered by Etrig1 , . . . , Etrigm . The problem is to solve the following set of equations, i.e. the values of (Z1 , . . . , Zn )  .    .. Etrigi → Expri (Z1 , . . . , Zn ) = 1    .. . Using ABC [23], we translate the set of equations into a combinational circuit, a solver whose inputs are Etrig1 , . . . , Etrigm and whose outputs are Z1 , . . . , Zn and their negations ZN1 , . . . , ZNn . Figure 7 shows the interconnection of all the reactants with a solver for the resolution of signal BtoS ACK 0 .

•

•

•

Fig. 7.

Interconnection of reactants with a solver

V. P RACTICAL EXPERIMENTS SyntHorus2 implements the FPA method disclosed in sections III and IV. It takes as input the entity (interface) declaration of the specified module and a set of properties written in the simple subset of PSL, and produces a RTL design in the synthesizable subset of VHDL. Since our approach is so different from the “two players game” advocated by most authors who tackled the FPA problem, it is of interest to evaluate how it compares on a set of benchmarks of increasing complexity. We have installed SyntHorus2 and Ratsy on a workstation with the following characteristics: 64 bit Intel Core 2 Duo CPU E8400, clock rate 3.0GHz, RAM size 2 giga bytes. After execution, the result of all tools has been synthesized with ABC, to allow a fair comparison in terms of logic gates. Ratsy [24], [25] is an update of Rat, which contains the Lily and Anzu previous tools of the same research group. Ratsy inputs GR(1) PSL properties and produces a Verilog design. Also based on game theory, in this system the environment player moves first. Ratsy checks every input, and the properties must be partitioned into a guarantee and an assume part. We had to rewrite our specifications between Ratsy and SyntHorus2, because the GR(1) PSL subset does not accept operators rose, fell, and next event with a temporal expression operand nor any weak PSL operator. Tables I to III give the results of our experiments with SyntHorus2and Ratsy. For each tool, we provide the number of properties used for the circuit synthesis, the number of gates generated by ABC for the combinational part, the number of registers generated by the tool, and the execution time of the tool. The ABC execution time is not reported in the tables, it is insignificant. Table I gives the figures for the GenBuf specifications with FIFO, for two receivers and varying numbers of senders. Tables II and III summarize the experiments on the GenBuf specifications, with and without FIFO, for different numbers of receivers and two senders. The following comments can be made on these tables: • The number of properties used to generate the design is higher for Ratsy than for SyntHorus2. This is due to the underlying method: game-based methods need to consider both the guarantee and the assume properties,

while the modular method of SyntHorus2 only takes the guarantee properties to produce the circuit design. As soon as the number of sender/receivers is greater than 3, the size of the combinational part (gates) of the generated circuit is smaller for SyntHorus2. The number of registers generated by SyntHorus2 is higher than by Ratsy. If we assume 6 logic gates/flipflop (which is high), the total circuit size is smaller for SyntHorus2 starting from 3 sender or 5 receivers. The circuit generation time is one to two orders of magnitude smaller for SyntHorus2 depending on the number of senders/receivers. The higher the number, the higher the order of magnitude. At this point, it is fair to say that SyntHorus2 does not perform verification, while Ratsy has verification embedded in the generation process. Thus, comparing the runtimes of the two tools is not relevant for who wants to perform verification.

VI. C ONCLUSION In this paper, we have presented a modular technique to generate synthesizable circuit designs from formal specifications written in the simple subset of PSL. The prototype tool SyntHorus2 compiles several dozens properties in seconds, and produces a reasonably sized RTL circuit model that complies with the specified behavior. The efficiency of the method allows to experiment with the produced model, and integrate it with a design to be analyzed or understood, for emulation, simulation or formal verification purposes. The use of SyntHorus2 for design understanding can be seen in two very different ways: • By the verification engineer: to debug a manually written functional specification of the design, and verify if it is consistent and complete. SyntHorus2 processes the specification; then assertions on the trigger signals identified in section III can be written and be either verified on the fly by a simulator, or model checked with another tool. • By the design engineer: to provide an environment (test bench) for testing specific features of the design. SyntHorus2 fastly produces a reactive test generator to be interconnected with the module of interest. Currently, SyntHorus2 only processes scalar Boolean properties. Future works include the recognition of more complex data types, such as vectors and enumerated types. R EFERENCES [1] H. Foster, . Krolnik, and D. Lacey, Assertion-Based Design. Kluwer Academic Publishers, Jun. 2003. [2] M. Boule and Z. Zilic, Generating Hardware Assertion Checkers. Springer, 2008. [3] R.-W. Floyd and J. D. Ullman, “The compilation of regular expressions into integrated circuits,” J. ACM, vol. 29, no. 3, pp. 603–622, 1982. [4] A. Seawright and F. Brewer, “Clairvoyant: A synthesis system for production-based specification,” IEEE TVLSI, pp. 172–185, Jun 1994. ¨ [5] J. Oberg, “Program : A grammar-based method for specification and hardware synthesis of communication protocols,” Ph.D. dissertation, KTH, Sweden, 1999. [6] H. T. M. Fujita, S. Kono and T. Moto-oka, “Tokio: Logic programming language based on temporal logic and its compilation to prolog,” in Third Internat. Conf. on Logic Programming, vol. Lecture Notes in Computer Science 225. Springer, 1986, pp. 695–709.

TABLE I G EN B UF CONTROLLER WITH FIFO, FOR DIFFERENT NUMBERS OF SENDERS

SYNTHESIS RESULT FOR

#send 1 2 3 4 5 6 7 8

#prop. 20 25 29 33 37 41 45 49

SYNTHESIS RESULT FOR

#rec 2 3 4 5 6 7 8

#rec 2 3 4 5 6 7 8

time 0.16 0.30 0.32 0.33 0.37 0.51 1.14 2.14

#prop. 41 49 59 67 76 85 99 103

RATSY #gates #reg. 227 16 224 20 3105 25 4556 29 3871 33 8195 38 9328 42 8804 46

time