Final thesis

Evaluation of Real-Time Operating Systemsfor Xilinx MicroBlaze CPU

Performed for ABB Corporate Research

byAnders Ronnholm

MDH-IDE-EX--2006/xxx--SE

2006-06-01

Final thesis

Evaluation of Real-Time Operating Systems forXilinx MicroBlaze CPU

by

Anders RonnholmMalardalens University

Department of Computer Science and ElectronicsPO Box 883

SE-721 23 Vasteras, Swedenanders.ronnholm@gmail.comarm00001@student.mdh.se

MDH-IDE-EX--2006/xxx--SE

Supervisors : Susanna NordstromDept. of Computer Science and Electronicsat Malardalens University

Roger MellanderAutomation Technologiesat ABB Corporate ResearchAnders PetterssonDept. of Computer Science and Electronicsat Malardalens University

Examiner : Lennart LindhDept. of Computer science and Electronicsat Malardalens University

Abstract

System-On-Chip is an interesting target platform that includes both the com-puter and all required components on one single chip. Having both hardwareand software on a single chip makes an embedded system a typical environment.Many products today offer their solution on several chips making a System-On-Chip design interesting where the whole solution is placed on only one chip.

This thesis evaluates the three operating system Xilkernel, uClinux and As-terix real-time characteristics running on a MicroBlaze on a System-On-Chipplatform. Their determinism and responsiveness are evaluated by testing theirinterrupt latencies and task response times. This thesis also compares the differ-ent kernels priority inversion mechanisms, kernel sizes, scalability and support.

The results show that the real-time systems Xilkernel and Asterix are moredeterministic and responsive than the Linux port uClinux. While the tests forXilkernel and Asterix showed low spreading in interrupt latency, no guaranteescan be made about a worst case execution time. The tests show however thatexecution times much worse than those measured are not likely. Asterix is thesmallest kernel and Xilkernel the most scalable one. uClinux has a much worseworst case execution time but can still be used as a real-time system in a designwithout hard timing requirements but a lot of memory.

Keywords : FPGA, MicroBlaze, uClinux, Xilkernel, Asterix, Determinism,Reliability, Interrupt latency

Sammanfattning

System-On-Chip ar en intressant plattform som inkluderar bade processor ochkomponenter pa ett enda chip. Eftersom allting ligger pa ett enda kort ar inbyg-gda system en typisk miljo. Idag ar det vanliga att produkter ligger pa flera chipvilket gor en System-on-Chip losning intressant dar hela produkten kan ligga paett chip.

Denna rapport kommer att undersoka Xilkenel, uClinux och Asterix ochderas realtids egenskaper pa en MicroBlaze pa en System-on-Chip plattform.Deras determinism och svarbarhet ar undersokta genom ett avbrott svars testoch ett task svars test. Rapporten undersoker aven karnornas mekanismer foratt forhindra prioritets invertering, deras storlek, skalbarhet och support.

Resultaten visar att realtid systemen Xilkernel och Asterix ar mer determin-istiska och svarbara an Linux portningen uClinux. Bade Xilkernel och Asterixhade en lag spridning i deras avbrotts svarstider men de tiderna ger inte nagonmaximal exekveringstid. Testerna visar daremot att det inte ar troligt med tidermycket storre an de uppmatta. Asterix har den minsta storleken och Xilkernelar den mest skalbara karnan. uClinux har en mycket hogre maximal exekver-ingstid men ar anda sa pass bra att den kan anvandas som real-tids system dartidskraven inte ar lika hoga.

iv

v

Foreword

Although this thesis is for anyone with interest in real-time systems and em-bedded systems it targets people with experience about real-time systems andembedded systems.

Tanks to everybody that has been involved and contributed on way or an-other to this thesis and my time at ABB. I would like to mention a few peoplethat were extra helpful to me. My supervisor at ABB Roger Mellander who gaveme the opportunity to write this thesis at ABB and also having the patienceto answer all my questions. Thanks to Susanna Nordstrom my supervisor atMDH for all support she gave me throughout this thesis. Thanks to AndersPettersson who was a great help during the Asterix porting phase. I would alsolike to thank Said Zahrai my project leader at ABB and my examiner LennartLindh for reading this thesis.

Working on this thesis at ABB has been a great time and has given me avaluable experience of how it is to work out in the ”real” world.

Anders Ronnholm - 1st of June 06

vi

Contents

1 Introduction 1Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related works 4

3 Real-Time Operating Systems 5Hard and soft systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Real-Time Operating System Characteristics . . . . . . . . . . . . . . 5

4 The target system ML403 8Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8MicroBlaze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

General purpose registers . . . . . . . . . . . . . . . . . . . . . . 10Special purpose registers . . . . . . . . . . . . . . . . . . . . . . . 10

Bus Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10On-chip Peripheral Bus . . . . . . . . . . . . . . . . . . . . . . . 11Local Memory Bus . . . . . . . . . . . . . . . . . . . . . . . . . . 11Fast Simplex Link Bus . . . . . . . . . . . . . . . . . . . . . . . . 11Xilinx CacheLink . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Debug Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 uClinux 13Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Tool-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Running the kernel and applications . . . . . . . . . . . . . . . . . . . 14Scheduling model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

SCHED OTHER . . . . . . . . . . . . . . . . . . . . . . . . . . . 15SCHED FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15SCHED RR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii

viii CONTENTS

Interrupt handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Xilkernel 17Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Tool-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Running the kernel and applications . . . . . . . . . . . . . . . . . . . 18Scheduling model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Round-Robin scheduling . . . . . . . . . . . . . . . . . . . . . . . 18Priority driven preemptive scheduling . . . . . . . . . . . . . . . 18

Interrupt handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Asterix 20Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Tool-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Running the kernel and applications . . . . . . . . . . . . . . . . . . . 21Scheduling model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Interrupt handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Asterix Porting 23Interrupt handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Context switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9 Evaluation 25Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Priority Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Kernel size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10 Results 29Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Interrupt latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Task response time . . . . . . . . . . . . . . . . . . . . . . . . . . 30Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Priority inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33uClinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Xilkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Asterix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Kernel size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37uClinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Xilkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Asterix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39uClinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

CONTENTS ix

Xilkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Asterix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40uClinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Xilkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Asterix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

11 Summary and conclusion 42

Appendix 46

A Test Programs 46uClinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Xilkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Asterix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

B Benchmark Results 50Minimum latencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Alternative Asterix results . . . . . . . . . . . . . . . . . . . . . . . . . 50Axis tasks benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

x CONTENTS

Chapter 1

Introduction

System-On-Chip (SoC) on an Field Programmable Gate Array (FPGA) board isan interesting platform that is starting to appear more and more throughout theembedded market. One of the reasons is that it places the processor, memorynetwork connection e.g on one single chip, resulting in a smaller and less powerdemanding system. Embedded products are therefore an useful area with itsoften limited space. A SoC typically consists of a 32-bit core processor and a lotof functions that a designer can choose from. These functions include memory,bus interfaces, I/O drivers, decoders and network support [27]. Since embeddedproducts often are placed on locations that need to respond to external eventsin real time a real-time system is often used. The real-time system need to beable to respond to an event fast enough and also be small since memory on thechip is limited. A high scalability on the real-time system is therefore requiredin order to keep down the kernel size.

Background

Today many embedded products place their solution on several chips making itbigger, more expensive and more power requiring. The SoC solution has existeda long time on Application Specific Integrated Circuit (ASIC) boards but israther new on FPGA boards. FPGA boards has become bigger, faster andcheaper and is now able to handle a SoC solution. As the FPGA boards havebecome bigger and faster they are now able to handle a soft processor whichis an Intellectual Property (IP) core implemented using logical primitives. Akey benefit is configurability where it is possible to add only what is neededin the design. A trade of is performance, a hard processor is faster but lessconfigurable and more expensive [29]. More and more companies are thereforelooking into the possibility of using SoC on an FPGA board with a soft processorwhich makes it easier to develop and evaluate the solution. A kernel running ona soft processor is required to be small and Asterix was chosen because of itssmall size, and connections to researchers at Malardalen University. Xilkernel

1

2 1.0. Thesis

was chosen because of its integration into the Xilinx tools. uClinux was chosenbecause of the growing interest of uClinux. All three kernels needed to providethe source-code.

Thesis

This thesis will evaluate the operating system uClinux and the Real-Time Oper-ating Systems (RTOS) Xilkernel and Asterix. Their performance will be testedon the soft processor MicroBlaze with respect to real-time requirements. Thequality of their support, the kernels scalability and sizes will also be evaluated.A soft processor is an on a FPGA board.

Methodology

The performance test consists of the following two benchmarks. They are madeto determine how predictable and fast they can respond to interrupts.

• Interrupt latency - The time from an interrupt until its assigned InterruptService Routine (ISR) starts to execute.[17]

• Task response time - This Benchmark will test how long it takes for a taskto start executing from that an interrupt has occurred.

Priority inversion is another requirement that will be evaluated, since mostreal-time systems offer some sort of protection against priority inversion. Prior-ity inversion occurs when a lower priority task blocks a higher priority task byholding a semaphore that the higher priority task is waiting for [17]. This eval-uation will be strictly theoretical and will only evaluate if the systems providesa mechanism to avoid this and what that might be.

The support evaluation is to investigate if there is any commercial supportbecause it is important that there is help when a problem occurs.

Their scalability is evaluated by investigating what possibility there is tomodify the kernels to include and exclude functionality. A well scaled kernelkeeps down the kernel size by only including the needed functionality.

The kernel sizes are each kernels footprint which is the amount of memorythey consume. Embedded systems has limited space and therefore requires asmall kernel.

Following equipments have been used throughout this thesis:

• ML-403 evaluation board

• Virtex4 XC4VFX12 - Speedgrade -10

• Xilinx Embedded Development Kit (EDK), version 7.1 service pack 2

• uClinux version 2.4.32

• Xilkernel 3.00a, provided in EDK 7.1

Introduction 3

• MicroBlaze 4.00a, provided in EDK 7.1

• Co-Linux 0.6.2

• Windows XP service pack 2

Outline

Chapter 2 presents related works. Chapter 3 describes differences between anoperating system and an RTOS. Chapter 4 presents the target system ML403.The evaluated kernels uClinux, Xilkernel and Asterix are presented in chapters5, 6 and 7. Chapter 8 explains the Asterix porting process. Chapter 9 discussesin more detail what the evaluation will compare and why. In chapter 10 resultsfrom the evaluation are presented, analysis of the results and future work in thearea. Chapter 11 summarizes the work.

Chapter 2

Related works

Linuxdevices.com has several interesting articles measuring interrupt latenciesand task response times on Linux and uClinux. Venkatakrishnan has porteduClinux 2.4 to the MTPSR2-150 processor and gives an interrupt latency bench-mark [19]. In his test uClinux had a maximum interrupt latency of 15,816 clockcycles and a minimum of 2,100. An interesting benchmark from H.S. Choi andH.C. Yun gives a context switch comparison between Linux 2.4 and uClinux 2.4[2]. Their test shows that uClinux is faster when using cache because it hasonly a single address space. Ordinary Linux has to invalidate the cache in eachcontext switch because of its virtual space.

The researchers at Malardalen Real-Time Research Center have publisheda paper regarding Asterix, The Asterix Real-Time Kernel [28]. It discusses theAsterix design its functionality and characteristics. Joakim Lindgren has done amaster thesis where he developed a configuration tool named Obelix for Asterix[7]. Obelix consists of a configuration tool, a down-loader, an up-loader and across compiler. Joakim Lindgrens thesis gives a deep insight into Obelix and itsdifferent parts.

Xilinx has released a document that gives a thoroughly description of Xilk-ernel [18]. It discusses among other things the scheduling model, interrupthandling and the Xilkernel API.

An interesting comparison between the synthesizable processors MircoBlaze,LEON2 and OpenRISC 2000 is presented in a master thesis from Chalmersuniversity [10]. It compares the performance, configurability and usability. TheMicroBlaze version used is 2.10.a and it performs well in the benchmarks but itis discovered that it does not follow the floating point standard.

4

Chapter 3

Real-Time OperatingSystems

Hard and soft systems

There are two different types of RTOSes, hard and soft systems.In a hard RTOS the system must be able to react to an event within a set

deadline. If a deadline miss would occur the system would failure and result infatal consequences, either in major financial losses or in human lives. Examplesof systems that have hard real-time constraints are airbags and nuclear plants[17] [5].

In the event of a deadline miss in a soft system the result is not fatal forthe system and it still has a value to complete the operation after the deadline.Media player applications are a typical area where it is not vital that every frameis showed but more important that they are processed in a timely manner [17][24].

A RTOS often consists of both hard and soft tasks. The hard tasks mustmeet their deadlines otherwise the system will fail. The system tries to meetthe deadlines of the soft tasks but a missed deadline on one of those does notlead to a failure.

Real-Time Operating System Characteristics

A real-time operating system can be characterized by the following requirements[25] [16]:

• Determinism - Is the tendency of a system to perform operations at a welldefined predetermined time intervals. While a non deterministic systemhas no upper boundary for operation times a fully deterministic systemexecutes operations in the same amount of time, all the time. How wellan operating system deterministically handles process requests depends on

5

6 3.0. Real-Time Operating System Characteristics

two things. How fast it can respond to interrupts and if the system has thecapacity to handle all requests within its deadline. A system that for longperiods operate with interrupts disabled has a less deterministic behaviorthen a system that always have enabled interrupts since its determinism iseffected of how long time it will continue operate with disabled interruptswhen an interrupt occurs. A system that always has enabled interruptshas a better determinism since it will be able to respond to the interruptimmediately. A measurement of operating systems determinism is to mea-sure the systems interrupt latency spreading. A non real-time system canhave long interrupt latencies, between 10-100 milliseconds. A RTOS onthe other hand may have interrupt latencies from a few microseconds upto a millisecond.

• Responsiveness - Is related to determinism. In determinism the focus layson how predictable the system is. Responsiveness concerns the ability torespond quickly to an event, the time from acknowledgment until it isbeing serviced. Three important components in responsiveness are:

– The time it takes to handle the interrupt and start execution of cor-responding ISR. This time is very dependent on the ISR type. If theISR is a task requiring a context switch, then the time to performthe context switch becomes a significant delay that do not exist if theISR can run within current context.

– The time it takes to execute the ISR.

– Nested interrupts. If an ISR can be interrupted by another higherpriority interrupt the ISR will be delayed.

Determinism combined with responsiveness make up the interrupt re-sponse time, a critical requirement in a RTOS because they must respondto asynchronous events generated by users and external devices.

• User control - Is much broader in a RTOS than in an ordinary operatingsystem. In a RTOS it is essential that the user has a good control overthe scheduling. The user should be able to define hard- and soft tasks andspecify relative priorities within each class. A non mandatory functionalitycould also be to give the user option to specify the use of page or processswapping.

• Reliability - Typically much more important in an RTOS than in an ordi-nary operating system. In a ordinary operating system a failure can oftenbe solved by rebooting the system. But if the same would happen to aRTOS, since it is often placed in an environment that need a real-time re-sponsiveness would be catastrophic. A process failing in a factory buildingcars could lead to major financial losses, a process failing in an airplanecould lead to loss of human life. A system that can run continuously foryears without failure is therefore vital.

Real-Time Operating Systems 7

• Fail-soft operation - Refers to the systems ability to preserve as much ca-pability and data as possible on a failure. For example, when a corruptionof data is detected in UNIX it performs a panic operation that issues afailure message on the system console, dumps the memory contents to diskfor failure analysis and terminates execution of the system. In a RTOSin the same example it would either attempt to correct the problem orminimize the effect and if possible continue to run, possibly with a re-duced level of performance. Stability is an important aspect of fail-safeoperation. A stable RTOS meets at least its hard tasks deadlines when itis impossible to schedule all task to meet their deadlines.

To meet the previous requirements real-time operating systems need to have[25] [26]:

• A Fast context switch

• A Small size (with its associated minimal functionality)

• Ability to respond to external interrupts quickly

• Multitasking with interprocess communication tools such as semaphores,signals and events

• Use of special sequential files that can accumulate data at a fast rate

• Preemptive scheduling based on priority

• Minimization of intervals during which interrupts are disabled

• Primitives to delay tasks for a fixed amount of time and to pause/resumetasks

• Special alarms and time-outs

Chapter 4

The target system ML403

This chapter gives an overview on the target system ML403. It concentrates onthe soft processor MicroBlaze, its architecture, bus interfaces and cache whichis the target processor.

Overview

The target system is a ML403 which is a SoC board from Xilinx. It consistsof many different peripherals such as memory controllers, General Purpose I/O(GPIO) and bus interfaces making it a fitting system in different areas such asIndustrial, Telecom, Medical and Digital Video [15].

Its key features are [31]:

• Virtex4 XC4VFX12 - The chip where all logic connecting the differentperipherals and MicroBlazes are placed.

• Memory - Has support for several different memory types. It has 64 MBDDR-SDRAM, 8Mb SRAM, 64Mb flash and 4kb IIC EEPROM.

• Connectors - Keyboard, mouse, microphone, head phone, RS-232 serialport, USB ports, PC4 JTAG, VGA Display, 10/100/1000 RJ-45 EthernetPort, GPIO consisting of buttons and LED.

The ML403 has support for two processors. A hard PowerPC 405 ReducedInstruction Set Computer (RISC) processor and Xilinx’s own soft MicroBlazeRISC processor. The ML403 can have up to eight MicroBlazes in a design.

MicroBlaze

MicroBlaze is an embedded soft 32-bit RISC core. It is developed and main-tained by Xilinx and is therefore optimized for Xilinx FPGA boards. Anoverview of MicroBlaze architecture can be seen in figure 4.1. It is distributed

8

The target system ML403 9

with Xilinx EDK as a parameterizable netlist and it can also be bought as VHDLsource code for a higher price. MicroBlaze uses a big endian numeric presenta-tion meaning the most significant byte is assigned the lowest byte address.

Figure 4.1: Overview of MicroBlaze architecture

General purpose registers, Special purpose registers, a 32-bit address busand a pipeline are all features that are fixed on MicroBlaze. The list belowconsists of some additional features that can be added to the MicroBlaze [12].

• Hardware barrel shifter - A digital circuit that can shift data any numberof bits in one operation. A vital component in floating point operations

• Hardware divider

• Instruction and data cache

• On-chip peripheral bus (OPB)

• Local memory bus (LMB)

• Fast Simplex Link (FSL)

• Xilinx CacheLink

Registers

MicroBlaze provides two kinds of registers, general purpose registers and specialpurpose registers.

10 4.0. Bus Interface

General purpose registers

There are 32 general purpose registers divided into three categories. Volatile,non-volatile and dedicated [12].

• Volatile registers (caller-save) are temporary registers and do not retaintheir values across function calls. Volatile registers are registers R3-R12,R3 and R4 are used for returning values to the caller function. R5-R12are used to pass parameters.

• Non-volatile registers keep their values across function calls (callee-save).Non-volatile register are registers R19-R31.

• Dedicated registers are the other registers. Registers R14-R17 are used tostore return addresses from interrupts, sub-routines, traps and exceptions.R0 is always value 0 and R1 is used to store the stack pointer. Theseregister should not be used for anything else.

Special purpose registers

There are five special purpose registers [12].

• Machine Status register (MSR) - The MSR register holds control andstatus bits for the processor. In the MSR it is possible to enable/disableinterrupts, exceptions and data and instruction cache. It also containsbits for errors such as division by zero and FSL errors.

• Program counter (PC) - A read-only register containing the address of theexecuting instruction.

• Exception Address Register (EAR) - Stores the full address that causedthe exception.

• Exception Status Register (ESR) - Contains exception status bits for theprocessor.

• Floating Point Status Register (FSR) - Contains status bits for the floatingpoint unit.

Bus Interface

MicroBlaze has several bus interfaces to be used in different areas. It followsthe Harvard architecture where separate paths are used for data and instructionaccesses. An advantage using Harvard architecture is that it makes it possibleto read both instructions and data from memory at the same time [12].

The target system ML403 11

On-chip Peripheral Bus

The OPB is a fully synchronous bus that provides access to both on-chip and off-chip peripherals. The bus is not intended to connect directly to the processor.[3].

Local Memory Bus

The LMB is a fast local bus used to connect MicroBlaze to high-speed periph-erals, mainly Block RAM (BRAM). LMB makes is possible to access BRAM inone clock cycle [12].

Fast Simplex Link Bus

FSL is a one way point-to-point communication bus used between an outputFIFO device and an input FIFO device. It has support for up to eight masterand slave interfaces and data can be transfered in two clock cycles [12].

Xilinx CacheLink

The Xilinx CacheLink (XCL) interface is a high-speed bus for external memorycommunication and is only available when the caches are enabled. XCL canbe combined with an OPB where one cache uses XCL and the other one usesan OPB bus. Memory located outside the cache-able area is accessed throughOPB or LMB [12].

Debug Interface

The debug interface is used with the Microprocessor Debug Module (MDM) andis controlled through the JTAG port by the Xilinx Microprocessor Debugger(XMD) [12].

Cache

The cache consists of both a instruction and a data cache and are controlledusing a bit each in the MSR [12]. They are 1-way associative (Direct mapped),each block (a collection of data containing the requested word) can only beplaced at one place in the cache [6]. The memory can be divided into cache-ableand non-cache-able segments, making it possible to tell exactly what to cache.The only address space that can not be cached is the LMB address space. Thedata-cache uses write-through, where the cache is mirrored on main memory bywriting to memory on each cache writing [6].

The cache can be used with either the OPB interface or the dedicated XCLinterface or as combination. The differences between those interfaces are [12]:

12 4.0. Cache

• CacheLink uses a 4 word cache block (critical word first). It takes therequested word and the next three which increases the hit rate, OPB usesa single word cache block.

• CacheLink uses a dedicated bus interface for memory accesses. This re-duces traffic on the OPB bus.

• The CacheLink interface requires a specialized memory controller inter-face. The OPB interface uses standard OPB memory controllers.

• CacheLink allows posted write accesses on write-misses. OPB caches re-quires the write access to be completed before execution is resumed (Onlydata cache).

Chapter 5

uClinux

This chapter describes the operating system kernel uClinux. uClinux is not areal-time system like the other ones but is still evaluated because of its growingpopularity and many features. uClinux is a derivative of Linux and they aretherefore very similar.

Overview

uClinux (pronounced ”you-see-linux”) is a port of regular Linux, intended for mi-croprocessors that do not have a Memory Management Unit (MMU). In shortMMU translates logical addresses into physical addresses. All requests for datais sent to the MMU, it then decides if the data is in RAM or needs to be fetchedfrom disk. It also decides if the process has the rights to access the memoryit is trying to reach [25]. Without MMU there is no memory protection orvirtual memory leaving a bigger responsibility to the programmer not to writeover other processes memories. The most noticeable effect for the programmeris that vfork() is used instead of fork(). vfork() and fork() creates a child pro-cess that only differs from the parent process by its PID and PPID number [9].uClinux has been ported to many processor architectures, Motorolas Coldfireand Dragonball, Blackfin, ARM7TDMI and MicroBlaze are the ones most used.It exists as a derivative from linux kernels 2.0, 2.4 and 2.6 but it is the 2.4derivative that has been ported to the most number of microprocessors [13].

uClinux consists of two packages; a kernel package and a distribution pack-age. The kernel package only contains the kernel while the distribution packagecontains everything else that makes a complete uClinux operating system. Thatmeans applications, C libraries (glibc, uClibc), vendor specific code and drivers.[11]

13

14 5.0. Tool-chain

Tool-chain

For every ported processor there is a tool-chain package that contains processorspecific compilers such as gcc, g++ and binutils (a collection of binary toolssuch as the linker ld) that must be used when building the kernel and userapplications [14]. There are three steps to create a uClinux system. The first isto configure the kernel, in the configuration there is a possibility to add featuressuch as GPIO drivers, network drivers, flash card drivers, file systems, soundcard drivers e.q. The next step is to compile the kernel. The third is to compilethe system where the kernel, application and file system is linked together.

Running the kernel and applications

All uClinux development needs to be done in a Linux environment where thetool-chain is installed. The compilation of uClinux and its applications createsa binary file containing uClinux its applications and the file-system. To makeuClinux running on the platform the binary file needs to be downloaded withXilinx tools in Windows.

There are several ways to make applications run on uClinux. One way tomake it running is to create the application in the user directory of the distri-bution package (where the sources of all other included applications lies) andinclude it to the user application makefile. Including it to the setup makefilewill also give an option when setting up the kernel to install the program. Thisis suitable if the application should be optional when creating the kernel. Addi-tional device drivers is created the same way but should be placed in the driversdirectory in the uClinux kernel package. To avoid altering makefiles it is alsopossible to manually copy the compiled application binaries to the file systemdirectory that exists in the distribution root directory.

Another way is to make an ”out of tree” compilation. The application iscreated outside the distribution package and only declares a relative path to thedistribution package in the makefile to find the needed libraries. This methodrequires that the compiled binaries are manually copied to the file system direc-tory.

A third and very dynamical way is to download the application from a httpserver with netflash when running the kernel on the embedded system.

When creating applications the programmer need to use vfork() instead offork() when creating child processes, a modification made to circumvent the nonexisting MMU.

Scheduling model

As a derivative of Linux the scheduling model is the standard Linux model.It offers three scheduling models, Round-robin, First-In First-Out (FIFO) andOther. Processes can have a static priority ranging from 1-99 or a dynamicpriority. The dynamic priority is the sum of the base time quantum and the

uClinux 15

number of clock ticks left before the current epochs quantum expires. Epochsare specified CPU time periods and every process has a time quantum, themaximum CPU time the process has in that epoch. When a new epoch isstarted a new time quantum is calculated for every process. Each process canhave the states [1]:

• TASK RUNNING - A running process.

• TASK INTERRUPTIBLE - A suspended process waiting on an interrupt,shared resource or a signal. Then returns to TASK RUNNING

• TASK UNINTERRUPTIBLE - Similar to TASK INTERRUPTIBLE withthe difference that delivering a signal to the process does not change theprocess state.

• TASK STOPPED - A process whose execution has been stopped.

• TASK ZOMBIE - A terminated process. If the parent process has notissued a wait() command to be able to collect return information aboutthe terminated process, the kernel can not discard the terminated processdata.

The kernel is non-preemptive making it less suitable for hard real-time appli-cations. The kernel can spend a long time in kernel mode handling an interruptor exception while a real-time process that becomes runnable wont be able tostart its execution.

SCHED OTHER

SCHED OTHER is a standard time-sharing scheduler and processes using itmust be assigned the static priority 0. This scheduler is for processes that donot have any real-time requirements. The process to run is the process withhighest dynamic priority from the list containing processes with static priority0. The dynamic priority is set by the nice level and is increased each timequantum the process is ready to run but denied by the scheduler. The nice levelis the process base priority [4].

SCHED FIFO

FIFO scheduling can only be used by processes with a static priority higher than0 and will therefore always preempt processes using SCHED OTHER schedul-ing. FIFO scheduling do not use time quantum as the other schedulers, it letsthe current process run until it has finished executing, unless a higher prioritytask gets ready. The preempted task will stay as the head among task with thesame priority. When a task first gets ready it will be placed last among its ownpriority group, hence the name first in first out. [1] [4].

16 5.0. Interrupt handling

SCHED RR

SCHED RR is similar to SCHED FIFO, the difference is that SCHED RR usestime quantum. Each process executes its time slice before it yields its executionand lets the next process in the ready queue start its execution. When a processhas used its time slice it will be put last in its priority group, if it is preemptedit will resume and use the time quantum that was left [1] [4].

Interrupt handling

uClinux uses the same interrupt handling as Linux, it has three types of inter-rupts I/O interrupts, timer interrupts and interprocessor interrupts [22].

• I/O - I/O handlers must be able to service several devices at the sametime since several devices may share the same IRQ line. The I/O interrupthandler executes several ISRs since it is not possible to know what deviceit is that has generated the interrupt. When the correct ISR is found theIRQ line is allocated and released when the ISR is finished with the device.All I/O interrupt have the same priority and are divided into three classes.

– Critical - These are interrupts such as acknowledging an ProgrammableInterrupt Controller (PIC) interrupt or updating data structures.These are critical interrupts that can finish their execution quicklyand are therefore executed within the interrupt handler with inter-rupts disabled.

– Noncritical - These are interrupts such as reading a keyboard keypress, they are also quickly finished and are executed in the interrupthandler, but with interrupts enabled.

– Noncritical deferrable - Sending the keyboard line buffer to the ter-minal handler is a noncritical interrupt. They can be delayed for along time without affecting the kernel operations and are executedin separate functions. These functions are divided in a top half anda bottom half section. Top half is executed immediately while thebottom half is delayed.

• Timer - These interrupts are generated when an Advanced ProgrammableInterrupt Controller (APIC) or external timer has reached fixed-time in-terval and therefore generated an interrupt. They are handled like I/Ointerrupts.

• Interprocessor - Interrupts when multiple processors are used.

Chapter 6

Xilkernel

This chapter describes the RTOS Xilkernel.

Overview

Xilkernel is a small and robust kernel for Xilinx embedded processors. It isshipped with and is therefore highly integrated into the XPS, making it possibleto configure and build a platform using Xilkernel in minutes.

Xilkernel has the following key features [18]:

• A POSIX API targeting embedded systems.

• Statically declare threads to startup with the kernel

• High scalability

• Support for processes running in separate executable ELF files

With its POSIX support application development and porting are madeeasier since it can run almost equivalently on other kernels that use the POSIXstandard. However Xilkernel only defines a chosen subset of POSIX coveringonly the most useful interfaces and concepts [18].

Tool-chain

Xilkernel software development is done using Xilinx EDK. The EDK includesXilinx Platform Studio (XPS) which is an integrated development environment(IDE). The EDK also provides correct compilers for the target platform. XPSgives a wide selection of settings to modify the kernel as needed. It allowsthe user to for example initiate interrupt handlers, add thread support, specifyclock resolution. All modifiable settings can be seen in Xilinx OS and librariesdocument [18].

17

18 6.0. Running the kernel and applications

Running the kernel and applications

Applications can be developed separately or as a software application project inthe XPS, they can also be created in the Software Development Kit (SDK) byimporting the XPS design. All applications need to link to the Xilkernel libraryin order to get the kernel functionality [18]. The kernel and its applications canthen be downloaded to the target within the EDK and SDK.

The applications in Xilkernel can be run in two ways. One method is tobuild the applications into the kernel, having only one executable file. Theother method is to have each application as a separate executable file, the samemethod that is used in a conventional operating system where the kernel is aseparate image file and the applications are separate files. To have it all in onefile makes the bootloading, debugging and downloading easier and is thereforebetter suited during the development phase [18].

Scheduling model

Xilkernel supports two scheduling models; priority driven preemptive schedulingand round-robin scheduling. The scheduling model is global and has to be setwhen configuring the kernel [18].

A process in Xilkernel can have the following states [18].

• PROC NEW - When a process is created it enters this state.

• PROC READY - A process that is ready to execute.

• PROC RUN -A running process.

• PROC WAIT - A process blocked on a shared resource.

• PROC DELAY - A process waiting on a timeout.

• PROC TIMED WAIT - A process blocked on a shared resource with atimeout.

• PROC DEAD - A terminated process.

Round-Robin scheduling

In round-robin there is one ready queue and each process executes its time slicebefore it yields its execution and lets the next process in the queue start itsexecution [18].

Priority driven preemptive scheduling

In the priority driven scheduling there are as many queues as there are prioritieswith priority 0 as the highest priority. Each queue has its own round-robinscheduling and the head process in the highest priority queue is the one that isallowed to execute [18].

Xilkernel 19

Interrupt handling

Interrupts are divided into two levels. The first level performs operations todisable interrupts during the interrupt handling and the stack is switched to akernel stack instead of using the current process stack. The second level activatesthe corresponding ISR. On a MicroBlaze the kernel invisibly registers itself as thehandler to system timer interrupts when an interrupt controller is in use. Whenthe second level is finished the first level resumes and performs rescheduling ifthe executed ISR requires that. When it is done it enable interrupts and returnsto the process scheduled to execute next.

ISRs can perform any action they want, with one execption, they can notperform any blocking operations such as taking a semaphore since that couldblock the entire system [18].

Chapter 7

Asterix

This chapter describes the RTOS Asterix.

Overview

Asterix is a small real-time kernel developed at Malardalen Real-Time ResearchCenter (MRTC) located at Malardalen University, Vasteras (Sweden). It isused in courses at Malardalen University and for different research projects atMRTC.

Its greatest strength lies in its support for powerful development and veri-fication tools. It has a built in monitoring support for tools like deterministictesting and deterministic replay debugging and visualization. Asterix also pro-vides support for a high resolution measurement of task execution times [28].

The Deterministic replay offers reproducible debugging of single tasking,multitasking and distributed real-time systems. While running the kernel infor-mation about interrupts, task-switches, timing and data is recorded for off-linereproduction [28].

Deterministic testing on Asterix uses an analysis technique that given a setof tasks and a schedule calculates all execution orderings that can occur inrun-time. This technique also enables a deterministic and reproducible test-ing. Techniques used to test sequential program can be used since each derivedexecution can be seen as a sequential program [28].

Asterix provides a communication mechanism called Wait and Lock-freeCommunication (WLFC). WLFC functions as a shared memory communicationbetween tasks. This communication type decreases the need of semaphores. Itdoes not generate any blocked tasks and hence it is easier to analyse. WLFCuses a simplex communication where one task is allowed to write to a buffer andseveral tasks are allowed to read the buffer [28].

Asterix tasks are single shot tasks meaning they are all need to terminate.A single shot task can not suspend its execution, much like an ISR. When itstarts executing it will execute until it terminates, when preempted it still keeps

20

Asterix 21

its running state and continue its execution when resumed. When terminatedit makes sure that it is restarted when the next period starts or an event occurs[20].

Tool-chain

Asterix software development is done using Xilinxs EDK. The EDK providecompilers that compiles Asterix correctly for the target platform.

Running the kernel and applications

The software design needs to be configured as a stand alone OS inside the EDKand Asterix needs to be added as a software project. It can then be compiledand downloaded within the EDK.

User applications in Asterix requires a configuration file. A configurationtool called Obelix transforms the configuration file into C-code kernel files usedto initiate the kernel such as system-clock resolution, TCB list, dispatch liste.g [7]. Obelix can not be run within the EDK, it must be run with Asterixprovided compilers.

Obelix need following task defines in the configuration file:

• Period time - Except for aperiodic tasks where it is undefined.

• Deadline - The time, relative the period time, the task has to finish exe-cution. The tasks chosen error handler will be executed if the deadline ismissed.

• Offset - The time a periodic task can delay its reactivation relative itsperiod time.

• Priority - Must be unique, higher number is higher priority.

In addition to task defines the configuration file also contains declarationsof [28]:

• Hard/Soft task - Except for aperiodic tasks where it is undefined.

• Semaphores - What semaphores different tasks use.

• Signals - What signals different tasks use.

• Wait and Lock-free - Declaration of what tasks are using Wait and Lock-free communication, specification of what task that is the writing task andwhich task(s) that reads.

22 7.0. Scheduling model

Scheduling model

Asterix can be used both as a strictly statical scheduled system using a FixedPriority preemptive Scheduling (FPS), an event triggered system or a combina-tion of them. Tasks can be both periodic (time triggered) and aperiodic (eventtriggered) [28].

A task in Asterix can have the following states.

• READY - A process is ready to execute.

• RUNNING -A running process.

• WAITING - A process blocked on a shared resource.

• SIG BLOCKED - An aperiodic task that is waiting to be signaled.

With information specified in the configuration file the scheduler executes thetask with highest priority in the ready queue. When a new period has occurredfor periodic tasks the scheduler put them in the ready queue and supervises theirdeadlines, if the deadline is missed it executes the corresponding error handler.

Interrupt handling

In Asterix all interrupts are designed to be handled as aperiodic tasks exceptfor the system clock. The interrupt handling is divided into two levels. Thefirst level is a low level interrupt handler that disables further interrupts whileprocessing the occurred interrupt. It also reads the interrupt vector to see whatdevice generated the interrupt and executes the corresponding low level ISR.The low level ISR invokes acknowledges the interrupt and sends a signal thatawakes the high level ISR who then is made ready. This gives a delay of oneclock period if the ISR has highest priority in the ready queue. The second levelis the high level ISR that does what is needed to be done on task level and thenit terminates.

Chapter 8

Asterix Porting

As Asterix only supported the h8 processor used in Lego Mindstorm a porting toMicroBlaze was necessary. The h8/300 processor is a 16-bit Complex Instruc-tion Set Computer (CISC) processor with hard vector addresses for externalinterrupts whilst MicroBlaze is a 32-bit RISC processor with only support forone external interrupt source. Asterix is designed to be easy to port becausethe kernel is divided into two parts, a Hardware Abstraction Layer (HAL) anda os layer. The HAL layer contains all hardware specific code to ease porting.The hardware specifics in the os layer are register address sizes and number ofregisters. h8 has eight 16-bit general registers using the stack for passing param-eters and return addresses and two control registers, a 16-bit program counterregister and a 8-bit code condition register. MicroBlaze has thirty two 32-bitgeneral purpose registers and five special purpose registers. MicroBlaze onlyuses the stack to temporarily save registers unlike h8, instead it uses its manyregisters for example to store return addresses from interrupts and exceptions.

Interrupt handling

h8 supports four external interrupt sources, each with a hard vector address.MicroBlaze uses an interrupt controller when more than one interrupt source isused. To make Asterix support more than one external interrupt source on a Mi-croBlaze, a completely new interrupt handling needed to be implemented. Thisnew interrupt handling had to search through the interrupt vector, acknowledgethe interrupt and execute the correct ISR connected with the interrupt.

Context switch

With thirty two registers instead of eight registers to be saved in each contextswitch the Task Control Block (TCB) list had to be modified. The TCB listcontains the state of all processes. In MicroBlaze, certain registers are savedautomatically when an interrupt occurs and thus not all registers have to be

23

24 8.0. Context switch

saved. But to make the port easier all registers were saved on every contextswitch resulting in a overhead.

Minor porting objects were the system clock initiation where provided func-tions by Xilinx were used. The stack was also changed to a separate stackfor each task for simplicity during the port. Soft interrupts from semaphoresand termination of tasks were also needed to be ported, which is like a manualcontext switch.

Chapter 9

Evaluation

This chapter explains the parts that have been evaluated and why knowing themis important when deciding on a real-time operating system.

Benchmarks

Two benchmarks have been performed. An interrupt latency test and a taskresponse time test.

The interrupt latency test measures how long time the kernel takes to starthandling the interrupt with its assigned ISR after the occurred interrupt (seefigure 9.1).

The task response time test measures how long time the kernel takes toresume execution of the next task after the occurred interrupt (see figure 9.1).Figure 9.1 describes the steps the different benchmarks goes through.

Interrupt latency and task response time have been tested on the three ker-nels to find out how deterministic they are and their responsiveness. Becauseas explained earlier, when creating a real-time system it is important to knowthat the system will respond to and process external events fast enough to havea reliable system.

The benchmark was done by adding a timer to the SoC design that was setto generate interrupts at a specified rate. The ISR then read the counter registerto find the interrupt latency time and signaled a task that also read the counterto find the task response time. Both maximum and minimum times were savedand compared with each new counter reading (see appendix A for test code).The minimum and maximum times were needed to calculate the spreading, tofind out the determinism. The test was run both with and without cache withas few additional tasks as possible.

Testing codes for the three kernels were done to be as similar as possible togive good comparison values. Since they operate in such different ways and offersdifferent functionality there had to be modifications. The difference between thebenchmarks is the signaling from ISR to user task.

25

26 9.0. Priority Inversion

Figure 9.1: The figure shows the different steps the Interrupt and Task ResponseTime tests goes through

In uClinux a counting semaphore is shared between ISR and a kernel task,the kernel task get blocked by the semaphore and the ISR releases it so that thekernel task can execute, a user task (pthread) can not be used here since theISR runs in kernel-space and user tasks run in user-space and there is no sharedmemory between them.

Asterix do not have kernel tasks and semaphores can not be used in an ISR.Instead the response time task was made as an aperiodic task that was invokedby a signal from the ISR.

Xilkernel can share semaphores between user tasks and ISRs and that is howthe ISR invoked the response time task in the Xilkernel test.

This difference does not make the comparison less accurate for this evalu-ation. The task response time is only measuring how fast the kernel can startexecuting the next task after an interrupt. Using a signal or a semaphore is onlydifferent methods to make sure that it is the benchmark task that is ready to bescheduled next, it will still go through the same process that is exit the inter-rupt, reschedule and start executing the next task. A slight difference in time isthe time it takes to perform the different function calls, Asterix’s invokeISR(),Xilkernel’s sem post() and uClinux’s up().

Priority Inversion

Real-time systems need to provide a mechanism to avoid priority inversion inorder to minimize the blocking-time of high priority tasks as shown in figure9.2.

Figure 9.2 shows three tasks, a high priority, a medium priority and a lowpriority all with executions times of 5.

• T(1) - T3 takes S1 and executes

• T(2) - T3 is preempted by T2

Evaluation 27

Figure 9.2: An example of Priority inversion that shows how a high prioritytask can get blocked by lower priority tasks. T1 is high priority, T2 is middlepriority and T3 is low priority

• T(3) - T2 is preempted by T1

• T(4) - T1 is blocked by T3 who holds S1, T2 resumes execution

• T(8) - T3 resumes execution

• T(10) - T3 releases S1, T1 starts execution with S1

• T(13) - T1 releases S1 and finishes execution

• T(14) - T3 finishes execution

Priority inversion has only been theoretically evaluated on each kernel withan example describing their functionality.

Kernel size

The kernel size is an important factor especially in an embedded system wherememory is very limited. Depending on what memory type the kernel need torun on makes the kernel size a very decisive factor as some memories are assmall as a few kB. The size measured is the kernels footprint which is the totalamount of space the kernel occupies. The footprint consists of a .bbs section, a.data section and a .text section. The .bss section contains uninitialized globalor static variables such as

char str[4];double arr[2];

The .text section is unalterable containing machine code instructions andconstants. The .data section contains initialized variables and is alterable.

char str[]= "foo";double arr[2] = {4.2, 42.42};

28 9.0. Scalability

The footprints taken are the kernels as small as possible by having minimumfunctionality and the size they had with the functionality needed to perform thebenchmarks.

Scalability

A scalable kernel is a kernel that provides the possibility to add and removeselected features. Typical modifiable features are thread stack size and supportfor malloc, semaphores and message-queues. The scalability of a kernel is highlyrelated to the kernel size, the more it is possible to scale down the kernel thesmaller it will be and the more features added the larger the kernel will be. Theimportance of scalability is as explained in the kernel size section the need tokeep the kernel size to a minimum. If the kernel can be scaled to only includewhat is needed the kernel size will also be kept down to an optimum size.

Scalability has been evaluated by investigating how they are scaled, howmuch they can be scaled and what functionality that can be scaled.

Support

It is also important to know that it is possible to get help when problems occur.The support should be fast and correct which could be a problem with opensource projects that may not have a commercial support.

Support has been evaluated by investigating if they have commercial support,and if they do not have that, do they have a different kind of support such asforums.

Chapter 10

Results

This chapter presents the results from the benchmarks and explains each kernelspriority inversion mechanism. It also presents the kernel sizes, their scalabilityand support.

Benchmark

Target board configuration during the benchmarks were:

• ml-403 evaluation board

• 100 MHz XC4VFX12

• 64 MB DDR-ram

• 16 kB L1 I-cache on opb bus

• 16 kB L1 D-cache on opb bus

• opb timer

The systems were as minimalistic as possible. Xilkernel and Asterix onlyhad an idletask running. uClinux had seven system task running [1]:

• keventd - A kernel thread that manages taskqueues.

• ksoftirqd CPU0 - Manages soft interrupts and lets the scheduler take careof those that cannot execute immediately.

• kswapd - Swaps modified pages out to the swapfile.

• bdflush - Flushes ”dirty” buffers (buffers containing data) to disc.

• kupdate - Flushes old ”dirty”buffers to disc to reduce the risk of filesysteminconsistencies.

29

30 10.0. Benchmark

• flatfsd - Reads and writes to flash. At startup it copies the flash contentsto the ram filesystem then it runs persistently handling config writes toflash.

• mtdblock

The opb timer that generated the interrupts ran at 100 Hertz, generating aninterrupt each 10ms. The benchmark ran for 5 million interrupts which madea total run time of 833 minutes (13.8 hours). The tests was run once to fill thecache in the cache enabled test.

uClinux and Xilkernel handle their timer interrupts immediately, Asterixwas therefore modified to also take care of interrupts immediately and avoidingthe latency of one system clock period. That way the benchmark gave a bettercomparison and Asterix was also provided with a new functionality that may bebetter suited for systems requiring fast interrupt handling (benchmark resultsfor Asterix with task ISR can be viewed in table B.3 in appendix B).

Interrupt latency

Figures 10.1, 10.2 and 10.3 show the interrupt latencies with cache enabled (seetable B.1 in appendix B for minimum latencies). Figures 10.4, 10.5 and 10.6shows the interrupt latencies with cache disabled.

The deterministic view of the cache enabled tests show that Asterix with aspreading of 29 clock cycles and Xilkernel with 28 clock cycles is rather equal.uClinux is the least deterministically system with a spreading of 4660 clockcycles.

Asterix has a spreading of 75 clock cycles when the cache is disabled. Xilker-nel also has a low spreading with 87 clock cycles and uClinux is again the leastdeterministically system with a spreading of 17040 clock cycles.

The responsiveness is overall good. Calculated in seconds Asterix has ainterrupt latency of 4.94 µs and Xilkernel has 5.69 µs with the caches enabled.A real-time system normally has a interrupt latency of a few microseconds upto a millisecond, considering that Xilkernel and Asterix performs very good testscore [16]. uClinux has a 56.30 µs interrupt latency with enabled cache. It isnot a very good test score but not a bad one either.

With the caches disabled Asterix and Xilkernel show again roughly the sameresponsiveness with maximum interrupt latencies of 18.12 µs and 21.86 µs.uClinux has a 206.86 µs interrupt latency. The kernels still perform well fora real-time system.

Task response time

Figures 10.1, 10.2 and 10.3 show the task response times with the cache enabled(see table B.1 in appendix B for minimum latencies). Figures 10.4, 10.5 and10.6 shows the task response times with the cache disabled.

Results 31

Figure 10.1: uClinux with cache enabled

Figure 10.2: Xilkernel with cache enabled

Figure 10.3: Asterix with cache enabled

32 10.0. Benchmark

Figure 10.4: uClinux with cache disabled

Figure 10.5: Xilkernel with cache disabled

Asterix is the most responsive kernel when the caches are enabled with a110.82 µs maximum task response time, Xilkernel is almost as fast with 197.77µs and uClinux is far behind the other two with 678.10 µs.

Asterix is also the most responsive kernel with the caches disabled with amaximum task response time of 25.08 µs. Xilkernel has roughly the same timewith 25.90 µs and uClinux is far behind the other two with 224.41 µs.

Reflections

Surprisingly the systems show a less deterministically behavior when the cacheis disabled. Normally a system using cache should behave less deterministicallydue to unpredictable behavior caused by cache misses. A reason is probablythat the whole test lies in the cache in the Asterix and Xilkernel case due to thesmall test program size.

Theoretically, on a cache miss the processor would have to go out to the

Results 33

Figure 10.6: Asterix with cache disabled

main memory and fetch the needed instruction giving an equally high maximumlatency and response time as the disabled cache test.

Even if the maximum times would be the same, Asterix and Xilkernel stillhave the best and roughly the same times and uClinux is still far behind.

Below are tables summarizing the tests with enabled and disabled caches.

Kernel Interrupt latency Task response timeuClinux 5,630 22,441Xilkernel 564 2,590Asterix 494 2,508

Table 10.1: Summarization of the test with enabled caches in clock cycles

Kernel Interrupt latency Task response timeuClinux 20,686 67,810Xilkernel 2,186 19,777Asterix 1,812 11,082

Table 10.2: Summarization of the test with disabled caches in clock cycles

Priority inversion

All three kernels use different mechanisms for priority inversion creating differentresults. uClinux does not handle it, Xilkernel use the basic priority inheritanceprotocol and Asterix uses immediate inheritance.

34 10.0. Priority inversion

uClinux

uClinux does not have a mechanism to handle priority inversion so the outcomewill be as in the priority inversion example (figure 9.2). However there existspatches that modifies the kernel to have that functionality but none of them areofficially supported on MicroBlaze [8].

Xilkernel

As of version 3.00a Xilkernel handles priority inversion by implementing a com-mon protocol named priority inheritance [18]. With priority inheritance pro-tocol the blocking-time is minimized by temporarily increasing the priority ofthe blocking task to the priority of the highest task that it is blocking. This isexplained in more detail in following example (see figure 10.7) [17].

Figure 10.7: Three tasks using priority inheritance protocol. T1 is high priority,T2 is middle priority and T3 is low priority

As seen in figure 10.7 the low priority task receives the highest priority whenthe high priority task gets blocked on that resource.

• T(1) - T3 takes S1 and executes

• T(2) - T3 is preempted by T2

• T(3) - T2 is preempted by T1

• T(4) - T1 is blocked by T3 who holds S1 making T3 the higher prioritytask who resumes execution

• T(6) - T3 releases S1, T1 gets S1 and starts executing

• T(9) - T1 releases S1 and finishes execution

• T(10)- T2 finishes execution

• T(14)- T3 finishes execution

Results 35

Priority inheritance is a basic protocol that increases the blocking taskspriority only when it is necessary, but it does not prevent the system fromdeadlocks (See example in figure 10.8) since a high priority task can lock aresource that the low task will try to lock inside the critical section. A methodto avoid this is done by always taking resources in the same order. A secondproblem is that the blocking time can be substantial through a chain of blocking[23].

Figure 10.8: Deadlock using priority inheritance protocol. T1 is high priority,T2 is middle priority and T3 is low priority

• T(1) - T3 takes S1 and executes

• T(2) - T3 is preempted by T2

• T(3) - T2 is preempted by T1

• T(4) - T1 takes S2

• T(5) - T1 is blocked by T3 who holds S1 making T3 the higher prioritytask who resumes execution

• T(6) - T3 is blocked by T1 who holds S2

To calculate the response time using priority inheritance a maximum block-ing time needs to be calculated. Priority inheritance maximum blocking can becalculated with the formula Bi =

∑k∈K

usage(k, i)Ck.

K is the set of resources. usage(k, i) generates 1 for a task less importantthan i which shares k with i or any higher priority task otherwise 0. Ck is thelength of the longest critical section locking k. [21]

Asterix

Asterix uses the immediate inheritance protocol as seen in figure 10.9. Imme-diate inheritance protocol is a simple protocol that immediately increases thepriority of the locking task to the priority ceiling for that semaphore [17]. InAsterix the priority ceiling of a semaphore is calculated offline to be one priorityabove the highest priority tasks priority that uses the semaphore [28], adhering

36 10.0. Priority inversion

to the design of unique priorities. By increasing the priority immediately nodeadlock can occur due to the fact that no other task that uses the same sharedresource will have priority high enough to execute afterward. This protocol alsoavoids the chain of blocking that can occur in the basic priority inheritanceprotocol. But a problem when handling priority inversion this way is that alow priority task can be allowed to execute with a higher priority unnecessaryoften, since it increases the priority even though no other task wants the sameresource hence delaying middle priority tasks. Following example gives a moredetailed explanation.

Figure 10.9: Three running tasks using immediate inheritance protocol. T1 ishigh priority, T2 is middle priority and T3 is low priority

• T(1) - T3 takes S1 and executes

• T(2) - T2 is ready to execute but is blocked by T1

• T(3) - T3 is ready to execute but is blocked by T1

• T(4) - T3 releases the semaphore and has its priority set back to normal,T1 preempts T3

• T(5) - T3 takes S1

• T(8) - T1 releases S1 and finishes execution

• T(9) - T2 finishes execution

• T(14)- T3 finishes execution

The algorithm to calculate the maximum blocking time for immediate in-heritance is Bi = max(tst1, ..., tstk).

A task i can be blocked maximum one critical section of a lower prioritytask that locks a semaphore with a higher or equal priority ceiling than task i’spriority. All tasks t1..tk that can block task i has the critical sections st1...stk,with the execution times tst1...tstk [17].

Results 37

Protocol Blocking time Execution timeNone 6 11

Priority inheritance 1 6Immediate inheritance 2 7

Table 10.3: The high priority task blocking time and execution time using theprotocols the kernels use

Reflections

Following is a table (table 10.3) summarizing the high priority task blockingtime and execution time from the examples in figures 9.2, 10.7 and 10.9.

Since uClinux does not try to prevent priority inversion high priority taskcould be blocked for a long time.

Priority inheritance tries to minimize the blocking time but do not preventdeadlocks and with chains of blocking the blocking time could be severe for thesystem.

Immediate inheritance also tries to minimize the blocking time and it alsoprevents deadlocks and chains of blocking. This protocol needs to know all tasksthat uses the semaphore upon initiation in order to calculate its ceiling and istherefore only suitable for systems using off-line scheduling.

Kernel size

Compilation was done with optimization grade 2 (o2) and without debuggingsymbols. The footprints taken are the minimum and the footprints when theywere configured for the benchmarks.

uClinux

The different sections that make up the footprint are:

Section Minimal size Benchmark size.text 757 kB 757 kB.data 878 kB 878 kB.bss 118 kB 118 kB

Total 1,759 MB 1,759 MB

Table 10.4: uClinux footprints

uClinux size was configured to only include a romfs filesystem, flash supportand DDR RAM support. The size is the same in both cases since no scalability isprovided on another level than the operating system and the same configurationis needed on that level.

38 10.0. Kernel size

Xilkernel

Section Minimal size Benchmark size.text 6,764 bytes 12,692 bytes.data 334 bytes 396 bytes.bss 13,348 bytes 12,268 bytes

Total 19,97 kB 24,76 kB

Table 10.5: Kernel sizes of Xilkernel

For the test size Xilkernel had support for pthreads with a stacksize of 200bytes, semaphores, interrupt controller and a static thread. Nothing was in-cluded in the minimal size.

Asterix

Section Minimal size Benchmark size.text 6,572 bytes 7,292 bytes.data 953 bytes 1,169 bytes.bss 364 bytes 576 bytes

Total 7,70 kB 8,82 kB

Table 10.6: Asterix footprints

The minimal size is the kernel scaled down to nothing but an idletask with200 bytes in stack size. The test size includes signal support, an idle task and atest task both with 200 bytes in stack size.

Reflections

Since Xilkernel and Asterix consists of only the kernel they are much smallerthan uClinux which is a full operating system. They all can vary very much insize depending on how much they are scaled which is described more thoroughlyin the scalability section.

Asterix has the smallest size since it is less complex and do not provide asmuch features as the other two. The kernel size is also kept down by only allo-cating memory that is needed. All tasks are already defined at compilation timeand only allocates memory needed by those tasks. If no signals or semaphoresare declared in the configuration file that functionality will not be included inthe compiled kernel.

With uClinux’s big size it is reasonable to think that all other functionalityis still included in the kernel.

Results 39

Kernel Minimal size Benchmark sizeuClinux 1,759 MB 1,759 MBXilkernel 19,97 kB 24,76 kBAsterix 5,49 kB 10 kB

Table 10.7: Footprints of the evaluated kernels

Scalability

uClinux

uClinux offers scalability at a operating system level, making it possible toadd many different types of files systems, joysticks, memory types and networksupport.

Xilkernel

The Xilinx tool offers a wide selection of settings making it possible to onlyinclude the needed functionality on Xilkernel and by that keeping the kernelsize to the minimum. A selection of scalable properties is the support of mes-sagequeues, semaphores and mutexes, their queue sizes and number of queues.Support of pthreads and each threads stack size. Xilinx OS and libraries docu-ment contains all scalable features [18].

Asterix

Asterix offers good scalability, only functionality that are used are compiledinto the kernel to keep the kernel size to a minimum. If no semaphores, signalsor wait-lock queues have been declared in the configuration file, none of thatfunctionality will be provided in the kernel. Stack sizes of the tasks is alsodeclared in the configuration file.

Reflections

Asterix and Xilkernel offer equally good scalability, Xilkernel is the most scalablekernel but that is because it also has most functionality to offer.

Scaling of Xilkernel is done in the Xilinx tool where a wide selection ofproperties enables the designer to customize the kernel as wanted. Asterix isscaled when compiling the kernel. Functionality such as signals and semaphoresare included only if they are declared in the configuration file. uClinux is alsoscalable but on a different level. Whilst Asterix and Xilkernel offer scalabilityon the kernel, uClinux offers scalability on the operating system such as networksupport and support of many different file-systems.

40 10.0. Support

Support

uClinux

PetaLogix is a commercial support for the MicroBlaze-uClinux porting. It hasbeen created by John Williams the man who started the MicroBlaze-uClinuxporting in order to meet the growing interest for commercial use [30]. There isalso an active mailing list with as of November 2005 has over 400 subscribers[14]. Since it is only a mailing-list a difficult question might take a while beforeit gets answered or it might not get answered at all. Many people at PetaLogixoriginate from the mailing list and are still very active on the list answeringquestions.

Xilkernel

Since Xilkernel is a component of Xilinx’s EDK, Xilinx provides commercialsupport for Xilkernel.

Asterix

Asterix does not have a commercial support. It is only an educational real-time operating system used in courses and as a research project at MalardalensUniversity, created and maintained by a few teachers and researchers. Becauseof that the only available support is to contact those teachers and researchers.

Reflections

Xilkernel has a good support as a product by Xilinx. uClinux also offers goodsupport with the newly started Petalogix for commercial support. It also hasan active mailing-list with many helpful members. Asterix on the other handhas only a handful of teachers and researchers that can answer questions whenthey have the time.

Discussion

There are many aspects to be considered when deciding on a kernel for usagein an embedded system and all three kernels are the best choice depending onthe situation.

With almost equally low spreading in the benchmark tests Asterix and Xilk-ernel proves to be the most deterministic kernels. uClinux is with its big spread-ing far behind the other two.

Asterix and Xilkernel also have the best responsiveness and again almostequal results and uClinux is again far behind. One thing to consider in these testsis that the measured results are not guaranteed to be the worst case executiontimes. Based on the results much worse times than those measured is unlikely.

Results 41

Every kernel has the ability to choose task priorities, whilst Xilkernel anduClinux only offer that and the possibility to change scheduler model, Asterixoffers even greater user-control with its possibility to define periodic and aperi-odic tasks and offsets.

Well tested kernels such as uClinux and Xilkernel is likely to have the bestreliability, Asterix could very well be just as reliable but without throughlytesting there are no guarantees of that.

Asterix with its ability to specify hard and soft task and deadlines makes itthe kernel with best fail-soft operation. The other kernels have no protection ifa deadline would fail since they do not have deadlines.

Looking at the quality of support Asterix lacks the commercial support thatXilkernel and uClinux have. A big advantage Asterix has over the other twois its size with only a fourth of Xilkernels and 300 times smaller than uClinux.But with that small size there is a cost in functionality and also that all tasksmust terminate.

If the design requires a deterministic and responsive system Asterix andXilkernel is a good choice and the choice of kernel is most based on how muchmemory that can be laid on the kernel. uClinux is a good alternative if thedesign do not require a very deterministic and responsive system and otheraspects such as networking support is more important. Also memory shouldnot be an issue if deciding on uClinux, at least not smaller than two MB.

Future work

If more time was given it would be interesting to port Real-Time ApplicationInterface (RTAI) that exists for uClinux or uClinux 2.6 to MicroBlaze. RTAIis a patch that makes uClinux more real-time by providing more deterministicinterrupt latencies and real-time tasks and uClinux 2.6 has an preemptive kernel.It would improve uClinux determinism and responsiveness and making it morecompetitive with the other kernels.

A future work for Asterix would be to add networking support as manyembedded systems communicate through network. It could also be interestingto add functionality for non single shot tasks since often it is better to onlyput a task to sleep instead of always terminate it. Asterix could also be moreresponsive by only saving the required registers on a context switch.

Chapter 11

Summary and conclusion

In this thesis three kernels have been evaluated based on real-time requirementson a System-on-Chip platform with a MicroBlaze processor. The kernels weretwo real-time systems, Xilkernel and Asterix and one ordinary system, uClinux.The evaluation consisted of two benchmarks and what mechanism they provideto avoid priority inversion. This thesis has also evaluated the kernels scalability,support and kernel sizes. The benchmarks were an interrupt latency test andtask response time test to find their deterministic and responsive behavior.

To be able to benchmark Asterix it had to be ported first as it only hadsupport for the h8/300 processor used in Lego Mindstorm. One problem with aport to MicroBlaze is the interrupt handling, the h8 processor has support forfour external interrupt sources while MicroBlaze only have one. To make Asterixsupport more than one external interrupt on a MicroBlaze it has to check aninterrupt vector to find the interrupt source and then start the correspondinginterrupt handler.

The evaluation showed that it was the real-time kernels Asterix and Xilk-ernel that had the best determinism and responsiveness. Asterix was found tohave the smallest kernel and Xilkernel the one with support of most scalablefunctionally. uClinux had more support for networking and file systems.

If the design have very limited memory and need good real-time behaviorAsterix was concluded to be the best choice, with more memory Xilkernel wasthe preferred system with its larger functionality and robustness. uClinux wasthe system to choose for a design with more focus on networking support thanreal-time behavior.

42

Bibliography

[1] D. P. Bovet and M. Cesati. Understanding the LINUX KERNEL. O´Reilly,October 2000.

[2] Context Switching and IPC Performance Comparison between uClinux andLinux on the ARM9 based Processor.http://linuxdevices.com/articles/AT2598317046.html.

[3] CoreConnect Architecture - On-chip Peripheral Bus (OPB), Xilinx, 2006-04-24.http://www.xilinx.com/ipcenter/processor central/coreconnect/coreconnect opb.htm.

[4] J. Haas. sched setscheduler - Linux Command - Unix Command About,Inc, 2006-05-02 .http://linux.about.com/library/cmd/blcmdl2 ched etscheduler.htm.

[5] Hard real-time, 2006-05-12.http://en.wikipedia.org/wiki/Hard real-time.

[6] J. L. Hennessy and D. A. Patterson. Computer Architecture: A Quantita-tive Approach, Third Edition. Morgan Kaufmann, May 2002.

[7] J. Lindgren. Obelix development environment. Master’s thesis, August2000.

[8] Linux for Real Time Requirements, SoftTech Solutions P Ltd.www.isofttech.com/downloads/Linux-RTOS.pdf.

[9] Linux Operating System and Linux Distributions.http://linux.about.com/.

[10] D. Mattson and M. Christensson. Evaluation of synthesizable cpu cores.Master’s thesis, 2004.

[11] D. McCullough. uclinux for linux programmers. In Linux Journal Volume2004 , Issue 123 (July 2004) Page: 7 Year of Publication: 2004 ISSN:1075-3583. ACM Press, July 2004.

43

44 BIBLIOGRAPHY

[12] MicroBlaze Processor Reference Guide, Xilinx.http://www.xilinx.com/ise/embedded/edk7 1docs/mb ref guide.pdf.

[13] Microblaze uClinux FAQ, John Williams, 2006-02-16.http://www.itee.uq.edu.au/jwilliams/mblaze-uclinux/Documentation/FAQ.html.

[14] Microblaze uClinux Project Home Page, John Williams, 2006-02-16.http://www.itee.uq.edu.au/jwilliams/mblaze-uclinux/.

[15] ML40x EDK Processor Reference Design.http://www.xilinx.com/bvdocs/userguides/ug082.pdf.

[16] K. D. Morgan. The rtos difference. In Byte, pages 161–172, August 1992.

[17] C. Nordstrom et al. Robusta realtidssystem. Malardalen Real-Time Re-search Centre, Vasteras, August 2000.

[18] OS and Libraries Document Collection, Xilinx.http://www.xilinx.com/ise/embedded/edk71 docs/oslibs rm.pdf.

[19] Porting uCLinux to the MC68360-Based MTPSR2-150 Board.http://www.linuxdevices.com/articles/AT6851875594.html.

[20] Real time OS basics, 2006-05-11.http://www.algonet.se/staffann/developer/rtbasics.htm.

[21] Realtime Systems SMD138.http://www.sm.luth.se/csee/courses/smd/138/138.vt05/lecture11.pdf.

[22] A. Rubini and J. Corbet. Linux Device Drivers, Second Edition. O´Reilly,June 2001.

[23] L. Sha, R. Rajkumar, and S. Sathaye. Priority inheritance protocols: Anapproach to real-time synchronization. In IEEE Transactions on Comput-ers Volume 39, Issue 9, pages 1175–1185. IEEE Xplore, September 1990.

[24] Soft real-time, 2006-05-12.http://en.wikipedia.org/wiki/Soft real-time.

[25] W. Stallings. Operating systems: internals and design principles, FourthEdition. Prentice-Hall, 2001.

[26] J. A. Stankovic and K. Ramamritham. The spring kernel: a new paradigmfor real-time operating systems. In ACM SIGOPS Operating Systems Re-view archive Volume 23, Issue 3, pages 54–71. ACM Press, June 1989.

[27] D. Stepner, N. Rajan, and D. Hui. Embedded application design using areal-time os. In Annual ACM IEEE Design Automation Conference Pro-ceedings of the 36th ACM/IEEE conference on Design automation, pages151 – 156. ACM Press, August 1999.

BIBLIOGRAPHY 45

[28] H. Thane, A. Pettersson, and D. Sundmark. The asterix real-time kernel.In 13th EUROMICRO INTERNATIONAL CONFERENCE ON REAL-TIME SYSTEMS, INDUSTRIAL SESSION, Technical University of Delft,Delft, The Netherla, June 2001. IEEE Computer Society.

[29] What is a soft processor?, Xilinx, 2006-01-18.http://www.xilinx.com/ipcenter/processorcentral/microblaze/doc/mb faq.pdf.

[30] J. Williams. What does PetaLogix mean for the MicroBlaze uClinux com-munity, PetaLogix, 2006-02-16.http://www.petalogix.org/news events/petalogix announce.

[31] Xilinx Development Boards: Virtex-4 ML403 Embedded Platform. http://www.xilinx.com/xlnx/xebiz/designResources/ip productdetails.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Design+Tools&category=&iLanguageID=1&key=HW-V4-ML403-USA.

Appendix A

Test Programs

Benchmark programs used to evaluate interrupt latency and task response times.

uClinux

static void lowThread(int prio){while(1){down(&sem);semLat = timer_get_time(CONFIG_XILINX_TIMER_1_BASEADDR,0);high++;if(intLat < intMax){intMax = intLat;}if(intLat > intMin){intMin = intLat;}

semLat = 0 - semLat;if(semLat < semMax){semMax = semLat;}if(semLat > semMin){semMin = semLat;}}}

static irqreturn_t interruptHandler(int irq, void *dev_id, struct pt_regs *regs){intLat = timer_get_time(CONFIG_XILINX_TIMER_1_BASEADDR,0);flag = timer_get_csr(CONFIG_XILINX_TIMER_1_BASEADDR,0);if((flag & 0x100) == 0x100){

46

Test Programs 47

up(&sem);timer_set_csr(CONFIG_XILINX_TIMER_1_BASEADDR,0,flag);startTick = 0 - startTick;if(iter == iterations){free_irq(0,NULL);printk("max latency is %ld ticks\n",count - intMax);printk("min latency is %ld ticks\n",count - intMin);printk("max semlatency is %ld ticks\n",count - semMax);printk("min semlatency is %ld ticks\n",count - semMin);}}iter++;}return IRQ_HANDLED;}

Xilkernel

void* thread_func (void *arg){while(1){

while (1) {sem_wait(&barrier);semLat = XTmrCtr_mGetTimerCounterReg(XPAR_OPB_TIMER_2_BASEADDR,0);break;

}if(titer > 1){ //cache is still disabled the first timeif(intLat < intMax)intMax = intLat;if(intLat > intMin)intMin = intLat;

if(semLat < semMax)semMax = semLat;if(semLat > semMin)semMin = semLat;}}}

/* timer interrupt service routine */void int_handler(void * baseaddr_p) {intLat = XTmrCtr_mGetTimerCounterReg(XPAR_OPB_TIMER_2_BASEADDR,0);/* Read timer 0 CSR to see if it raised the interrupt */csr = XTmrCtr_mGetControlStatusReg(XPAR_OPB_TIMER_2_BASEADDR, 0);

48 A.0. Asterix

if (csr & XTC_CSR_INT_OCCURED_MASK) {XTmrCtr_mSetControlStatusReg(XPAR_OPB_TIMER_2_BASEADDR, 0, csr);sem_post(&barrier);intLat = 0 + intLat;if(titer >= ITERATIONS){XIntc_mDisableIntr(XPAR_OPB_INTC_0_BASEADDR, XPAR_OPB_TIMER_2_INTERRUPT_MASK);microblaze_disable_interrupts();xil_printf("max latency is %ld ticks\r\n",count - intMax);xil_printf("min latency is %ld ticks\r\n",count - intMin);xil_printf("max semlatency is %ld ticks\r\n",count - semMax);xil_printf("min semlatency is %ld ticks\r\n",count - semMin);}}}

Asterix

void intlat_handler(void * baseaddr_p) {intLat = XTmrCtr_mGetTimerCounterReg(XPAR_OPB_TIMER_2_BASEADDR,0);if(titer == ITERATIONS){XTmrCtr_mSetControlStatusReg(XPAR_OPB_TIMER_2_BASEADDR, 0, 0);XIntc_mDisableIntr(XPAR_OPB_INTC_0_BASEADDR, XPAR_OPB_TIMER_2_INTERRUPT_MASK);

xil_printf("Iterations = %d (%d s)\r\n",ITERATIONS, count*ITERATIONS);xil_printf("max latency is %ld ticks\r\n",count - intMax);xil_printf("min latency is %ld ticks\r\n",count - intMin);xil_printf("max semlatency is %ld ticks\r\n",count - semMax);xil_printf("min semlatency is %ld ticks %d\r\n",count - semMin, co);XIntc_mEnableIntr(XPAR_OPB_INTC_0_BASEADDR, XPAR_OPB_TIMER_2_INTERRUPT_MASK);

} else{titer++;invokeISR(0); //invoke thread_func}}

C_task void thread_func( void *ignore ){semLat = XTmrCtr_mGetTimerCounterReg(XPAR_OPB_TIMER_2_BASEADDR,0);if(titer > 1){if(semLat< semMax)semMax = semLat;if(semLat > semMin)semMin = semLat;

Test Programs 49

if(intLat < intMax)intMax = intLat;if(intLat > intMin)intMin = intLat;}}

Appendix B

Benchmark Results

Minimum latencies

Kernel Interrupt latency Task response timeuClinux 970 5,769Xilkernel 536 2,362Asterix 466 2,364

Table B.1: Enabled cache in clock cycles

Kernel Interrupt latency Task response timeuClinux 3,644 16,938Xilkernel 2,099 19,076Asterix 1,737 10,821

Table B.2: Disabled cache in clock cycles

Alternative Asterix results

Test Cache Enabled Cache DisabledInterrupt Latency Min 2,399 11,635Interrupt Latency Max 2,415 14,803

Task Response Time Min 3,350 22,875Task Response Time Max 3,562 26,048

Table B.3: Asterix results with ISR as a scheduled task in clock cycles

50