09/20/2012 2012 Illinois Institute of Technology

ECE 587 Hardware/Software Co-Design

Lecture 09 Processor Modeling I
Professor Jia Wang
Department of Electrical and Computer Engineering
Illinois Institute of Technology
September 20, 2012
ECE 587 Hardware/Software Co-Design Fall 2012 1/23
Reading Assignment

This lecture: 3.4

Next lecture: 3.4

ECE 587 Hardware/Software Co-Design Fall 2012 2/23
Outline
Processor Modeling
Application Layer
Operating System Layer
ECE 587 Hardware/Software Co-Design Fall 2012 3/23
The Whole Picture

Processors: a.k.a. processing elements

General-purpose processors

DSPs and ASIPs

ASICs

Processor modeling provides necessary details to evaluate

mappings from processes to processors.

The computation part of system modeling

ECE 587 Hardware/Software Co-Design Fall 2012 4/23
Processor Modeling

Processors specic to certain applications

Processes are usually specied with MoCs that can be directly

mapped to the processors.

Based on hardware metrics, estimating system design metrics

could be straight-forward.

Otherwise, we can model such processors as special cases of

general-purpose processors.

General-purpose processors, or software processor

Processes are usually specied as sequential programs.

To estimate system design metrics, one has to consider not

only the programs but the supporting software (e.g. OS).

Much more complicated than the above case. Will be our

focus.

Challenges for software processors modeling

Most estimations of system design metrics, e.g. latency,

throughput, and power consumption, depend on simulation.

Models enable fast simulations while provide accurate

(relatively) estimations are desired.

At what level should we model software processors?

ECE 587 Hardware/Software Co-Design Fall 2012 5/23
Processor Modeling

Processors specic to certain applications

Processes are usually specied with MoCs that can be directly

mapped to the processors.

Based on hardware metrics, estimating system design metrics

could be straight-forward.

Otherwise, we can model such processors as special cases of

general-purpose processors.

General-purpose processors, or software processor

Processes are usually specied as sequential programs.

To estimate system design metrics, one has to consider not

only the programs but the supporting software (e.g. OS).

Much more complicated than the above case. Will be our

focus.

Challenges for software processors modeling

Most estimations of system design metrics, e.g. latency,

throughput, and power consumption, depend on simulation.

Models enable fast simulations while provide accurate

(relatively) estimations are desired.

At what level should we model software processors?

ECE 587 Hardware/Software Co-Design Fall 2012 5/23
Software Processor Modeling

At instruction level, processors can be modeled as FSMs, and

processes can be modeled as assembly programs. However,

Simulations are slow as the supporting software are treated the

same way.

With all the details mixed together, it is dicult for the

designers to make design decisions for improvements, especially
when multiple processes are mapped to a single processor.

Separate the computation into layers

E.g. processor, OS/library, application processes

Allow designers to reason about various parts of the system.

Certain functionality, e.g. those from OS/library, can be

simulated faster at levels higher than instructions.

Software processor modeling is not limited only to the

processors themselves but should include all pieces of the
supporting software.
ECE 587 Hardware/Software Co-Design Fall 2012 6/23
Typical Modeling of Software Processor
(Gajski et al.)
ECE 587 Hardware/Software Co-Design Fall 2012 7/23
Typical Layers of Computation

Processor Hardware (HW)

Actual hardware that communicates with the other parts of

the system.

Hardware Abstraction Layer (HAL)

Provide abstractions of actual hardware as canonical interfaces

as most modern OS are hardware independent.

Operating System (OS)

Provide necessary services like multi-tasking, scheduling,

inter-process communication

Application

With the help of OS, we can still model multiple processes

mapped to the same processor as they are.

Notion of time can be introduced as execution delay.

Via back-annotation
ECE 587 Hardware/Software Co-Design Fall 2012 8/23
Outline
Processor Modeling
Application Layer
Operating System Layer
ECE 587 Hardware/Software Co-Design Fall 2012 9/23
Application Modeling

Applications are modeled as communicating processes.

All this processes are running on the SAME processor so

somewhat you may ignore the costs associated with their
communications.

Processes may be composed hierarchically, e.g. through the

fork-join model.

Process scheduling is handled at the OS layer and is irrelevant

at this layer, though it may aect the performance of the
system.

Communication mechanisms: shared variable and message

passing

Message passing could be in its special and high-level forms

like events, semaphores, queues, and abstract channels.

Message passing is most likely implemented at the OS layer,

though we need to include the specication for applications.
ECE 587 Hardware/Software Co-Design Fall 2012 10/23
Specifying Applications

It is quite common that the initial application specications

are migrated from some other systems.

Computations are specied in a programming language like

C/C++

Except shared variables, communications are specied as

function calls to certain library/OS.

Process management are specied in similar ways like

communication.

Using a system design language like SystemC, the eort of

migrating code could be minimized.

Computations are included directly.

Function calls for communications/process management can

be replaced by corresponding primitives.
ECE 587 Hardware/Software Co-Design Fall 2012 11/23
Considerations for Simulation

Fast simulation

Computation could be emulated in host instructions, usually

much faster than simulating target instructions.

Simulation kernel may be optimized to reduce process

management/scheduling overhead and communication costs,
and to utilize the multi-processing power of the host.

Accurate estimations

Back-annotation is necessary if timing behavior is of concern

as simulation is not performed on targeted platform.

System design languages support back-annotations via

execution timings, which are independent of their running
times on host.
ECE 587 Hardware/Software Co-Design Fall 2012 12/23
Application Layer Modeling Example
(Gajski et al.)
ECE 587 Hardware/Software Co-Design Fall 2012 13/23
More about Back-Annotation

Back-annotations may be included at various level of

computations.

E.g. the whole process or basic blocks

As a process may react dierently for dierent inputs,

assigning it a simple delay number could be inaccurate.

Associating delay numbers with basic blocks will be able the

capture such dynamic behavior and thus improve accuracy.

However, it will slow down simulation because of the excessive

interactions with the simulation kernel required by
back-annotation.

There is always a trade-o between simulation speed and

accuracy.

The delay numbers may be obtained by estimation or

measurement.
ECE 587 Hardware/Software Co-Design Fall 2012 14/23
Outline
Processor Modeling
Application Layer
Operating System Layer
ECE 587 Hardware/Software Co-Design Fall 2012 15/23
OS and Multi-Processing

We assume processes are running truly concurrently at

application layer.

However, when mapped to a single processor, thats not

possible.

OS provides the illusion that processes are running

concurrently,

though actually they run sequentially on the processor.

The major focus of the OS layer is thus to model the

scheduling of parallel processes on the sequential processor.
ECE 587 Hardware/Software Co-Design Fall 2012 16/23
Static vs. Dynamic Scheduling

Static scheduling combines processes into a singe task

following a pre-dened static schedule.

E.g. you may interleave the statements of multiple processes

to achieve a static round-robin scheduling.

Modeling of static scheduling is no harder than modeling of a

sequential program.

What if a process need to communicate for either data or

synchronization and have to wait?

The task has to wait.

All the processes in the task halt.

May hurt system latency/throughput or even lead to articial

deadlocks

Dynamic scheduling allows OS, at runtime, to hang tasks that

have to wait and to execute tasks that are ready to go.

For embedded systems, typically a Real-Time Operating

System (RTOS) is used.

And thus a model of RTOS should be established.

Real-time here doesnt imply low computing latency, but

means mechanism to meet certain deadlines.
ECE 587 Hardware/Software Co-Design Fall 2012 17/23
Other OS Layer Modelings

Process/task management

Synchronization

Timing, i.e. delay modeling

Realize communication channels as IPC primitives

Synchronization may be required.

ECE 587 Hardware/Software Co-Design Fall 2012 18/23
Interaction between Application and OS Layers
(Gajski et al.)
ECE 587 Hardware/Software Co-Design Fall 2012 19/23
RTOS Modeling Choices
(Gajski et al.)

For specication (a), tasks execute directly on the simulation

kernel and scheduling is omitted.

There are two choices to model the actual RTOS scheduling

algorithm.

(c) simulation at instruction level

(b) provide a transaction-level RTOS model

ECE 587 Hardware/Software Co-Design Fall 2012 20/23
RTOS Modeling Choices
(Gajski et al.)

For specication (a), tasks execute directly on the simulation

kernel and scheduling is omitted.

There are two choices to model the actual RTOS scheduling

algorithm.

(c) simulation at instruction level

(b) provide a transaction-level RTOS model

ECE 587 Hardware/Software Co-Design Fall 2012 20/23
Instruction vs. Transaction-Level RTOS Modelings

Instruction level simulation

Need to compile all codes, including applications, to target

instructions.

Simulation is done in an instruction-set simulator (ISS).

Very accurate, but slow

Transaction-level RTOS models combine fast application

simulation in host instructions and instruction-level modeling
accuracy.

Use an abstract RTOS model that removes unnecessary

implementation details

Only care about multi-tasking, preemption, interrupt handling,

inter-process communication, and synchronization

Add only a negligible simulation overhead

Allow designers to consider important OS eects early on in

the design process
ECE 587 Hardware/Software Co-Design Fall 2012 21/23
Example for Scheduling and Other OS Services
(Gajski et al.)
ECE 587 Hardware/Software Co-Design Fall 2012 22/23
Summary

Processor modeling should include all pieces of supporting

software, e.g. HAL and OS.

Application layer includes functional models that can be

eciently simulated.

Process/task scheduling are the major focus of OS layer

modeling.

Back-annotations enable accurate estimations.

ECE 587 Hardware/Software Co-Design Fall 2012 23/23