You are on page 1of 6

Embedded Software Generation from System Level Design Languages

Haobo Yu, Rainer Dömer, Daniel Gajski


Center for Embedded Computer Systems
University of California, Irvine, USA
{haoboy,doemer,gajski}@cecs.uci.edu

Abstract— To meet the challenge of increasing design com- level, much overhead is introduced to support the system level
plexity, designers are turning to system level design languages features (e.g hierarchy, concurrency, communication). How-
(SLDLs) to model systems at a higher level of abstraction. This ever, these features are not necessarily needed for the target
paper presents a method of automatically generating embedded software code. Considering the limited memory space and ex-
software from system specification written in SLDL. Several re- ecution power of embedded processors, we need to generate
finement steps and intermediate models are introduced in our compact and efficient software code for implementation. In
software generation flow. We demonstrate the effectiveness of the this paper, we address this problem by proposing a method
proposed method by a tool which can generate efficient ANSI C consisting of several software refinement steps and intermedi-
code from system models written in SLDL. ate models to generate efficient ANSI C code from the system
specification written in SLDL.
The rest of this paper is organized as follows: Section II
I. I NTRODUCTION gives an insight into the related work. Section III describes
In order to handle the ever increasing complexity and time- the flow for software generation. Details of the software gen-
to-market pressures in the design of embedded systems, raising eration process are covered in Section IV, Section V and Sec-
the level of abstraction to the system level is generally seen as tion VI. Experimental results are shown in Section VII and
one solution to increase productivity. Many system level de- Section VIII concludes this paper with a brief summary .
sign languages (SLDLs) and methodologies [3, 4] have been
proposed in the past to address the issues involved in system II. R ELATED W ORK
level design. The typical system level design process usually
starts from an abstract system specification model, partitions Various design methodologies exit for designing embedded
the specification to HW/SW components and ends with the de- software. There are approaches to code generation from an
tailed implementation model [10]. Much work has been done abstract model (UML[2]), from graphical finite state machine
in synthesizing the HW part of the system. However, most in- design environments (e.g StateCharts [15], from DSP graph-
dustrial embedded software is still created manually from the ical programming environments(e.g. Ptolemy [18]), or from
system specification [16]. It is desired that the embedded soft- synchronous programming languages (e.g Esterel [7]).
ware can be generated from the system specification automat- In [17], a software synthesis approach using quasi-static
ically. scheduling in Petri-Nets to produce a set of corresponding state
In the system specification, the functionality of an embedded machines is presented. In [8], a way of combining static
system is described as a hierarchical network of modules (or task scheduling and dynamic scheduling in software synthe-
processes) interconnected by hierarchical channels. Syntacti- sis is proposed. In [11], a method for automatic generation of
cally, these can be described in SLDLs as a set of behavior, application-specific operating systems and corresponding ap-
channel and interface declarations. During system synthesis, plication software is given. While these approaches mainly fo-
the specification functionality is partitioned onto multiple pro- cus on software synthesis issues, no efficient code generation
cessing elements (PEs), such as DSP, custom hardware. Those method is described.
behaviors mapped onto general or application specific micro- In POLIS [6] system, code generation is performed by
processors will later be implemented as embedded software. first transforming the Co-design Finite State Machine (CFSM)
Deriving embedded software from system specification de- specification into a s-Graph and then translating the s-Graph
scribed in SLDL means implementing all SLDL language ele- into portable C code. However, POLIS is mainly for reactive
ments (e.g. modules, processes, channels and port mappings). real time systems and can’t be easily extended to other more
Since the predominant SLDLs are C/C++ extensions [10, 14], general frameworks.
directly compiling SLDL to produce the binary code for the The work in [9, 14, 16] are close to the topic of this pa-
target microprocessors is possible but highly inefficient. The per. In [9], software generation from a high-level model of
main reason is that the large simulation kernel for the SLDL is operating system called SoCOS is proposed. Compared with
included in the compiled code. Besides, some cross compilers [9], our approach uses SLDL based RTOS model and enables
for embedded processors may only support C. While SLDL is automatic refinement while [9] requires its own proprietary
used mainly for modeling and simulation of designs at system simulation engine and needs manual refinement to get the soft-
Specification Model PE PE
SLDL
WW X

Bus driver

Bus driver
read
Architecture Partition & ()
write
protocol

Communication ()

Synthesis Y Z

ISR S1
Task
Transaction Level Model Creation Unscheduled TLM
RTOS
Model
RTL H/W Interface C Code RTOS
Synthesis Synthesis Generation
Task Creation
IP IP Task
Parameters

Implementation Model PE PE
SLDL
T1

Bus driver

Bus driver
read
Fig. 1. System design flow ()
write
protocol
()
T2 T3

ISR S1
Task table
ware code. In [16], software generation from SystemC SLDL RTOS Model
T1: X priority: 1
based on the redefinition and overloading of SystemC class li- T2: W, Y priority: 0
T3: Z priority: 2
Multi-Task Model
brary elements is presented. However, this approach requires
the use of C++ cross-compilers and introduces SLDL language
elements overhead. In [14], a software-software communica- C Code Generation
tion synthesis approach by substituting each SystemC module
PE PE
with an equivalent C struct is proposed. Our method differs

Bus driver

Bus driver
from [14] in that [14] requires special SystemC modeling C Code protocol

styles (i.e. using macro definitions and preprocessing switches


C Code
in addition to the original specification code) while ours don’t ISR S1

have any restrictions on how the system model is described. RTOS Model

OS Targeting C Code Simulation Model


III. D ESIGN F LOW
Compile and Link
System level design is a process with multiple stages where RTOS
Lib
the system specification is gradually refined from an abstract Binary Image
idea down to an actual implementation. Figure 1 shows a typ-
ical system level design flow [10]. The system design process
Fig. 2. Software generation flow
starts with the specification model. During system synthesis,
the specification functionality is then partitioned onto multiple
processing elements (PEs) and the communication synthesis
generates the transaction level model in which a communica-
tion architecture consisting of busses and bus interfaces is syn-
can be validated through simulation or verification to evalu-
thesized to implement communication between PEs.
ate different dynamic scheduling approaches (i.e. round-robin,
Our proposed software generation flow is shown in Fig-
priority-based) as part of system design space exploration.
ure 2, where we generate a set of software tasks scheduled by a
preemptive, priority-driven real time kernel (usually a RTOS) In the next system design step, each PE in the transaction
from the partitioned design specification written in SLDL. It level model is then implemented separately. ANSI C code
is carried out in three separate steps. Task creation is the first is generated for tasks created in the previous step from their
step, where the modules/processes are converted into software SLDL specification. By importing the C code into the system
tasks with assigned priorities. Synchronization as part of com- model and replacing the SLDL task specification, we get the C
munication between processes is refined into OS-based task code simulation model. The designer can simulate and validate
synchronization. In order to evaluate the output multi-task sys- the generated C code using the C code simulation model. Note
tem model (e.g. in terms of the scheduling algorithm) at this that the RTOS model is still used as an environment to provide
moment (i.e. before the actual binary implementation), we use the task-scheduling and inter-task communication support for
a high level model of the underlying RTOS [12]. The RTOS the generated C code.
model provides an abstraction of the key features that define
a dynamic scheduling behavior independent of any specific As the last step, services of the RTOS model are mapped
RTOS implementation. The output model generated from the onto the APIs of a commercial or custom RTOS and the C
task creation step consists of multiple PEs communicating via code is compiled into the processor’s instruction set. The fi-
a set of busses. Each PE runs multiple tasks on top of its local nal binary executable for the chosen processor is generated by
RTOS model instance. Therefore, the output multi-task model linking the compiled code against the RTOS libraries.
1 behavior B1( int v) R1 1 struct B1
{ {
1 behavior B2B3() 1 behavior B2B3(RTOS os) R4 int (*v) /*port*/;
2 {B2 b2(); 2 {Task_B2 task_b2(os); int a; R3 int a;
3 B3 b3(); 3 Task_B3 task_b3(os); 5 5 };
4 void main(void) 4 void main(void) void main( void ) R5 void B1_main( struct B1 *this)
5 { 5 {Task t; { {
a = 1; (this->a) = 1;
6 6 task_b2.os_task_create(); (*(this->v)) = (this->a) * 2;
v = a *2;
7 7 task_b3.os_task_create(); 10 } 10 }
8 8 t = os.fork(); }; struct Task1
9 par{ b2.main(); 9 par{task_b2.main(); behavior Task1 {
10 b3.main();} 10 task_b3.main();} { int x;
11 11 os.join(t); int x; int y;
15 int y; 15 struct B1 b11 ;
12 } 12 } R2 struct B1 b12 ;
B1 b11(x);
B1 b12(y); };
void Task1_main( struct Task1*this)
void main( void ) {
(a) before (b) after 20 { 20 B1_main(&(this->b11));
b11.main(); B1_main(&(this->b12));
b12.main(); }
Fig. 3. Task creation } R6 struct Task1 task1 =
}; { 0, /* x init value*/
25 0, /* y init value*/
{ &(task1.x), /*port v of b11 */
0 /* a init value */
IV. TASK C REATION }, /*b11*/
{ &(task1.y), /*port v of b12*/
30 0 /* a init value*/
In system design, the specification is written in SLDL as }, /*b12*/
a network of hierarchical behaviors. However, in the imple- };
void Task1()
mentation, many designers use a task-based approach, where {
a set of tasks are scheduled by a preemptive, priority-driven 35 Task1_main(&task1);
}
real time kernel. The software task generation process converts
the design specification into a RTOS based multi-task model. (a) SpecC Code (b) C Code
Essentially, the task creation step synthesizes the concurrency
and communication elements contained in the SLDL descrip- Fig. 4. An illustrative example
tion.

A. Concurrency
nels. We developed a standard channel library to be used
Concurrency is supported by SLDL to express the parallel in system specification, it includes common communication
executing behaviors in system specification (e.g. par state- primitives, such as c semaphore, c mutex, c queue and
ment). The task creation step converts concurrent processes in c double handshake. For our software generation pro-
the specification into RTOS-based tasks. Generally speaking, cess, only those channels inside the standard channel library
it involves dynamic creation of child tasks in a parent task. In are allowed in system specification. During the task creation
this process, each SLDL concurrency statement (par) in the process, these SLDL channels are replaced by the channels
specification description is refined to dynamically fork child from the RTOS model library [12]. And the task synchroniza-
tasks as part of the parent’s execution. After the child tasks tion as well as inter-task communication are handled by the
finish execution and the par exits, the system joins with the RTOS model.
children and resumes the execution of the parent task by the Now that the software part of the system model is refined
underlining RTOS [12]. to a multi-task system scheduled by the RTOS model. The
This step is illustrated in Figure 3. The par statement in the designer can simulate the model and get feedback as regards
input model (line 9-10 in Figure 3a) is converted to dynami- to the timing properties of the system implementation. Some
cally fork and join child tasks as part of the parent’s execution import parameters (e.g scheduling algorithm and task priority)
(line 6-11 in Figure 3b). During this refinement process, the are determined and checked in this step.
os task create methods of the children are called to create the
child tasks (line 6,7 in Figure 3b). Then, fork is inserted be-
fore the par statement to suspend the calling parent task by the V. TASK C ODE G ENERATION
RTOS model before the children are actually executed in the
par statement. After the two child tasks finish execution and After the task creation step, those behaviors and channels
the par exits, join is inserted to resume the execution of the mapped to the same processor are refined into multiple soft-
parent task by the RTOS model. ware tasks scheduled by a RTOS model. Each task is still
written in SLDL as hierarchical behaviors (computation part of
the task) and channels (communication part of the task). The
B. Communication
task code generation step creates C code for each task from its
In system specification, communications among processes SLDL task description. Essentially, this step synthesizes the
are done through channels and control mechanisms for com- hierarchy and port mapping elements contained in the SLDL
munication are described explicitly in the description of chan- description.
A. Code Generation Rules Algorithm 1 GenerateCCode(Design, BT ask )
1: for all Behavior B ∈ Design do
The code generation process converts the SLDL description
of tasks into ANSI C code. The main idea is that we convert 2: if IsChildBehavior(B,BT ask ) then
the behaviors and channels into C struct and convert the 3: GenerateC4Behavior(B);
behavioral hierarchy into the C language struct hierarchy. 4: end if
5: end for
Rules for C code generation are as follows:
6: for all Channel C ∈ Design do
• R1: Behaviors and channels are converted into C 7: if IsChildChannel(C,BT ask ) then
struct and their structural hierarchy is represented by 8: GenerateC4Channel(C);
the C struct hierarchy, 9: end if
10: end for
• R2: Child behaviors and channels are instantiated 11: for all Function F ∈ Design do
struct members inside the parent struct, 12: if IsCalledInBehavior(F ,BT ask ) then
• R3: Variables defined inside a behavior or channel are 13: if IsMemberFunc(F ,BT ask ) then
converted into data members of the corresponding C 14: B = GetParentBehavior(F );
struct, 15: GenerateC4MemberFunction(F ,B);
16: else
• R4: Ports of behavior or channel are converted into data 17: GenerateC4GlobalFunction(F );
members of the corresponding C struct, 18: end if
19: end if
• R5: Functions inside a behavior or channel are converted 20: end for
into global functions with an additional parameter added 21: T opInst = FindInstance(BT ask )
representing the behavior to which the function belongs, 22: GenerateStructInstance(T opInst);
• R6: A static struct instantiation for each PE is added 23: GenerateTaskCall(BT ask );
at the end of the output C code to allocate the data used by
software. Port mappings for the behaviors and channels
inside the task are reflected in this struct initialization. references to the data members of struct B1. For ex-
ample, inside function B1 main, the variable a in the in-
put code (line 8 in Figure 4a) is replaced by this→a in the
B. An Illustrative Example output code (line 8 in Figure 4b),
Figure 4 is a simple example illustrating the code genera-
tion process. Figure 4a shows a software task Task1 in SpecC • R6: the data used by task Task1 is statically allocated
SLDL. It consists of two instances of behavior B1 executing se- through the instantiation of struct Task1 (line 23 to
quentially. Figure 4(b) is the automatically generated C code line 36 in Figure 4b). Note that the initial values for data
from our tool. In figure 4, we can find the examples of the six members in side struct Task1 are all set at this time.
rules for code generation process: This includes the port mapping information for behavior
instances b11,b12. For example, the port mapping of be-
• R1: behavior B1 is converted into struct B1, havior instance b11 (line 16 in Figure 4a) is reflected in
struct B1 instantiation (line 26 of Figure 4b). The ad-
• R2: In the input code, behavior Task1 contains two in- vantage of this approach is that the C compiler does the
stances of behavior B1(line 16,17 in Figure 4a). in the port mapping at compile time rather than the program cal-
output C code, struct Task1 contains two instances of culates at run time. The goal here is to optimize the code
struct B1 (line 15,16 in Figure 4b), at compile time as much as possible, such that the run-
• R3: int a defined in behavior B1 is converted to int a time is reduced to a minimum.
inside struct B1,
Note that the generated C code has a clear structure. There
• R4: port int v of behavior B1 (line 1 in Figure 4a) are are three separate code parts, namely, the struct definition
represented by int *v inside struct B1 (line 3 in Fig- part, the function definition part and the struct instantia-
ure 4b). Note that all the ports are represented by pointer tion part. After the system compilation, the function definition
type, part becomes the code segment while the struct instantia-
tion part becomes the data segment for the final object file.
• R5: function main inside behavior B1 is converted to a
global function B1 main in the output C code. One ad-
C. The Algorithm
ditional parameter, struct B1 *this is added reflecting
that this function belongs to behavior B1 in the specifica- We have implemented a code generation tool that can con-
tion. We need this parameter because there might be mul- vert the software part of an embedded system described in
tiple instances of B1 and each has its own data members. SpecC into efficient ANSI C code. Algorithm1 reflects the six
In case only one instances exists. This parameter can be rules for software code generation in the previous section and
optimized away. Note that, inside function B1 main, ref- it is used to generate C code for a task described in SpecC. The
erences to data members of behavior B1 are replaced by detailed explanation for Algorithm1 can be found in [19].
D. CoSimulation with System Model 1 struct B2B3
2 { struct Task_B2 task_b2;
As shown in Figure 2, to validate the software, the C code is 3 struct Task_B3 task_b3;
co-simulated with the other part of the system using the SLDL 4 };
simulator as a simulation backplane. In this process, the C 5 void *B2_main(void *arg)
code is imported to the design and wrapped by SLDL mod- 6 { struct Task_B2 *this=(struct Task_B2*)arg;
7 ...
ules. The software part of the system specification code is then 8 pthread_exit(NULL);
replaced by the C code with SLDL wrappers using SLDL’s 9 }
plug’n’play capabilities while task scheduling and inter-task 10 void *B3_main(void *arg)
communication are still provided by the RTOS model routines. 11 { struct Task_B3 *this=(struct Task_B3*)arg;
12 ...
13 pthread_exit(NULL);
14 }
VI. O PERATING S YSTEM TARGETING 15 void *B2B3_main(void *arg)
16 { struct B2B3 *this= (struct B2B3*)arg;
After the C code is validated through the co-simulation. 17 int status;
The operating system targeting step generates the final read- 18 pthread_t *task_b2;
to-compile C code. Generally, this means that each routine 19 pthread_t *task_b3;
20 /*task_b2.os_task_create()*/
of the RTOS model interface will be mapped to 1 or N target 21 pthread_create(task_b2, NULL,
RTOS APIs [12]. 22 B2_main, &this->task_b2);
23 /*task_b3.os_task_create()*/
24 pthread_create(task_b3, NULL,
A. Task Management 25 B3_main, &this->task_b3);
26 /*t = os.fork()
In the target processor, task management is handled by the 27 par { task_b2.main();
real RTOS calls. Without loss of generality, we use the POSIX 28 task_b3.main(); }*/
pthread interface, which is supported by many RTOS[1, 5]. 29 /*os.join(t)*/
pthread_join(*task_b2, (void **)&status);
Some of the task management routines (e.g. task create) of 30
31 pthread_join(*task_b3, (void **)&status);
the RTOS model can be directly mapped to the correspond- 32 pthread_exit(NULL);
ing pthread interface routines. For those routines which can’t 33 }
be mapped to pthread interfaces, we implemented them using
combinations of target RTOS APIs. Fig. 5. Task management implementation
Figure 5 shows the generated C code for the example in Fig-
ure 3. In the output C code, two behaviors T ask B2 and
T ask B3 (which represents two tasks in RTOS model) are SPEC TLM SW(TLM) C
turned into two POSIX threads (line 5 and line 10). They are
Behaviors 102 127 96 0
created dynamically inside the thread B2B3 main (line 21
Operations 16,614 19,526 14,573 23,868
and line 24). The RTOS model routines (code commented out)
Lines. 11,557 12,606 10,920 7,882
are replaced by the corresponding phtread interface routines.
TABLE I
B. Task Communication VOCODER EXPERIMENTAL RESULTS .

In our RTOS model, tasks communicate using channels


from RTOS model library. In the final target software im-
plementation, IPC (inter process communication) mechanisms the SoC Environment. We applied the software generation
(mutex, semaphore, mailbox, FIFO etc) are normally provided tool to the design of a voice codec for mobile phone appli-
by RTOS to support task communication. Implementing com- cations [13]. The result is shown in Table I. The original
munication means replacing functions of RTOS model chan- specification contains 102 behaviors (16614 C level operations
nels with equivalent services of the target RTOS library rou- (plus,minus,multiply...), 11557 lines of SpecC code). After
tines. Currently, our software generation tool can only support SW/HW partitioning and scheduling, we added 2 component
channels from the RTOS model standard channel library. behaviors representing two PEs and 23 behaviors for compo-
nent communication and synchronization. The output trans-
C. Binary Code Creation action level model contains 127 behaviors (19526 operations,
12606 lines of SpecC code) in which the software part has 96
Depending on the number of tasks and the selected RTOS, a behaviors (14573 operations, 10920 lines of SpecC code). We
makefile is created for the chosen target platform. The gener- applied the automatic software generation tool to the transac-
ated C code can be cross compiled and linked against the target tion level model and it generated 7,882 lines of C code (23868
RTOS libraries to create the final binary executable file. operations) for the software part of Vocoder. The reason for
more operations in the generated C code than in SLDL is that
many pointer operations are introduced inside C functions to
VII. E XPERIMENTAL R ESULTS
access C struct members.
We developed a tool of creating ANSI C code from SpecC To create the final executable, the model was compiled into
SLDL, it has been integrated into our system level design tool: binary code for the ARM processor and the RTOS model was
replaced by the µC/OS-II real time operating system. The fi- [16] F. Herrera, H. Posadas, P. Sanchez, and E. Villar. Systematic embedded
nal executable image size is 75KB (47KB code/28KB data) in software generation from systemc. In Proceedings of Design, Automa-
tion and Test in Europe, March 2003.
which the vocoder software is 52KB (33KB code/19KB data).
[17] B. Lin. Software synthesis of process-based concurrent programs. In
Proceedings of the Design Automation Conference, 1998.
VIII. C ONCLUSIONS [18] J. L. Pino, S. Ha, E. A. Lee, and J. T. Buck. Software synthesis for dsp
using ptolemy. Journal of VLSI Signal Processing, 1995.
In this paper, we presented the steps for generating em- [19] H. Yu, R. Dömer, and D. Gajski. Automatic Software Generation for
bedded software from system specification written in SLDL. System Level Design. Technical Report CECS-03-18, UCI, May 2003.
The automation of embedded software creation process frees
the designer from the tedious and error-prone work of creat-
ing software manually after SW/HW partition. Since the fi-
nal software is derived from the specification, validation of the
software code become easier than the manually written code.
Also, the designer doesn’t need to maintain two different ver-
sions of system code (for software specification and software
implementation ).
We developed a tool of creating ANSI C code from SLDL.
Experiments are performed to show the usefulness of the tool
in system design. Currently the tool is written for SpecC SLDL
because of its simplicity. However, the concepts in this paper
can also be applied to SystemC.
Future work includes automatically generating co-
simulation model from the generated binary code to test the
performance as well as validating the generated software with
other parts of the system.

R EFERENCES
[1] QNX. Available: http://www.qnx.com/.
[2] Rational. http://www.rational.com/uml/index.html.
[3] SpecC. http://www.specc.org/.
[4] SystemC. http://www.systemc.org/.
[5] VxWorks.http://www.vxworks.com/.
[6] F. Balarin et al. Hardware-Software Co-design of Embedded Systems –
The POLIS approach. Kluwer Academic Publishers, January 1997.
[7] F. Boussinot and R. de Simone. The ESTEREL Language. In Proceed-
ings of the IEEE, September 1991.
[8] J. Cortadella, A. Kondratyev, L. Lavagno, M. Massot, S. Moral,
C. Passerone, Y. Watanabe, and A. L. Sangiovanni-Vincentelli. Task
generation and compile time scheduling for mixed data-control embed-
ded software. In Proceedings of the Design Automation Conference, June
2000.
[9] D. Desmet, D. Verkest, and H. D. Man. Operating system based software
generation for system-on-chip. In Proceedings of the Design Automation
Conference, June 2000.
[10] D. Gajski, J. Zhu, R. Dömer, A. Gerstlauer, and S. Zhao. SpecC: Speci-
fication Language and Methodology. Kluwer Academic Publishers, Jan-
uary 2000.
[11] L. Gauthier et al. Automatic generation and targeting of application-
specific operating systems and embedded systems software. IEEE Trans.
on CAD, November 2001.
[12] A. Gerstlauer, H. Yu, and D. Gajski. RTOS modeling in system level
design. In Proceedings of Design, Automation and Test in Europe, Mar.
2003.
[13] A. Gerstlauer, S. Zhao, D. Gajski, and A. M. Horak. Design of a GSM
Vocoder using SpecC Methodology. Technical Report ICS-TR-99-11,
UCI, Feburary 1999.
[14] T. Grötker, S. Liao, G. Martin, and S. Swan. System Design with Sys-
temC. Kluwer Academic Publishers, 2002.
[15] D. Harel et al. Statemate: a working environment for the development of
complex reactive systems. IEEE Trans. on Software Engineering, April
1990.

You might also like