an ideal api for rtos modeling at the system abstraction level

An Ideal API for RTOS Modeling at the System Abstraction Level

Adnan Shaout, Khalid Mattar, and A. Elkateeb,The University of Michigan-Dearborn

The Electrical and Computer Engineering [email protected]

process from another and the ability to model the affect oftask serialization and preemption on a processor when usingRTOS. As shown in table 1, current specification languageslack features needed to support RTOS modeling.

D. Outline ofthe paper

In section 2, we compare five RTOS modeling techniquesthat have been proposed in the literature. In section 3, wedescribe the requirements for designing an RTOS model ontop of a SLDL. In section 4, we define an ideal API for a

D RTOS d rT bI 1 S

C. Approaches for RTOS modeling and simulation

Le Moigne, et al. in [5] describe three approaches forsupporting RTOS modeling at the system level.

1) Using a model and a simulator dedicated to a specificRTOS. This approach provides precise results since themodel is designed for a specific RTOS. The drawbackof this approach is that it limits design spaceexploration to the selected RTOS.

2) Using a generic abstract RTOS model with its ownsimulation engine. This approach addresses the issue oflimiting the design space exploration by using a genericabstract RTOS model. However, since this approachuses its own simulation engine, it requiressynchronizing RTOS simulation with hardwaresimulation which uses the simulation engine providedthe SLDL.

3) Using a generic abstract RTOS model on top ofexisting SLDL. This approach is not limited to specificRTOS since it provides a generic model. In addition, itutilizes existing SLDL primitives and simulationengines. Thus, avoiding potential synchronizationdifficulties. Approach # 3, using a RTOS model on topof existing SLDL, is the main focus of this paper.

a e : upport or roo emgFormal Languages Real-time Languages HOt. SlDL

Supplltb"RTOS LOTOS SOL EstereI StatIlChaIts 'v'HOL \lerilog HilIdwanlC SpecC SyaraC

~

Dynamicproc;tlftl N N N N N N N N f1creetlon

Proc:eescortrol N N F ? N N N N NZ(6lJI!lpend, re&lJITle, kill,re&et)

SuP!Dtb" N N F[2] P(3] N N N N NPreemJm1Scheduler modeling N N N N N N N N N3

(l-)l'uIly,uppJrl.ld (l')JldIildl)'IIJ'Pl'lhld (N)IaJlIIIJIIUt.ed

Vwa 1Ib_¥iWmO in SystImC 21JApIQPOHd~JgSyUnCliUppgrta~~lIl\rQIl'l

~ CumlIlUynotsupport. blJtincklded in5yItemC 3.0 specification (4)

A. System Level Design

System Level Design is concerned with addressing thechallenges encountered in designing heterogeneousembedded systems. In System Level Design, complexitiesare managed by starting the design process at the highestlevel of abstraction (System Level) and utilizing automateddesign methodologies to enable step-wise refinementsduring the design process [15]. Designing at a higher levelof abstraction reduces the number of components withwhich the designer has to deal with, and thus increasingdesign productivity. System Level Design maps a high-levelabstract specification model of an entire system onto targetarchitecture [16].

Hardware/Software co-design (also referred to systemsynthesis) is a System Level Design top-down approach thatstarts with system behavior, and generates the architecturefrom the behavior. It is performed by gradually addingimplementation details to the design. Generally, Hardware /Software co-design consists of the following activities: (1)specification and modeling, (2) design and refinement and(3) validation [17].

B. System Level Design Languages (SLDL) and RTOSmodeling

Specification is the first step in the co-design processwhere the system behavior, at the system level, is captured.Specification languages, specifically System Level DesignLanguages (SLDL), can model and simulate concurrentbehaviors, and have primitives to allow modeling ofsynchronization and time delays. In addition, SLDL haveprimitives to control execution of a process via events.However, most SLDL lack primitives for controlling one

I. INTRODUCTION

Abstract-In System Level Design, specification languages,especially System Level Design Languages (SLDL), are used tobuild high level models to allow fast design space exploration,and to assist designers in exploring alternatives early in thedesign process. Current SLDL languages lack built-in supportfor modeling RTOS at the System Level, and specific RTOSimplementation can not be used directly in models at theSystem Level. In this paper, we define and provide theprimitives for an ideal API for a generic RTOS model to beused on top of existing SLDL. The model is based on the keyfeatures provided by a typical RTOS, and is generic such thatit can be used with any SLDL. Using the API defined in thispaper, we describe the refinement of the RTOS model so thatthe model can be integrated into the System Level co-designprocess.

978-1-4244-2034-6/08/$25.00 ©2008 IEEE.

Authorized licensed use limited to: PONTIFICIA UNIV CATOLICA DO RIO GRANDE DO SUL. Downloaded on May 6, 2009 at 18:46 from IEEE Xplore. Restrictions apply.

generic RIOS model derived from the key featuresprovided by a typical RIOS. Section 5 describes the RIOSmodel using the API we defined.

In section 6, we describe in the steps for refining theRIOS model so that it can be used in as part of the codesign process. Lastly, section 7 concludes the paper.

II. COMPARISON OF RTOS MODELING TECHNIQUES

Several RTOS modeling techniques using System Level

Design Languages (SLDL) have been proposed in theliterature to enable assessing the dynamic real time behaviorof embedded system at the System Level. The majority ofRTOS modeling techniques in the literature are based on theSystemC SLDL. Only two techniques were found based onSpecC. Table 2 provides a comparison of five RTOSmodeling techniques.

Table 2: Comparison ofRTOS modeling techniques

Yu etal. [8] Le Moigne et at. [5] H..... et ... [7] T ornlyama et al. [111 Hastono .. al. [12)

1 Modeling RTOS model on top of ROTS modet on top of ROTS model on top Using native spece RTOS model on top onapproach SLDL SLDL based on MCSE ofSLDL exception handling & SLDL

methodology [131 COI'1CUT'eI1CY constructs

2 Und_lying 8LDL Specc SystemC Systemc SpecC SystlBmC

3 How are tasks SpecC behaviors & SystemC threads that POSIX thf"88d5 & SpecC behaviors. Tasks SystlBmC th'vad& &modeled? Task Control Block use SystemC events Task ConIr"ol Block are modeled as runing Task Control Block

(TCB) to hold task (TCB) to hold task in parallel using the -par" (TCB) to hold taskcharactaistics dlanIcteristics space construct dlanIct&is1ics

4 Task states Supports tasks state Reedy, running & waiting Idle. ready, executi ng No explicit stB1es are Reedy, runring.supported by transition. but 1he & preempted defined preempted, postponedmodel cifferent states are not & sleep

mentioned in the paper

5 Howta.ka Esllmatad at the block Estimated using a delay Not specified Not specified Uses a stochasticexecution level. Delay primllves procedure based on the timing model based onestimated? inserted at the end of worK cbne by [14] the Gumbel probabi ity

each block. density function

8 How I. the SpecCI~acec.ss C++ object with RTOS SystemC thread that specC behaVtor Which SysternC th'vad thatscheduler method that takes the procedures called by runs con1lnuously run& In parallel with the Invokes the appropr1atemodeled? &Che<lJUng poley as tasks appllca1lon tasks fu1cIIon based on the

parameter. and Is scheduIlng polleyImplemented as specC selectedchannel

7 Is scheduler No Yes No No Nooverheadmodeled?

8 Support different Implements EDF only. Yes. Implements different Yes. Implemen1s No. only fixed priority Yes. Supports 1hescheduling but capable of po.des. SUpports FCFS, Round Robin, pr-eempUve foIowing polldas.policies? ~por1Ingother defining addttonal RM, EDF static event driven

policies poldes schecIuIi ng, static time-triggered scheduling,static priority basedschedJIing &preemptive scheduling(RMS, EDF)

.. Support Yes. Yes Yes Yes Yes. Using the RTOSpreemption await() primitivemodeling?

10 Accuracy of Dependent on model's Independent of any clock Dependent on the Not specified I Unknown Depends ona~cypreemption clock accuracy consideration granularity of tBsks of estimated taskmodeling (granularity of tBsks delay (estimated task execution

delay) execution 1Ime)

11 Supportt_k Yes. Provi des Yes. Provides primitives Yes. Provides Yes. specC "try-internJpt"' Yes. Providescontrol (auspend, "suspend"' and & events to support -suspend-, "resume'· constructs are used to ''suspend"', '"resumell

resume. tenninate) "resume". "end" llsuspend"' & "resume". & -mrminate- n'lOdelllresurne" & and llferminate"primitives Does not prooyIde a primitives IIsuspend" primitives

terminate primitive

12 Support dynamic Yes. Model provides Yes Yes No Yestaak creation ''fol1<."'' & "join"

primitives

13 Support Yes. Model provtdes Yes. Supports events, Yes. ProvIde6 -walt"'. Yes. Using specC native Yes. ProvideseynchronIzstlon "walt" & "MaUry" queues & shared -notifY' primitives. "walt" & "MaUry" pr1rn1Sves fOrmodeling? pr1m1lves. Dennes variables. Deftnes "receive" & constructs ''suspend''. '"re&ume".

mailboX, mu18x, queue -send- pr1rn1tives ''kill''& semaphores using based on the RTOSthe RTOS "waif' & -waif' & "notif('''notify"' primitives primitives

14 RTOSmodel SpecC simulation SystemC simulation SystemC simulation SpecC simu.tion engine SystemC simulationalmulation engine engine engine engine engine

15 Provide Yes. Yes Yes No Noautomatedrefln.....nt tool?

18 Refln.-nent tool , No Yes. Tool available from No No Nomodel available C::9FIY~nt.P~jgncommercially?

r Via SC_spBWn(} In Sy.emC 2.1


III. DESIGN CRITERIA FOR RTOS MODELING AT SYSTEMLEVEL

As mentioned earlier, the objective of modeling RTOSat the System Level is to accurately model the real timeand dynamic behavior of a system, and to identify anytiming constraints early in the design process. In thissection we describe the major criteria / requirements fordesigning an abstract RTOS model on top of existingSLDL [5, 6].

1) Support all key features of a typical RTOS. A RTOSmodel must provide features such as:

a) OS management services. Supports initializationof the RTOS and its data structures.

b) Scheduling service

i) Support several scheduling polices

ii) Support modeling of scheduler timingproperties (i.e. context switch)

c) Task management services. Supports bothperiodic and non-periodic tasks

d) Tasks synchronization services

e) Support modeling of interrupts

t) Support modeling of preemption

g) Support modeling of time

2) Requires minimal modeling efforts in terms ofmodeling refinement and simulation overhead.

3) The RTOS model should be generic, and not limitedto a specific SLDL so that it can be used on top ofdifferent System Level Design Languages (SLDL).

4) The RTOS model should be designed such that it caneasily integrate into existing System Level co-designmethodologies.

5) The RTOS model should be independent of anyspecific RTOS implementation.

IV. AN IDEAL API FOR AGENERIC RTOS MODEL

In this section we define and describe an API of ageneric RTOS model. The API defines key services foundin typical RTOS [6-8]. The API for the RTOS modeldefines the interface between the system application andthe RTOS model.

A. OS management services

The main functionality of the OS management services isto initialize the RTOS data structures and to start thescheduler. Table 3 provides the API for the OSmanagement services.

Table 3: API for OS management services

DeKription Parameter Retum

void rtos_init() Initializes the RTOS None Nonedata structures

void Starts the None Nonestart_scheduler(schedu multitaskingUOLPOUcy) scheduler. The

scheduling policy ispassed as aparameter to thisfunction

void scheduler() Selects a ready task None Noneto execute.Depending on thescheduling policy,the appropriatealgorithm is used toselect a task to run.

B. Task management services

The purpose of the task management services is toprovide a mechanism so that the system application can bespecified as a set of tasks. In addition, the API providesservices to allow preemption. Tables 4 and 5 providedetails bout the API for the task management services

Table 4: API for task management services (1/2)

fkscription Parameter Return

void (Rate_task ~reates atask and lark id: a'Jnique None(task_id. state, ...) iletL:leS ib identitication for ea:h task

p~ramete~s. state: :l task can be in on offour slcll~ tlOmdnt, rl~(tLY~

runnin~ cr 5U.<>?cnd\Xl. Tt.c

(brmant state.: is th~ dcfaul:

stat~ ofnnewly crented task.priori~.': an integer valuerepresenting tre ta~k jriority.The bwer the v:l1ue thehigh'--T the priority.J~~1()d: a1 int~gcr vah:.c

r~prcsl.:ntin~ lr.~ rdcClSl; tncofthe taskweet: an :.r:tegervdJerepresenting Wors: ~~"ase

E.~e~ution TiJr.e.b~el: an int~gcr 'r'alul:representing ~~t rase

Ex~:utinn Tirr~.

void suspend task Suspends a task b) tiuk td N:)ne

(task_id) ~hanging its st.1te

to "suspe:1ded"

Void resume_task Resumes a ca!k id none(task_id) suspended tasK1 by

:hanging its stateto "ready'


Table 5: API for task management services (2/2)lJes£ription .P-..nameler Return

void end.JJeriodic_ta.,k Supports modeling ofperiodic taskjd None(task_ld) tasks

When a periodic task finishesits e.x.ecution. it Invokes theend periodic task(task id)which in tum invokes thereset..Jleriod;c taskO primitive

"oid Resets the TeB of a periodic tasL:_id Nonereset.JJeriodic_task task, and then invokes(task_ld) scheduler()

void end...Jask(task_id) Supports modeling ofnon- task_jd Noneperiodic tasks.\Vhen a n(lll-~riouic tasktinishes execution. it invokesend_task(task)d), whichinvokes kill ta.'\k(ta.~k id).

void IdIl_task(task_ld) Kills a non-periodic task, and task_id Nonethen mvokes the scheduler().

C. Task synchronization services

The task synchronization services provide means tosynchronize concurrent task, and to enable inter-taskcommunication. Table 6 shows the API for the tasksynchronization primitives

execution, it invokes the end_periodic_task() primitive tonotify the scheduler that it has finished execution. Fornon-periodic tasks the end_task() primitive is used tonotify the schedule when a task completes its execution.

B. Scheduling model

The scheduler is the heart of the RTOS. Its mainpurpose is to select the next task to run from the list ofready tasks according to a scheduling policy.

To accurately assess the influence of scheduling on thesystem's real time performance at the System Level, boththe scheduler behavior and its timing properties [5] needto be modeled. The scheduler behavior is characterized byits scheduling policy. The scheduler timing properties arecharacterized by the scheduler latency (how long it takesto select a ready a task to execute), and by the contextswitching duration (for both context-save and context-loadoperations). The RTOS model described in this papersupports modeling of both properties. The schedulingpolicy is selected by passing a parameter to thestart_scheduler() primitive. The timing properties of thescheduler are defined in the RTOS configuration file.

In the RTOS model, tasks can be in one of four states:dormant, ready, running or suspended. When a task iscreated using the create_task () primitive, its default stateis the dormant state. A task in the dormant state goes intothe ready state when (1) a periodic task enters a newexecution time or (2) a non periodic task has all requireddata to execute. A ready task goes to the running stateonce selected by the scheduler based on the schedulingpolicy used the RTOS model. When in the running state,a task goes to the ready state when (1) preempted by ahigher priority task or (2) the time slice allocated to thetask expires. When a task in the running state requiresdata or a resource that is not available, it goes to thesuspended state. When the resource becomes available,the suspended task goes to the ready state so that it can bescheduled. When a periodic task finishes its execution, itgoes to the dormant state. A periodic task in the dormantstate goes to the ready state when its release time is up.

C. Timing and Preemption model

In System Level models, the execution time of a task ismore important than the exact functionality of the task.Execution times can be estimated at the statement level orthe behavior level [7]. At the behavior level executiontimes can be estimated based on the task's average and/orworst case execution timings. Most SLDL provideprimitives to model timings and delay. The RTOS modeldescribed in this paper provides the rtos_delay() primitivefor time modeling. To ensure synchronization between theRTOS model and SLDL simulation engine, the RTOSrtos_delay() primitive is implemented as a wrapper aroundthe SLDL delay primitive [7]. The execution time of atask is modeled by passing the estimated execution time asa parameter to the RTOS rtos_delay() primitive.Typically, the code of a task is divided into atomic blocks

Table 6' API for task synchronization services

D. Time servicesTable 7' API for time services

V. THE RTOS MODEL

A. Task model

A Task must be modeled such that it holds allinformation needed for task execution, and it allowspreemption and resume by the scheduler. Tasks aremodeled using the Task Control Block (TCB) model [9].The TCB model uses a circular linked list for the systemtasks. The TCB structure for each task holds informationsuch as task_id, state, priority, period, Worst CaseExecution Time (wcet) and Best Case Execution Time(bcet). The create_task() primitive is used to create a taskand populate its TCB. To support preemption, the modelprovides the suspend_task(), and resume_task()primitives. The model provides two primitives to supportperiodic tasks. When a periodic task completes its

Description Parameter Return

void rtos_delay(time) Introduces a time delay as Time Nonespecified in the function'sparameter.It is used lor moddingexecution time ofa task.

Destription Panmftff Return

void nos_wait() Blocks the current task until None Noneanother task cxe(;ules the

1105_notlfy() function.

void Notifies a task which is waiting task id N(mertos_Dotit)'(task_id) on data $yn<:hronization.


b) For each processor in the unscheduled TLMmodel, create an RTGS run time environment,which initializes the internal data structures ofthe RTGS model

5) Task refinement transforms all behavior tasks in theTLM model to RTGS based tasks. Task refinementconsists of the following steps:

a) Step 1: Flatten all hierarchal tasks and parallelprocesses mapped to each processor by creatingnew tasks and processes.

Step 2: For all tasks in the TLM model, insert the RTGSprimitive for task creation along with the parameters thatcharacterize the task (i.e. priority,

Figure 1: RTOS modeling and co-design

b) period, ... ). Using the API defined in this paper,this step inserts the task_create() primitive.

c) Step 3: For all tasks in the TLM model, insert theRTGS primitive responsible for informing thescheduler that the task has completed itsexecution. Using our API, this step inserts theend_periodic_task() primitive for periodic tasks,and the end_task() primitive for non-periodictasks.

6) Synchronization refinement wraps all SLDLsynchronization primitives in the TLM model withRTGS synchronization primitives. Using the APIdefined in this paper, synchronization refinementwraps SLDL synchronization primitives with

(i.e. blocks that execute until completion), and the RTGSdelay primitive is inserted at the end of an atomic block todenote the execution time of an atomic block [6].Preemption is based on the timing model build using theRTGS rtos_delay() primitive such that preemption occursduring the time delay. The suspend() and resume() RTGSprimitives are used to model Interrupt preemption.

D. Synchronization model

Synchronization of tasks in a multitasking system iscritical to allow data and resource sharing, and ensure dataintegrity. The purpose of the RTGS synchronizationmodel is to provide services to synchronize concurrenttasks. The RTGS model uses two primitives: rtos_wait()and rtos_notify() for synchronization.

The rtos_wait() primitive blocks a task until another taskinvoke the rtos_notify() primitive. When a task is blockedwaiting for data it goes to the suspended state. Thertos_notify() primitive signals a suspended task for theavailability of data. At such point, the task goes from thesuspended state to the ready state.

VI. RTGS MODELING AND CO-DESIGN FLOW

During the design & refinement stage of the co-designprocess, the specification model is partitioned intohardware and software components. Yu et al. [10] refersto the result of the hardware/Software partition step as theunscheduled Transaction Level Model (TLM). Theunscheduled TLM model is represented using primitivesprovided by the SLDL supported in the co-design system.Tasks (processes) mapped to the same processor need tobe scheduled either statically or dynamically. In order tosimulate the behavior of dynamically scheduled tasks andassess the dynamic real time behavior of the system, ahigh level RTGS model need to be incorporated into theunscheduled TLM model. To do so, the unscheduled TLMmodel must be refined such that it uses the RTGS-basedprimitives instead of / along with the SLDL primitives[10]. This is referred to as model refinement. Figure 1shows model refinement incorporated into the co-designflow.

A. Model Refinement

The purpose of the model refinement is to transform theunscheduled TLM model into a scheduled RTGS-basedmodel. The output of model refinement is a scheduledmodel where each processor runs multiple tasks on top anRTGS model. Based on the work done in [10] and [7], thefour main steps for model refinement are described below.These steps will be described below using the RTGS APIdefined in this paper.

4) RTOS model instantiation includes the followingactivities

a) An RTGS model is selected from the RTGSlibrary based on the scheduling algorithm to besimulated

co

~~.>.oo

co:cCIJ

3E°itoo

'EuEuc'ia:IIcar'M..a

Specification and ~deling

IRTGS ModeIln&crtiatirn I II Tasks Refirement I!~ ---,iISynchroniz<Ecn RefiremeriI iI Preem~ionRefinement I I

SChedUled mOdel


rtos_waite) and rtos_notify() primitives. That way theRTOS can intercept any SLDL synchronizationprimitives, and switch tasks as appropriate.

7) Preemption Refinement replaces all SLDL time delayprimitives with the corresponding RTOS primitives(i.e. rtos_delay() primitive in the API defined in thispaper). As stated earlier, the task code is divided intoatomic blocks, and execution time for each atomicblock is estimated by inserting SLDL time delayprimitives at the end of each block. Based on thisscheme, tasks can only be preempted inside the SLDLtime delay primitive. Therefore, preemptionrefinement is necessary to accurately modelpreemption.

VII. CONCLUSION

Designing at the System Level abstraction layer reducesthe complexities encountered in designing heterogeneousembedded systems. Real Time Operating Systemmodeling at the System Level abstraction layer is criticalsince it allows the designer to asses the real timecharacteristics and dynamic behavior of the system earlyin the design process before committing to a specificRTOS. System Design Languages (SLDL) are gainingwide usage for specifying and modeling heterogeneousembedded systems at the System Level. However, currentSLDL such as SystemC and SpecC lack built-in supportfor RTOS modeling at the System Level. Several RTOSmodeling techniques on top SLDL have been proposed inthe research literature. Only two techniques were foundthat are based on SpecC, the rest are based on SystemC.In this paper, we compared five RTOS modelingtechniques: two based on SpecC and three based onSystemC. All of the SystemC based techniques use theapproach of defining RTOS interface on top SystemC.One of SpecC techniques uses the native SpecC constructsto provide RTOS modeling capabilities, while the otheruses RTOS interface on top of SpecC. A comparison ofRTOS modeling techniques is presented in table 2. Wedescribed in this paper the major requirements forsupporting RTOS modeling at the System Level, anddefined an ideal API to support RTOS modeling on top ofSLDL. The proposed API is based on services providedby a typical RTOS, and is generic such that it can be usedwith any SLDL.

REFERENCES[1] B. Bhattacharya, 1. Rose, and S. Swan, "Language Extensions

to SystemC: Process Control Constructs," in Proceedings ofthe 44th annual conference on Design automation, San Diego,CA, pp. 35-38, 2007.

[2] I. Radojevic, Z. Saleic, and P. S. Roop, "Modeling EmbeddedSystems: From SystemC and Esterel to DFCharts," Design &Test ofComputers, IEEE, vol. 23, no. 5, pp. 348-358, 2006.

[3] M. von der Beeck, "A comparison of statecharts variants," inProceedings of the Third International Symposium OrganizedJointly with the Working Group Provably Correct Systems on

Formal Techniques in Real-Time and Fault-Tolerant Systems,pp. 128-148, 1994.

[4] T. Groetker, "Modeling software with SystemC 3.0," in 6thEuropean SystemC Users Group Presentations, 2002.

[5] R. Le Moigne, O. Pasquier, and 1. P. Calvez, "A generic RTOSmodel for real-time systems simulation with systemC," inProceedings ofthe conference on Design, automation and testin Europe pp. 82 - 87, 2004.

[6] H. Yu and D. Gajski, "RTOS Modeling in System LevelSynthesis," University of California, Irvine, Center forEmbedded Computer Systems Technical Report 02-25, Aug14,2002.

[7] F. Hessel, C. Marcon, and T. Santos, "High Level RTOSScheduler Modeling for a Fast Design Validation," inProceedings of the IEEE Computer Society AnnualSymposium on VLSI, Porto Alegre, Brazil, pp. 461-466, 2007.

[8] "FreeRTOS Homepage," http://www.freertos.org/, Nov, 2007.

[9] P. A. Laplante, Real-Time Systems Design and Analysis:Wiley-IEEE, 2004.

[10] H. Yu, A. Gerstlauer, and D. Gajski, "RTOS scheduling intransaction level models," in Proceedings of the JstJEEE/ACM/IFIP international conference onHardware/software codesign and system synthesis, NewportBeach, CA, pp. 31-36, 2003.

[11] H. Tomiyama, Y. Cao, and K. Murakami, "Modeling fixedpriority preemptive multi-task systems in SpecC," inProceedings of Workshop on Synthesis and SystemIntegration ofMixed Technologies (SASIMI), Nara, Japan, pp.93-100,2001.

[12] P. Hastono, S. Klaus, and S. A. Huss, "Real-Time OperatingSystem Services for Realistic SystemC Simulation Models ofEmbedded Systems," in Proceedings of The InternationalForum on Specification & Design Languages (FDL'04), Lille,France, pp. 380-391,2004.

[13] J. P. Calvez, O. Pasquier, D. Isidoro, and D. Jeu1and,"CoDesign with the MCSE methodology," in EUROMICRO94. System Architecture and Integration. Proceedings of the20th EUROMICRO Conference., Liverpool, UK, pp. 19-26,1994.

[14] Y. Sungjoo, I. Bacivarov, A. Bouchhima, Y. Paviot, and A. A.Jerraya, "Building fast and accurate SW simulation modelsbased on hardware abstraction layer and simulationenvironment abstraction layer," in Design, Automation andTest in Europe (DATE'03) Conference and Exhibition,Munich, Germany, pp. 550-555, 2003.

[15] R. Domer, D. Gajski, and J. Zhu, "Specification and Design ofEmbedded Systems," it+ ti magazine, 01denbourg Verlag,Munich, Germany, no. 3, June 1998.

[16] R. Domer, "System-level Modeling and Design with the SpecCLanguage," Ph. D. Dissertation, Department of ComputerScience, University of Dortmund, Dortmund, Germany, 2000.

[17] M. O'Nils, "Specification, SYnthesis and Validation ofHardware/Software Interfaces," Doctoral thesis, Department ofElectronics, Royal Institute of technology, Stockholm, 1999.


an ideal api for rtos modeling at the system abstraction level

Documents