Transcript Title of Presentation

Operating System
for
SOPC
Spring 2009
Final Presentation
Part A
Performed by: Dvir Olansky
Omri Flint
Supervised by: Mony Orbach
Motivation
In recent years, embedded systems have
become more and more popular
These systems receive greater memory and I/O
resources
As an outcome of these changes, the need for
an OS, that manages multiple tasks ,has
increased
Project Goals
Learning the principles and development
environment of SOPC systems and µC OS
Understanding the integration of the OS and the
SOPC system
Establishing a basis for future projects by
creating an example based guidance document
Performance analysis and conclusions about the
µC OS abilities
The Hardware
Altera’s DE2 development board
Nios II processor
Board’s I/Os
HW added for OS:
SDRAM memory
PLL
Timers
Block Diagram
DE2
Cyclone II
NIOS System
JTAG
UART
On-Chip
MEM
(16KB)
NIOS II core
text
text
AVALON
text
PIO
PIO
PIO
Leds
PIO
PIO
Switches
Buttons
Timer
Timer
SDRAM
Controller
PLL
SDRAM
(8MB)
µC/OS-II
First version was published on 1992
Third version already out
Currently maintained by Micrium
Simple and robust - implemented in the highest
level safety critical devices (avionics, medical,
etc.)
Mainly for embedded systems
Supports large number of architectures
Based on C source code
µC/OS-II - cont.
Main features:
Scalable (5-24KB)
Real time
Pre-emptive multitasking
Priority based
Limited (but big enough) number of tasks
Supply OS services:
Semaphores and mutexes
Message mailboxes and queues
Timer and memory management
µC Scheduling
µC always executes the highest priority task
ready to run
No dynamic scheduling
Running 2 tasks that “say hello”:
Starvation of task2 
µC Scheduling - cont.
Tasks scheduling in µC is under the programmer
responsibility
There are several methods to schedule tasks
System calls from within the tasks
Separated scheduler task
ISR - Interrupt Service Routine
System Calls From Within The Tasks
Scheduling 3 tasks using OSTaskSuspend and
OSTaskResume:
No Starvation 
Each task has to suspend itself and resume the
next task to run 
Separated Scheduler Task
Scheduling 3 tasks using Round-Robin scheduler
task:
No Starvation 
Scheduling code is written only in the scheduler
task 
Can implement any scheduling algorithm
ISR - Interrupt Service Routine
I/O tasks Vs. Batch tasks
When an I/O task is ready to run it is a good
idea to schedule it ASAP
The OS has to know when an I/O task is ready
One way of notifying the OS is using ISR
ISR - cont.
Scheduling one I/O task and one batch task
using ISR:
Guidance Document
The previous cases we have seen cover
fundamental use of µC
Our project book contains a step-by-step
“hands-on” guidance for implementing them all
Future projects can rely on this document for an
easy start with µC
Performance
Every OS requires CPU time for management
and scheduling
Tasks latencies becomes longer
This could be a problem in real time systems
When designing a RT system, designer should
figure out how much overhead is acceptable
Performance - cont.
e.g. Round robin scheduling:
Performance - cont.
total
Context
Switches
4
10
20
40
50
50
50
50
100
100
100
100
200
200
250
500
1000
2000
5000
10000
total time
total time
Sequencial [uSec] Parallel [uSec]
4956.86
5075.48
4957.14
5175.14
4963.58
5316.92
4972.58
5619.88
553.58
1308.22
1295.38
2053.74
2522.84
3293.86
4976.66
5762.7
140.76
1609.1
1089.46
2522.72
2564.68
4016.02
4999.18
6490.52
2111.36
4988.36
5043.02
7934.72
5063.06
8682.64
5174.1
12310.58
5412.38
19646.64
5771.72
34216.04
6988.96
77879.88
9022.66
150636.54
avarage_CS_time_on_all_runs[uSec]
diff
avarage Context Switch
[uSec]
Time [uSec]
118.62
29.655
218
21.8
353.34
17.667
647.3
16.1825
754.64
15.0928
758.36
15.1672
771.02
15.4204
786.04
15.7208
1468.34
14.6834
1433.26
14.3326
1451.34
14.5134
1491.34
14.9134
2877
14.385
2891.7
14.4585
3619.58
14.47832
7136.48
14.27296
14234.26
14.23426
28444.32
14.22216
70890.92
14.178184
141613.9
14.161388
15.9769636
Measuring
shows that
every task
switch takes
about 14-16
µSec
Summery
An operating system has many benefits in a
complex system:
abstraction
Modularity
Synchronization
Nothing comes without cost:
Scheduling is not trivial! (maybe easier in µC III)
Computing time will be damaged
Good design can take advantage of the features
with not too much overhead
Future Projects
A smart scheduler
Take responsibility off the programmer
Advanced µC features
Semaphores, messaging, etc.
Drivers
Projects that require multitasking abilities,
memory management and other OS services
Thank you