Abstract RTOS Modeling for Embedded Systems F. Hessel1, V. Rosa1, I. Reis1, R. Planner1, C. Marcon2, A. Susin2 1 Catholic University - PUCRS 2 Federal University - UFRGS Porto Alegre - Brazil

Outline Introduction to SoC and OS Design Related Work Design Flow RTOS Model Task Model Scheduler Model Synchronization Model Case Study Conclusions and Future Works

Introduction to SoC Design ITRS, 70% of ASICS will be SoC in 2005; Dedicated Software complexity larger than HW in 2005; ITRS, Embedded SW represents 80% design cost for SoCs; 10 000 new SoC Designs Generic SoC platform (programmable, configurable, …) Specific SoCs with heterogeneous components (RF, Analog, MEMS, …) 100 Bn$ market; STB, Multimedia, network processors, mobile terminals, and game applications require multiprocessors and will drive the semiconductor market.

Introduction to SoC Design, cont´d SoC Components: Heterogeneous Hardware Specific hardware (DSP, IP, Memory, non digital…) Communication Network Non structured logic to links components to Network Sophisticated Software High level SW (Application/OS) Low level SW (Dedicated CPU, ASIP, DSP) Multi-disciplinary knowledge is required: Heterogeneous processors: different CPU cultures; Sophisticated communication protocols and On-Chip networks. SoC architecture design flow should enable the designer To master the design complexity; To meet the time-to-market.

Operating Systems Principles HW/SW issues: Large variety of processors, difficult to program Sequential software execution, distributed and parallel functions The solution: operating system Abstraction of hardware, multitasking Processor Periph. 1 Periph. 2 Periph. 3 Software Tasks SW HW Operating System API kernel drivers [Jerraya]

Generic OS (Simulator) Post Synthesis Netlist OS Abstraction Levels Execution Machine Concepts Abstraction level Application level Generic OS (Simulator) SW+HL primitives OS level Specific OS SW+System calls Driver Level Generic Processor Software+I/O calls ISA Level Processor Post Synthesis Netlist [Jerraya]

OS Design Challenges Current RTOS design: SoCs design: high abstraction levels; Low abstraction level (RTL); RTL OS implementation used in higher abstraction levels (negating the abstract system model principles); Validation of RTOS implementations in HW/SW simulation; Current SLDLs lack support for modeling an RTOS at higher abstraction levels Need new design methodologies and techniques to enable RTOS Design

Objective and Problems Objective: fast and accurate RTOS simulation model Abstract RTOS model, higher abstraction levels (Application level) Timing simulation for the final RTOS implementation Problems How to build such a simulation model? executed on the host machine, OS simulation models Advantage/Limitation: simulation speed/lack in accuracy Timing simulation Delay annotation to the sw code (estimation/back annotation) Resources sharing, multi-task management Real-time services I/O = adapts to different I/O schemes Synchronization = interrupts management Task inter-dependence = avoids dead locks

Related Work Low level models: High level models Kohout: specific hw for few OS operations; Wang: synthesize OS based on device drivers; O´Nil: OS library to generate device drivers; Yi: model the OS in the cosimulation backplane at RTL level (ISS); Cortadella: combine static and dynamic scheduling; Gauthier: methodology for automatic generation of application-specific OS; High level models Desmet (SoCOS): emphasis on the task concurrency issues, requires own proprietary simulation engine; Gonzales/Madsen: based on master-slave SystemC library; Gerstlauer/Gajski: OS model to extend SpecC language, hard and complex to adapt to another SLDL; Our approach: RTOS model based on SystemC (untimed system specification – Transaction level modeling);

Design Flow TL specification; Extend SystemC execution model; Can be integrated into any SystemC-based model and design flow; Easy to use;

RTOS Model Build on the top of SystemC language; A RTOS model library provides the common services of a RTOS; The model supports periodic and non-periodic soft real-time tasks; SystemC lacks support to model dynamic real-time behavior; Need language extensions; Two major categories of services: OS management Task management

OS Management and Task Management OS Management: Initialization of the RTOS sc_rtos_init(): initializes the RTOS data structure and starts the multitasking scheduling; sc_rtos_reset(): reinitializes the RTOS (validation purposes); sc_task_suspend(id): preempt a task; sc_task_resume(id): resume a task; Task Management: makes the interface between the (Exo)kernel and the application. Provides an easy way to describe an application as a set of tasks;

Task Model Each task is a PosixThread Primitives SystemC not provide a mechanism to preempt and resume threads during execution time; Need languages extensions; SystemC Open Initiative works in a new release to provide these mechanisms; Primitives sc_task_create(id, task_name, priority, period, wcet, bcet, deadline), assigns the task to the scheduler that attributes idle as the inital state; sc_task_notify(); sc_task_end(); sc_task_wait(); sc_task_end_cycle(), to notify the scheduler that a task finished its computation in the current cycle (periodic tasks);

Example of task modeling id task_name priority period wcet bcet deadline

Scheduler Model Objective: how long an application takes to compute and the tasks interactions; The scheduler model considers that all tasks are independent threads; Hierarchical tasks need to be flatted; A task can be in one of three basic scheduling states: ready, execute or idle; The scheduler is modeled as a SystemC thread process that run continually; The RTOS library implements FCFS, RR, RM, and EDF scheduling algorithms;

Synchronization Model Provides services to synchronize concurrent and cooperative task; Provides mechanisms that handle inter-processor and intra-processor synchronization problems; Two primitives: sc_task_wait: wait until another task invokes the sc_task_notify or a specified amount of time has elapsed; sc_task_notify: wake-up a task; Input/Output operations (like send/receive): abstract send/receive operation was implemented and aggregated to sc_task_notify/sc_task_wait;

PBX Case Study Design a PBX (Digital Private Branch Exchange) with VoIP©; Soft real-time system composed by more than 50 process with 4 priority levels; Partitioning: 92% software modules (grouped in clusters – PEs); 6% assembly modules (IP modules); 2% hardware modules (mapped into Altera FLEX-10KE); Clusters and IP modules are mapped into AM186ES (AMD 80186) processor and ADSP2185M DSP (Analog Devices); An Exo-Kernel was generated for each processor; Communication synthesis: Shared memory for processors communication; Handshake protocol for FPGA-processor communication; © Digistar Telecom Inc.

Design Challenges and Constraints RTOS fulfilled all real-time constraints? Is RTOS code size acceptable (memory constraint)? Constraints: Testbench vectors extracted from real PBX operation; Profile techniques: wcet and bcet estimation;

Results AM186ES simulation analysis Code size (in bytes) Scheduling Context switches RT constraints fail Round-robin 465,577 97 EDF 490,254 3 RM 402,239 5 Code size (in bytes)   AM186ES DSP C/C++ 457,976 16,356 Assembly 22,233 27,453 Scheduling algorithm 7,456 2,489

Results cont’d AM186ES simulation analysis Simulation time TL-simulation 16min RTL-simulation 6h 15min Cosimulation 98h 43min

Conclusions and Future works We presented an abstract RTOS model and an associate design flow; The model allows was build on the top of SystemC; The abstract RTOS model allows the designer evaluate different OS design alternatives in early design phases; Limitations; Hard real-time systems; Priority inversion; Mutual exclusion; Future works: Improve OS services; Network OS; Interfaces for commercial real-time OS; Techniques to power estimation at higher abstraction levels;