TIMA Lab. Research Reports

Transcription

1 ISSN TIMA Lab. Research Reports A Model for Assertion-Based Verification of TLM Designs Laurence PIERRE ISRN: TIMA-RR--07/ FR TIMA Laboratory 46 Av. Félix Viallet, Grenoble cedex, France

2 A Model for Assertion-Based Verification of TLM Designs Laurence PIERRE TIMA (CNRS-INPG-UJF) - 46 Av. Félix Viallet Grenoble cedex - France Laurence.Pierre@imag.fr Septembre 2007 Abstract This report addresses assertion-based verification (ABV) and proposes a model for supervising semi-formal verification of temporal properties of TLM (transaction level modeling) descriptions. This modeling level of the SystemC language emphasizes the transactions (communications) in a SoC, considered at a very high level of abstraction. We define an observer-based model that can be used during simulation to monitor expected properties regarding communications, expressed in a specification language like PSL. The TLM descriptions can be timed or not, and the properties can involve several channels, of different types. Résumé Ce rapport a pour objet l'assertion-based Verification (ABV), et propose un modèle pour permettre et contrôler la validation semi-formelle de propriétés temporelles de descriptions TLM (transaction level modeling). Ce niveau de modélisation du langage SystemC met l'accent sur les transactions (communications) dans un SoC, considérées à un très haut niveau d'abstraction. Nous définissons un modèle de type observateur qui peut être utilisé en cours de simulation pour surveiller des propriétés attendues des communications, exprimées dans un langage tel que PSL. Les descriptions TLM peuvent être temporisées ou pas, et les propriétés peuvent mettre en jeu plusieurs canaux de communication, de types différents. 1

3 A Model for Assertion-Based Verification of TLM Designs Laurence PIERRE TIMA (CNRS-INPG-UJF) - 46 Av. Félix Viallet Grenoble cedex - France Laurence.Pierre@imag.fr I. INTRODUCTION With the growing complexity of SoC's, verification is becoming a crucial task in the design cycle, and monopolizes a major portion of the development time [1], [2]. In that context, assertion-based verification (ABV) has widely gained acceptance [3], [1]. Assertions are used to specify logical and temporal properties that the design under development should satisfy. These assertions are commonly expressed in languages like PSL [4] and SVA [5]. They are checked using formal or semi-formal methods: formal techniques involve model-checkers (e.g. in the tools Incisive Formal Verifier of Cadence, or RuleBase of IBM) whereas semiformal approaches are based on simulation. For instance, the simulator ModelSim from Mentor Graphics allows to include PSL assertions in VHDL or Verilog descriptions and to check their validity during simulation. The tool FoCs from IBM generates checkers from PSL assertions under the form of RTL processes in VHDL, Verilog, or SystemC [6]. These checkers can be used to monitor the simulation. Currently available ABV tools can deal with synchronized VHDL or Verilog descriptions written at the RT level. Even if efforts in that direction have recently been reported, none of them is actually able to reason on real-size specifications made at the Transaction Modeling Level (TLM) of SystemC. Implemented as an extension of C++, SystemC provides a library of classes for modeling SoC's [7]. It offers various levels of accuracy [8]: structural, timing, functional, TLM is a modeling level of SystemC, to describe characteristics of the design at a much more abstract level than RTL. It provides communication models for complex data types ("transactions'') between IP's or circuits. Designers can thus easily and quickly develop early specifications, and dramatically improve simulation performance. As mentioned in [9], TLM is increasingly being adopted for the design of complex systems, and has become the basis of advanced verification. The need for methodologies adapted to ABV of TLM specifications is consequently compelling. The highest level of abstraction, TLM PV (programmer's view), is an algorithmic level in which communications are implemented as function calls. This level does not encompass timing information. Classical model-checking or monitoring tools are based on a discrete time model (that corresponds to clock edges) inherent to the RT level, and nonexistent at the TLM level (PV and even PVT i.e., timed). Hence these tools are not directly applicable, and new methods are needed. In this report, we propose a model that takes advantage of the object-oriented features of the SystemC language. It is based on the notion of observer pattern, and is directly implementable in SystemC. It actually fulfils the requirements of the TLM level, it can deal with timed or untimed descriptions and can be used to monitor properties that involve several channels, of different types. We will show that existing methods can be adapted to TLM descriptions through this model: either the compositional technique developed in our team [10], [11], or the automata-based monitor generation of the FoCs tool. 2

4 II. STATE OF THE ART An early approach to the verification of temporal properties for SystemC [12] was limited to RTL descriptions. In [13], SystemC designs are modeled using UML, and are transformed into Abstract State Machines (ASM). In general, building the whole FSM is not feasible and only a portion of the FSM is produced. Model-checking is performed w.r.t. PSL properties (Boolean and SERE expressions) that are extracted from the UML sequence diagrams and also expressed in ASM. Optionally, the SystemC model is generated, and the properties are translated in C#. Then assertion-based verification can be performed at this level. Reported results are restricted to synchronized (clocked) descriptions where communications are only operated through signals. The method of Moy et al [14] extracts architecture and behavioural information from a SystemC TLM design, performs abstractions and builds an intermediate model called HPIOM (for "Heterogeneous Parallel Input/Output Machines'' i.e., communicating parallel machines). This intermediate representation can be connected to model checkers like SMV, Lesar or NBac. Abstraction techniques are required to get tractable models, nevertheless there are limitations in the size of the devices that can be treated. Assertions are not expressed using a specification language like PSL; only a small set of properties is mentioned (such that global deadlock never occurs, a process never terminates,...). In [15] SystemC models are translated into Petri nets, and model-checking of CTL properties is performed using the UPPAAL tool. Events and signals are represented by Petri nets, and the SystemC scheduler too. Each statement corresponds to one place and one transition. Method calls are also translated into this model. This approach is attractive but yields huge Petri nets (e.g. each signal gives rise to a sub-system of about 20 places and 12 transitions), even for rather moderate descriptions. Model-checking properties for a packet switch example, with 2 masters and 2 slaves, takes several hours of CPU time. The work of Lahbib [16], [17] uses FoCs for the translation of the PSL property in C++ [6] (a class is generated for each checker, a method transition implements the checker's transition function). Since there is no clock to trigger the executions of the monitors, this work makes use of specific channel classes: a channel can contain instance(s) of the checker(s), and during simulation the TLM method transport calls on the checker's function transition when a transaction is initiated. Like our method, this one wraps the checker in a structure that allows to control its triggering. However, enclosing the monitors inside the channels has strong limitations. Among them, several ports cannot be monitored simultaneously (i.e., the assertions cannot involve several channels), and it is impossible to deal with hybrid properties (i.e., properties that include both signals and TLM channels). The model we propose overcomes these limitations. In [18], a specialized language is defined. It extends SVA to explicitly express events. A possible implementation using proxies is mentioned (and more detailed in [19]). Our claim is that there is no need for defining a specific language. The PSL language, in particular its Temporal layer, is rich enough to express a large range of properties, even at the TLM level. To a certain extent, syntactic sugar could be considered, but new semantic constructs are not necessary. Various modalities (such as until, before, next_event,...) are present in the language and are given a trace semantics (a trace is an observation). At the synchronous RT level, the observation is made on the clock edges. Transposing the interpretation at the TLM level simply requires to identify the observation points at this level. We consider that observation points are when the property needs 3

5 to be re-evaluated i.e., each time a variable of the property has possibly been modified (an appropriate event occurs in the corresponding channel). This is the intrinsic concept of the approach described in section IV. Moreover, we show in section V how we take advantage of the fact that the Boolean layer of PSL is given the "flavor'' of the underlying language [4]. The underlying language here is C++, hence Boolean expressions can include calls to predicate functions. This is very useful to easily express conditions on channels. 4

6 III. A COMPOSITIONAL APPROACH AT THE RT LEVEL The observer model we present in the next section can easily be used to extend the capabilities of a tool like FoCs to TLM designs. However, the original goal of this work was to adapt to TLM the monitor construction method developed in our team, the main advantages of which are that it is compositional, efficient, and formally proven correct. Let us now briefly recall this method at the RT level [10], [11], which is the basis of our Horus environment. Thanks to a specialized interconnection technique, monitors are built compositionally from elementary components that correspond to the primitive PSL operators. More precisely, a monitor for a property P is built as a module that takes as inputs the reset, the synchronization clock, a signal Start that triggers the evaluation, and the signals of the design under verification that are operands of the PSL operators in P. The outputs have the following meaning: o Checking: a '1' indicates that output Valid is effective at the next synchronization time o Valid: provides the evaluation result ('1' means absence of error, '0' means error). The combined values of Checking and Valid indicate whether the property is inactive, currently being computed, or known and passed or failed. These combined values are useful for coverage. Primitive single operator monitors are interconnected to build complex monitors. The method is based on the syntax tree of the property. Roughly speaking, it works as follows: o for two operators N1 and N2 such that N2 is an operand of N1, the output Checking of N1 is fed to input Start of N2, the output Valid of N1 is useless and unconnected, and the clock and reset are shared by N1 and N2, o the primary outputs Checking and Valid are those of the rightmost PSL operator. Both the library of primitive components and the interconnection method have been formally proven correct using the PVS theorem prover [10]. Example 1. Here is the monitor obtained for the following property: always (A -> next![2] (B before! C)) Example 2. Section V will report a simple example of FIFO, and the following property will be considered: always ( (car = & ) -> next( (not (car = & )) until (car ) ) ) 5

7 i.e., each time a transfer is initiated from the sender to the receiver (the sender sends the starting character '&'), a new transfer is not initiated until this current transfer is finished (the sender sends the ending character '@'). The composite monitor for this property has the structure shown below. Its primary inputs include the boolean signals associated with the conditions (car = & ) and (car ). always impl next until valid checking We now explain how this methodology is extended to TLM. 6

8 IV. MONITORING ASSERTIONS FOR TLM DESIGNS IV.1 The Observer Model Here we are in a context where the designs under verification are described in SystemC, the level of description is transactional and there is no synchronization clock. We provide a solution for monitoring properties regarding communications i.e., properties associated with transactional events (for instance a given transfer eventually completes, data are transfered at the right place,...). We need a model that helps triggering the monitors (i.e., observing the properties) at appropriate instants. The concepts of this model are illustrated on Figure 1: the monitor(s) is (are) enclosed in a wrapper that observes some channels of the TLM description of the system under verification. These channels are the ones that are concerned by the property(ies) expressed by the monitor(s). The wrapper is in charge of activating the evaluation of the monitor(s). TLM System under verification observed channels Wrapper Monitor valid checking Figure 1. Link between the TLM system and the monitor(s) The UML diagram of the model we propose is depicted on Figure 2, it is inspired from the wellknown observer pattern [20]. Observer «abstract» + Update(Subject *, const void *) : void * Subject + Attach(Observer *) : void + Detach(Observer *) : void + NotifyObs(const void *) : void Wrapper «abstract» + Attach_Monitor(Monitor *) : void + Detach_Monitor(Monitor *) : void + Update_Monitors() : void * Monitor + update() : void Figure 2. A model for observing transactions 7

9 Basically, each monitor is enclosed in a wrapper that observes the channels and/or signals involved in the property of this monitor. These channels/signals are thus observable objects, or Subjects. Each wrapper (observer) can include a collection of monitors (it can register or unregister any monitor using the methods Attach_Monitor and Detach_Monitor). Similarly, each subject can have a collection of observers (it can register or unregister any observer, using the methods Attach and Detach). When a relevant event is raised, the subject runs its notifyobs method, the effect of which is that each observer receives a callback (called Update on the diagram), that receive as parameters information about the event that is occurring. The actual wrappers are sub-classes of the Wrapper class. In their own version of the Update function, they call on the Update_Monitors method of their parent class, the effect of which is to run the update function of each enclosed monitor (evaluation of the monitor). It suffices to declare the channels/signals involved in the asserted properties as sub-classes of Subject. They have to notify their observers each time a relevant event occurs (i.e., the property needs to be re-evaluated), by running the notifyobs method. We override the method that corresponds to the event as follows: its definition is identical to the inherited one and, in addition, it calls on the function notifyobs. Example. If the property concerns the values received by a consumer through a FIFO (we use the fifo example of the SystemC distribution), then the relevant events are the acquisitions of data by the consumer i.e., its calls to the method read of the FIFO. In that case the following class represents this observable FIFO: class fifo_obs : public fifo, public Subject { public: fifo_obs(sc_module_name name) : fifo(name) {} } }; void read(char &c){ fifo::read(c); NotifyObs(&c); IV.2 C++ Encoding for the Monitors // overriden method Let us describe the adaptation of the components presented in section III in that framework. We transform each primitive component into a SystemC class (more precisely a sub-class of Monitor) the main method of which is the update function. We have to remove the synchronization clock and to transform the description accordingly. Example. Here is our original VHDL description of the basic component for the implication operator: entity mnt_impl is port (clk, reset_n, start, cond, expr : in BIT; checking, valid : out BIT ); end mnt_impl; architecture monitor of mnt_impl is signal start_impl : BIT; signal valid_t : BIT := '1'; begin start_impl <= start and cond; evaluate_expr: process (clk) 8

10 begin if clk'event and clk='1' then if reset_n='0' or start_impl='0' then valid_t <= '1'; elsif expr = '1' then valid_t <= '1'; else valid_t <= '0'; end if; end if; end process; valid <= valid_t; checking <= start_impl; end monitor; The code has to be sequentialized, which is quite easy due to the linearity of all our primitive components. We use simple C++ variables (not signals), and the order in which the statements are written preserves the original evaluation order. The resulting SystemC components are not sensitive to any signal; instead their update method will be called when necessary as explained above. Example. Here is the SystemC counterpart of the implication operator: class mnt_impl : public Monitor { protected : bool reset_n, start, cond, expr, checking, valid, start_impl, valid_t; public : mnt_impl(const char *n) : Monitor(n) { valid_t = true; } void update() { start_impl = start && cond; if ((reset_n == false) (start_impl == false)) valid_t = true; else if (expr == true) valid_t = true; else valid_t = false; valid = valid_t; checking = start_impl; } }; In the VHDL description, valid_t is a clocked flip-flop, its value is modified on the clock rising edges but available only in the next simulation cycle (delta cycle). Each asynchronous modification of the input start or cond induces a re-evaluation of the value of start_impl. Since valid_t combinationaly depend on start_impl, its assignment has to be written after the one of start_impl. In the VHDL code, the availability of the new value for the output valid is delayed until the next clock tick, for synchronization reasons. Here we want it to be available in the current evaluation and then we put its assignment after the one of valid_t. To build elaborate monitors for complex properties, we keep the original interconnection method. Instances of the primitive components are translated as sub-classes of the ones described above. These sub-classes override the inherited update method to express the way components are interconnected: the update function of the rightmost component of the composite monitor is the one that is called by the Update_Monitors function of the wrapper. Thus this update method calls the update method of its neighbour, and so on, up to the leftmost one. 9

11 Example. Let us come back to the property always ( (car = & ) -> next( (not (car = & )) until (car ) ) ) The corresponding monitor is called mnt_checkfifo below. It contains an instance of each elementary monitor of the property. We can see that the update method of mnt_checkfifo calls on the update method of the until component (which is the rightmost one). Each component is in charge of calling the method of its neighbour prior to running its own method. Hence the overall property is evaluated. class mnt_checkfifo : public Monitor { public: mnt_checkfifo(const char *name) : Monitor(name) { impl = new mnt_impl_chkfifo("implic"); next = new mnt_next_chkfifo("next", 1); until = new mnt_until_chkfifo("until"); always = new mnt_always_chkfifo("always");... } void update() { expr_0 = (car == '&'); expr_1 =! (car == '&'); expr_2 = (car until->update(); valid = valid_i; checking = checking_i;... } }; Remark. Monitors generated by FoCs can also easily be plugged in this framework: we create a sub-class of Monitor and the update function of this class calls on the transition function produced by FoCs. 10

12 V. EXPERIMENTAL RESULTS Some examples have been used to demonstrate the effectiveness of this approach: 1) A producer sends messages to a consumer through a FIFO channel. The property under consideration is "a new transfer does not start until the previous one is completed'' (car is the character read in the FIFO, '&' and '@' are the starting and ending characters): always ( (car = & ) -> next( (not (car = & )) until (car ) ) ) Figure 3 depicts the link between the producer/consumer system and the monitor: here the property concerns the values received by the consumer. Hence the events to be observed are its calls to the method read of the FIFO, that is overriden in an appropriate observable sub-class (see the example of page 8). TLM System Sender FIFO Receiver Wrapper Monitor valid always impl next until checking Figure 3. Organization of example 1 2) Two producers send messages to a consumer, and they share a FIFO under the control of an arbiter. This system is depicted on Figure 4 (for property 2). TLM System Sender1 Sender2 ack1 Arbiter ack2 FIFO Receiver Wrapper Monitor always impl next_event valid checking Figure 4. Example 2 (property 2) 11

13 Property 1 is mutual exclusion (ack1 and ack2 are output signals of the arbiter): always ( not (ack1 and ack2) ) Property 2 involves both a signal and the FIFO channel: "each time the signal ack1 has a positive edge, then the first client will send its message'' i.e., the next character to be written in the FIFO will be the starting character of the first client (we assume that the two clients have distinct starting characters '&' and '!'): always ( (ack1.posedge()) -> next_event(fifo.iswritten())(car='&') ) Here we exploit the C++ flavor of the Boolean layer in our object-oriented model: predicate functions posedge and iswritten are given straightforward definitions in the observable sub-classes of sc_signal and fifo. The same experiments have been made with the FIFO of the SystemC distribution ("FIFO1'' hereinafter), and with the FIFO of the TLM distribution ("FIFO2'' hereinafter) where the FIFO size is 512 bytes. In the simulations reported in Table 1, the producers send 1000 messages of random length (between 1 and 1000 characters), and messages of random length (between 1 and characters). CPU times are taken on a Pentium 4 (1.8 GHz). We report CPU times for the simulations without monitoring, with monitoring using the Horus-based components and using the checkers generated by FoCs (V1.05 running under SunOS 5.9). No monitoring Horus FoCs FIFO msg, lg max s s s msg, lg max s s s FIFO1+arb, prop msg, lg max s s s msg, lg max s s s FIFO1+arb, prop msg, lg max s s s msg, lg max s s s FIFO msg, lg max s s s msg, lg max s s s FIFO2+arb, prop msg, lg max s s s msg, lg max s s s FIFO2+arb, prop msg, lg max s s s msg, lg max s s s Table 1. Simulation results Figure 5 gives a graphical view of the results in the case where the producers send messages of random length, between 1 and characters. 12

14 Simulation time (s) FIFO1 FIFO1+arb prop.1 FIFO1+arb prop.2 FIFO2 FIFO2+arb prop.1 FIFO2+arb prop.2 No monitoring 18,456 29,469 37,483 17,332 27,298 35,396 Horus 44,313 29,505 89,673 40,012 27,522 82,896 FoCs 115,8 29, , ,832 27, ,887 Figure 5. Graphical view of the simulation results 13

15 VI. CONCLUSION In this report, we provide a solution for monitoring properties regarding communications in SystemC TLM specifications. Let us compare the results of this work with the capabilities of FoCs. With regard to translating PSL properties in SystemC, FoCs works as follows: o the property is translated into a nondeterministic finite automaton, that is converted into an optimized deterministic automaton, o FoCs generates a C++ class for the property checker (a method transition of this class corresponds to the evaluation of the property each time a state transition occurs), and a wrapper (clock, control,...). The approach suits RTL descriptions of synchronous designs. Our technique has the following characteristics: o the monitor is generated from the property thanks to a method that simply interconnects the elementary monitors associated with the primitive operators of the property, o we also generate a C++ class for the monitor (a method update of this class corresponds to the evaluation of the property each time a notification by an observable subject occurs). An observer wraps the monitor, to activate this method when necessary. Hence our approach can suit TLM descriptions and does not require any synchronization clock. It is worth noticing that the function transition generated by FoCs is a counterpart of our function update of the global monitor. The methods that produce these functions are fundamentally different but the functions behave similarly. Therefore, checkers generated by FoCs can easily be plugged in our framework. However, the simulation results given in Section V clearly show that, except for the simple mutual exclusion property, the Horus-based monitors outperform the FoCs checkers. Our approach is also relevant in the case of more complex TLM architectures (for instance, subclasses of the initiator_port family can be created). Future works include establishing a link between this model and the upcoming TLM2.0 interfaces of the analysis_if family, and exploiting our different levels of monitors to relate TLM and RTL descriptions. ACKNOWLEDGEMENTS The author is grateful to Dominique Borrione and Luca Ferro for their fruitful comments. 14

16 REFERENCES [1] D. Maliniak, Assertion-Based Verification Smoothes The Road To IP Reuse, September [2] R. Dubey, Elements of Verification, SOC Central : White paper, March [3] A. Gupta, Assertion-based Verification Turns the Corner, IEEE Design & Test of Computers, vol. 19, no. 4, July [4] IEEE Std , IEEE Standard for Property Specification Language (PSL). IEEE, [5] IEEE Std , IEEE Standard for System Verilog: Unified Hardware Design, Specification and Verification Language. IEEE, [6] A. Dahan, D. Geist, L. Gluhovsky, D. Pidan, G. Shapir, Y. Wolfsthal, L. Benalycherif, R. Kamdem, and Y. Lahbib, Combining System Level Modeling with Assertion Based Verification, in Proc. ISQED [7] IEEE Std , IEEE Standard System C Language Reference Manual. IEEE, [8] T. Grötker, S. Liao, G. Martin, and S. Swan, System Design with SystemC. Kluwer Academic Pub., [9] M. Glasser, Applying Transaction-Level Models for Design and Testbenches, SOC Central, June [10] K. Morin-Allory and D. Borrione, Proven correct monitors from PSL specifications, in Proc. DATE 2006, [11] K. Morin-Allory and D. Borrione, On-line monitoring of properties built on regular expressions, in Proc. FDL 2006, [12] D. Große and R. Drechsler, Formal Verification of LTL Formulas for SystemC Designs, in Proc. ISCAS 2003, [13] A. Habibi and S. Tahar, Design for Verification of SystemC Transaction Level Models, in Proc. DATE 2005, [14] M. Moy, F. Maraninchi, and L. Maillet-Contoz, LusSy: an open tool for the analysis of systems-on-a-chip at the transaction level, Design Automation for Embedded Systems, [15] D. Karlsson, P. Eles, and Z. Peng, Formal Verification of SystemC Designs Using a Petri- Net Based Representation, in Proc. DATE [16] Y. Lahbib, Extension of Assertion-Based Verification Approaches for the Verification of SystemC SoC Models, Ph.D. dissertation, University of Monastir (Tunisia), [17] Y. Lahbib, A. Perrin, L. Maillet-Contoz, A. Clouard, F. Ghenassia, and R. Tourki, Enriching the Boolean and the Modeling Layers of PSL with SystemC and TLM Flavors, in Proc. FDL 2006, [18] W. Ecker, V. Esen, and M. Hull, Specification Language for Transaction Level Assertions, in Proc. HLDVT 06, [19] W. Ecker, V. Esen, and M. Hull, Implementation of a Transaction Level Assertion Framework in SystemC, in Proc. DATE 07, [20] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley,

17 TABLE OF CONTENTS I. Introduction 2 II. State of the art 3 III. A compositional approach at the RT level 5 IV. Monitoring assertions for TLM designs 7 IV.1 The observer model IV.2 C++ encoding for the monitors V. Experimental results 11 VI. Conclusion 14 References 15 16