Präzises Interrupt Scheduling in abstrakten RTOS Modellen in SystemC Henning Zabel, Wolfgang Müller Universität Paderborn, C-LAB Fürstenallee 11, D-33012 Paderborn 8. Januar 2008 Zusammenfassung Bei der Simulation von eingebetteten Echtzeit Systemen zur Analyse von Ausführungszeiten und Scheduling gibt es immer einen Kompromiss zwischen zyklengenauen Ergebnissen und der Laufzeit der Simulation. Mithilfe von abstrakten RTOS Modellen auf Basis von SystemC wird versucht diese Lücke zu schließen. Aktuelle Arbeiten besitzen allerdings nur unzureichende Möglichkeiten zur Modellierung von Interrupt Scheduling und ihren hardwareabhängigen Prioritäten. Unser Ansatz verwendet zwei getrennte Scheduler für Software Task und Interrupt Service Routinen. Diese Trennung erlaubt die präzise Modellierung von Interrupt Prioritäten und Interrupt Scheduling unabhängig von dem eigentlichen RTOS Scheduler.

1 Einleitung Komplexe Steuersoftware, an die harte Zeitanforderungen gestellt werden bezüglich des Einhalten von Zeitschranken, müssen durch ein Echtzeitbetriebssystem (RTOS) mit einem vorhersehbaren (predictable) Zeitverhalten unterstützt werden [BB97]. Echtzeitbetriebssysteme besitzen daher im Gegensatz zu anderen Betriebssystemen die Möglichkeit zur Angabe von Ausführungszeiten und Zeitpunkten (deadlines) zu dem die Ausführung zwingend beendet sein muss. Diese Angaben fließen in dem RTOS mit in die Schedulingverfahren ein. Ein sehr wichtiger Aspekt bei Echtzeitsystemen ist die Behandlung von Interrupts. Wie der Name sagt unterbrechen sie die Ausführung von anderen Realzeit Prozessen und erschweren damit die Vorhersagbarkeit der Zeitschranken. Es gibt verschiedene Ansätze zur Interruptbehandlung [BB97]: Man kann z.B. Interrupts deaktivieren und über Polling die entsprechenden I/O Register abfragen. Der Ansatz erhöht zwar die Vorhersagbarkeit, aber ständiges (aktives) Anfragen der I/O z.B. beim Warten auf eine Beendigung einer Übertragung kann die Prozessorlast erhöhen. Insbesondere bei Low-Power Anwendungen ist dies aber unerwünscht. Wenn man Interrupts zulässt kann man das Warten auf eine I/O-Operation mit Hilfe von Events realisieren. Die Events werden in den Interrupt Service Routinen (ISR) des entsprechenden I/O-Bausteines generiert. Durch die Verwendung eines RTOS kann der Prozessor während dieser Wartezeit einen anderen Task bearbeiten oder in einen Wartezustand wechseln. Der klassische Ansatz zur RTOS Scheduling Analyse ist neben Schedulebility Tests die Simulation der Software in einem Instruktion Set Simulator (ISS) für den Zielprozessor. Die Simula-

tion eines kompletten Netzwerk eingebetteter Prozessoren ist prinzipiell möglich, aufgrund des hohen Rechenaufwands für die einzelnen Prozessoren aber unpraktikabel. Aufgrund dieses Problems haben sich verschiedene Ansätze zur Simulation eines RTOSs in einer Systembeschreibungssprache (SLDL) wie SpecC oder SystemC entwickelt [GYG03, HK07, MPC04, AKS+ 04, PAS+ 06, KBR06]. Die Simulation der Software erfolgt direkt auf dem Simulationsrechner. Ein wichtiger Aspekt bei der Simulation von eingebetteter Software ist die exakte Simulation von Interrupts und ihren Antwortzeiten. Letzteres hat großen Einfluß auf die Reaktionszeit des Systems und des nachfolgenden Schedules der Tasks. Existierende Ansätze für RTOS Modelle beinhalten daher die Simulation von Interrupts und insbesondere die zeitnahe Simulation der Interrupt Service Routine bei Erhalt eines Interrupt Requests. Durch die Aufteilung der Tasks in atomare Blöcke ist die Simulation der Ausführungszeiten innerhalb der SLDL eine Herausforderung. Alle Arbeiten versuchen mit verschiedenen Ansätzen für Interrupts die nicht Unterbrechbarkeit des Simulator zu umgehen. Alle Arbeiten haben allerdings Schwächen bei der Modellierung von Interrupt Prioritäten und der Unterbrechung der Interrupts untereinander. Unser Ansatz verfolgt daher die Idee analog zu RTOS Scheduler für Tasks einen weiteren Scheduler nur für die Interrupt Service Routinen zu verwenden. In diesem Scheduler kann direkt die prozessorabhängige Priorisierung der Interrupts abgebildet werden. Dies geschieht völlig unabhängig von dem eigentlichen Software Scheduler, insbesondere werden die Datenstrukturen des SoftwareScheduler nicht verwendet. Andere Arbeiten simulieren die ISR als hochpriorisierten Task und müssen die ISR entsprechend mit in die Taskmenge aufnehmen. Im folgenden werden zunächst die Unterschiede der Simulation mit RTOS Modellen zu ISS und bestehende Arbeiten vorgestellt. Danach stellen wir unser RTOS Modell vor, bevor das Papier mit einer Zusammenfassung schließt.

2 Verwandte Arbeiten Die Simulation von Software in einem Instruction Set Simulator (ISS) und die abstrakte Simulation mit Hilfe eines RTOS Modells in SystemC (oder SpecC) unterscheiden sich grundlegend: Instruction Set Simulatoren beinhalten ein komplettes Prozessormodell und simulieren die Ausführung von Assembler Anweisungen auf den Registern der CPU. Die Simulation der Funktion und die Ermittelung der dafür notwendigen Taktzyklen, d.h. der Ausführungszeit, ist ein Schritt. Die Simulationen sind Takt-genau und Unterbrechungen von der Hardware werden exakt nachgebildet. Ebenso werden Laufzeiten von Pipelines und Speicherzugriffen berücksichtigt. Bei der Simulation von Software Tasks in einer SLDL werden die einzelnen Tasks zunächst in atomare Blöcke unterteilt und jeder Block mit einer Ausführungszeit annotiert. Manche Arbeiten fügen zu diesen Blöcken zusätzlich Annotationen mit dem Energieverbrauch hinzu. Zur Simulation wird der Quelltext direkt für den Simulationsrechner übersetzt und ausgeführt. Die Unterteilung der Software in Blöcke erschwert die Simulation von Unterbrechungen. Da die Blöcke atomar sind, können Unterbrechungen nur nach einem Block erfolgen. Es ist daher sinnvoll Blöcke beim Zugriff auf globale Variablen und Systemaufrufen zu unterteilen, um eine funktional korrekte Simulation zu gewährleisten. Existierende Ansätze unterscheiden sich in den implementierten RTOS Modellen und der Behandlung von Unterbrechungen. Insbesondere die Möglichkeit zur Modellierung von Prioritäten der Interrupts, bzw. den Interrupt Behandlungsroutinen ist in existierenden Arbeiten ein Schwachpunkt.

Hassan et al. verwendet eine an Petrinetze angelehnte Darstellung von Tasks als Menge von atomaren Transitionen auf Basis von SystemC [HSTI05]. Die Transitionen sind jeweils mit Ausführungszeiten und Energieverbrauch markiert. Zustandsübergänge werden durch Events µ-ITRON RTOS Kernel angestoßen. Das Modell kann die Simulation der Ausführungszeit unterbrechen, um eine Interrupt Service Routine zeitnah zu simulieren. Die Möglichkeit zur Modellierung von ISR Prioritäten ist nicht gegeben. Gerstlauer et al. stellen in [GYG03] ein kanonisches RTOS Modell auf Basis von SpecC/C vor. Das Modell beinhaltet grundlegende Operationen wie Taskwechsel, Kontextwechsel und Semaphoren. Während des Entwurfs werden nebenläufige SpecC Tasks mit diesen Operationen erweitert. Die Synchronisation zwischen Scheduler und Tasks wird mit Events realisiert. Die Implementation des kanonischen RTOSs auf einem realen Betriebssystem erlaubt die (Software-) Synthese aus SpecC Modellen. Yu stellt dieses Vorgehen als Entwurfsmethode in [Yu05] vor. SpecC erlaubt aufgrund seiner Architektur keine Unterbrechungen von ISRs untereinander, somit können ISR Kaskadierungen und Priorisierung nicht simuliert werden. In [HKH04] wird eine vergleichbare RTOS Erweiterung für SystemC vorgestellt. Durch Ableiten einer Basisklasse können eigene Scheduler entwickelt werden. Über Callback-Funktionen wird der aktuelle Zustand der Tasks an den Scheduler weitergeleitet. In der Dissertation von Klaus wird dieser Ansatz zur Entwurfsraumexploration für eingebettete Systeme verwendet [Kla05]. In [HK07] wird der Ansatz am Beispiel einer mobilen Robotersteuerung evaluiert. Mit Hilfe der Gumbel Verteilung zur Modellierung der stochastischen Verteilung von Ausführungszeiten werden verschiedene Schedulingstrategien untersucht. Eine explizite Behandlung von Interrupts wird nicht erwähnt. In [PAS+ 06, PAV+ 05] wird ein POSIX kompatibles RTOS Modell für SystemC vorgestellt. Zur Simulation werden die Tasks in Segmente unterteilt. Die Ausführungszeit einzelner Anweisungen werden durch überladen der C-Operatoren an einen Time-Manager weitergeleitet und am Ende jedes Segmentes mit Hilfe eines wait simuliert. Bei Unterbrechungen in Form von Interrupts wird zwischen vorhersagbar und nicht vorhersagbar unterschieden. Vorhersagbare Unterbrechungen sind zum Beispiel Timer oder Timeouts. Diese werden direkt vom Time-Manager berücksichtigt, indem ein wait-Aufruf und damit eine automatische Segmentierung bei erreichen des Zeitpunktes durchgeführt wird. Bei nicht vorhersagbaren Interrupts wird das Segment komplett simuliert und die errechnete Simulationszeit bei der Unterbrechung aufgeteilt und mit der Simulationszeit der Unterbrechung ergänzt. Auf diese Weise wird sichergestellt, dass Zeitpunkte für Kommunikation korrekt simuliert werden. Um die funktionale Simulation der Zugriffsreihenfolge auf globale Variablen und Kommunikation zu verbessern, werden Systemaufrufe und Zugriffe auf globale Variablen in einem eigenen Segmenten bzw. am Start oder Ende eines Segmentes realisiert. Der Simulationsfehler gegenüber einer ISS wird mit maximal 8% angegeben. Die Arbeiten sind in dem Tool PERFidiX realisiert. Aufbauend auf diesen Arbeiten wird in [QPV+ 06] ein TLM Modell zur Anbindung von Hardware Komponenten an ein RTOS Modell vorgestellt. Die Hardwaremodelle können über ein TLM Businterface Interrupts an das RTOS Modell senden. Ein spezieller SystemC Thread überwacht diese Anforderung und instantiiert entsprechend einen POSIX Thread zur Simulation der zugehörigen Interrupt Service Routine. ISR und Tasks werden von einem gemeinsamen Scheduler ausgeführt, wodurch die getrennte Modellierung der Prioritäten von ISR und Tasks nicht möglich ist und damit eine unabhängige Analyse von ISR und Tasks nicht unterstützt wird. Wie oben erwähnt unterstützen die vorgestellten Modelle die Simulation von Interrupts, allerdings können Prioritäten von Interrupts nur in Verbindung mit Tasks vergeben werden, wobei

in allen Fällen eine unabhängige Analyse von ISRs und Tasks nicht möglich ist. Unser Ansatz verwendet daher zwei Scheduler, einen für die Hardware abhängige Priorisierung der ISR und einen zur Modellierung des RTOS Scheduler. Hierdurch wird eine unabhängige Analyse unterstützt und unter anderem die Modellierung von Prioritäten erheblich vereinfacht.

3 RTOS Modellierung Mit Hilfe eines kanonischen RTOS Modells in sog. System Level Design Language (SLDL) wie SpecC oder SystemC können verschiedene Scheduling Strategien für Embedded Software in einem frühen Entwurfsstadium untersucht werden. RTOS Modelle in einer SLDL haben im wesentlichen die Aufgabe, die Pseudo-paralellen Tasks zu sequentialisieren und die Evaluierung verschiedener Schedulingstrategien zu erlauben. Zur Analyse von Interrupts und Exceptions müssen ebenfalls I/O und Hardware Signale berücksichtigt werden. Insbesondere eine genaue Behandlung der Interrupts ist notwendig in Kombination mit dem RTOS Scheduling. Wir stellen ein kanonisches RTOS Modell auf Basis von SystemC vor, das neben dem RTOS Scheduler einen weiteren Scheduler für die Interrupts Service Routinen verwendet. Lauffähige ISRs besitzen gegenüber Tasks immer eine höhere Priorität. Das RTOS Modell stellt sicher, daß immer exakt eine Task oder ISR zu einem Zeitpunkt lauffähig ist. Tasks und ISR werden mit einem SystemC-Thread simuliert. Zur Synchronisation mit dem RTOS Modell wird nicht zwischen Tasks und ISR unterschieden. Einzig und allein bei der Auswahl des nächsten lauffähigen SystemC Threads werden alle ISR über ihren HardwareScheduler und entsprechend alle Task über den Software-Scheduler gescheduled. Der SoftwareScheduler ist dabei dem Hardware-Scheduler unterlagert. Diese Anordnung erlaubt die getrennte Modellierung der Hardware abhängigen Prioritäten von Interrupts unabhängig von den Datenstrukturen des Software Scheduler. Mit Hilfe von Callback Aufrufen werden bei der Implementation von ISR Start und Ende der eigentlichen Behandlungsroutine markiert und an den Scheduler weitergeleitet. Dieser kennt somit immer den aktueller Zustand aller ISRs. Abbildung 1 zeigt eine Übersicht der Klassen unseres Modells. sc_rtos_context ist die Hauptklasse und wird im Folgenden als Kontext bezeichnet. Alle Task und Interrupt Service Routinen, die zu einer CPU zugeordnet sind, werden an einer Instanz dieser Klasse registriert. Die registrierten Tasks und ISRs werden in einer Liste aus sc_rtos_context_tcb gespeichert. Diese sind vergleichbar mit Task Kontroll Blöcken bei herkömmlichen Betriebssystemen. Ferner speichert der Kontext Zeiger auf die Scheduler. Das Event event_schedule stößt ein neuen Schedule der ISRs bzw. der Tasks an. Ein Task Kontroll Block (sc_rtos_context_tcb) speichert die folgenden Informationen: • pid ist die interne eindeutige ID einer Task oder ISR. • isr_flag zeigt an, ob es sich bei dem gespeicherten Daten, um eine Interrupt Service Routine handelt oder nicht. ISR haben gegenüber Tasks immer eine höhere Priorität und werden von einem eigenen Scheduler behandelt. • process enthält einen Zeiger auf den zugehörigen SystemC Prozess. • state speichert der Zustand einer Task bzw. ISR und kann die folgenden Werte annehmen: {CREAT ED, READY , RU N N IN G, W AIT IN G, DEAD}. Die Variable wird durch Aufrufe der kanonischen RTOS API verändert.

Abbildung 1: Klassendiagramm des abstrakten RTOS Modells • user_ptr hält einen Zeiger auf Schedulingdaten pro Task/ISR, die vom Anwender beliebig verwendet werden können. Innerhalb der Scheduling-Routinen kann auf diese Daten zugegriffen werden. Der Zeiger wird bei der Initialisierung der Task/ISR gesetzt. • wait_event implementiert das Ereignis über das die Task/ISR von Kontext aktiviert wird. Die Klasse sc_rtos_scheduler ist ein Interface zur Modellierung des hardwareabhängigen ISR Scheduler und des RTOS abhängigen Task Scheduler. Das Interface definiert die Callback Funktion notify_task_state, die bei jedem Zustandswechsel aufgerufen wird. Ebenso wird das Anund Abmelden an dem Kontext gemeldet, so daß die Funktion zum Aufbau spezifischer Task Kontroll Blöcke für einen bestimmten Scheduler verwendet werden kann. Der Hauptscheduler ist in der Funktion schedule implementiert, die sensitive auf das Signal event_schedule reagiert. Wann immer eine Task/ISR einen Zustandswechsel durchführt, wird ein Reschedule für den nächsten Deltazyklus ausgeführt. Zu diesem Zeitpunkt warten alle Task/ISR mit ihrem wait_event auf die Reaktivierung durch den Kontext. Damit wird sichergestellt, das exakt nur eine Task oder ISR zum gleichen Zeitpunkt lauffähig ist. Bei einem Reschedule wird zunächst geprüft, ob eine ISR lauffähig ist. Wenn dem so ist, wird der Scheduler für die ISR aufgerufen, ansonsten wird der Scheduler für die Tasks ausgeführt. Die ISR werden somit immer bevorzugt. Die Scheduler liefern die ID der Task/ISR zurück. Entsprechend wird die entsprechende wait_event der zugehörigen Task/ISR gefeuert.

Alle Tasks und ISRs werden hierzu in einer von sc_rtos_module abgeleiteten Klasse als SystemC Thread definiert. Alle Tasks/ISRs erfüllen folgendes Muster: void run () { task_start (); while (true){ ... CONSUME_CPU_TIME (1,SC_MS); ... wait (); } task_end (); }

task_start melden dem Kontext den Start einer Task, entsprechend benachrichtigt task_end über dessen Terminierung. Analog werden für ISR die Funktionen isr_start und isr_end aufgerufen. Um den Start einer Interruptbehandlung zu markieren, wird die eigentliche Interrupt Behandlung mit Aufrufe zu isr_enter and isr_return markiert. All diese Aufrufe werden an die zugehörigen Scheduler weitergeleitet. Explizite Kontextwechsel werden mit den Funktionen task_sleep, task_deactivate, task_activate und task_yield realisiert. Die ersten beiden ändern den Zustand auf WAIT und geben die Aktivität an den Scheduler ab. task_activate setzt entweder den Zustand einer anderen Task auf READY oder wartet aktiv auf Reaktivierung durch den Scheduler. Letzteres wird zur Annotation von wait Aufrufen innerhalb von SystemC verwendet, die alle wie folgt erweitert wurden: void sc_rtos_module::wait (sc_event &e){ int pid = m_rtos_context->task_sleep (); sc_module::wait (e); m_rtos_context->task_activate (pid); }

Der Aufruf von task_sleep ändert nur den Zustand der aufrufenden Task/ISR, das eigentliche blockieren findet erst in sc_module::wait statt. Nach Erhalt des Events muss die Task/ISR zunächst die Aktivierung von Kontext bekommen. Daher wartet task_activate bei Aufruf mit der eigenen PID intern auf das Ereignis wait_event. Bei Aufruf mit einer anderen PID genügt es hingegen den Zustand der zugehörigen Task/ISR auf READY zu setzen. Interrupt Service Routinen warten auf einen Interrupt durch Aufruf von isr_wait. Der Request selbst wird mittels eines sc_signal dargestellt. Da ein Interrupt Request vor dem eigentlichen Aufruf der ISR verschwinden kann (z.b. durch Löschen eines Flags in einem geschützten Bereich), stellt du Funktion sicher, das bei Aktivierung der ISR durch den Kontext das Interrupt Signal gesetzt ist. Anderenfalls wird die ISR nicht ausgeführt und das Warten beginnt von neuem. Ausführungszeiten für den Zielprozessor werden durch den Aufruf von CONSUME_CPU_TIME modelliert. Innerhalb der Funktion wird die übergebene Zeitspanne abgewartet. Sollte während des Wartens ein Interrupt auftreten, so wird dieses Warten ausgesetzt und die Task/ISR gibt ihre Aktivität an den den Kontext zurück. Auf diese Weise kann exakt zu dem Zeitpunkt einer Zustandsänderung in irgendeiner Task/ISR ein neuer Schedule erfolgen, abhängig von den aktuellen Daten. Ursprüngliche Ideen verfolgten den Ansatz, die komplette Wartezeit abzuwarten. Damit war die Zeitgenauigkeit allerdings beschränkt auf die Größe der übergebenen Zeitspannen.

Name TIMER0_COMPA_vect PCINT0_vect PCINT2_vect USART_RX_vect USART_UDRE_vect handle_clock_1khz handle_clock_250hz handle_command signal_comm_tx_empty controller_left controller_right analog_update transmit_rpm transmit_ticks transmit_supply transmit_throttle

Laufzeit 54 74 74 522 53 7 9 497 324 468 468 127 232 274 259 256

Latenz Deadline 214 16000 601 4438 679 4438 740 1527 239 1527 743 16000 752 64000 1232 1527 590 1527 633 64000 1627 64000 1761 16000 2424 64000 1940 64000 1925 64000 1922 64000

Abbildung 2: WCET und Antwortzeiten der Steuersoftware

4 Evaluierung Der beschriebene Ansatz wurde als SystemC Implementierung am Beispiel der Motorsteuerung für einen mobilen Roboter mit Differentialantrieb evaluiert. Die Steuerung wird auf einem Atmel Mikrocontroller AT90CAN128 bei 16Mhz ausgeführt und bekommt ihr Fahrbefehle über eine serielle Schnittstelle von einem PC. Die Steuerung übernimmt folgende Aufgaben: (1) Auswertung der Radencoder zur Messung der Umdrehungsgeschwindigkeit, (2) Motorregelung für die Antriebsmotoren, (3) Messung von Motorströmen und Versorgungsspannung und (4) Kommunikation über UART mit Hilfe eines an CAN angelehnten Datenformats. Die Software verfügt über 5 ISR und 11 Tasks. Die Tasks werden jeweils über Ereignisse aus den ISR oder anderen Tasks selbst aktiviert. Die Simulation dient zur Verifikation, daß (1) die Regelung innerhalb des Intervalls von 250Hz berechnet wird und (2) die ISR für die Radencoder ausreichend schnell sind um eine Geschwindigkeit von 300U/min sicher zu messen. Für die Task und ISR wurde jeweils die WCET ermittelt und ein abstraktes RTOS Modell erstellt. Die IRQs für Timer, UART und Radencoder werden über ein externes Modell mit den erforderlichen Raten getriggert. Abbildung 2 zeigt die einzelnen ISR und Tasks mit ihrer WCET, der Antwortzeit (Latenz) und der maximal erlaubten Antwortzeit. Sowohl Tasks als auch ISR werden mit statischen Prioritäten ohne Verdrängung simuliert. Daraus ergeben sich die Antwortzeiten aus Abbildung 2, wobei eine CPU Auslastung von 7% gemessen wurde. Der Implementation des verwendeten Schedulers erlaubt ebenfalls ein Prioritäten basiertes Scheduling mit Verdrängung. Für das Scheduling der ISR würde das bedeuten, daß nach Eintritt in die Interruptbehandlung andere ISR die aktuelle Unterbrechen können. Solche Implementation sollten zwar vermieden werden, können aber die Antwortzeiten von höher priorisierten ISR reduzieren. Durch die Simulation konnte nachgewiesen werden, das dieser Effekt keine Auswirkung hat. Ferner konnte ermittelt werden, daß bei Reduktion der Übertragungsrate von 115200 auf 38400 die Taktrate der CPU auf 4MHz reduziert werden kann, was zur Reduktion der Stromaufnahme führt.

5 Zusammenfassung Wir haben ein kanonisches RTOS Modell auf Basis von SystemC vorgestellt, das zum Schedulen von ISR und Task jeweils einen eigene Scheduler verwendet. Diese Aufteilung ermöglicht die Trennung der hardware abhängigen Priorisierung der ISR von dem eigentlichen RTOS Scheduler. Der Kern besteht aus der RTOS Kontextklasse, der Operationen zum Taskwechsel und Zustandswechsel bereitstellt und die Verwaltung der Scheduler übernimmt. Task und ISR werden in einer erweiterten Modul-Klasse definiert, bei der alle SystemC-Waits ersetzt wurden, um die Synchronisation mit dem RTOS Modell zu ermöglichen.

Literatur [AKS+ 04] H. M. AbdElSalam, S. Kobayashi, K. Sakanushi, Y. Takeuchi, and M. Imai. Towards a higher level of abstraction in hardware/software co-simulation. In ICDCSW ’04: Proceedings of the 24th International Conference on Distributed Computing Systems Workshops - W7: EC (ICDCSW’04), pages 824–830, Washington, DC, USA, 2004. IEEE Computer Society. [BB97]

Giorgio C. Buttazzo and Giorgio Buttanzo. Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications. Kluwer Academic Publishers, Norwell, MA, USA, 1997.

[GYG03] A. Gerstlauer, H. Yu, and D. Gajski. Rtos modeling for system level design. In Proceedings of Design, Automation and Test in Europe, March 2003., 2003. [HK07]

Sorin A. Huss and Stephan Klaus. Assessment of real-time operating systems characteristics in embedded systems design b systemc models of rtos services. In DVCon 07: Design and Verification Conference and Exhibitation, San Jose, CA, 2007.

[HKH04] Prih Hastano, Stephan Klaus, and Sorin A. Huss. An integrated systemc framework for real-time scheduling assessments on system level. In Proceedings of IEEE Int. Real-Time Systems Symposium, 2004. [HSTI05] M. AbdElSalam Hassan, Keishi Sakanushi, Yoshinori Takeuchi, and Masaharu Imai. Rtk-spec tron: A simulation model of an itron based rtos kernel in systemc. In DATE ’05: Proceedings of the conference on Design, Automation and Test in Europe, pages 554–559, Washington, DC, USA, 2005. IEEE Computer Society. [KBR06]

M. Krause, O. Brinkmann, and W. Rosenstiel. A systemc-based software and communication refinement framework for distributed embedded systems, 2006.

[Kla05]

S. Klaus. System-Level-Entwurfsmethodik eingebetteter Systeme. PhD thesis, Technische Universität Darmstadt, 2005.

[MPC04] R. Le Moigne, O. Pasquier, and J-P. Calvez. A generic rtos model for real-time systems simulation with systemc. In DATE ’04: Proceedings of the conference on Design, automation and test in Europe, page 30082, Washington, DC, USA, 2004. IEEE Computer Society.

[PAS+ 06] Hector Posadas, Jesús Ádamez, Pablo Sánchez, Eugenio Villar, and Francisco Blasco. Posix modeling in systemc. In ASP-DAC ’06: Proceedings of the 2006 conference on Asia South Pacific design automation, pages 485–490, New York, NY, USA, 2006. ACM Press. [PAV+ 05] 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, 10(4):209–227, December 2005. [QPV+ 06] D. Quijano, H. Posadas, E. Villar, F. Escuder, and M. Martinez. TLM interrupt modeling for HW/SW co-simulation in systemc. XXI Conference on Design of Circuits and Integrated Systems, DCIS’06, 2006. [Yu05]

Haobo Yu. Software Synthesis for System-on-Chip. PhD thesis, University of California, Irvine, 2005.