1. 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

2. 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

3. 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;
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.

4. 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.

5. 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]

6. 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]

7. 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

8. 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

9. 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);

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

11. 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

12. 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;

13. 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);

14. Example of task modelingid
task_name
priority
period
wcet
bcet
deadline

15. 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;

16. 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;

17. 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.

18. 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;

19. 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

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

21. 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;