Evaluation of real time performance of embedded linux

List of Figures 4-4 Timing diagram for the operation of state machine 21 4-9 Block diagram of Interrupt Latency Test Module 24 4-14 User interface during jitter testing progress 28 4-15

EVALUATION OF REAL TIME PERFORMANCE OF EMBEDDED LINUX

by

Truong Quang Vinh

A thesis submitted in partial fulfillment of requirements for the

degree of Master of Engineering

Examination Committee: Dr Nitin V Afzulpurkar (Chairman)

Dr Lertsak Lekawat Prof Phan Minh Dung

Prof Helmuth Gesch

Mr Markus Waidelich (External)

Nationality: Vietnamese Previous degree: Bachelor of Electronics Engineering,

Ho Chi Minh University of Technology, Vietnam

Scholarship Donor: Ministry of Education and Training (Vietnam)

Asian Institute of Technology School of Advanced Technologies

Thailand December 2003

I would also like to thank all technicians Ramiro, Xia, Yon, Su and Jani in MicroFuzzy GmbH for their constant advice and assistance Without their help, I would never have come close to finishing

Finally, I would like to thank all of my family and friends for putting up with me over the years

ABSTRACT

Nowadays, embedded systems with Linux OS are commonly applied in automotive industry Some of applications require strict time response, and others need to be exactly scheduled to execute a period task All of these are called time-sensitive applications Measuring and evaluating time parameters of an embedded system for time-sensitive applications is very necessary for developers to guarantee that it works functionally For this purpose, signal stimulating and signal analyzing hardware are required In this thesis, modular signal generating and signal analyzing means will be designed The prototype of the evaluation system will be implemented to test and verify an embedded system

Improving the performance of the system is the next part of this thesis The research focuses deeper on the possibility of turning Linux into a real-time operating system Particularly, it investigates available real-time solutions for Linux, but also looks into the soft variants for completeness A number of performance tests are conducted during the improvement to make sure that the implementation meets the demands of a real-time operating system

Table of Contents

Acknowledgment iiAbstract iii

2.3 The survey of real-time operating systems found in the market 3

References 47

List of Figures

4-4 Timing diagram for the operation of state machine 21

4-9 Block diagram of Interrupt Latency Test Module 24

4-14 User interface during jitter testing progress 28

4-15 User interface during Interrupt latency testing progress 29

6-1 Histogram of jitter of the periodic task using OS timer interrupt 37

6-2 Histogram of jitter of the periodic task using FIQ 41

List of Tables

5-1 Statistic data of jitter of the periodic task using sleep function 32

6-2 Statistic data of jitter of the periodic task using OS timer interrupt 38

6-4 Statistic data of jitter of the periodic task using FIQ 41

CHAPTER 1 INTRODUCTION 1.1 Overview

Nowadays, embedded systems have become a buzz word in the last five years, but embedded systems and processors have been around for much longer than that One only needs to look around to see embedded systems everywhere: cell phones, alarm clocks, personal data assistants (PDAs), automobile subsystems such as ABS and cruise control, etc [1] Embedded systems now are more and more modern and complex so that they require a powerful and effective operating system Following the development of embedded systems, the popularity

of Linux is increasing rapidly the world Linux is used not only in general computer, but also

in embedded system That is called embedded Linux It can be ported to many microprocessors such as ARM, PowerPC, MIPS… Because of its versatile and cost effective characteristic, many device manufacturers turn Linux for embedded systems Therefore, the number of embedded electronic system supported by Linux used in automobiles, tractors, and other control systems, increases explosively Performance of Linux OS impact on operation effect of embedded systems For this reason, the evaluation of performance of embedded Linux running on these systems is an important task in period of product development All parameters about timing need to be investigated in order to ensure that systems response enough for a certain application However, the standard Linux kernel cannot support real-time processing, which may be required by certain embedded applications There exist a number of extensions to Linux that provide support for real-time tasks

1.2 Objectives of the thesis

The purpose of this thesis is to evaluate the real-time performance of the embedded Linux on

a specific platform The target system chosen in this thesis is Intel PXA255 processor platform The evaluations are realized by hardware experiments with FPGA The major timing parameters in the Linux kernel are statistically tested in various conditions The goals

of the evaluation are to verify the functionality of the system as well as measure its real-time performance on the PXA255 platform With these evaluations, we can foretell exactly the timing problem for time-sensitive application such as jitter, interrupt latency, deadline of priority tasks…etc

After the timing parameters have been investigated, the next challenging part of this thesis is

to improve the real-time performance of the Linux on PXA255 processor In order to safely implement the extension module for Linux kernel, it is important to understand how the kernel ports in the PXA255 processor, how Linux OS manages the hardware A number of performance tests are conducted during the improvement to make sure that the implementation meets the demands of a real-time operating system

1.3 Approach

To evaluate real-time performance, a hardware instrument is designed to measured jitter interrupt latency, cycle times, etc For this purpose, signal stimulating and signal analyzing means are required In this thesis, modular signal generating and signal analyzing means will

be designed and implemented The evaluation system is required to be high accuracy and able

to collect data stream in real-time Capability to generate synchronous stimulating signal and analyzing response signal in real-time is important for the evaluation system

To obtain greater accuracy in pinpointing timing problems of a real-time system, the analysis and prediction of tasks schedulability was done using actual measured data from the system

condition of system load; each scheduling mechanism is applied; then, execution times and periods of all executing tasks are logged

We then utilize a FPGA to timestamp, and collect the data while the system is executing The collected data is then exported to a host PC, where the test results will be shown The extracted data is analyzed to determine whether the tasks are satisfactorily scheduled, and whether any timing problems are encountered The results from the analysis can be sent to the predictor and modified to determine the effect of changes in the timing parameters of a system

Evaluating an embedded system is premier step to conduct the next: improvement This part is

an extension of the thesis Features affecting the performance need to be brought out the meaning Understanding how embedded Linux schedule the tasks is very important to enhance the performance of the system Evaluation step will be repeated to verify the improvement The loop of these tasks is carried out as a development cycle

CHAPTER 2 LITERATURE REVIEW

This section offers a brief background into the areas that are related to the research performed

in the report as well as the areas that support the reasons for performing this research

2.1 Embedded Linux OS

Since Linux was initially developed by Linus Torvalds in 1991 as an operating system for IBM compatible personal computers based on the Intel 80386 microprocessor, Linux today is available for many embedded systems with others various microprocessors Over the years, Linus and many coordinating developers around the world have worked to make Linux available on other architectures, including Intel Xscale, Alpha, SPARC, Motorola MC680x0, PowerPC, and IBM System/390 [1]

Linux is a versatile and cost effective operating system for embedded systems It can be embedded in a surprisingly small system to handle simple tasks and scaled up to handle more complex tasks Linux can run on most microprocessors with a wide range of peripherals and has a ready inventory of off the shelf applications Development cycles are shortened through the use of mature tools, open source code, substantial documentation and available support services Due to all those advantages, Linux is a good choice for embedded systems [2]

2.2 Real-time embedded Linux OS

Since the evaluation system needs to be process all analyzing signals at strict time, we need a real-time operating system for the processor Linux, with the real time extension, provides this kind of precise control over interrupt handling Essentially, there is an interrupt manager that handles all interrupts It does a good job of making sure that critical interrupts get run when needed The hardness of this approach depends mostly on the CPU interrupt structure and context switch hardware support This approach is sufficient for a large range of real time requirements Even without the real time extensions, Linux is pretty good at keeping up with multiple streams of events [6] [7]

2.3 The survey of real-time operating systems found in the market

This section describes theoretical study of real-time operating system in the market The study

is focused on their scheduling policies and how these policies are related to the microprocessor-specific hardware In particular, scheduler of Linux is presented to understand its operating manner before the software and hardware structure is developed for testing the performance of Linux running on PXA255 processor

Nowadays, there are many real-time operating systems developed by different companies such as RTEM by OAR (On-Line Applications Research-Corporation), uCLinux by Arcturus Networks Inc., Timesys Linux by TimeSys Corporation, RTLinux by FSMLabs (Finite

Machine Labs) and RTAI by Dipartimento di … This survey provides some general

background features about scheduling of real-time operating systems in the market [2]

2.3.1 RTEM

RTEMS, Real-time Executive for Multiprocessor System, is a real-time kernel which supports

a high performance environment for embedded application

RTEM provides four mechanisms which allow the user to impact the task scheduling process: user-selectable task priority level, task preemption control, task times-slicing control, and manual round-robin selection

RTEM also provides facilities to manage the execution of periodic task This manager uses Rate Monotonic Algorithms

No malloc() Processes allocate memory to themselves via mmap() This requires a bit of care

in handling pointers, but isn’t really an issue since the Linux ports of most C libraries implement malloc() via mmap() anyway, since it’s faster

No memory protection Applications have unhindered access to the entirety of system RAM, including kernel space

2.3.3 TimeSys Linux

The highlights of TimeSys linux are as follows:

The TimeSys Linux kernel is fully preemptable A scheduling decision is made whenever an interrupt occurs, regardless of whether the processor was executing within the kernel or user space at the time of the interrupt

Interrupt Handlers are run as real-time threads in TimeSys Linux This provides a prioritized, preemptable interrupt hierarchy

SoftIRQ processing, which executes interrupt bottom halves and various other kernel functions, is performed by a real-time thread

The TimeSys Linux scheduler makes a scheduling decision in constant time

“near the hardware limit”)

2.3.5 RTAI

RTAI (Real Time Application Interface) has its origin in RTLinux, when main developer

Paolo Mantegazza wanted to bring his work and experiences with real-time on DOS to Linux RTAI provides several complementary scheduling configuration options:

Depending on the hardware, the following scheduling options are available: uni-processor scheduling (UP), multi-processor scheduling (MUP; the application programmer can assign each task to a specific (set of) processors), and symmetric multi-processor systems (SMP; the scheduler assigns tasks at run-time to any available processor)

Tasks can configure periodic scheduling (scheduled every time a certain time has elapsed) and one-shot scheduling (scheduled only once at the requested time)

RTAI has static priority-based scheduling (“SCHED_FIFO”) as its default hard real-time scheduler, but if offers also Round Robin time-sliced scheduling (“SCHED_RR”), Rate Monotonic Scheduling, and Earliest Deadline First It’s the responsibility of the application programmer to get the scheduler and timings choices correct When multiple scheduler

schemes are used, RTAI has made the (arbitrary) choice to give EDF tasks a higher priority than tasks scheduled with other policies

2.4 The scheduler of Linux

Like any time-sharing system, Linux achieves the effect of an apparent simultaneous execution of multiple processes by switching form one process to another in very short time frame

2.4.1 Scheduling policy

The scheduling policy of Linux is based on ranking processes according to their priority Complicated algorithms are sometimes used to derive the current priority of a process, but the end result is the same: each process is associated with a value that denotes how appropriate it

is to be assigned to the CPU In Linux, process priority is dynamic The scheduler keeps track

of what processes are doing and adjusts their priorities periodically; in this way, processes that have been denied the use of the CPU for a long time interval are boosted by dynamically increasing their priority Correspondingly, processes running for a long time are penalized by decreasing their priority [4] [5]

When speaking about scheduling, processes are traditionally classified as "I/O-bound" or

"CPU-bound."

Table 2-1: Class of processes

I/O bound Heavy use of devices, wait a lot

of I/O to complete

Implicitly favored (for good response time)

CPU-bound Heavy use of CPU time

An alternative classification distinguishes three classes of processes:

Table 2-2: Alternative class of processes

Interactive Frequent interaction with user,

wait a lot, timely response required (50-150ms)

Batch No user interaction, background

execution

Same class, executed only when there is no real-time process in state TASK_RUNNING (runable)

Real-time Should never be blocked by

processes with lower priority, timely response required with low variance

nice( ) Change the priority of a conventional process

getpriority( ) Get the maximum priority of a group of conventional

processes

setpriority( ) Set the priority of a group of conventional processes

sched_getscheduler( ) Get the scheduling policy of a process

sched_setscheduler( ) Set the scheduling policy and priority of a process

sched_getparam( ) Get the scheduling priority of a process

sched_setparam( ) Set the priority of a process

sched_yield( ) Relinquish the processor voluntarily without

Get the maximum priority value for a policy

sched_rr_get_interval( ) Get the time quantum value for the Round Robin

policy

2.4.2 Priorities of processes

In Linux, process priority is dynamic The scheduler keeps track of what process are doing and adjusts their priority periodically; in this way, processes that have been denied the use of the CPU for a long time interval are boosted by dynamically increasing their priority Correspondingly, processes running for a long time are penalized decreasing their priority Linux kernel is non pre-emptive Processes running in kernel mode cannot be interrupted after

Linux processes are pre-emptive If a process enters the TASK_RUNNING state, the kernel checks whether its dynamic priority is greater than the priority of the current running process

If it is, the execution of current process is interrupted and the scheduler is invoked to select another process to run

a process enters TASK_RUNNING

Priority > current process' priority

CPU allocated to the current process

Interrupt current process

Select another process

Time quantium expires

Figure 2-1: Scheduling algorithm The Linux scheduling algorithm works by dividing the CPU time into epochs In a single epoch, every process has a specified time quantum whose duration is computed when the epoch begins In general, different processes have different time quantum durations The time quantum value is the maximum CPU time portion assigned to the process in that epoch When

a process has exhausted its time quantum, it is preempted and replaced by another runnable process Of course, a process can be selected several times from the scheduler in the same epoch, as long as its quantum has not been exhausted—for instance, if it suspends itself to wait for I/O, it preserves some of its time quantum and can be selected again during the same epoch The epoch ends when all runnable processes have exhausted their quantum; in this case, the scheduler algorithm recomputes the time-quantum durations of all processes and a new epoch begins

Each process has a base time quantum: it is the time-quantum value assigned by the scheduler

to the process if it has exhausted its quantum in the previous epoch The users can change the base time quantum of their processes by using the nice( ) and setpriority( ) system calls A new process always inherits the base time quantum of its parent

The INIT_TASK macro sets the value of the base time quantum of process (swapper) to DEF_PRIORITY; that macro is defined as follows:

If the quantum duration is too long, processes no longer appear to be executed concurrently For instance, let's suppose that the quantum is set to five seconds; each runnable process makes progress for about five seconds, but then it stops for a very long time (typically, five seconds times the number of runnable processes)

The choice of quantum duration is always a compromise The rule of thumb adopted by Linux is: choose duration as long as possible, while keeping good system response time

2.4.3 Management of processes under Linux

Within Linux, processes that are in memory and are ready to run or are running are in state TASK_RUNNING The scheduler selects a process ready to run and allocate the CPU to it The scheduler is implemented by the function schedule() (see file /usr/src/linux/kernel/sched.c)

Processes within the kernel are represented as instances of the following structure (file /usr/src/linux/include/linux/sched.h):

pid_t pid; /* process id */

pid_t pgrp; /* process’s group */

A process is in the TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state while the OS performs an I/O on its behalf or is sleeping In the TASK_INTERRUPTIBLE state, a process can be reactivated by a signal whereas it cannot in the TASK_UNINTERRUPTIBLE state

In state TASK_ZOMBIE, a process has completed its execution but its parent has not done yet the system call wait()

In state TASK_STOPPED, a process has been stopped by a signal or using the system call ptrace(), that is, it is being traced

Within the kernel, statements that change the state of a process are of the form:

2.4.4 Implementation of the scheduler

The scheduler supports the following three scheduling polices (file /usr/src/linux/include/linux/sched.h):

There is a notion of priority Each process has the priority field, which has a range from 0 to

99 A running process can be pre-empted by a process that becomes runnable with a higher priority

Processes with the SCHED_OTHER policy all have priority zero and cannot preempt other processes They are subject to interruption caused by the expiration of their time slice They are called normal processes

Processes with the SCHED_FIFO policy is First In First Out real-time process It must have super-user permission and have a priority from 1 to 99 They are not subjected to interruption caused by the expiration of a time slice

Processes with the SCHED_RR policy is Round Robin real-time process It must have user permission and have a priority from 1 to 99 They are subject to interruption caused by the expiration of their time slice

super-2.5 The target system _ Triton Starter Kit

In this thesis, Triton Starter Kit is chosen for target system to evaluate real-time scheduling capability of Linux running on PXA255 processor

TRITON is delivered with pre-installed Redboot firmware Redboot supports several level-debugging options and file download via serial XModem or TFTP via Ethernet These

low-files can additionally be stored into the permanent flash-memory to be started by command or power-on

The TRITON Starter-Kit is a ready to use development system for building applications based

on the TRITON embedded processor board It includes power supply, RS232, Ethernet, JTAG interface, compact-flash socket, and a socket for the TRITON board, with solder-pad access All schematics of the base board are included as reference Besides the pre-installed RedBoot firmware, a Linux kernel is installed, which supports all components of the Starter-Kit Thus the module can be quickly integrated into existing platforms

Figure 2-2: Triton Starter Kit

Triton Starter Kit features:

CPU: XScale PXA255 400MHz

SDRAM onboard 32 MBytes

Flash memory onboard 32 MBytes

Pre-installed RedBoot firmware

Embedded Linux Debian 2.5.21-RMK

PCMCIA/ compact-flash interface

JTAG test-interface

10/100Mbps Ethernet controller

RS232 connector

2.6 Intel PXA255 processor

The target system that will be evaluated is supported by Intel PXA255 processor PXA255 processor is a low-power, high performance 32-bit Intel XScale core-base CPU [3]

As the diagram below shows, the Intel PXA255 application processor contains a number of peripheral features and functions It includes integrated controllers for external memory, serial buses, parallel buses, wired and wireless communications links, expansion card

Figure 2-3: Block diagram of Intel PXA255

At the core of the Intel PXA255 is an Intel XScale core-based microprocessor Intel XScale is

a 32-bit RISC microarchitecture based on architecture by Advanced RISC Machine (ARM) now the most popular 32-bit embedded CPU family in the world ARM-based and Intel XScale technology are completely binary compatible So software and software-developed tools designed for older ARM processors also work on newer Intel XScale core-based processors Of course, new Intel XScale technology-specific development tools work even better and take advantage of Intel XScale technology’s newer features

The application processor integrates the Intel XScale Core with the following peripheral set:

• Memory Controller

• Clock and Power Controllers

• Universal Serial Bus Client

• DMA Controller

• LCD Controller

• AC97

Most of the evaluation of real-time performance use external instrumentation such as function generator, logic analyzer, oscilloscope… The experiment need to be setup by an expert, so it

is difficult for users to make the test on their hardware system A testing module is required to

do the test with the ease to apply on different kinds of systems The evaluation module needs

to support signal generator function, time counter, and diagram visualize This thesis will propose a test module with all these function for testing real-time performance of embedded Linux

CHAPTER 3 EVALUATION OF REAL-TIME SYSTEM

From complex mathematical theories to full system hardware simulation, there are many different ways to evaluate real-time systems The evaluation of these systems, like research in many fields, usually falls into two parties; theoretical and experimental While many argue for one over the other, these two fields should not be at odds against each other They are in fact complementary, and any evaluation cannot really be said to be complete without both having been performed This chapter provides both the methods and metrics used to evaluate the target system, and provides description of experiments that were done in the evaluation of real-time systems

3.1 Evaluation methods

There are varying levels of real-time systems evaluation The most prevalent ones are the use

of analytical models, the simulation of scheduling algorithms, and hardware simulation Analytical models are mathematical theorems and proofs that model the worst time performance of one or more of the aspects of real-time systems, and by changing certain inputs to these theorems, an optimum performance can be proven Simulation takes the analytical models one step further in creating a simulation using scheduling theory to experiment with behavior of real-time systems Finally, hardware tests take the theorems that were postulated by the analytical model and have been simulated through the use of scheduling algorithms, and run tests on the actual hardware to discover any behavior that was not determined through either of the other two methods

This thesis focuses on experimental test for actual hardware The test is for the purpose of evaluating real-time scheduling capability of the embedded operating system The target system is Triton board using PXA255 processor with embedded Linux In experiments, some test programs are run on the target system Then a testing module logs all real-time data from

it The data will be sent to the host PC to analyze The detail of experiments will be presented

in the Section 3.3

3.2 Metrics of Characterization

Two of the most common metrics used to characterize real-time systems are jitter and response time These metrics will be measured and analyzed carefully on the test

Jitter represents the minimum and maximum time separating successive iterations of periodic

tasks If this inter-arrival time is greater than the period of the task, it means that the task is running late, and this will show up as a positive jitter value If that inter-arrival time is less than the period of the task, it means that the task is running early, and that will show up as a negative jitter value This variation is caused by interference with interrupt and other tasks This parameter is very important for real-time applications such as mechanic control, medicine instrument, etc

Figure 3-1: Real-Time Jitter

The execution of Task B pushes back the 3rd execution of Task A, causing the task completion times to deviate from their ideally periodic nature

Interrupt response time (interrupt latency) is the time that it takes for a real-time system to

respond to an external interrupt and represents the reaction time of the system to an unscheduled event while under load In other word, interrupt response time is the amount of time between when an interrupt is generated (internally or by an external device) and when an installed interrupt handler starts to execute When the system is in an idle state this time is very short, but will be longer when for example other interrupts are processed

Interrupt response time is a very important measurement in a real-time system It affects many other performance aspects such as scheduling precision and interrupts task latency The worst case interrupt latency yields, for example, a lower boundary for the worst case interrupt task latency The most interesting tests are those with load as the worst latencies show up under different levels of load

time

IRQ signal

Response

interrupt latency

The interrupt handler

The actuator triggers an interrupt

Figure 3-2: Interrupt Latency

3.3 Experiments

In this section, two tests will be proposed They are performed on Triton Starter Kit

For the first one, a mark with an output bit of the GPIO port is generated, when a fixed period

of time has elapsed, using as time generator the internal clock of the PC The intention of this test is to measure the variations that come up when Linux is performing synchronic tasks For the second test, the time that Linux take to response to an external interrupt is measured The intention of this test is to characterize the ability of Linux in handling asynchronic tasks All tests are performed under different kinds of load for the system:

No load: all background processes that are started at init are killed

Background load: init 3, including telnetd, inetd, syslogd, and klogd

Hard disk load: the command ls -lR is repetitively executed, during the time of the measure Network load: the command ping -f to another host in the same LAN is repetitively executed

Calculation load: a small program in C that performs a floating point division is executed in a loop

Full load: hard disk + network load + calculate load

3.3.1 Test 1: Jitter

A 20 millisecond pulse-width square wave is generated in an output bit of the GPIO port The time between the leading edge and the trailing edge of the square wave measured for single periods This experiment will show the jitter of a periodic task The period time is realized by

using usleep function to sleep in a specified mount of time The test result is the time that it

actually slept

The pseudo code for the periodic task:

Void task() {

While(1) // Loop forever

{ Set_gpio_bit(11); // Set bit GPIO11

Usleep(200000); // sleep 20ms Clr_gpio_bit(11); // Clear bit GPIO11

Usleep(200000); // sleep 20 ms }

}

Hardware setup

PXA255+Linux system Testing Module

Result

Control periodic signal

Figure 3-3: Hardware setup for test 1

milisecond

3.3V

Figure 3-4: Output wave form

Testing module has two objectives First is to send start signal to target system The second task is to receive periodic signal from the target system and evaluate jitter of the system

3.3.2 Test 2: Interrupt Latency

The testing program responds by turning on a digital output when an interrupt occurs When the system receives a stimulate signal for interrupt at GPIO10, a pulse is generated in an output bit of the GPIO11 Any interrupt occurring while the output is high should be ignored The elapsed time between the interrupt edge and the leading edge of the response pulse will

be statistically measured, and shown in the histogram

The test program running on target system

Hardware setup

PXA255+Linux system Testing Module

Result

stilmuate interrupt response

Figure 3-5: Hardware setup for test 2

interrupt response latency

CHAPTER 4 IMPLEMENTATION OF TESTING SYSTEM

Testing system has objectives to measure parameters of the target system and analysis the test results Testing system includes Jitter Test Module, Interrupt Latency Test Module A computer is connected to these module to store, visualize and analysis test results

4.1 Jitter Test Module

Jitter testing module is designed based on FPGA The objectives of this module are to receive pulse signal from target system, count the time interval of this signal and transfer this value to

PC through serial port The accuracy degree of this module is 1 microsecond

4.1.1 Top level design

The block diagram of this module is shown in Figure

Control

Time Counter

PXA250+Linux system

FPGA

CLK

1MHz

EN Clear Data

GPIO

Result T

Din

RAM

WE

8 bit

Figure 4-1: Block diagram of jitter test module

Control: is a state machine which receives signal from target system and controls

time-counter, mux, UART to do evaluation of jitter parameter

Clk_div: is necessary to create 1 MHz clock for time-counter

Time-counter: is 16 bit counter that calculates time interval of the periodic task

Mux: is a multiplexer that converts from 16 bit data to 8 bit data to transfer to UART

RAM: is a 1 KB 16 bit dual-port memory to store the count values

UART: (Universal Asynchronous Receive Transmitter) has the function by which it sends

data to PC through serial port

4.1.2 Control unit

Block diagram of Control unit is shown in figure

Figure 4-2: Control unit

Table 4-1: Pin description of control unit

Clock for the state machine Command that receive from UART unit Signal to indicate the last samples measure is finished Interrupt when a new command comes in

Interrupt after finishing sending a byte periodic pulses from PXA255

Reset the state machine Flag of current state for debugging Enable counter

Increase address counter Reset address counter Reset time counter Reset UART unit Select for multiplexer unit Strobe signal for UART unit Write enable for memory unit

Algorithmic State Machine (ASM) Chart

rst_count, rst_addr, rst_uart

inttx

1 0

is to send data to UART unit

The Intrx signal is checked to know when UART receives a start command from PC After receive start command, the control measures the time interval in high duty of the periodic pulse from the target system The measured value is stored into the memory every period When the control finishes the last sample (at that time, count_full goes logic one), all data from memory will be transferred to UART unit

The timing diagram below demonstrates the operation of state machine

This unit is for providing 1 MHz clock signal for the time counter

Figure 4-5: Block diagram of Clk_div unit

4.1.4 Time Counter Unit

Time counter unit is to measure the time interval in high duty of the periodic signal from target system

Figure 4-6: Block diagram of Timer Counter Unit

Table 4-2: Pin description of Timer Counter Unit

Clock input Clear, active high Enable counting, active high Count value output

4.1.5 Mux unit

This unit is a multiplexer to convert data from 16 bit to 8 bit

Figure 4-7: Block diagram of Mux Unit

Sel = 0 : dout (7:0) = din(7:0)

Sel = 1 : dout (7:0) = din(15:8)

4.1.6 UART unit

The UART unit (Universal Asynchronous Receiver Transmitter) is designed to make an interface between a RS232 line and FPGA It connects to the serial port of a PC for data exchange with custom electronics It was built in the perspective to be very small, but efficient It integrates two separate clocks, one for wishbone bus, and the other for bitstream generation

Figure 4-8: Block diagram of UART Unit

WISHBONE interface signals:

Table 4-3: Pin description of UART Unit

WB_CLK_I 1 Input Block’s clock input

WB_ADDR_I 2 Input Used for register selection

WB_WE_I 1 Input Write or read cycle selection

WB_STB_I 1 Input Specifies transfer cycle

WB_ACK_O 1 Output Acknowledge of a transfer

Other internal signals

Port Width Direction Description

IntTx_O 1 Output Transmit Interrupt

IntRx_O 1 Output Receive Interrupt

BR_CLK_I 1 Output Clock for serialisation/unserialisation

External (off-chip) connections

TxD_PAD_O 1 Output The serial output signal

RxD_PAD_I 1 Input The serial input signal

Upon a write to the data input bus WB_DAT_I, the core will automatically serialise and emit the byte on the TxD_PAD_O It will hold IntTx_O low as long as it cannot accept an incoming byte Therefore a rising edge on IntTx_O can trigger the interrupt line of a microcontroller to emit another byte

Upon reception of a bitstream on RxD_PAD_O, the core will unserialise the information and assert IntRx_O pin This announce that the received byte can be read on the data output bus WB_DAT_O As soon as the byte is read, IntRx_O is negated

4.2 Interrupt Latency Test Module

Interrupt test module is design based on FPGA The objectives of this module are to generate

an interrupt requests and receive response pulse from target system The time interval between the rising edge of the interrupt pulse and the leading edge of the response pulse will

be statistically measured, and be sent to PC to draw in the histogram The block diagram of this module is shown in Figure 4.9

4.2.1 Top level design

PXA250+Linux system

1MHz

EN Clear

Figure 4-9: Block diagram of Interrupt Latency Test Module

IRQ_generator: to send interrupt request signals to the target system

Control: a state machine control data flow in the module

Time counter: consists of eight channel that can count interrupt latency for eight interrupt

lines

Mux: a multiplexer 2 to 1 to transfer data to UART unit

UART: (Universal Asynchronous Receive Transmitter) has the function by which it sends

data to PC through serial port

4.2.2 IRQ_generator unit

Figure 4-10: IRQ_generator unit