Verification of Real-Time Properties for Hardware-Dependent Software

Verification of Real-Time Properties for Hardware-Dependent Software Wolfgang Mueller, Marcio F. da S. Oliveira, Henning Zabel, Markus Becker University of Paderborn/C-LAB, Paderborn, Germany {wolfgang, marcio, henning, markus.becker}@c-lab.de Abstract—Seamless HW/SW codesign flows support early verification of hardware and Hardware-dependent Software (HdS) like drivers, operating systems, and firmware. For early estimation and verification, the application of SystemC in combination with Instruction Set Simulators and Software Emulators like QEMU is widely accepted. In this article, we present an advanced design flow for HW, (RT)OS and HdS refinement and verification with focus on the transition from abstract RTOS verification to full system RTOS/HdS emulation. In the context of assertionbased verification, we introduce a set of generic real-time properties which can be reused and verified at different abstraction levels and discuss their application. The properties are presented by the means of IEEE standard PSL assertions which are applied for mixed SystemC/HdS models. Keywords- Verification; PSL; SystemC; Real-Time Systems

I.

INTRODUCTION

With increasing design complexity, the early consideration of software became a crucial factor in electronic systems design [12]. In this context, the configuration and scaling of the Hardware-dependent Software (HdS) as an important interface between application software and hardware became the focus of multiple investigations throughout the last years.

imately-timed TLM (bus arbitration) abstraction to untimed system specifications with respect to computation and communication. In parallel, [10][14] introduced clockless TLM abstractions to interface embedded SW and HW to capture logic operations on busses for master and slave communication. For the smooth transition from timed to untimed models, the levels of Programmer’s View with and without timing were introduced (PV & PV-T) which finally contributed to the OSCI TLM 1.0 standard [27]. Thereafter, PV-T was revised by the OSCI and refined to loosely- and approximately-timed coding styles as they can be found in TLM 2.0 [28]. As such, TLM provides a bus-centric abstraction for mixed HW/SW systems as they are sketched in Fig. 1. Models of different abstractions are connected to a TLM-based communication by so-called transactors, which convert the individual interfaces and protocols to the respective TLM protocol. Embedded software is typically analyzed by formal timing analysis or by means of a virtual prototype. For static formal timing analysis, Worst Case Execution/Response Time (WCET/WCRT) analysis is applied on a frequent basis. WCRT analysis is typically based on an event stream abstraction, where the individual tasks in the model are activated by events [9][33]. The event stream abstraction takes composable event FIFOs at the components' inputs and outputs for performance analysis. The underlying theory defines a workload for the individual tasks within a specific time interval, so that minimal and maximal distances between events can be determined, e.g., by the means of the sliding window technique [24]. This allows the analysis of over and under sampling effects in distributed systems, for instance. For the implementation of a virtual system prototype, a system level language - today mainly SystemC - is applied in combination with an abstract canonical RTOS [13] and/or an Instruction Set Simulator [25]. Abstract RTOS models have the advantage that they provide a significantly faster simulation speed for time-based simulations on the costs of less accuracy in the simulation results. As such, significant speed-ups of up to 40.000x compared to ISS with simulation errors of less than 2% have been reported [31][36].

Figure 1. HdS in a Layered Systems Architecture [12]

In order to deal with consideration of mixed HW/SW systems, additional methodologies and abstraction levels were introduced beyond Register Transfer Level (RTL). In 2003, [8] introduced the notion of Transaction Level Modeling (TLM). They address the abstraction of cycle-timed RTL via approx-

In the context of virtual prototypes, several approaches for different abstraction and refinement levels have been introduced through the last years. A layered approach was presented in [31], incrementally describing processor modeling with essential features of task mapping, dynamic scheduling, interrupt handler, low-level firmware and hardware interrupt handling. At the highest level, the application is running natively on the simulation host. At Task Level, an abstract RTOS model is introduced and processes are refined into tasks. In the proces-

sor models at the Firmware (FW) and Transaction-Level Modeling (TLM) refinement steps, hardware abstraction (HAL) and processor hardware layers are introduced. The FW and TLM level add models of the external bus communication and the interrupt handling chain on the software and hardware side, respectively. Finally, a Bus-Functional Model (BFM) of the processor includes pin- and cycle-accurate models of the bus interfaces and the protocol state machines driving and sampling the external wires. Fig. 2 gives an overview of the different levels and their features.

Figure 2. Processor Model by Schirner et al. [31]

A dedicated approach for the refinement from functional SystemC PV models to SystemC/ISS cosimulation is introduced in [11]. It supports smooth HW/SW partitioning by replacing SystemC threads with POSIX threads without code modifications with the help of their SC2OS library. However, the approach is limited to the functional evaluation of SW not considering (RT)OS properties. Therefore, it was extended in [2] to a four-level RTOS-aware TLM 2.0-based refinement that starts from functional untimed SystemC PV models. In a first step, the methodology applies SC2OS before models are ported to a canonical abstract RTOS, namely, aRTOS, which is finally replaced by the target (RT)OS running in the full system mode of the QEMU software emulator as given in Fig. 3. In the third step, aRTOS system calls for abstract RTOS simulation are introduced [35], which are replaced by system calls of the target (RT)OS in the final step.

Figure 3. Final Virtual Prototype Platform of [2]

In this paper, we first introduce the basic principles of QEMU and abstract RTOS simulation. Thereafter, based on the work in [2], we extend the previous approach and show how the transition from the abstract to the target RTOS can be smoothened even further before we discuss the specification and verification of real-time properties. The later is based on our work in [26] which introduced a basic set of PSL assertions for abstract RTOS simulation.

II.

INSTRUCTION SET SIMULATION WITH QEMU

QEMU is a software emulator, which provides an instruction and register accurate CPU abstraction with the support of multiple platform, e.g., x86, ARM and PowerPC [4]. QEMU comes with an efficient dynamic binary translation based on a fetch/decode/execute cycle. The cycle applies an online compilation of instructions into a host Instruction Set Architecture (ISA). For this, target code is considered on Basic Block (BB) level, i.e., linear code segments until a final branch instruction. QEMU uses a dynamic code generator to translate BBs at runtime by concatenating precompiled host code segments, i.e., Translated Basic Blocks (TB). For faster execution, TBs are stored in a TB cache. Then, the major translation effort is just chaining TBs from the cache and patching instruction operands. Meanwhile several approaches like [2] apply QEMU for efficient Instruction Set Simulation in combination with SystemC. [16] additionally presents a QEMU extension for QEMU/SystemC cosimulation for time and power estimation also considering caching effects. QEMU can operate in two modes: (i) user mode and (ii) full system mode. The user mode supports an efficient user space simulation of a single process on top of one process on the simulation host. In user mode, a system call raises an exception, which in turn invokes a corresponding Linux system call. The user mode maps the target memory directly to the host memory, so that it abstracts from any specific memory model. The QEMU full system mode includes an entire target platform with full I/O and kernel space access for operating system and driver simulation so that system calls can be directly executed. III.

ABSTRACT RTOS SIMULATION

Several approaches for efficient RTOS simulation were introduced in the last years for early HW/SW estimation and verification. They can be roughly divided by the integration of a real (RT)OS API, like the POSIX-based PERFidiX library [30] and u-ITRON-based RTK-Spectron system [17], and approaches based on abstract RTOS models like [13]. The latter was originally developed in SpecC and reimplemented in SystemC [35] enhanced by a separate interrupt management and preemptive wait statements. In SystemC, for HW/SW cosimulation, the application software and interrupt service routines are typically executed in SC_THREADs and divided into non-preemptive time/powerannotated code segments with interaction points between them. Interaction points are for the synchronization with the simulation kernel, e.g., for advancing the simulation time, for system calls, and for various communications. Time and power information are backannotated from ISS or WCET analysis which can be done at source code level [13][31][37] or at compiled/intermediate code level [18]. Considering the impact of compiler optimization, [37] also investigates automatic source code annotations and their traceability in the compiled code. It is important to note, that the number of interaction points has an impact on the simulation speed as each interaction point implies a synchronization with the simulation kernel. For abstract RTOS simulation, typically, one interaction point is

assigned for each execution path. However, more coarse- or fine-grained segmentations are possible, if necessary.

standard SW components like device drivers or general realtime properties as we will show later in this section.

As the advance of the simulation time between the interaction points is not preemptive, less interaction points may result in a lower accuracy of the simulation when just applying native (SystemC) wait statements. The processing of an interrupt by the simulator, for instance, has always to be postponed to the next wait statement in such a case. To significantly increase the accuracy of the simulation, several approaches were developed to replace the direct synchronization with the kernel by higher level constructs or an overloaded wait statement [30][32][35].

A. Abstraction Levels for Assertion-based Verification We apply our (RT)OS assertions along different refinement levels starting with the abstract RTOS simulation and ending with the full system mode QEMU software emulation as a final step. This approach is based on the flow introduced in Fig. 3 [2] and extended by user mode QEMU emulations for a more efficient transition between both levels. In this refinement, we take system calls as a clear interface between the application software (limited to user space access) and system operations with kernel space access for the execution of privileged instructions. As such, we can identify three RTOS refinement levels:

In our simulations, we apply our aRTOS SystemC library [35] which implements an abstract canonical RTOS model based on SystemC 2.1. The library provides basic functions for SW task and ISR (Interrupt Service Routine) synchronization, context switching, and scheduling. The actual RTOS context is defined and implemented by a sc_rtos_context module. Each instance of the RTOS context corresponds to a separate execution unit, i.e., processor core. It provides functions to register/deregister tasks and ISRs as well as managing their synchronization and performing RTOS context switches. SW tasks and ISRs are implemented as SC_THREADs. For a smooth refinement with user mode QEMU emulation, we can apply Translated Blocks (TBs) segmentation with corresponding interaction points for time annotation. SW tasks are SC_THREADs executed in an SC_RTOS_MODULE. As shown in Fig. 4, aRTOS implements an explicit state model with three basic states: waiting, ready, and running [7]. We later also refer to waiting as blocked and to ready as preempted to simplify our PSL assertions. Entering the blocked state means that the task was running and is waiting for a blocked resource for synchronization. A task enters preempted, when it was preempted and needs to get running again to complete.

Figure 4. Different aRTOS States

IV.

ASSERTION-BASED VERIFICATION FOR HDS

The notion of Assertion-based verification (ABV) [5] is based on the declarative definition of systems properties by the means of functional assertions. Once defined, the formalized properties can be applied to different verification technologies, which are provided by the underlying verification tools like formal verification or simulation. Assertions are defined by a Hardware Verification Language (HVL) like the IEEE standards SystemVerilog [19], e [21], and PSL [20]. Meanwhile, large assertion libraries and methodological guidelines became available to supplement the tooling and standardization efforts, such as the Verification Methodology Manual (VMM) [6] and the Open Verification Methodology (OVM) [29]. As assertions typically define properties at the interface of a component, their main benefit is their massive reuse at different levels of abstractions. This makes them also potentially applicable for

Abstract RTOS Model. At this level, the SW has to be divided into segments separated by interaction points. An interaction point is either determined by (i) an abstract RTOS system call, (ii) a communication operation (e.g., bus access, I/O), and (iii) a synchronization with the simulation kernel for advancing the simulation time, where (ii) and (iii) should be implemented as specific system calls. For (iii) we can take QEMU Translated Blocks (TBs) for segmentation. User Mode QEMU. At this level, we can keep the SW code without modification as long as each interaction point can be implemented as a system call. Otherwise, remaining interaction points have to be replaced by a system calls or removed. For this, we have modified the QEMU kernel by retargeting the system call exception handling routine of QEMU to calls of the SystemC aRTOS library. Full System Mode QEMU. At this level, each abstract RTOS system call has to be refined to a native RTOS system call. In contrast to the previous refinements, this may require considerable effort to port system calls to the target operating system. If adequately defined, we may apply the same assertions to all three levels under the condition that it is possible to insert explicit state and scheduling information into the code of the abstract and target operating system which just requires little modifications which at least presumes the availability of the (RT)OS source code, like it is the case with the different Linux variants. The refinements comes at the costs of increasing simulation times. Our experiments showed that, in the first step, User Mode QEMU approximately doubles the simulation time compared to aRTOS simulation. This little increase is due to the efficient of QEMU's binary translation. From user mode to full system mode, we measured an increase between 5x 150x, dependent on the number of synchronizations between SystemC and QEMU [3]. With less processor utilization, the difference between those levels can even be higher. The next subsection gives a short introduction to PSL before we introduce the application of PSL for the verification of real-time properties in the context of the previous abstraction levels.

B. The Property Specification Language (PSL) The IEEE P1850 Property Specification Language (PSL) [20] is composed of several layers which support the reuse of PSL statements. At the Boolean layer, Boolean expressions describe system state properties at a point in time. Temporal operators and sequence expressions (Temporal layer) are used to define the relationship between those states over the time. Regardless to the respective abstraction level, an EDA tool typically requires that the evaluation of assertions has to be triggered by a specific clock. As such, PSL properties must refer to the clock operator @ in order to define a Boolean clock expression. Therefore, the system state must be sampled in the clock cycle, where the clock expression is true. At the Modeling layer, input stimuli, complex behavior and auxiliary logic can be defined by different hardware description languages (flavors) like Verilog and VHDL. At the Verification layer, socalled verification directives define instructions for individual verification tools, e.g., assert, assume, cover. On top of this, PSL properties are grouped into separate verification units (vmode, vprop and vunits) which are bound to the specific component to be verified. C. RTOS Verification Library (RVL) For real-time property verification, we implemented an RTOS Verification Library (RVL) based on the principles of the Open Verification Library (OVL) [1]. The RVL provides so-called checkers with well-defined interfaces and PSL vunits bound to those checkers. Fig. 5 illustrates the general RVL verification architecture, the binding of PSL properties to checker modules and their instantiation in the virtual prototype. For this, checker modules are instantiated and connected via ports and signals to the given SystemC model under test. As an example, in Fig. 5, Context A Checker is an instance of a RVL checker module which verifies RTOS Context A.

property (see also next subsection). The other three signals refer to signals providing RTOS internal information: preemption, scheduling and state (of the tasks in the task set). assert_arrival_time verifies the point in time when a task becomes ready for execution. assert_start_time checks when a schedulable task must start executing, i.e., to become running. Here, the Boolean signal required_start_time indicates the specific start time event. assert_absolute_deadline (finishing time) defines the time a task must finish its execution. The assert_relative_deadline checker verifies the time window until a task must finish its execution. Here, the parameters required_start_time and deadline are signals which define the execution window. In order to support fault tolerance analysis and the design of soft real-time tasks, assert_max_tardiness can be used to verify if the time a task remains running after its deadline not exceeding a specific limit. Complementary to [7], assert_reach_state verifies if a task or an ISR reaches a specific state (rstate). The assert_precedence checker defines the dependence between two executing tasks and is used to verify a proper scheduling order. Some implementations require the atomic execution of two or more functions due to strict timing requirements. For this, the assert_no_preemption checker also verifies that the current execution of a task is not preempted by another one. assert_arrival_time#(taskid)(pulse, preemption, scheduling, state, required_arrivel_time); assert_start_time#(taskid)(pulse,preemption, scheduling, state, required_start_time); assert_absolute_deadline#(taskid)(pulse, preemption,scheduling, absolute_deadline); assert_relative_deadline#(taskid)(pulse, preemption, scheduling, state, required_start_time, relative_deadline); assert_max_tardiness#(taskid)(pulse,preemption, scheduling, state, deadline); assert_reach_state#(taskid)(pulse, preemption, scheduling, state, rstate); assert_precedence#(taskid1,taskid2) (pulse, preemption, scheduling, state); assert_no_preempted#(taskid)(pulse, preemption, scheduling, state); Figure 6. RVL Checkers

Figure 5. Application of the RVL

The RVL is implemented along the basic concepts of [7] which identifies a set of basic properties for real-time tasks: arrival time, deadline, start time, finishing time, lateness, tardiness and laxity.1 We have defined PSL assertions for those properties to be applied in the checker modules. Fig. 6 gives an overview of the corresponding checkers with their interface definitions. Checkers are implemented for the verification of real-time tasks which are identified by the individual taskid. The first four ports define standard signals where pulse refers to a high level asynchronous event which triggers the evaluation of the 1

We ignore other properties like criticalness and value as we consider them as either redundant or as parameters for the scheduler.

In real-time systems, time-triggered busses, like FlexRay, connect different communicating nodes and reserve communication slot for each individual node (or task). In this context, we can also define real-time checkers, which verify bus scheduling properties as given in Fig. 7. assert_no_reading_in_slot#(taskId,slotId)(reading); assert_no_writing_in_slot#(taskId,slotId)(writing); assert_reading_after_slot#(taskId,slotId)(reading); assert_writing_before_slot#(taskId,slotId)(writing); Figure 7. RVL Checkers for Time-Triggered Busses

assert_no_reading_in_slot and assert_no_write_in_slot verify that a task given by a taskId must not read/write in the slot identified by slotId, where the signals reading and writing represent reading and writing events generated by the bus. For synchronizing tasks with the bus schedule, assert_reading_ after_slot defines that a task taskId must read from a slot after slot slotId, so that the task accesses the most recent information

available in the buffer. Similarly, assert_writing_before_slot defines that task taskId must write into a time slot time slot before slotId. To finally give one example for an assertion, Fig. 8 shows the definition of the start_time property that is applied by the assert_start_time checker. This property verifies when a schedulable task must start executing. Parameter t indicates which task is verified. The Boolean rstart_time is a signal, which indicates the specific start time (rising edge) event. The property states that when rstart_time holds, it implies that the state of task t state[t] must be WAITING or READY in the previous cycle (prev) and RUNNING in the current cycle (the cycle which the property is triggered). start_time(const t; boolean rstart_time) = rstart_time ->(prev((state[t] == WAITING))|| prev((states[t]==READY)))&&(state[t]==RUNNING) Figure 8. PSL start_time Property

D. Synchronization of RTOS Assertions Assertions are typically applied in the context of cycleaccurate simulations and are presumed to be triggered by a low level high frequency clock. However, our application is specified for clockless TLM-based simulation, so that we need a dedicated asynchronous trigger, i.e., the pulse, for the evaluation of the checkers. The pulse is a combination of several events. For RTOS related properties, these are mainly (i) the state changes of tasks, (ii) scheduling events indicating when a task is scheduled by the (RT)OS scheduler, (iii) a preemption event indicating that one task has been preempted, (iv) additional user defined timers for the inspection of specific periodic or aperiodic points in time. Additionally, for real-time property verification of busses, at least reading and writing events have to be available. For the impact of different triggers on the evaluation of the properties, let us consider the scheduling example of the task set in Fig. 9. That figure applies a RTL clock as a highfrequency clock. It can be easily seen that the rising edge of that clock matches each single change of the task schedule and thus also correctly triggers the evaluation of the assertions at any time. In contrast, the rising edge of the low frequency clock does neither adequately match the return from the ISR I1 and the scheduling of task T2. On the other hand, we can see that we can catch all changes of task states by a dedicated asynchronous pulse.

It can be easily seen by this example that an adequate pulse is mandatory for a correct and efficient evaluation of the assertions. This basically requires the emission of events from the RTOS task scheduler. However, as long as the (RT)OS source code is available, this comes at low costs as it only needs a few local modifications in the code of the abstract RTOS and the target RTOS. V.

APPLICATION RESULTS

In order to measure the detailed impact of the granularity of the pulse, we evaluated the presented approach by the verification of a realistic fuel injection module of an automotive case study with Mentor Graphics Questa 6.2. Fig. 10 presents the architecture with two SystemC modules implemented on top of the RTOS model: the Engine and Fuel Controller. The engine model is executed in a periodic 5ms task and provides sensor signals like throttleAngle, (engine) speed, manifold absolute pressure (map), and exhaust gas oxygen (ego). The fuel controller model is implemented by two 10ms periodic tasks. The first one calculates the fuel rate and the second one detects and corrects sensor faults.

Figure 10. Case study of a fault tolerant fuel injection system

We applied 3 different synchronization policies for this example: (i) an aperiodic high level pulse as it was introduced in the previous subsection, (ii) a low frequency clock determined by the minimum common divisor of the periodic task with a period of 1ms, and (iii) a high-frequency clock defined as 50% faster as the fastest simulation event with a period of 5us. The last two policies basically resemble two different alternatives of a clock based RTL synchronization. Our studies have shown that the PSL checkers for TLMbased multi level verification adequately matches all verification points with a simulation overhead of not more than 40%. The simulation with the low frequency clock of the presented example was 19.72% faster but missed a significant amount of verification points. The high frequency clock increases simulation time of the example by 32.54% compared to the aperiodic pulse, and even then it was not able to match all verification points. We finally applied the clock of the target processor running at 25 MHz with a 4ns period, which guarantees that all verification points are matched. This simulation was 20.000x slower than the previous simulation runs. This clearly indicates that the latter is not a real alternative to reach a fast high level simulation. VI.

Figure 9. Three synchronization polices for PSL assertions

CONCLUSIONS

In this paper, we presented the basic principles of SystemC based simulation of HdS and an approach for RTOS refinement from an abstract RTOS model to full system mode QEMU emulation. Based on this refinement, we applied IEEE P1850 PSL to define a general set of real-time properties for RTOS tasks and time-triggered busses. In general, our results show that assertion-based simulation is well applicable for HdS

components and we can overcome the inefficient synchronization of current EDA tools which presumes a high frequency RTL clock. However, our results also show that the synchronization policy has to be carefully selected to run meaningful simulations. This and the definition of standard interfaces for assertion-based simulation at multiple levels certainly require more studies. ACKNOWLEDGEMENTS The work described herein was partly funded by EU through the COCONUT project (FP7-ICT-3217069), by the DFG through the SFB 614 (Self-Optimizing Systems for Mechanical Engineering), and by the German Ministry of Education and Research through the SANITAS (01M3088) and the VERDE projects (01S09012). REFERENCES [1] [2]

[3]

[4] [5] [6] [7] [8]

[9]

[10]

[11]

[12]

[13]

[14] [15]

Accellera. Open Verification Library. Available at http://www.accellera.org/activities/ovl. Accessed in march, 2010. M. Becker, G. Di Guglielmo, F. Fummi, W. Mueller, G. Pravadelli and T. Xie. RTOS-Aware Refinement for TLM2.0-based HW/SW Designs. In Proc. of the Design Automation and Test in Europe (DATE). Dresden, Germany, 2010. M. Becker, H. Zabel and W. Mueller. A Mixed Level Simulation Environment for Stepwise RTOS Software Refinement. In L. Kleinjohann, B. Kleinjohann (eds.). IFIP Conference on Distributed and Parallel Embedded Systems (DIPES). Springer Verlag, 2010. F. Bellard. QEMU, a fast and portable dynamic translator. In Proc. of the USENIX Annual Technical Conference, pp. 41–46. 2005. J. Bergeron. Writing Testbenches – Functional Verification of HDL Models. Kluwer Academic Pub., 2003. J. Bergeron, E. Cerny, E., A. Hunter and A. Nightingale,. VMM for SystemVerilog. Springer Verlag, 2005. G. C. Buttazo. Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications. Kluwer Academic Pub., 1997. L. Cai and D.D. Gajski.. Transaction Level Modeling: An Overview. In Int. Conference on Hardware/Software Codesign and System Synthesis(CODES+ISSS). Newport Beach, USA, 2003. S. Chakraborty, S. Künzli and L. Thiele. A General Framework for Analysing System Properties in Platform-Based Embedded System Designs. In Proc. of the Design, Automation and Test in Europe Conference (DATE). Munich, Germany, 2003. A. Clouard, K. Jain, F. Ghenassia, L. Maillet-Contoz, J.-P. Strassen Using transactional level models in a SoC design flow. In W. Mueller, W. Rosenstiel, J. Ruf (eds.) SystemC – Methodologies and Applications. Springer-Verlag, 2003. P. Destro, F. Fummi and G. Pravadelli. A Smooth Refinement Flow for CodesigningHW and SW Threads. In Proc. of the Design Automation and Test in Europe (DATE). Nice, France, 2007. W. Ecker, W. Mueller and R. Doemer. Hardware-dependent Software – Introduction and Overview. W. Ecker, W. Mueller, R. Doemer (eds.) Hardware dependent software - Principles and practice. Springer-Verlag 2009. A. Gerstlauer, H. Yu and D.D. Gajski. RTOS Modeling for System Level Design. In Proc. of the Design Automation and Test in Europe (DATE). Munich, Germany, 2003. F. Ghenassia (ed.). Transaction-Level Modeling with SystemC. Springer Verlag, 2005. Z. Glazberg, M. Moulin, A. Orni, S. Ruah and E.l Zarpas. PSL: Beyond Hardware Verification. In S. Ramesh and P. Sampath (eds.). Next Generation Design and Verification Methodologies for Distributed Embedded Control Systems. Proc. of the GM R&D Workshop, Bangalore, India, Jan. 2007.

[16] M. Gligor, N. Fournel and F. Petrot. Using binary translation in event driven simulation for fast and flexible MPSoC simulation. In Proc. of the Int. Conference on Hardware/software codesign and system synthesis (CODES+ISSS). Grenoble, France, 2009. [17] M. A. Hassan, K. Sakanushi, Y. Takeuchi and M. Imai. RTK-Spectron: A simulation model of an itron based rtos kernel in systemc. In Proc. of the Design Automation and Test in Europe (DATE). Munich, Germany, 2005. [18] Y. Hwang, S. Abdi and D.D. Gajski. Cycle-Approximate Retragetable Performamnce estimation at Transaction Level. In Proc. of the Design Automation and Test in Europe (DATE). Munich, Germany, 2008. [19] IEEE Computer Society. IEEE Standard SystemVerilog Language Reference Manual – IEEE Std 1800-2005. IEEE Computer Society, New York, NY, USA, 2005. [20] IEEE Computer Society. IEEE Standard PSL Reference Manual – IEEE Std 1850-2005. IEEE Computer Society, New York, NY, USA, 2005. [21] IEEE Computer Society. IEEE Standard e Reference Manual – IEEE Std 1647-2008. IEEE Computer Society, New York, NY, USA, 2008. [22] IEEE. IEEE Standard SystemC Language Reference Manual – IEEE Std 1666-2005. IEEE Computer Society, New York, NY, USA, 2006. [23] Y. Lahbib, M.-A. Ghrab, M. Hechkel, F. Ghenassia and R. Tourki. A New Synchronization Policy between PSL Checkers and SystemC designs at Transaction Level. In Proc. of the Design and Test of Integrated Systems in Nanoscale Technology (DTIS), pp.85-90. 2006. [24] J. Lehoczky. Fixed Priority Scheduling of Periodic Task Sets with Arbitrary Deadlines. In Proc. of the Real-Time Systems Symposium (RTSS), 1990. [25] A. Nohl, G. Braun, O. Schliebusch, R. Leupers, H. Meyr and A. Hoffmann. A Universal Technique for Fast and Flexible Instruction-Set Architecture Simulation. In Proc. of Design Automation Conference (DAC). New Orleans, USA, 2002. [26] M. F. S. Oliveira, H. Zabel and W. Mueller. Assertion-Based Verification of RTOS Properties. In Proc. of the Design Automation and Test in Europe (DATE). Dresden, Germany, 2010. [27] OSCI. TLM Transaction Level Modeling Library, Release 1.0. OSCI April 2005. [28] OSCI. TLM-2.0 Reference Manual. SW version 2.0.1, July 2009. [29] OVM. Open Verification Methodology. 2005. Available at: http://www.ovmworld.org. [30] H. Posadas, J. A. Adamez, E. Villar, F. Blasco and F. Escuder. RTOS modeling. In SystemC for Real-Time Embedded SW Simulation: A POSIX Model. Design Automation for Embedded Systems, vol. 10(4), 2007. [31] G. Schirner, A. Gerstlauer and R. Dömer. Abstract, Multifaceted Modeling of Embedded Processors for System Level Design. In Proc. of Asia and South Pacific Design Automation Conference (ASP-DAC). Yokohama, Japan, 2007. [32] G. Schirner and R. Dömer. Fast and Accurate Transaction Level Models using Result Oriented Modeling. In Int. Conference on Computer Aided Design(ICCAD). San Jose, USA, 2006. [33] S. Schliecker, A. Hamann, R. Racu and R. Ernst. Formal Methods for System Level Performance Analysis and Optimization. In Proc. of the Design Verification Conference (DVCON), San José, USA, February 2008 . [34] Y. Yi and, D. Kim and S. Ha. Fast and Accurate Cosimulation of MPSoC Using Trace-Driven Virtual Synchronization. In IEEE Trans. on CAD of Integrated Circuits and Systems, vol. 7, n. 12, 2007. [35] H. Zabel, W. Müller and A. Gerstlauer. Accurate RTOS Modelling and Analysis in SystemC. In W.Ecker, W. Müller, R. Dömer(eds). Hardware Dependend Software – Principles and Practice. Springer Verlag, 2009. [36] H. Zabel and W. Müller. Noise injection in abstract RTOS Simulation in SystemC. In Proc. of the Design Automation and Test in Europe (DATE). Nice, France, 2009. [37] H. Zabel, W. Mueller. An Efficient Time Annotation Technique in Abstract RTOS Simulations for Multiprocessor Task Migration. In L. Kleinjohann, B. Kleinjohann (eds.). IFIP Conference on Distributed and Parallel Embedded Systems (DIPES). Springer Verlag, 2008.