RTOS Modeling gfor System Level Design
Design, Automation and Test in Europe Conference and Exhibition (DATE’03)
Andreas Gerslauer, Haobo Yu, Daniel D. Gajski
2010. 1. 20Presented by Jinho Choi
ⓒ KAIST SE LAB 2010
Presented by Jinho Choi
Contents
IntroductionBackgroundSystem-Level Design Flowy gRTOS ModelExperimental ResultsExperimental ResultsConclusionDiscussion
ⓒ KAIST SE LAB 2010 2/21
Introduction (1/2)( / )
Problems of systems-on-chip designDesign complexityTime-to-market pressure
Raising abstraction level to solve the problemSLDL(System Level Design Language)( y g g g )
• SystemC, SpecC
ⓒ KAIST SE LAB 2010 3/21
Introduction (2/2)( / )
MotivationLimitation of most SLDLs
• No support for modeling the dynamic real-time behavior
D i l i b h iDynamic real-time behavior• Only support by a RTOS (Real Time Operating System)
P lProposalDesign flow with RTOS model for system level
• Capturing the RTOS behaviors in system level models• Written on top of SpecC language• Support all the key concepts in RTOS• Support all the key concepts in RTOS• Only a minimal modeling effort• Evaluating a system design at early design space exploration
ⓒ KAIST SE LAB 2010 4/21
Background(1/3)g ( / )
SpecCA system-level description and specificationA superset of ANSI-CProgram is set of behaviors, channels, and interfacesExecution starts from behavior Main.main()
/* HelloWorld.c */
#include <stdio.h>
// HelloWorld.sc
#include <stdio.h>#include <stdio.h>
void main(void){printf(“Hello World!\n”);
behavior Main{void main(void){} {printf(“Hello World!\n”);
}};
ANSI-C
ⓒ KAIST SE LAB 2010SpecC
5/21
Background(2/3)g ( / )
SpecC (cont’d)Basic Structure
• Top behaviorChild b h i
Behavior Ports InterfacesChannelinterface I1{bit[63:0] Read(void);void Write(bit[63:0]);• Child behaviors
• Channels• Interfaces v1
c1B
p1 p2o d te(b t[63:0]);
};
channel C1 implements I1;
Interfaces• Variables• Ports
v1behavior B1(in int, I1, out int);
behavior B(in int p1, out int p2){int v1; b1 b2int v1;C1 c1;B1 b1(p1, c1, v1),
b2(v1, c1, p2);
VariableChild behaviors
void main(void){ par { b1.main();
b2.main();}
ⓒ KAIST SE LAB 2010
}};
6/21
Background(3/3)g ( / )
SpecC (cont’d)
B_parB_seq B_fsm B_pipe
Sequentialexecution
FSMexecution
Concurrentexecution
Pipelinedexecution
b1
b2
b1
b2
b1
b3
b2
b4
b1
b2
b3b3 b5 b6 b3
behavior B_pipe{B b1, b2, b3;
behavior B_seq{B b1, b2, b3;
behavior B_fsm{B b1, b2, b3,b4 b5 b6;
behavior B_par{B b1, b2, b3;
void main(void){pipe{b1.main();
b2.main();b3.main();
void main(void) { b1.main();b2.main();b3.main();
b4, b5, b6;void main(void) { fsm { b1:{…}
b2:{…}…}
void main(void){ par{b1.main();
b2.main();b3.main();
ⓒ KAIST SE LAB 2010 7/21
} }};
}};
}};
} }};
System-Level Design Flow(1/4)y g ( / )Spec. model
SystemPartitioning
Static Scheduling
C S th i
SystemSynthesis
Unscheduled d l
Comm. Synthesis
model
RTOSModel Dynamic Scheduling
Arch. model
Backend
RTLIP
Hardware synthesis
Interfacesynthesis
Softwaresynthesis
RTOSIP
Backend
ⓒ KAIST SE LAB 2010Impl. model
8/21
System-Level Design Flow(2/4)y g ( / )
Specification ModelBehavioral description of the systemFree of any implementation details
• Without any implications about the structure of the implementation
No notion of timeNo notion of time
ⓒ KAIST SE LAB 2010 9/21
System-Level Design Flow(3/4)y g ( / )
Architecture modelThe result of mapping behaviors onto actual processing elements
ⓒ KAIST SE LAB 2010 10/21
System-Level Design Flow(4/4)y g ( / )
Implementation modelThe output of the backend design processA structural description of the micro-architecture of
h h RTLeach processor at the RTL
ⓒ KAIST SE LAB 2010 11/21
RTOS Model (1/7)( / )
High-level RTOS abstractionModel standard RTOS concepts
• Multi-tasking, time-sharing, preemptionR l ti h d li• Real-time scheduling
• Task synchronization, task communication
ⓒ KAIST SE LAB 2010
Specification model Architecture model Implementation model12/21
RTOS Model (2/7)( / )
OS Management
Task Management
Event Handling
ⓒ KAIST SE LAB 2010Time modeling
13/21
RTOS Model (3/7)( / )
Model refinement
rM
odelrefinem
ent
U h d l d d l A hit t d l
ⓒ KAIST SE LAB 2010
Unscheduled model Architecture model
14/21
RTOS Model (4/7)( / )
Task refinementStep1.
• Convert behaviors in the specification into RTOS-based tasks
Unscheduled model
ⓒ KAIST SE LAB 2010Architecture model
15/21
RTOS Model (5/7)( / )
Task refinement (cont’d)Step 2
• Create child tasks in a parent task
ⓒ KAIST SE LAB 2010 16/21
Unscheduled model Architecture model
RTOS Model (6/7)( / )
Synchronization refinementAll events primitives are replaced with event handling routines of the RTOS model
Unscheduled model Architecture model
ⓒ KAIST SE LAB 2010 17/21
RTOS Model (7/7)( / )
Preemptive muti-task system modeling
Unscheduled model
Architecture model
ⓒ KAIST SE LAB 2010 18/21
Experimental Resultsp
The design of a voice codeTwo tasks for encoding and decodingMotorola DSP56600 processorA small custom RTOS
Unshced. Arch. Impl.Lines of Code 13,475 15,552 79,096Execution time 24.0 s 24.4 s 5 hContext switches 0 326 326Transcoding delay 9.7 ms 12.5 ms 11.7 ms
ⓒ KAIST SE LAB 2010 19/21
Conclusion
A RTOS model for system level designNot require any specific language extensionsSupport all the key concepts in RTOSOnly a minimal modeling effortValidate the dynamic real-time behavior of muti-task systems in the early stage of system design
• Providing accurate results with minimal overhead
ⓒ KAIST SE LAB 2010 20/21
Discussion
ProsEarly validation of dynamic scheduling effects at system designTh fi d l RTOS f iThe first attempt to model RTOS features in system design
ConsIs it useful to know the number of context switch?Hard to estimate the accurate system behavior.
ⓒ KAIST SE LAB 2010 21/21
Top Related