EE249 Term Project Report




Дата канвертавання25.04.2016
Памер59.44 Kb.
Interfacing POLIS to Mentor Graphics RTOS
Minxi Gao and Sherry Xu

minxi@ic.eecs.berkeley.edu

xiaoling@ic.eecs.berkeley.edu
EE249 Term Project Report

December 10, 1998


Department of Electrical Engineering and Computer Sciences

University of California at U.C.Berkeley



Abstract


In this paper, we present the procedure to automatically interface POLIS to Mentor Graphics VRTXoc RTOS and to compare the memory and performance of POLIS OS and Mentor Graphics VRTXoc RTOS. Currently, commercial RTOS such as VRTXoc provides operation system service routines for embedded systems that significantly reduce the design cycle. Commercial RTOSs are quite general and therefore are not efficient for many applications. However, it is still desirable for POLIS to be able to interface commercial RTOSs, since they are often well structured and easy to maintain. They also provide a wider range of service routines that Polis does not support. We developed a set of tools that automatically generate this interface. We also measured the base performance metrics for some of the VRTXoc service routines. In addition, another type of communication mechanism, message queuing, was also explored by using VRTXoc.
1. Introduction
Currently, POLIS provides an automatically generated operating system for the application that it generates. POLIS OS is application specific and usually is more efficient than a commercial RTOS. However, a commercial RTOS is still sometimes preferred in certain situations, as they provide a wider ranger of service routines. It is also well structured and easy to maintain. It may also be chosento comply with a company’s policy and to access features such as file or network I/O.
Some previous work was done on the CMX RTOS with the belt controller example that was supplied with a Motorola HC11 micro controller target board. In this project, we attempted to interface POLIS generated application to another commercial RTOS, Mentor Graphics VRTXoc RTOS (section 2). We also wanted to measured and compared performance metrics for both POLIS OS and VRTXoc (section 3). Upon success, we also automatically generated this interface which was not done in the previous work with Motorola HC11 (section 4). Finally, we want to use VRTXoc to explore another communication mechanism, message queuing, which is not supported by Polis at current stage, but is desirable in future work(section 5).

2. Manual Implementation of the Interface
The application example that we chose to experiment on was the dash board belt controller. We use the POLIS pure software partitioning to obtain the z_belt_control.c, z_timer.c and the POLIS operating system os.c files. We wanted to use the ARMulator to execute and evaluate the two operating systems on the belt controller example. We used the software simulation method to input user events by prompting the user with an infinite printf(command) loop. We used the round robin scheduling for POLIS OS. For VRTXoc, we were not able to use the round robin scheduling that is provided by the kernel because the scheduling requires a target board supported timer which we currently do not have access to. We have used a task suspension call sc_delay(0) provided by VRTXoc to manually implement the round robin scheduling.
The open source license Mentor Graphics VRTXoc provides a configuration tool that
enable the user to generate an OS by providing system specifications such as tasks, events, queues, timers and interrupt services routines. By running the configuration tool, a set of application specific files will be generated which include a system start.s file and initialization files for the RTOS service routines. (The detail about how to run VRTXoc’s configuration tools is in the appendices at the end of this paper.) This configuration tool, however, is designed for their own ARM debugger, rather than the ARMulator that we chose to work with. For example, the start.s file tries to allocate stack to the tasks which overwrites the ARMulator standard kernel support and we were unable to print to or scan from the console. The make file is also automatically generated by this configuration tool that uses a library whose source code is not contained in the open license source code. Upon suggestion from mentor Bassam Tabbara, we decided to extract only the VRTXoc source files that are needed by the belt controller application and recompile it with the ARMulator compiler. This method worked well.
To interface the belt controller with VRTXoc service routines, we have to first create a “main” function that will initialize the RTOS. The VRTXoc initialization routines make the application tasks and events known to the kernel.
We also need to add a wrapper for the application tasks, e.g. z_belt_control_0.c, that will interface to the VRTXoc service routines. Unlike the POLIS scheduler that explicitly calls the tasks, VRTXoc reschedule the tasks by calling service routines from the current task that will jump to the next task with the next highest priority, effectively suspending the current task.
To keep system integrity, the application routines _t_z_belt_control_0( ) and _t_z_timer_0( ) are untouched. Instead, the emit functions in the original os.c now contain sc_fpost( ) from VRTXoc to post events instead of the POLIS event posting implementation.
Since the POLIS scheduler is now replaced by the VRTXoc scheduler initiated by calling task suspending routines such as sc_fpend, we have implemented the software simulation user interaction routine in poll_taker.

3. Size and Performance
We measured the ROM and RAM usage for both Polis’s and Mentor’s OS & applications. We also measured the basic performance metrics for both OS. Results are attached in Appendix A.
VRTXoc uses more memory than POLIS: VRTXoc provides a lot more service routines, which adds ROM space. In addition, during the execution time, Mentor uses variables for those service routines and therefore has RAM than Polis does. The application ROM space for VRTXoc is also larger because we used an additional wrapper for each of the task Polis generates.
As of the performance measurement, as we can see from the table (Appendix A), the measurement we obtained is quite different from the data Mentor Graphics provides. After talking to Mentor Graphics Technical Support, we consider that one possible reason could be the environment: Mentor Graphics used a target board to measure the performance meaning they could not go through the code line by line. According to Mentor Graphics Technical Support, they ran the function to be measured 1000 time and then take the average execution time. The measurement for some of the functions could be complex such as sc_delay(0) with context switch, sc_fpend with context switch, and sc_qpend with context switch. For instance, if sc_delay(0) is called, it will invoke the rescheduling routine, namely vmc_schedule_enable( ) which executes ContextSwitch. Because of this context switch, this rescheduler will not return to the calling function, rather it will jump to the next highest priority task. After execution, this task will not return to sc_delay(0) until it is later suspended by a system call such as sc_fpend( ) again through the rescheduler:


sc_delay(0)
1



8

2 7



sc_fpend( )

vmc_tresched( )
3



6

4 5



The numbers represent the order that the transaction is executed.
Since Mentor was using a target board, they measure the time from the moment a routine calls sc_delay(0) until sc_delay(0) returns to this task. This process includes all the tasks running in between. They may have used a dummy task, but they still will have to include the execution time of the system calls such as sc_fpend( ) and ContextSwitch back from the task to sc_delay(0). We also measure the time from the routine calling sc_delay(0) until it returns to this routine, but we subtracted the execution time of the task and all system functions involved with calling this task, such as sc_fpend( ) and ContextSwitch from the task to sc_delay(0). This could explain why Mentor Graphic has a measurement much larger than ours (about twice). We also tried taking the measurement using their approach and we got a very close number as theirs.
The schedule latency measurement is not fair to VRTXoc. We explained earlier that because we do not have a target board, we had to use “sc_delay(0)” to manually implement the round robin scheduling. This function itself takes a long time to finish. We believe that if we have used VRTXoc’s default round-robin scheduler, the difference between the two schedule latencies could be narrowed down.
In analyzing the service routine execution time with similar functionality from both VRTXoc and Polis, we have the following observations: most of the VRTXoc service routines are written in C, instead of assembly language. Although Polis also has the service routine in C, it is an application specific OS and therefore does not have the overhead that VRTXoc has to keep the generality. We would like to use the function call “sc_fpost” from VRTXoc and function fall “deliver_e_reset_to_z_belt_control_0” from Polis to make the comparison:
In Polis, the routine to post a event, “deliver_e_reset_to_z_belt_control_0” is as follows:

#define deliver_e_reset_to_z_belt_control {*(inp_events[_p_z_timer_0]+0) |= 2;}


In VRTXoc, this service routine “sc_fpost” is defined as:
/*---------------------------------------------------------------------*/

SYSCALLv sc_fpost(int evgroup, vmc_event_t event, int *err)

{

register struct fentry *fptr;



register struct tentry *tcbp;

int next_tid, tid = NO_TID;

cpu_interrupt_t ps;

vmc_event_t new_flags;


if ((unsigned) evgroup < vmc_nflag) {

....


disable(ps);

....


....

new_flags = fptr->fevent |= event;

....

start:


for (tid = fptr->list; tid != NO_TID; tid = next_tid) {

....


....

restore(ps);



}

}

/*---------------------------------------------------------------------*/


VRTXoc first checks whether the event is put into a correct event group and whether it is valid. It then disables the interrupt, which is an overhead in our situation since we are not using interrupt at all. All that Polis does in posting the event is included in VRTXoc in one single line new_flags=fptr->fevent|=event. After that, sc_fpost( ) checks for each task suspended for that event, and updates them. This is also not included in Polis.
By comparing these two function calls, we see that VRTXoc scarifies the performance to maintain generality. However, we believe that for complex applications, the performance gap should be reduced.
4) Automating the Interface Generation
The automation process is rather simple. The most important information is the task names, event names, event bit positions in the inp_event used by the poll_taker to check for a specific event ID for the tasks. We also provide the user a choice to use either event flag or message queuing as his/her communication mechanism. (All the automation scripts are appended in the end of the paper.)
We used Perl script to extract the above information in a temp file that we remove after the process is complete. The temp file is extracted from the POLIS os.c file and is also used by all the new task files for VRTXoc.
In the future, the command gen_os can be modified to add a switch for interfacing VRTXoc. This way we will not have to go through an extra step and can be more consistent with the whole design generation process.
5. Communication between Different Task
At this point, the only communication mechanism Polis supports is event passing. Each event corresponds to one bit in the event buffer. In the belt example, a character sized event buffer is used for each task, namely, poll_taker, z_belt_control_0 and z_timer_0. The advantage of using event passing mechanism is to save memory: in the best situation, we need only one bit memory for each event. The disadvantage is that in some cases, it may miss events. For instance, if we had used a scheduler that gets inputs faster than the tasks can handle, e.g., two msec are input every time z_timer_0 is executed. Using event passing mechanism, we will miss one msec event, since we only have one bit for the msec event with the second msec event overwriting the first one. This is a drawback for event passing mechanism. Except for some cases where missing event can be tolerated, we will have to introduce a new communication mechanism for Polis.
VRTXoc also supports event passing mechanism. It works in a similar way as Polis, except for: 1) Instead of using a char sized buffer for each task, the basic unit for event buffer VRTXoc supports is an int which has a length of 32 bits for ARM7, the microcontroller that we experimented with. This could introduce waste of memory. In our example, z_timer_0 only has two input events, “msec” and “start_timer”. Since the basic unit for event buffer in VRTXoc is an int, 30 bits of memory is unused. However, for Polis, only 6 bits is unused. 2) VRTXoc has very complete error checking mechanism. In the case of event overwriting that we mentioned earlier, VRTXoc would return an error message to the task/procedure posting the event. This allows the user to be aware of the missing events.
In addition to event passing mechanism, VRTXoc also supports two other communication mechanisms: message queuing and passing message through mailbox. We only experimented with message queuing, as we believed that we can resolve the missing event problem by using this mechanism. VRTXoc uses buffer with fixed size pointer type or each message. User can specify as many buffer as they like for each message queue. VRTXoc supports up to 255 queues for each application. If there are two msec events being received from the input, they can be queued together in the message queue for task z_timer_0. The task can then work on both of them later, one at a time.
We noticed that for VRTXoc, the execution time for handling event flag is larger than the execution time for handling message queuing. (As shown in the performance result section) For event flag passing, VRTXoc allows different tasks to pend for the same event. However, for message queuing, VRTXoc allows only one task pending to that message. We consider this to be a reason that VRTXoc handles message queuing faster than it does to event passing.
6. Conclusion

In this paper, we described the procedure to manually and automatically interface POLIS to Mentor Graphics VRTXoc RTOS. We also measured and compared the memory and performance of POLIS OS and Mentor Graphics VRTXoc RTOS. We observed that POLIS is more efficient because it is application specific. VRTXoc, however, is expected to provide a better structured and easier to maintain environment for its more complete support in various service routines as well as error checking scheme. Overall, the project was successful: we were able to accomplish all the goals we started out with.


Acknowledgments

Special thanks to our mentor Bassam Tabbara for generously sparing his time and supervision throughout the project. We also want to thank technical support personnel from Mentor Graphics Inc. for helping us with some of the problems in using VRTXoc.


References:


  1. Balarin, Jurecska, Tabbara, “Automatic Generation of a Real-Time

Operating System for Embedded Systems

  1. Balarin, et al. “Hardware-Software Co-Design of Embedded Systems, the POLIS Approach”


Appendix A: Size and Performance Measurement Tables

Size (in bytes)





POLIS

VRTXoc


Application RAM

32

32

OS RAM

400

524

Total RAM

432

556

Application ROM

600

968

OS ROM

4528

12708

Total ROM

5128

13676

Total memory

5560

14232


Appendix A: Size and Performance Measurement Tables (continued)

Performance



Call Name

Description

Execution Time (msec)







our data

Mentor’s data

sc_delay(0)

(w/o context switch)



preemptive the current task.

push it to the lowest priority



4

9.3

sc_delay(0)

(w/ context switch)






31a/41b

57.5

sc_fpend(...)

(w/o context switch)

(w/o pended task)


pend the task for some event

6

11.9

sc_fpend(...)

(w/ context switch)

(w/ pended task)





35a/49b

59.9

sc_fpost(...)

(w/o context switch)

(w/o pended task)


post an event into the event buffer

9




sc_fpost(...)

(w/o context switch)

(w/ pended task)





26

47.4

sc_fclear(...)


clear the event from the event buffer

3

8.3

sc_qpend(...)

(w/o context switch)

(w/o pended task)


pend the task for some message

5

12.0

sc_qpend(...)

(w/ context switch)

(w/ pended task)





27a/41b

47.3

sc_qpost(...)

(w/o context switch)

(w/o pended task)


post a message into a message queue

6

11.5

sc_qpost(...)

(w/o context switch)

(w/ pended task)





22

35.9

a: with one context switch



b: with two context switch
We also compared some of the metrics from Polis and Mentor.




Polis OS(msec)

Mentor OS(msec)

Schedule Latency

14

52

Context Switch

2

4

detect

1

1

emit

4

19



Appendix B: File for Automation


All files are in /usr/xiaoling/ee249/project/demo/auto_package_queue


File Name

Description

Format

Example


vrtx_auto



The executable file user need to use to generate the files for Mentor VRTXoc

vrtx_oc target_name polis_os_filename polis_task_filename1 polis_task_filename2

vrtx_oc belt

os z_belt_control_0 z_timer_0

auto_gen_os


The file used by vrtx_auto to modify Polis’s os.c file by using event flag as the communcation mechanism.

auto_gen_os polis_os_filename.c

auto_gen_os os.c

auto_gen_task

The file used by vrtx_auto to modify Polis’s task file by using queue as the communcation mechanism.

auto_gen_task polis_task_filename.c

auto_gen_task z_belt_control_0.c

auto_gen_userdef

The file used by vrtx_auto to modify Mentor’s tmplt.def file, by using event flag as the communication mechanism.

auto_gen_userdef

auto_gen_userdef

auto_gen_os_queue

The file used by vrtx_auto to modify Polis’s os.c file by using queue as the communcation mechanism.

auto_gen_os_queue polis_os_filename.c

auto_gen_os_queue os.c

auto_gen_task_queue

The file used by vrtx_auto to modify Polis’s task file by using queue as the communcation mechanism.

auto_gen_task_queue polis_task_filename.c

auto_gen_task_queue z_belt_control_0.c

->continued










auto_gen_userdef_queue

The file used by vrtx_auto to modify Mentor’s tmplt.def file, by using queue as the communication mechanism.

auto_gen_userdef_queue

Auto_gen_userdef_queue

tmplt.def

The tmplt file we provided for Mentor’s configuration







os.c

Os file Polis generated







z_belt_control_0.c

Task file Polis generated







z_timer_0.c

Task file Polis generated







Output files from Automation


Mentor_os.c : modified Polis os.c file for VRTXoc usage

Mentor_z_*.c: modified Polis task files for VRTXoc usage

User.def: The file modified from tmplt.def, for VRTXoc’s configuration usage.

Appendix C Files supplied by Mentor


WS_FTP.LOG

ansiprot.h

arm.h

assert.h


context.s

cpu.h


cpu_cm.h

delay.c


delay.h

dequeued.c

error.h

event.h


fclear.c

fcreate.c

fpend.c

fpost.c


global.c

inivrtx.c

insert.c

insertd.c

intendis.s

interrup.s

kernel.h

loc_types.c

loc_types.h

makefile


panic.c

partition.h

processor.h

procinit.c

q.h

qcreate.c



qpend.c

qpost.c


queue.h

rdinsert.c

rmc.c

rmc.h


rmc.o

simul_0.h

simul_1.h

sysinit.c : We modified this file to allow us to run an initialization loop in the beginning of the program.

sysinit.o

target.h


task.h

taskinit.c

tcreate.c

test.txt


ticker.c

timer.c


timer.h

timerhd.c

tresched.c

tsuspend.c

twakeup.c

uC_types.c

uC_types.h

unlock.c


user.def

userexit.c

vmcconf.c

vmcconf.h

vmcconf.o

vmcisrst.o

vmcisrst.s

vrtxil.h


vthandle.c


Appendix D: Configuration Tools From VRTXoc
Mentor provides user a configuration tool, allows the user to define all the application specific OS objects, such as tasks, events, interrupts, e.t.c. The input to the tool is “user.def”, which is written by the user.
We do provide user a tmplt file for configuration. In addition, we provide the user an automation tool to generate the file “user.def” from the tmplt file. But we recommend the user to modified the “user.def” themselves, just use our “tmplt.def” file as an example.



База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка