3.3 Verification of temporal properties
4.1.2 Phase 2: Timing requirements formalization and Code generation
In order to verify the timing properties of the design model, requirements need to be translated into a formal specification language. The formalized requirements can then be used to check if the design model is compliant to its specification. ABV is a well-known approach that provides verification
Chapter 4. Methodology
12 Gilles Bertrand Defo
Cooperative Computing & Communication Laboratory Cooperative Computing & Communication Laboratory
© Atos and University of Paderborn
Flow
Generation of pure Simulation model (SystemC) Formalization of timing requirements (PSL) Timing verification Functional equivalence check Component Assembly (IP-XACT) Restbus simulation Design model (IP-XACT) Pure simulation model (SystemC) Formal timing specification (PSL) Generation of Restbus simulation model (SystemC) Restbus simulation Model (SystemC) Restbus simulation Model (SystemC) Pure simulation model (SystemC) 1 2 3 4 5Chapter 4. Methodology
engineers with means to formally capture the intended requirement specifi- cations [42]. By means of assertions the model under investigation can then be checked in the following phase 3. In this phase of the design process PSL assertions are derived from the timing information contained within the IP-XACT descriptions. The transformation is based on the rules defined in Chapter 5.
Concerning code generation, it is important to first recall the behavior of the SystemC simulation kernel (see Section 2.4.2), which is a typical event- driven simulator. The scheduler of the SystemC simulation kernel is a coop- erative non-preemptive scheduler that runs at most one SystemC process at a time. A running SystemC process runs until completion (SC METHODS) or until it gives control back to the scheduler (SC THREAD). All runnable processes are executed one at a time in a single delta cycle while postponing channel updates made by those running processes. After all runnable pro- cesses have been executed, the scheduler materializes the channel updates and wakes up sleeping processes that are sensitive to the updated channels. If there are runnable processes available, the scheduler moves to the next delta cycle. Otherwise, it accelerates the simulated time to the nearest time point in the future, where sleeping processes or events can be woken up [23]. In a Restbus simulation environment however, the SystemC simulator com- municates with physical devices, and as a consequence, real-time here means the time measurements done at the physical environment. Figure 4.3 depicts the possible divergence between the time simulated in SystemC and the time measured on the physical system. As illustrated in Figure 4.3, SystemC can simulate faster or slower than real-time, depending on the complexity of the SystemC simulation model.
FlexRay Bus
Data is read twice Oversampling
SystemC Simulation Simulated time T T+1 T+2 T+3 ... FlexRay Bus Real-time T T+1 T+2 T+3 T+4
Figure 4.3: Divergence between simulated time and real-time
Since SystemC time and real time might diverge during simulation, it makes more sense to verify the timing properties in a homogeneous environment (with respect to time). Therefore, a pure SystemC simulation model is gener- ated in addition to the Restbus simulation model. An example of the the two model variants can be seen in Figure 4.4. Obviously, the assumption made
Chapter 4. Methodology
ever, both model variants should be functionally equivalent. This equivalence check analysis is performed in the next design phase. Moreover, the use of
SystemC Simulator (RT Task) TransmCtrl Wheel Interconnect Adapter (RT Task) Restbus Simulator (PC) RTOS Wheel FlexRay Bus SteeringWheel Wheel TransmCtrl SteeringWheel FlexRay bus (SystemC)
Pure SystemC simulation
Wheel
(a) Pure SystemC simulation model
SystemC Simulator (RT Task) TransmCtrl Wheel Interconnect Adapter (RT Task) Restbus Simulator (PC) RTOS Wheel FlexRay Bus SteeringWheel Wheel TransmCtrl SteeringWheel FlexRay bus (SystemC)
Pure SystemC simulation
Wheel
(b) Restbus simulation model
Figure 4.4: Simulation models used during the design process
a pure SystemC model gives the possibility to investigate and identify pos- sible design flaws with respect to timing; provided the fact that both model variants are functionally equivalent, we can then make sure that the design model complies to the requirements before moving on to the actual Restbus simulation process.
The generic structure of an example of our IP-XACT design can be seen in Figure 4.1. The Interconnect is a logical component. For the pure SystemC simulation model, this component is substituted by a bus network model as depicted in Figure 4.4a. Whereas for Restbus simulation, a bus network inter-
Chapter 4. Methodology
face, the so-called Adapter will additionally be generated (see Figure 4.4b). The reason for having two different implementations of the generic IP-XACT design is the fact that Restbus simulation includes the communication with real hardware components. Therefore, we then face the challenge depicted in Figure 4.3. To cope with this challenge we introduce an additional com- ponent(Adapter) that will handle synchronization and hardware communica- tion.
In [9] we presented an IP-XACT design integration framework for IP-XACT components and designs modeling. The front-end of the framework provides import and export functionality of IP-XACT descriptions. Furthermore, it includes a SystemC code generator. The code generator can be used for the generation of the SystemC top-level component in which the existing com- ponents are instantiated and connected. This code generator can be extended by additional features.
As already mentioned, we make use of IP-XACT Views to distinguish be- tween real and virtual components. This information is useful for code gen- eration. The View element in IP-XACT is an attribute that describes an im- plementation of a component. Components may have multiple views, each associated with its own function in the design flow (see Section 2.4.1). To differentiate between real and simulated ECUs, we introduce two additional views namely HIL (for real components) and RBS (for Restbus components).