Transaction Level Modeling for Model Checking

Transcription

1 Transaction Level Modeling for Model Checking Wei-Cheng Chao A Thesis Submitted to Institute of Computer Science and Information Engineering College of Engineering National Chung Cheng University for the Degree of Master in Computer Science and Information Engineering June 2004

2 Abstract Due to the increasing complexity of System-on-Chips (SoCs) and time-to-market pressures, the conventional RTL design process must be elevated to the system level so as to increase design productivity. Using simulation technology to verify very complex systems requires a large amount of time, and it is not sure how much coverage a testbench may provide. We use model checking to verify complex systems, because it can guarantee 100 % property satisfaction. However, model checking has one big problem that is state space explosion, which can be partly tackled by transaction level modeling (TLM). The main spirit of TLM methodology is that it abstracts the parts of a system that we do not currently care about. Though, the TLMs have precise definition and taxonomy, but their use in existing design phases, namely modeling, validation, refinement, exploration, and synthesis, is not well-coordinated. In this Thesis, we will use TLMs in model checking. We use extended timed automata to model an IP. We have created models for ARM s Advanced Microcontroller bus Architecture (AMBA). These models were then verified using a model checker called State Graph Manipulators (SGM). A user can select different TLMs during verification. Experiments show that using TLM technology not only avoids the state space explosion problem of model checking, but also speeds-up the verification process. Keywords: Transaction Level Modeling, Model Checking, Advanced Microcontroller Bus Architecture, Extended Timed Automata, State Space Explosion

3 Contents 1 Introduction Motivation Proposed Solution Thesis Organization Previous Work 5 3 System Model and Verification System Model General APB Slave of AMBA Architecture General APB Bridge of AMBA Architecture System Verification System Verification Flow Transaction Level Models and How to use TLMs The classification of Transaction Level Models i

4 4.1.1 Specification Model Architecture Model Arbitration Model Communication Model Computation Model Implementation Model How to Use TLMs Application Example Introduction to UART Abstracting UART to the TLMs Specification Model Architecture Model Arbitration Model Communication Model Computation Model Implementation Model Experimental Results of Example Conclusion and Future Work 58 Bibliography 58 ii

5 List of Figures 1.1 Verification Architecture General AMBA Architecture General APB Slave of AMBA General Bridge of AMBA General Bridge of AMBA for APB Part System Verification Flow Using TLM Models in AMBA Architecture Model Compositions using Un-timed Bridge Model Compositions using Cycle-timed Bridge UART Architecture Details of Control Line in FVP Architecture Clock Generator of UART Specification Model of UART Architecture Model of UART iii

6 5.6 Architecture Model of APB Bridge Architecture Model of Wrapper Merge of Bridge, Wrapper, and UART Arbitration Model of UART Arbitration Model of Wrapper Communication Model of APB Bridge Communication Model of Wrapper Computation Model of UART Computation Model of Wrapper Implementation Model of Wrapper iv

7 List of Tables 5.1 Clock Relation Result of Verification Composition Results v

8 Chapter 1 Introduction In the recent years, due to the complexity of System-on-Chip (SoC) designs, their verification requires a comparatively longer time than the actual implementation phase. However, time-to-market pressures do not permit such a large amount of time for verification, which becomes a big challenge for verification engineers. The traditional, verification method is to simulate the HDL code using a logic simulator and the software code using an ISS (Instruction Set Simulator). However, the testbenches used in simulation may not provide 100 % coverage and even if a high percentage of coverage is achieved, validating the simulation result for a SoC is not very intuitive due to the large number of signals and interactions among them. A higher-level of abstraction is thus called for. Recently, transaction-level modeling [8, 21, 36] seems to be a promising approach to expedite verification. Due to the traditional formal verification techniques such as model checking, complete verification of systems is now a possibility. By the method of model checking, we can verify a desired behavioral property of a reactive system against a given system through either exhaustive or symbolic enumeration of all the states reachable by the system and the behaviors that traverse through them. We choose model checking [35] 1

9 because it is automatic and when the system fails to satisfy a property, it produces a counterexample that illustrates a behavior that falsifies the property. 1.1 Motivation Simulation and testing techniques cannot provide complete verification guarantees for a system under verification and the traditional RTL level verification is very timeconsuming, hence we use the model checking method to accomplish full property satisfaction guarantee. Though model checking provides 100 % guarantee, yet it has a big problem, namely the state space explosion problem, which occurs whenever a system being verified has several concurrent components. The exponential sizes of state spaces may result in exhaustion of available memory in a machine. We do not desire such a situation, hence we must contrive state space reduction techniques. 1.2 Proposed Solution We choose model checking [35] because it is automatic and transaction-level models can be used for formal verification [35]. We use the State Graph Manipulator (SGM) model checker [12, 27, 28, 31, 32], whose input is a set of Extended Timed Automata (ETA) [4] modeling a system under verification (SUV). We will be using a UART [11] device to illustrate the different abstract level models then illustrate how to integrate the recently proposed Formal Verification Platform (FVP) [29, 30, 31] with the UART IP. SGM is used to merge a user-given IP model and the existing supported models in FVP. The different TLMs are used to verify correctness of the given IP model. 2

10 For Transaction Level Modeling (TLM), the overview given in [8] introduces TLM taxonomy and compares the benefits of TLM use. The authors proposed six TLM models, namely specification model, component-assembly model, bus-arbitration model, cycle-accurate model, cycle-accurate computation model, and implementation model. We will use the six models to refine our system. But, the six models originally used in the proposed design flow are different from our models. We have to redefine the TLM models to conform to our formal verification environment. Figure 1.1 illustrates a simple architecture for verifying the UART core IP. The formal verification platform block includes the architectural model of AMBA [13], from which we only use the APB bridge model to combine with our ETA models of UART. The wrapper sub-block connects the bridge and the UART core. However, the bridge used with each different transaction level model of UART must also be modified based on its abstraction level. The technology of transaction level modeling can effectively reduce verification time, and thus increase verification scalability. But, the major challenge of the TLM technology is to define the semantics of each model because there is no standard yet. 1.3 Thesis Organization This Thesis is organized as follows. Chapter 2 will introduce some research literatures related to the Thesis work. Chapter 3 will formulate the problem to be solved and describe the verification framework we adopt in this Thesis. Chapter 4 will define all the proposed TLM model and describe some rules proposed to guide users on how to use TLM models. Chapter 5 will illustrate how our verification framework is used in 3

11 verifying a UART example. Chapter 6 will conclude the Thesis with some research directions for future work. Figure 1.1: Verification Architecture 4

12 Chapter 2 Previous Work Recently, a lot of research focus on how to go from low level design to more abstract transaction level modeling and design. For example, the Transaction-Based Verification (TBV) environment [5, 6, 14, 15, 16, 33, 35] proposed by Cadence is a simulation-based functional verification environment that raises the level of abstraction from signals to transactions and makes developing effective and efficient and test suites simpler. The TBV environment includes two key technologies, TestBuilder and Transaction Analyzer that allow you to develop, execute, and diagnose tests from a system-level perspective. TBV employs the proven concept of transactors written in standard languages such as Verilog, VHLD, C/C++, system C. TBV environment defines three parts, Transactions, Transactors, and Design Under Test (DUT). In the TBV methodology, one writes test patterns in a high level language such as C, C++, or SystemC using transaction verification models (TVMs). The DUT is an RTL or gate-level description of the design. The TBV allows designers to write test patterns and transaction verification models using Verilog, C++, or SystemC with reference to the TestBuilder Library. The TBV methodology is based on Cadence EDA tools, such as VCS, NC Verilog, 5

13 NC VHDL, NC XL, and ModelSim. However, some terms have been used from the SystemC 2.0 modeling and simulation for AMBA architecture [10, 34]. Transaction- Based Verification Environment provides 100 % code coverage, but does not guarantee comprehensive functional coverage. Because of this problem, we want to use model checking to enhance functional coverage, too. Another system-level design language (SLDL) is the SpecC [7, 17, 18, 19, 22, 23, 24]. The SpecC design flow is based on four abstract levels. Those have specification model, architecture model, communication model, and implementation model. The designer defines a specification model from the requirements and the different models of computation. The model executes in zero simulation time. Behaviors communicate through variables and synchronize through events attached to their ports. The specification model is refined to architecture model that defines the components of system architecture. The system functionality is partitioned and partitions are assigned to different components. The main steps included in this process are behavior partitioning, variable partitioning, and scheduling. The behavior partitioning selects the suitable architecture to allocate a set of processing elements (PEs) and maps the specification behaviors to the processing elements. The variable partitioning maps communication of variables to message-passing channels. The scheduling step includes the scheduling of behavior executions on the processing elements. The communication model refines the abstract communication between components in the architecture model into an actual implementation. The communication step includes channel partitioning, and protocol insertion, and protocol inlining. The channel partitioning is the mapping of the channels from the architecture model to a set of buses. The protocol insertion replaces abstract bus channels over the real bus pro- 6

14 tocol. Function of protocol inlining includes the mapping of communication into the components. Finally, the implementation model implements three kinds of syntheses, including hardware synthesis, software synthesis, and interface synthesis. All models are executable for validation through simulation, reusing the same testbench throughout the whole design process. The SoC Environment (SCE) [1, 2] is an implementation of the SpecC-based methodology. Abstract models of system level design in SystemC [25], are refined as: un-timed functional model, timed functional model, transaction level model, behavior-level model, and register-transfer model. Another one kind of system modeling is the Transaction Level Modeling [8], which includes specification model, component-assembly model, bus-arbitration model, bus-functional model, cycle-accurate, computation model, and implementation model. Due to Transaction Level Modeling, SystemC, and SpecC are similar abstract model. Furthermore, the TLM models are the most complete classification for system design level. We compare TLM models [9] with SystemC, and SpecC that prove why TLM methodology must be selected to do verification. The specification model of TLM models indicates system behavior/functionality. It does not include any implementation details. Time is not used for execution. Process executes in zero time and the transport of data takes zero time. The specification model of TLMs corresponds to specification model of SpecC and un-timed functional model of SystemC. The component-assembly model decides the components of the system architecture. The execution time, processes are assigned, and the transport of data spend some finite time.the component-assembly model of TLMs corresponds to architecture model of SpecC and timed functional model of SystemC. The busarbitration model of TLM models indicates that interface of each component in system 7

15 architecture hide pin level details and the functionality is timing accurate transaction. It uses an arbiter to arbitrate the priority of each component. The abstract model is included into transaction level model of SystemC. The bus function model of TLM models is cycle accurate with pin level detail for system bus transactions, the functionality inherits from the component-assembly model. The model corresponds to communication model of SpecC and behavior level model of SystemC. The implementation model of TLM models, everything is completely timed. The complete functional description, the registers, the buses are synchronized with the clocks. The implementation model corresponds to communication model of SpecC and behavior level model of SystemC. However, SpecC and SystemC do not have including computation model from TLM. This model indicates that the functionalities are cycle accurate and the model interface is not pin level detail. The difficult degree of verification is raised because an escalating increase in complexity of hardware system. Due to we use formal verification technology to verify complex system, may be occur sate space explosion for implementation model. So, we select Transaction Level Modeling technique that includes the computation model, and apply it in model checking. It avoids state space explosion problem in formal verification. 8

16 Chapter 3 System Model and Verification Our target system for verification is a behavioral or register transfer level HDL design, which we basically view as a collection of hardware modules. A complex system is generally designed in a top-down, iterative manner such that the functionalities of a system are implemented gradually through replacing a higher level component by one or more lower level components. A system design must go through several iterations of refinement that will become a complete component. Because a complex system design is progressed, we want to verify it become very difficult doing. Traditional technology of design use simulator tool that system design is HDL code of low level language that is not debug for the designer. And traditional verification use simulation or testing that may be not find all bugs during finite time. We propose to use formal verification technology because it can use properties to check the design system whether it can satisfied or not. It effectively solves defect of traditional simulation or testing technologies. 9

17 3.1 System Model The most widely used and popular model for formal analysis of real-time systems is the Timed Automata (TA) model proposed by Alur and Dill in [4], which basically extends conventional automata by adding clock variables and time semantics. A TA is composed of various modes interconnected by transitions. Variables are segregated into categories of clock and discrete. Clock variables increment at a uniform rate and can be reset on a transition, whereas discrete variables change values only when assigned a new value on a transition. A TA may remain in a particular mode as long as the values of all its variables satisfy a mode predicate, which is a conjunction of clock constraints and boolean propositions. Our design component model is based on the extended timed automata model, which is an extension of TA and is defined as follows, where the sets of integers is denoted by N. Definition 3.1 Mode Predicate Given a set C of clock variables and a set D of discrete variables, the syntax of a mode predicate η over C and D is defined as: η := false x c x y c d c η 1 η 2 η 1, where x, y C, {, <, =,, >},c N, d D, and η 1, η 2 are mode predicates. Let B(C, D) be the set of all mode predicates over C and D. Definition 3.2 Extended Timed Automaton An Extended Timed Automaton (ETA) is a tuple A i = (M i, m 0 i, C i, D i, L i, χ i, E i, λ i, τ i, ρ i ) such that: 10

18 M i is a finite set of modes, m 0 i M is the initial mode, C i is a set of clock variables, D i is a set of discrete variables, L i is a set of synchronization labels, χ i : M i B(C i, D i ) is an invariance function that labels each mode with a condition true in that mode, E i M i M i is a set of transitions, λ i : E i L i associates a synchronization label with a transition, τ i : E i B(C i, D i ) defines the transition triggering conditions, ρ i : E i 2 C i (D i N ) is an assignment function that maps each transition to a set of assignments such as resetting some clock variables and setting some discrete variables to specific integer values. We use the above Extended Timed Automata definition to do a formal verification environment for AMBA specification (Rev 2.0). In Figure 3.1 exhibits the general AMBA architecture that includes one AHB master, arbiter, one AHB slave, APB bridge, two APB slaves. In the Thesis focus, the focus is on the APB part of AMBA, that includes an APB bridge, and an APB slave. So, we can abstract each component of AHB bus of AMBA. And both two the general models are defined in subsection and

19 Figure 3.1: General AMBA Architecture General APB Slave of AMBA Architecture Figure 3.2 illustrates APB slave model is a low speed device connected to the low speed peripheral bus, APB bus such as UART, USB... etc and complete the transfer through the signal from APB bridge. The combination of PSEL and PWRITE decides which APB slave and which operation to execute. In the next cycle, APB bridge transmits the signal PENABLE for transfer. Read after write saves one cycle and directly reaches the SETUP R state. APB slave can perform single transfer in our model, and the behavior of pipeline is not included. 12

20 Figure 3.2: General APB Slave of AMBA General APB Bridge of AMBA Architecture The bridge is a slave of a AHB bus, and the only master of APB bus on the same time. It not only transforms the signals during both sides, but also responds to both sides simultaneously. The speeds of AHB bus and APB bus are different, and the ratio of system bus to peripheral bus is 2:1. The data streams of read and write are different, and this results in the difference of timing during transfer. Therefore, we differentiate read and write as explicit states. In the Figure 3.3, the synchronization 13

21 label HPE indicates the transition synchronizes with AHB clock, the PPE indicates the transition synchronizes with APB clock. The HSEL signal indicates that the bridge is selected, through The HADDR variable and PSEL signal decides what APB slave is selected. In the bridge model, we do not model the pipeline behavior and burst transfers, we only support single transfers. In the Figure 3.4, we abstract the AHB part of the bridge because, we focus on the APB part and do not care about the AHB. In the future, the AHB part of the bridge will be needed for connecting the device components of the AHB bus. HSEL = 0 & HREADY = 1 & state = 0 ; READ HSEL =i & HREADY = 1 & HWRITE = 0 ; HREADY := 1; HRESP:= OKAY ; Sync HPE; IDLE HSEL = i & HREADY = 1 & HWRITE = 1 ; HREADY := 1; HRESP:= OKAY ; Sync HPE; WRITE HSEL = i & HADDR= i ; PSEL:=i-2 ; PWRITE=0 ; HREADY := 0 ; HRESP := OKAY ; Sync PPE; SETUP_R PENABLE:=1 ; HREADY := 1 ; HRESP:= OKAY ; Sync PPE; HSEL = i & HADDR= i & HWRITE = 1 ; PENABLE:=0 ; PSEL:=0 ; HREADY := 1 ; HRESP:= OKAY ; Sync PPE; RAW_ IDLE HSEL = i Sync HPE; ACTION ERROR HREADY := 1 Sync HPE; HSEL = i & HREADY = 1 ; Sync HPE; PWRITE:=1 ; PSEL:=i-2 ; HREADY := 0 ; HRESP:= OKAY ; split_master = 0 & split_master = 2 ; HSPLIT[2] := 1 ; Sync PPE; HSEL = i & HREADY = 1 ; Sync HPE; WRITE_BUSY HSEL = i & HADDR= i ; PWRITE:=1 ; PSEL:=i-2 ; HREADY := 0 ; HRESP:= OKAY ; Sync PPE; SETUP_W HSEL =i & HADDR= i & HWRITE = 1 ; ENABLE:=0 ; SEL:=i-2 ; HREADY := 0 ; HRESP:= OKAY ; ync PPE; HSEL = I & HWRITE = 1; PENABLE:=0 ; PSEL:=0 ; HREADY := 1 ; HRESP:= OKAY ; Sync PPE; HSEL = I ; PENABLE:=0 ; PSEL:=0 ; HREADY := 0 ; HRESP:= ERROR ; Sync PPE; HSEL = i ; PENABLE:=0 ; PSEL:=0 ; HREADY := 0 ; HRESP:= ERROR ; Sync PPE; PENABLE:=1 ; HREADY := 1 ; HRESP:= OKAY ; Sync PPE; HSEL =i & HADDR= i & HWRITE = 1 ; PENABLE:=0 ; PSEL:=i-2 ; HREADY := 0 ; HRESP:= OKAY ; Sync PPE; ENABLE_R ENABLE_W Figure 3.3: General Bridge of AMBA 14

22 "#$ " Figure 3.4: General Bridge of AMBA for APB Part 15

23 3.2 System Verification The goal of system verification is to verify functional correctness of a IP. The currently practiced methods for system verification are mostly techniques of full-chip simulation and testing. However, with an escalating increase in the complexity of IP, these two techniques are no longer adequate for system verification. After the advent of formal verification techniques such as model checking, complete verification of complex systems are now a possibility. Model checking (MC) takes a formal description of a system under verification and a property specification in order to check if the system satisfies the property. In case of property violation by the system, MC generates a counterexample in the form of a system behavior trace, which shows exactly where the system violates the property. Here we use an MC tool, SGM, to verify if the rectification of a Verilog HDL design is complete and as a result, a higher correctness of the design could be achieved. SGM is, a tool mainly used to resolve invariant checking problems, where a system, described as a set of communicating Extended Timed Automata models, is checked to see if a property is satisfied or not. A property is specified in a logic such as Timed Computation Tree Logic (TCTL) in Definition 3.3. If system S satisfies a TCTL property φ, it is denoted as S = φ. In Section 3.3, we will give a detailed description of how we apply such a formal model checker in our proposed verification methodology. 16

24 Definition 3.3 Timed Computation Tree Logic (TCTL) A timed computation tree logic formula has the following syntax: φ ::= η φ φ c φ φ φ φ, where η is a mode predicate, φ and φ are TCTL formula, {<,, =,, >}, and c N. φ means there is a computation from the current state, along which φ is always true. φ c φ means there exists a computation from the current state, along which φ is true until φ becomes true, within the time constraint of c. Traditional shorthands like,,,,, and can all be defined [26]. 3.3 System Verification Flow Figure 3.5 indicates the system verification flow. The user wants to verify a selfdesigned IP whether it is correct or not. We use ETA to model a system from its RTL code. In the flow, we separate three part of abstract models that specification model, Transaction Level Models, and implementation model. The specification model is manual transformation from RTL code. Transaction Level Models include architecture model, arbitration model, communication model, and computation model. The architecture model inherits from specification model and adds the refinements from RTL code. Reason by analogy, the arbitration model will inherit from architecture model, the communication model will inherit from arbitration model, and computation model will inherit from arbitration model. Then implementation model inherits from computation model and computation model. Each Transaction Level Model will be merged that becomes a new TA with Formal Verification Platform. Then two input datas for SGM model checker include the new TA and suitable properties of property library. The property library preserves suitable properties of each 17

25 TLM that provides the model checker to verify the new TA. If a given property is not satisfied, it will produce the counterexample to notify the user that rectifies the errors of RTL code. We can refine the TLM model and model check again until the suitable properties are satisfied. When a TLM model is complete, it is called golden model. We will illustrate it how to use in Section 4.2. Since the implementation model may be quite complex it may be run out of memory, hence the TLM technology is needed. 18

26 $ % $ $ " $ $ $ $ " # Figure 3.5: System Verification Flow 19

27 Chapter 4 Transaction Level Models and How to use TLMs The goal of design at the system level is to reduce the complexity of system verification. We will redefine the six models from [3, 8, 20]. The TLM models differentiate between communication and computation. The three kinds of time accuracy are un-timed, approximate timed, and cycle timed. Un-timed computation and communication represent a design specification without any time implementation details. Approximate timed computation and communication represents system-level implementation details, such as the selected system architecture, the mapping relations between processes of the system behavior and the processing elements of the system architecture. The execution time for approximate timed computation and communication is estimated at the system level without cycle accurate evaluation. Cycle timed computation and communication include implementation details, such that cycle accurate estimation can be obtained. 20

28 4.1 The classification of Transaction Level Models We will redefine the six abstract models, namely specification model, architecture model, arbitration model, communication model, computation model, and implementation model. Among the six abstract models, the Transaction Level Models only include architecture model, arbitration model, communication model, and computation model Specification Model It describes the IP (Intellectual Property) behavior and functionality, but does not express any detail implementation of the IP. Time is not used for execution. Processes execute in zero time and the transport of data takes zero time Architecture Model This model includes a set of interesting components that constitute the architecture. Due to different abstraction level among component models, wrappers must be implemented as communication, interfaces between components. A wrapper acts as a translator from higher level communication position such as a FIFO need to lover level communication positions such as assertion of signals. For abstraction of communication time, variables are need instead of actinal signals. We will use a formal verification platform FVP with the user designed IP attached to the APB (Advanced Peripheral Bus) bridge in ARM s AMBA. 21

29 4.1.3 Arbitration Model The abstraction model is communication requirement of the architecture model. Both computation and communication are approximate timed. Processes are assigned execution time and the transport of data takes some finite time. In this model, data phase is abstracted, but arbiter details added. An arbiter assigns bus access to processing elements on the basis of their priorities. With this model then main target of verification is the control signals of a system along with the latency Communication Model It contains time/cycle accurate communication and approximate timed computation. The time accurate model specifies the time constraints for communication, which is determined by the timing diagram of a component s protocol. The cycle accurate model specifies the time in terms of the system s clock cycles. The communication time of this model has refined cycle accurate time from the system to the interface of DUV (Design Under Verification). The DUV inherits the IP model has verified from arbitration model. That main verification purpose is to verify that system signals are correct when we use cycle accurate time between the system architecture FVP and the wrapper of interface implementation. In our system architecture we use Extended Timed Automata to model the system and use model checking [12] to verify the system, we add clock variable to do cycle accurate time. We do not use protocol channels, because our architecture is for a communication protocol. 22

30 4.1.5 Computation Model The model is refined from the arbitration model. The IP and the wrapper models have cycle accurate computation. The detailed implementation of the IP includes the control signals of the data transformation and interacts between the IP and the wrapper. The system models have approximate timed communication and use variables to communicate. The main verification purpose is to verify a fully detailed IP with cycle accurate time Implementation Model It defines the system, wrapper, and IP in cycle accurate time. The IP details are inherited from the computation model and the system is inherited from the communication model. The wrapper must add information related to the cycle accurate time. The main verification purpose is to verify that the whole system including the wrapper and the IP under cycle accurate time. Due to the direct modeling of the implementation model from the RTL code/verilog code of an IP, it may be happen that we run out of memory during model checking. Hence, we use Transaction Level Modeling in verifying each step so that it is not only reduces complexity of a system, but is also easy to understand. 4.2 How to Use TLMs We select AMBA (Advanced Microcontroller Bus Architecture) protocol to understand the interactions among the IPs. In Figure 4.1, it is indicated when we want to understand the interaction between two IPs, but do not need the details of the IP. 23

31 We can use decision procedures to select a suitable TLM by estimation methods. We write some codes to express each part of TLMs including the specification model (A), architecture model (B), arbitration model (C), communication model (D), computation model (E), implementation model (F). Looking at the Section 4.1, we can know each TLM model may be composed of the same subcomponent of the other TLM model. We will list the same subcomponent of TLM model. The bridge is modeled is 2 ways: an un-timed and a cycle-timed, the un-timed model is included in models B, C, and E, the cycle-timed model is included in models D, and E. Furthermore, the models B, C, and E are similar, besides the models D and E are similar. The Design Under Verification IP may be the same in the other TLM models. The model C is same as the model D, and the model E is same as the model F. The wrapper is different in each TLM model. Based on consideration of time, two kinds of TLM model compositions are proposed to guide a verification engineer on how to select suitable TLM models to verify a user-designed IP. Some model compositions proposed for selecting suitable TLM models are described as follows. 1. Model Composition 1 in Figure 4.2 illustrates the situation when a user wants to verify that the golden models can correctly receive signals from the bridge. The bridge is un-timed, and the sub-component uses the wrapper and the golden model from the arbitration model. We use arbitration model to verify un-timed communication between the bridge and the golden model, because the model is a complete model for un-timed communication. The golden model indicates the 24

32 IP has been verified completely. 2. Model Composition 2 in Figure 4.2 illustrates the situation where a user might only want to know the detailed IP interactions between the golden model and the bridge. For the other IP a user can use the highest abstraction model, that is, the architecture model for easier and feasible verification. 3. Model Composition 3 in Figure 4.2 as above, illustrates the situation where a user may want to verify two detailed golden IP models of here, it may result in an out of memory problem. 4. Figure 4.3 illustrates the cycle-timed interactions between the bridge and the golden IP models. Model Composition 4 illustrates the situation where a user may only want to know the interaction between the communication accurate part of a golden model for an IP and the bridge. For the other IP a user can use the highest abstraction model, that is, the architecture model to speed-up verification time. 5. Model Composition 5 in Figure 4.2 as above, illustrates the situation where a user may want to verify two communication accurate golden models of the IPs. Here, it may result in an out of memory problem, too. 6. Model Composition 6 and 7 from Figure 4.2 help a user to verify complete IPs, but these model compositions will result in state space explosions. 25

33 Figure 4.1: Using TLM Models in AMBA Architecture 26

34 Figure 4.2: Model Compositions using Un-timed Bridge (Each block below the APB bus includes a wrapper and a golden model) Figure 4.3: Model Compositions using Cycle-timed Bridge (Each block below the APB bus includes a wrapper and a golden model) 27

35 Chapter 5 Application Example We will introduce the verification of a UART IP design and show how to use the TLM models of UART for verification within the Formal Verification Platform [30]. 5.1 Introduction to UART The host machines can communicate via serial data channels with other hosts or devices that use modems. A modem is also called a Universal Asynchronous Receiver and Transmitter (UART). We model Verilog code of UART [11] and the UART architecture as shown in Figure 5.1. UART is generally found in most devices or computers. Due to the use of model checking technology, we only verify the behavior of a system, hence we must abstract the data, the variable, and some signals. Our system is modeled by a set of models. Integrating with the APB bridge of FVP for AMBA, the UART is merged using SGM, and verified against some properties. The FVP includes a generic AHB master, a generic AHB slave, a simple AHB arbiter, and APB bridge, and two generic APB slaves. Two bus clock models, AHBCLK and APBCLK, are also used to provide synchronizations in the AHB and in the APB, respectively. Because we model the design of UART as an APB slave, we only integrate 28

36 APB bridge and UART. $ %& ' "# "# "# ( "# Figure 5.1: UART Architecture 5.2 Abstracting UART to the TLMs In Figure 5.1 (We refer from [11]), it is indicated that the wrapper for the UART core receives signals from APB bridge, and then translates them into the input signals for UART core. The functions of each external signal are described as follows: PSEL (APB select): the signal indicates that the slave device is selected and a data transfer is required. There is a PSELx signal for each bus slave. PENABLE (APB strobe): this signal indicates the second cycle of an APB transfer. The rising edge of PENABLE occurs in the middle of the APB transfer. 29

37 PWRITE (APB transfer direction): when high this signal indicates an APB write access and when low it is a read access. PCLK (Clock of APB bridge): the rising edge of PCLK is used to time all transfers on the APB in Figure 5.1 is system clock. RCLK (Clock of Receiver): the rising edge of RCLK is used to time all transfers on the Receiver of UART in Figure 5.1 is sample clock. TCLK (Clock of Transmitter): the rising edge of TCLK is used to time all transfers on the Transmitter of UART in Figure 5.1 is clock. Load XMT datareg: assertion transfers Data Bus to the transmitter data storage register,xmt datareg But we have not simulated register of XMT datareg. Byte ready: asserted by host machine to indicate that Data Bus has valid data. T byte: assertion initiates transmission of a byte of data, including the stop, start, and parity bits, but parity is abstracted. Read not ready in: signals that the host is not ready to receive data serial bit stream received by the unit. Serial in: serial bit stream received by the unit. Serial out: serial bit stream send by transmitter. Explain the functions of each internal signal are as follows: Load XMT shfreg: assertion loads the contents of XMT data reg into XMT shfreg. Start: signals the start of transmission. 30

38 Figure 5.2: Details of Control Line in FVP Architecture Shift: directs XMT shfreg to shift by one bit towards the LSB and to backfill with a stop bit (1) in Transmitter and causes RCV shftreg to shift towards the LSB. Load: causes RCV shfreg to shift towards the LSB. Clear: clears bit count, which is abstracted because we can deassert bit count is zero. Sample counter: counts the samples of a bit in the Receiver. Bit count: counts bits in the word (defined eight bits) during transmission in Transmitter. Bit counter: counts the bits that have been sampled in the Receiver individually. Read not ready out: signals that the receiver has received eight bits, but we abstracted it. We do not need check whether it is correct or not. 31

39 Figure 5.3: Clock Generator of UART Inc sample counter, clr sample counter, inc bit count, inc bit count: that is abstracted because both sample counter and bit count are deasserted. The wrapper of block in Figure 5.2 is our defined to connect abstraction APB bridge with UART core. Figure 3.4 illustrated a transfer of APB device need two cycle time. When PSEL is high and PENABLE is also high then the wrapper is triggered. The wrapper begins communication with UART core. When PENABLE is low, it indicates a transfer is finished. We use UART clock generator (We refer from [11]) in Figure 5.3 to model each clock model of the TLMs. The APB bridge clock (system clock in Figure 5.3) has frequency thirteen times that of the Transmitter clock (clock in Figure 5.3), and the Transmitter clock (simple clock in Figure 5.3) has frequency eight times of the Receiver clock. We abstract the baud rate, because it relates to transmission rate of real communication equipment. The Reset signal is also abstracted. 32

40 The APB bridge uses PCLK, the transmitter of UART uses TCLK, and receiver of UART uses RCLK. The UART clocks relate with the APB system clock as follows. We define three clock variables that will be used in our TLM model. The clock variable x is used in the communication and the implementation models. The clock variables t and r are used in the computation and the implementation models. x : clock variable of APB bridge (PCLK) t : clock variable of transmitter (TCLK) r : clock variable of receiver (RCLK) t = (8 + 8) r t = t clock is eight times bigger than r x = 13 t = r = 208 r = x is thirteen times bigger than t r = ( ) 16 r = 128 r + 80 r = positive edges : negative edges = 8 : 5 In Table 5.1, clock variable r takes a value of 1 to indicate the time elapse of one cycle. The clock variable t is eight times larger than the clock variable r. The positive edge of clock variable t is 128 times bigger than r. The negative edge of clock variable t is 80 times larger than r. Table 5.1 summarizes the clock relation among the 3 clocks in our case study. In the following, we will introduce each abstract model of UART and how to verify it. 33

41 Table 5.1: Clock Relation Clock Name Positive Edge Negative Edge PCLK (variable x) TCLK (variable t) 8 8 RCLK (variable r) Specification Model The specification model in Figure 5.4 does not consider the full functional details the components. We only need to understand the behaviors of the components. We will explain the transmitter of a UART that use the select variable to select the UART then use data ready signal to determine whether the data from the host is ready or not. In the SENDING state, it begins transfer until finish signal is received from the host. However, the behavior of Receiver is also such doing. Trans and Rece signals are used to indicate transmission or receiving Architecture Model The abstraction level of the architecture model is byte level, which is concerned bytelevel data transfer. We are concerned with whether data is valid or not, but do not care about the data transfer time. The APB bridge in Figure 5.6 that uses PSEL signal to indicate UART is selected, and PWRITE signal assert high indicate that the transmitter of UART will be action, PWRITE equals zero that indicate doing receiver of UART. The synclabs BW signal indicates the APB bridge synchronizes with the wrapper, and synclabs WU is the wrapper synchronize with UART. AMBA has synchronization characteristic and this TLM level is not time/cycle accurate, so we must use the synchronization technique in the SGM tool. The wait ur variable 34

42 Figure 5.4: Specification Model of UART indicates that the UART (Figure 5.5) has completed transfer then notify wrapper (Figure 5.7). We will illustrate relation of three models in architecture model as follow: For example, when the APB bridge has one byte data for sending via UART. Figure 5.8 shows the merge results of three models via SGM tool. The merge order is APB bridge, wrapper, and UART. When the bridge is in the ENABLE W state and the wrapper in the Twr ready state, then in the next state the bridge goes back to the IDLE state and the wrapper arrives at the Twr load state simultaneously. When the byte ready signal is asserted in the wrapper then the wrapper arrives at the Twr send 35

43 state and the UART is in the WAITING state in the meantime. Afterwards, the wrapper waits for the wait ur variable of UART to be asserted then the wrapper enters Wr IDLE state. We wrote some properties to check whether the UART can receive correct signals from the APB Brdige or not, as follows: AG(( mode(apb BRIDGE) = SETUP W bri) && (PSEL = 1 ) EX(mode(wrapper) = Twr ready)); This property checks that when the bridge asserts the PSEL signal then there exists a next state which the is Twr ready state indicating that the transmitter of UART is selected. AG((byte ready = 1 & T byte = 1) AF(mode(UART) = SENDING)); The property checks that when the wrapper asserts byte ready and T byte signal, eventually the UART in SENDING state begins sending data. AG((mode(wrapper) = Twr load) && (byte ready = 1) AX(mode(UART) = WAITING)); The property checks that the wrapper asserts byte ready signal then the next state is WAITING state indicating the preparation for transmission. 36

44 "#$ Figure 5.5: Architecture Model of UART 37

45 Figure 5.6: Architecture Model of APB Bridge 38

46 " "# % "# $ $ $"# Figure 5.7: Architecture Model of Wrapper 39

47 ,- ") ",- (% ",- ( " "" #$,- ( "& # $ % #$ ',- ( " #$ ( ) #$ *+( " #$ # $,- " # $ % # $ (& # $ *+ (' # $ ) # $ & # $ ( # $ * +( # $ ",- %),- ',- (&,- "',- ( "%,- " Figure 5.8: Merge of Bridge, Wrapper, and UART 40

48 5.2.3 Arbitration Model The arbitration model is refined from the architecture model. The main tasks include adding latency time in the wrapper (Figure 5.10) and in the UART (Figure 5.9). The byte ready signal and T byte signal will consider latency time in The Transmitter of UART and in the wrapper. The receiver of UART adds latency time of rec serial in signal. The rec serial in signal must equal zero until it begins receiving data because it is a start bit of data transmission format. (The data transmission format includes start bit, eight bits of data, stop bit.) The APB bridge is the same as for the architecture model (Figure 5.6). We provide some properties to check selecting the UART because the arbitration model must decide to select which device, and to check delay time for each signal. AG((PSEL = 1 & PENABLE = 1) EF(mode(wrapper) = Rwr receive)); When PSEL and PENABLE are asserted in APB bridge, eventually the wrapper has a state in Rwr receive that notifies the UART to receive the data. E(T byte = 0 U mode(wrapper) = Twr send); The property checks that before the wrapper arrives Twr send state, the T byte signal is equal to zero. It indicates the UART begins send data when T byte is asserted one. AG(rec serial in = 1 (AX (mode(uart) = RECEIVING))); The property checks that the rec serial in signal is must asserted zero then the UART begins receiving data. 41

49 # " $% " # Figure 5.9: Arbitration Model of UART 42

50 # # #$ % # # # # $ # # # " Figure 5.10: Arbitration Model of Wrapper 43

51 5.2.4 Communication Model The abstraction level model focused on communication between the APB bridge (Figure 5.11) and the wrapper (Figure 5.12). The UART (Figure 5.9) inherits from the architecture model. The APB bridge and the wrapper use the clock variable for cycle accuracy. The clock variable is shown in Table 5.1. The IDLE state to SETUP R state or SETUP W state has two situations in APB bridge. A situation is using x = 128 in first execution that indicates the positive edge of first cycle is triggered via 128 counts. After the fist cycle, the cycle counts uses 208 to counter and use start clk X variable to determine. When the APB bridge sends one transfer control signals to the wrapper then it back to IDLE state. Before the bridge waits 208 cycles to arrive SETUP R state and the wrapper backs Wr IDLE state that must waits the receiver of UART assert wait ur variable. We use some properties to verify this model, as follows: AG((mode(APB BRIDGE) = ENABLE W bri) && (PENABLE = 1) (mode(wrapper) = Twr ready)); We check in each state if it is in the ENABE W bri state of the APB bridge, then the wrapper is sure in the Twr ready state that expresses the clock variable can correctly synchronize the two transitions. AG((mode(APB BRIDGE) = ENABLE R bri) && (PENABLE = 1) (mode(wrapper) = Rwr load)); This property checks the function as above, except it is for read transfer. AF(( mode(wrapper) = Twr send) EX (x = 208 && mode(wrapper) = wr IDLE)); 44

52 When the wrapper in a Twr send state through clock variable x counts 208 times, the wrapper backs the wr IDLE state. The property illustrates that the UART uses clock variable to constrain the interactions between the bridge and the wrapper. 45

53 " # " # " # " # # " " Figure 5.11: Communication Model of APB Bridge 46

54 ' ''%( '% ") " #$ " #$ #$ " ' #$ ' " #$ ' ' ' ( #$ ' #$ " " #$ ' % & #$ #$ " #$ Figure 5.12: Communication Model of Wrapper 47

55 5.2.5 Computation Model The computation model is inherited from the arbitration model. The APB bridge model is the same as that in the arbitration model. The wrapper (Figure 5.14) and the UART (Figure 5.13) models synchronize using two clock variables t and r. The model illustrates the model of UART, which includes Transmitter and Receiver. The transmitter flow includes: APB bridge sends PSEL selected UART, next cycle send PENABLE assert high indicated via wrapper send Load XMT datareg is high to load data form data bus. Using byte ready checked whether data are correct or not, then load XMT datareg register (8 bit array, 0 7 bit) to 1 8 bit of XMT shftreg register (9 bit array), and assert LSB (least significant bit) of XMT shfreg is 1. When T byte is high then setup start bit is high, which indicates the LSB of XMT shfreg is asserted low. Begin transfer one bit of one time until bit count equals nine then return IDLE state. The Receiver flow includes: when rec serial in equals 1 implies invalid transfer and return to IDLE state. When rec serial in is sampled three times equals zero, indicated data is valid. Receiver begins received data, each bit sampled eight times, at the eighth time one MSB (Most significant bit) of RCV shftreg register is received. We use the bit counter of variable to count received bits during receiving, each received one bit then right shift one bit until bit counter equals nine to load RCV shfreg register to RCV datareg register at the same time directed data bus. We write some properties to verify the UART with the wrapper, as follows: AG(rec serial in = 0 & sample counter = 3 AX(mode(UART) = RECEIV- 48

56 ING)); The property checks that before the receiver receives data, it must is sampled three times for the rec serial in signal equal zero. AG((mode(UART) = RECEIVING) && bit counter = 8 && sample counter = 7 AX(mode(UART) = IDLE)); We check this property that when the Receiver receives the eighth bit of the data and the bit is sampled eight times simultaneously, then the Receiver loads one byte data to data bus and backs the IDLE status. AG((mode(UART) = SENDING) && bit count = 9 AX(mode(UART) = IDLE)); This property checks that when Transmitter sends ten bits to include: start bit, eight bits data, and stop bit then the Transmitter backs the IDLE status to wait the next request. (bit count: 0 9) 49