Embedded Systems

(ENEE759V-ENEE459V)

Course Overview
ENEE759V and ENEE459V

Dr. George Zaki

University of Maryland at College Park, Summer 2017

Version: May 30, 2017

 Course Materials and Slides

These slides were developed based on the work

of:
Professors E. Lee and S. Seshia, University of
California Berkely
Professor P. A. Laplante, Pen State University
Professor Forrest Brewer, University of California
San Diego
Professor Shuvra Bhattacharyya, University of
Maryland
 Basic Lecture Information

Course #: ENEE759V-ENEE459V
Course Title: Embedded Systems
Credits: 3
Time: Mondays 5:30pm to 8:15pm
Location: JMP 3201
Prerequisites:
ENEE140/150 or equivalent (C programming)
ENEE 350 or equivalent (Computer Organization)
Recommended as co-requisite: ENEE 244(Digital
Logic Design)
 Basic Lecture Information
Instructor: Dr. George Zaki
Office: TBD
E-mail: gzaki@umd.edu
Office Hours: email me to schedule
Background
Hardware-Software Co-Design
Hardware Design and Software Synthesis
Scheduling Heterogeneous Multiprocessor
Systems, Graphics Processing Units, and
Embedded Digital Processor.
Targeted application fields: digital signal
processing, Medical Images, Augmented Reality,
and wireless sensor networks.
 Basic Lecture Information
Grader: Vivek Hemchandra
Email: vhemchan@umd.edu
 Course Website

Online content for the course is managed

through Canvas: https://myelms.umd.edu
Recordings of lectures will be posted under Lecture
Videos
Check the courses Canvas site frequently for
special notices, and new or updated information,
especially for the posts of reading and projects
assignments.
Check email frequently for course-related
messages.
 Lecture Information

Textbooks:
E. Lee and S. Seshia, Introduction to Embedded
Systems, A Cyber-Physical Systems Approach, (2nd
Edition) (required)
Can be download online
P. A. Laplante and S. J. Ovaska, Real-Time Systems
Design and Analysis, (4th Edition) (required)

Assignments are taken from the textbooks

 Lecture Information

Required readings
Textbook.
Lecture handouts.
Other course handouts.
Lecture notes written on whiteboard.
 Important Notes

When sending email to me about course-related

matters, please be sure to include a descriptive
subject, and start the subject with ENEEX59V
(without the quotes). This will make it easier for
me to quickly identify course-related messages
for faster response.

Please refer to the handouts for important details

about Course Information, Syllabus, Course
policies, etc.
 Important Notes

I will reply your email within 24 hours. If you do

not get a response, please email me again.
 Grading Guideline
(15%) Assignments
(15%) GPU labs
(25%) Final Exam.
(15%) Project 1: Embedded system simulation
using C
(15%) Project 2: RTOS simulation / Student
proposed project
(15%) Project 3: Embedded system
implementation using RTOS
 General Information about
assignments

Assignment will be given to be completed a day

after the following lecture during the semester.

Policy for missed assignments, refer to the

course handout: General Information about
Quizzes and Attendance
General Information about Course Projects
Project details will be given in each project
assignment. For the first project, you need to
use C, for the second project, you can use any
language you are familiar with (C, C++, Java,
Python) to write a scheduling simulator, and for
the third project, you need to use C and Texas
Instruments RTOS libraries
When a project is due, each student needs to
submit project source code along with project
report.
Suggestions for project 3 are welcomed.
Guidelines will be posted.
For the graduate section ENEE759V only
Paper reading assignments will be posted.
You will need to write one page abstract about every
assigned paper.
Some projects will include additional
deliverables to be submitted.

Students enrolled in the undergraduate section

ENEE459V can choose to submit these extra
deliverable for a bonus grade.
 Project 3 tools

To complete project 3 you will need the following

software and hardware components:
TI Code Composer Studio: 6.1.2.00015
XDC tools 3.32.0006
tirtos_msp43x_2_16_00_08

MSP430 FF5529 LaunchPad Evaluation Kit

Please install the tools and run the RTOS

examples as soon as you can. The project time
does not budget for the installation step.
 Project and assignment submission

Each project assignment is submitted via glue

submit utilities in the glue server.
Details about how to use glue submit utilities, refer to
the course handout: General Information about
Submitting Assignments and Late Penalties (will be
posted in the near future)
Information about course environment setup in glue
will be given in the near future.

Assignment solution can be submitted on

Canvas. Please scan an upload your solutions.
 Policy for Late Assignments

Less that 1 hour late: No penalty (one hour

grace period)
1-24 hours late: 20% penalty
24-48 hours late: 40% penalty
etc. (20% for every additional 24 hours late)

Policy for late assignments, refer to the course

handout: General Information about Submitting
Assignments and Late Penalties.
 Course Outline and Project Schedule
Introduction to embedded real time systems
Examples, definitions, the implementation gap
Shell scripting, Unix concepts and course software
environment
Cross platform unit testing

Embedded systems modeling: 1- Dataflow

Project 1 announcement
Embedded systems modeling: 2- FSM
 Course Outline and Project Schedule
Modern Computer Architecture for Embedded
Systems
Inputs and Outputs
Fundamentals of Real Time Operating Systems
Concepts
Project 2 announcement
RTOS Scheduling Techniques
Priorities and Deadlocks
Project 3 announcement
 Course Outline and Project Schedule
(Contd)
Programming for embedded multicore devices
General purpose programming for graphics
processors (GPUs)
CUDA: overview and tutorial
GPU Labs
Final Exam
 Course Objectives
By successfully completing this course, you should be able
to:
Understand fundamental models that describe
embedded real time systems

Identify the features required in real time operating

systems for a given embedded applications

Analyze real time programs for different set of

embedded processor architectures

Identify multicore implementation challenges and

implement data parallel programs on graphic processing
units.
 Embedded Systems
(ENEE759V-ENEE459V)

Introduction to Embedded Systems

Lee and Seshia: Chapter 1
Laplante and Ovaska: Chapter 1

Dr. George Zaki

University of Maryland at College Park, Summer 2017

Version: May 30, 2017

 Embedded applications
An embedded system is a computer system designed to
perform one or a few dedicated functions often with real-time
computing constraints (e.g. power, memory, throughput,
latency )
The I/O function is well defined and can be modeled. (mp3,
LTE transmitter, microwave, pace maker, high energy physics
detector,)
 Motivating Example 1: Augmented
reality in stereoscopic surgeries

https://www.youtube.com/watch?v=WHwuyeJTT
w8
 Motivating Example 2: A Cyber-Physical
System

STARMAC quadrotor aircraft (Tomlin, et al.)

Introductory Video:
http://www.youtube.com/watch?v=rJ9r2orcaYo
Back-Flip Manuever:
http://www.youtube.com/watch?v=iD3QgGpzzIM
 STARMAC Design Block Diagram

LIDAR RS232
URG-04LX 115 kbps
10 Hz ranges PC/104 WiFi
USB 2
Stereo Cam
Pentium M
480 Mbps
802.11g+
Firewire 1GB RAM, 1.8GHz 54 Mbps
Videre STOC
30 fps 320x240 480 Mbps RS232 Est. & control

GPS UART
Superstar II 19.2 kbps Stargate 1.0 WiFi
10 Hz
Intel PXA255
CF
UART 802.11b
64MB RAM, 400MHz 100 Mbps 5 Mbps
IMU 115 Kbps UART
3DMG-X1 UART Supervisor, GPS
Robostix
76 or 100 Hz 115 kbps
Atmega128
Low level control
Ranger I2 C PPM
SRF08 400 kbps 100 Hz
13 Hz Altitude Analog

Ranger Beacon
Mini-AE ESC & Motors
Timing/ Tracker/DTS Phoenix-25, Axi 2208/26
10-50 Hz Altitude Analog 1 Hz
 2001 National Research Council
Report
Embedded Everywhere
Information technology (IT) is on the verge of another revolution.
Driven by the increasing capabilities and ever declining costs of
computing and communications devices, IT is being embedded into a
growing range of physical devices linked together through
networks and will become ever more pervasive as the component
technologies become smaller, faster, and cheaper... These networked
systems of embedded computers ... have the potential to change
radically the way people interact with their environment by linking
together a range of devices and sensors that will allow information to
be collected, shared, and processed in unprecedented ways. ... The
use of [these embedded computers] throughout society could well
dwarf previous milestones in the information revolution.
 Why do we care? Some Market
Tidbits...
Specialized devices and appliances replacing PCs
variety of forms: set-top boxes, fixed-screen phones,
smart mobile phones, PDAs, NCs, etc.
In 1997, 96% of internet access devices sold in the US
were PCs, by 2004, shipments far exceeded PCs
2009 Tire Pressure Sensors: 60-70M/yr, Smart cards
100-200M/yr
Traditional Products
dependent on computation systems
Modern cars: ~100 processors running complex software

Slide courtesy of Mani Srivastava

Cyber-Physical Systems (CPS): Transportation
(Air traffic
Orchestrating networked control at
computational Avionics
SFO)
resources with physical systemsTelecommunications
Automotive Building Systems

Instrumentation
E-Corner, Siemens (Soleil Synchrotron)
Factory automation
Power
generation and
distribution

Daimler-Chrysler

Military systems:

Courtesy of
Courtesy of Doug Schmidt General Electric Courtesy of Kuka Robotics Corp.
Practical Embedded Systems

Aerospace Industrial
Flight control Crane
Navigation Paper machine
Pilot interface Welding robot
Automotive Multimedia
Airbag deployment Console game
Antilock braking Home theater
Fuel injection Simulator
Self driving cars Medical
Household Intensive care monitor
Microwave oven Magnetic resonance imaging
Rice cooker Remote surgery
Washing machine
Embedded Automotive

More than 30% of the cost of a car is now in Electronics

90% of all innovations will be based on electronic systems
Slide courtesy of Alberto Sangiovanni-Vincentelli
Roborace 2016-2017: 10 teams, 0 drivers

https://blogs.nvidia.com/blog/2016/04/05/roborace/
Mars Exploration Rover of NASA

Why it slowed down after launch?

 This Subject is Multidisciplinary

Computer Science: System Theory:

Carefully abstracts the Deals directly with

physical world physical quantities

Cyber Physical Systems:

Computational +
Physical
 Characteristics of Embedded Systems

Part of larger system

not a computer with keyboard, display, etc.
HW & SW application-specific not general purpose
application is known a-priori
definition and development concurrent
Interact (sense, manipulate, communicate) with the
external world
Never terminate (ideally)
Operation is time constrained: latency, throughput
Other constraints: power, size, weight, heat, reliability
Increasingly high-performance (DSP) & networked

Slide courtesy of Mani Srivastava

 Some Definitions
1- System

A system is a mapping of a set of inputs into a set

of outputs
Inputs Outputs

System
Input Space Output Space
.. Mapping Function ..
. .

1. A system is an assembly of components connected together in an organized

way
2. A system is fundamentally altered if a component joins or leaves it
3. It has a purpose
4. It has a degree of permanence
5. It has been defined as being of particular interest
 2- Response Time

The time between the presentation of a set of

inputs to a system and the realization of the
required behavior, including the availability of all
associated outputs, is called the response time of
the system

How fast and punctual does it need to be?

Depends on the specific real-time system
But what is a real-time system?
 3- Real-Time System

A real-time system is a computer system that must

satisfy bounded response-time constraints or risk
severe consequences, including failure

A real-time system is one whose logical

correctness is based on both the correctness of
the outputs and their timeliness
 4- Failed System

A failed system is a system that cannot satisfy one

or more of the requirements stipulated in the
system requirements specification

Hence, rigorous specification of the system

operating criteria, including timing constraints, is
necessary
 Another Definition: Embedded System
An embedded system is a system containing one
or more computers (or processors) having a
central role in the functionality of the system, but
the system is not explicitly called a computer

A real-time system may be embedded or non-

embedded
But it is always reactive
Task scheduling is driven by ongoing interaction with
the environment
 Degrees of Real-Time

All practical systems are ultimately real-time

systems
Even a batch-oriented systemfor example,
grade processing at the end of a semesteris
real-time
Although the system may have response times
of days, it must respond within a certain time
Even a word-processing program should
respond to commands within a reasonable
amount of time
Most of the literature refers to such systems as
soft real-time systems
 5- Soft, Hard, and Firm Real-Time

Definition: Soft Real-Time System

A soft real-time system is one in which performance is degraded but
not destroyed by failure to meet response-time constraints

Definition: Hard Real-Time System

A hard real-time system is one in which failure to meet even a
single deadline may lead to complete or catastrophic system failure

Definition: Firm Real-Time System

A firm real-time system is one in which a few missed deadlines will
not lead to total failure, but missing more than a few may lead to
complete or catastrophic system failure
 Example: Real-Time Classification

System Real-Time Explanation

Classification
Avionics weapons
delivery system in
which pressing a button
launches an air-to-air
missile
Navigation controller
for an autonomous
weed-killer robot
Console hockey game
 Example: Real-Time Classification

System Real-Time Explanation

Classification
Avionics weapons Hard Missing the deadline to launch the
delivery system in missile within a specified time after
which pressing a button pressing the button may cause the
launches an air-to-air target to be missed, which will result
missile in a catastrophe
Navigation controller
for an autonomous
weed-killer robot
Console hockey game
 Example: Real-Time Classification

System Real-Time Explanation

Classification
Avionics weapons
delivery system in
which pressing a button
launches an air-to-air
missile
Navigation controller
for an autonomous
weed-killer robot
Console hockey game
Hard Missing the deadline to launch the
missile within a specified time after
pressing the button may cause the
target to be missed, which will result
in a catastrophe
Firm Missing a few navigation deadlines
causes the robot to veer out from a
planned path and damage some
crops
 Example: Real-Time Classification

System Real-Time Explanation

Classification
Avionics weapons
delivery system in
which pressing a button
launches an air-to-air
missile
Navigation controller
for an autonomous
weed-killer robot
Console hockey game
Hard Missing the deadline to launch the
missile within a specified time after
pressing the button may cause the
target to be missed, which will result
in a catastrophe
Firm Missing a few navigation deadlines
causes the robot to veer out from a
planned path and damage some
crops
Soft Missing even several deadlines will
only degrade performance
 6- Real-Time Punctuality

Real-time punctuality means that every response

time has an average value, R , with upper and
lower bounds of R + U and R L , respectively,
and U , L 0+

In all practical systems, the values of U and L

are nonzero, though they may be very small
The nonzero values are due to cumulative
latency and propagation-delay components
(hardware/software)
Such response times contain jitter within the
interval L , +U
 Where Do Deadlines Come from?

Deadlines are based on the underlying physical

phenomena of the system under control
Punctuality is another measure related to
response times
Particularly important in periodically sampled systems
with high sampling rates (e.g., in audio and video
signal processing)
Rule of thumb for cost-effective real-time
systems:
Process everything as slowly as possible and repeat
tasks as seldom as possible
 Example: Where a Response Time
Comes from?
An elevator door is automatically operated and it
may have a capacitive safety edge for sensing
possible passengers between the closing door
blades
Thus, the door blades can be quickly reopened
before they touch the passenger and cause
discomfort or even threaten the passengers
safety
What is the required system response time from
when it recognizes that a passenger is between
the closing door blades and starting to reopen
the door?
 Door Reopening Example Contd

This response time consists of five independent latency

components:

Sensor: SE_min = 5 ms SE_max = 15 ms

Hardware: HW_min = 1 s HW_max = 2 s
System software: SS_min = 16 s SS_max = 48 s
Application software: AS_min = 0.5 s AS_max = 0.5 s
Door drive: DD_min = 300 ms DD_max = 500 ms

Now, we can calculate the minimum and maximum values of the

composite response time: min 305 ms, max 515 ms

The overall response time is dominated by the door drives

response time containing the deceleration time of the moving
door blades.
 Taxonomy of Events

An event can be either synchronous or

asynchronous
Synchronous events are those that occur at predictable
times in the flow-of-control of the running program
Asynchronous events occur at unpredictable points in the
flow-of-control and are usually caused by external sources
Moreover, events can be periodic, aperiodic or
sporadic
A real-time clock that pulses regularly is a periodic event
Events that do not occur at regular periods are called
aperiodic
Aperiodic events that tend to occur very infrequently are
called sporadic
 Example: Various Types of Events

Type Periodic Aperiodic Sporadic

Synchronous Cyclic code Conditional branch Divide-by-zero (trap)
interrupt
Asynchronous Clock interrupt Regular, but not fixed- Power-loss alarm
period interrupt
 Design Issues

We are dealing with complex systems

How to get it working?
(on time, on budget)
Need for abstraction and design reuse
How to test it?
Unforeseen Behaviors (Air Bus!)
Real Time Physical Embedding
Does it meet constraints?
Design Budgeting: Power, Size, Cost, Reliability
What are the exploitable design options?
Rich Variety of Real-Time
Disciplines

Programming
Languages
Operating
Algorithms
Systems

Data Software
Structures Engineering
Real-Time
Systems
Operations Control
Research Theory

Queuing Systems
Theory Theory
Computer
Architecture
 Technologies

Integrated Processors
Nearly free in production
A/D, D/A, Sampling
Interface Analog world to cheap computing
MEMS, NEMS, Opto-Devices
Miniature Direct Coupling to Real World
Batteries, Solar Cells, Vibration Scavenging,
Thermal Gradient Cell
Computation and Communication Power
 Usual Misconceptions

Real-time systems are synonymous with fast systems

Many (but not all) hard real-time systems deal with deadlines in the tens of
milliseconds
There are universal, widely accepted methodologies for real-time systems
specification and design
There is still no methodology available that answers all of the challenges of real-time
specification and design all the time and for all applications
There is no more a need to build a real-time operating system, because
many commercial products exist
Commercial solutions have certainly their place, but choosing when to use an off-the-
shelf solution and choosing the right one are continuing challenges
Rate-monotonic analysis has solved the real-time problem
While rate-monotonic systems provide guidance in the design of real-time systems,
and while there is theory surrounding them, they are not a panacea
The study of real-time systems is mostly about scheduling theory
While it is scholarly to study scheduling theory, most published results require
impractical simplifications and clairvoyance in order to make the theory work
CPS Challenge Problem: Prevent This
 An Emphasis on

Engineering Models for Cyber Physical

Systems
 A Theme in our course:
Model-based design

Image courtesy: Prof. Kathy Davis, UT Austin

Models are abstractions of reality

 A Challenge

We typically learn to use modeling techniques, not to evaluate

modeling techniques.
this is how computers work
this equation describes that feedback circuit
rather than
this is how Von Neumann proposed that we control automatic
machines
ignoring the intrinsic randomness and latency in this circuit, Black
proposed that we could idealize its behavior in this way

We need to think about meta-modeling, not just modeling. We

must learn to think critically about modeling methods, not just
about models.
 A Challenge

Models for the physical world and for computation diverge.

physical: time continuum, ODEs, dynamics

computational: a procedural epistemology, logic

There is a huge cultural gap.

Physical system models must be viewed as semantic

frameworks, and theories of computation must be viewed as
alternative ways of talking about dynamics.
 Models vs. Reality
Solomon Golomb: Mathematical models Uses and limitations.
Aeronautical Journal 1968

You will never strike oil by

drilling through the map!

Solomon Wolf Golomb (1932) mathematician

and engineer and a professor of electrical
engineering at the University of Southern
California. Best known to the general public and
fans of mathematical games as the inventor of
polyominoes, the inspiration for the computer
game Tetris. He has specialized in problems
of combinatorial analysis, number theory,
coding theory and communications.
But this does not, in any way,
diminish the value of a map!
 The Kopetz Principle

Many (predictive) properties that we assert

about systems (determinism, timeliness,
reliability, safety) are in fact not properties of
an implemented system, but rather properties
of a model of the system.

We can make definitive statements about

models, from which we can infer properties of
system realizations. The validity of this
Prof. Dr. Hermann Kopetz inference depends on model fidelity, which is

always approximate.
(paraphrased)
 Determinate Models

Physical System Model

Synchronous digital logic

 Determinate Models

Physical System Model

Single-threaded imperative programs

 Determinate Models

Physical System Model

Signal Signal

Differential Equations
Combinations are Nondeterminate

Signal Signal
Schematic of a simple CPS:
 Computation given in an
untimed, imperative language.
Physical plant modeled with
ODEs or DAEs
 A Key Challenge:
Timing is not Part of Software
Semantics
Correct execution of a program in C, C#, Java,
Haskell, OCaml, etc. has nothing to do with how long
it takes to do anything. Nearly all our computation and
networking abstractions are built on this premise.

Programmers have to step outside the

programming abstractions to specify
timing behavior.

Programmers have no map!

Computer Science has not ignored timing

The first edition of Hennessy and

Patterson (1990) revolutionized
the field of computer architecture
by making performance metrics
the dominant criterion for design.

Today, for computers, timing is

merely a performance metric.

It needs to be a correctness
criterion.
 Correctness criteria
We can safely
assert that line 8
does not execute

(In C, we need to
separately ensure that
no other thread or ISR
can overwrite the stack,
but in more modern We can develop absolute
languages, such
assurance is provided
confidence in the software, in that
by construction.) only a hardware failure is an excuse.

But not with regards to timing!!

 The hardware out of which we build
computers is capable of delivering
correct computations and precise
timing
The synchronous digital logic
abstraction removes the
messiness of transistors.

but the overlaying software // Perform the

convolution.
abstractions discard the timing for (int i=0; i<10; i++)
precision. {
x[i] = a[i]*b[j-i];
// Notify listeners.
notify(x[i]);
}
 A Theme in This Course:
Think Critically

Can we change programming models so that a

correct execution of a program always delivers the
same temporal behavior (up to some precision) at
the subsystem I/O?

i.e. we need determinate CPS models

 A Theme in This Course:
Think Critically

How can we overcome the powerful inertia created

by existing languages, tools, and methodologies to
allow innovation that may change key
abstractions?

i.e. we need open minds

 The Challenges of CPS
Design: How to choose
the right model?
x
E.g. Electric Power
Systems (EPS) for
Aircraft
Physically:
Generators
Contactors
Busses
Loads
 Even a Small Subsystem is an Elephant Its an
electrical
system
Its an Its a mechanical
electromechanical system
Plant system x f ( x, u, )
F ( x) 0
ref u Load
Contactor Bus
Generator Voltage disturbance

Its a
control Its a
system Protection software
PID Threshold detection system
u K p e K i e K d
de Fault
dt
LRU1
Energize
Supervisor
On/off FSM
Switch
Signal generator

LRU2
Cockpit Its a
Its a human- communicati
computer Thanks to Eelco Scholte, UTC
on network
interface
 Model Of Computation
What is a MoC: a mathematical description that has a syntax and rules for
computation of the behavior described by the syntax (semantics). Used to
specify the semantics of computation and concurrency.
A MoC allows:
to capture unambiguously the required functionality.
verify correctness of the functional specification wrt properties
synthesize part of the specification
use different tools all understanding the same model
Why different models?
Need to capture different properties
Some models more powerful, so some problems may be undecidable.

MoCs are a hierarchical collection of processes communicating by events. We

classify MoCs based on how they specify the behavior of processes, how
communicate, how an interconnection of processes can be composed in one
process, how they can be implemented and validated.
 Good Models
Simple
Amenable for development of theory
Theorems allow for generalizations and short-cuts
Should not be too general (theorems become too weak)
High Expressive Power
Compact representation enables higher productivity
Provides Ability for Critical Reasoning
Executable
Simulation/Validation
Synthesizable
Usually requires design orthogonality (e.g. compiler)
Unbiased towards any specific implementation
Extremely hard to achieve, but worth it.
Fit the task at hand
If the model doesnt fit, too much work is needed to use it
 What is Model-Based Design?

1. Create a mathematical model of all the parts of

the embedded system
o Physical world
o Control system
o Software environment
o Hardware platform
o Network
o Sensors and actuators
2. Construct the implementation from the model
o Construction may be automated, like a compiler
o More commonly, portions are automatically constructed
 What is Model-Based Design?

1. Create a mathematical model of all the parts of

the embedded system
o Physical world
o Control system
Different sub-systems,
o Software environment different approaches to
o Hardware platform modeling
o Network
o Sensors and actuators
2. Construct the implementation from the model
o Goal: automate this construction, like a compiler
o In practice, only portions are automatically constructed
 How do the models differ?

State: finite vs. infinite

Time: untimed, continuous time, partial order,
global order
Concurrency: sequential, concurrent
Determinacy: determinate vs. indeterminate
Data value: continuous, sample stream, event
Communication mechanisms
Others: composition, availability of tools etc.
 Modeling Techniques in this Course
Models that are abstractions of system dynamics
(how things change over time)

Examples:
o Modeling physical phenomena ODEs
o Feedback control systems time-domain modeling
o Modeling modal behavior FSMs, hybrid automata
o Modeling sensors and actuators calibration, noise
o Modeling software concurrency, real-time models
o Modeling networks latencies, error rates, packet loss
Modeling of Continuous Dynamics

Ordinary differential equations, Laplace

transforms, feedback control systems, stability
analysis, robustness analysis,
An Example: Modeling Helicopter
Dynamics
 Modeling Physical Motion

Six degrees of freedom:

Position: x, y, z
Orientation: pitch, yaw, roll
Notation
Notation
 Other Modeling Techniques

State machines
sequential decision logic
Synchronous/reactive concurrent composition
concurrent computation
composes well with state machines
Dataflow models
exploitable parallelism
well suited to signal processing
Discrete-event models
explicit about time
Time-driven
suitable for periodic, timed actions
Continuous-time models
models of physical dynamics
extended to hybrid systems to embrace computation
 Key Concepts in Model-Based Design

Models describe physical dynamics.

Specifications are executable models.
Models are composed to form designs.
Models evolve during design.
Deployed code may be (partially) generated from models.
Modeling languages have semantics.
Modeling languages themselves may be modeled (meta
models)

For embedded systems, this is about

Time
Concurrency
Dynamics
Heterogeneous Model Hierarchy

Different Models
composed, often in
hierarchy
Must understand
how models relate
when combined
Sometimes multiple
views (models) of
same subsystem
Circuit and
Simulation model
of Component
 Metrics / Models / Abstractions and
Systematic Analysis
To make progress, we need objective means to evaluate heterogeneous
collections of components, to test and validate correct operation and models
to abstract system complexity.
Models of Computation
Provide metrics on component and system performance
Time, Throughput, Power?
Abstract models as bounds on system behavior
Provable or at least Simulation bound on system correctness
Unfortunately no complete, encompassing, provable model exists
Lots of small provable sub-models: FSM, eFSM, SDL, Kahn Processes
Lots of encompassing but undecidable models: RT-FSM, General Modal Logic
In search of set of generally useful abstractions
Embedded Systems a bit like software compilers in Lisp/Fortran era
 Problem: Implementation Gap
Discard

Discard

FromDevice(0)

DecIPTTL ToDevice(0)

IPVerify

FromDevice(1)

Discard

Discard

FromDevice(2) DecIPTTL ToDevice(1)

IPVerify

Natural
FromDevice(3) Discard

ToDevice(2)

DecIPTTL

Lookup
IPRoute

representation of DecIPTTL

Discard
ToDevice(3)

applications FromDevice(15)

IPVerify
Discard
DecIPTTL

Discard
ToDevice(15)

Discard

Implementation Gap

Low-level
programming
environment
 Modeling, Design, Analysis

Modeling is the process of

gaining a deeper understanding
of a system through imitation.
Models specify what a system does.
Design is the structured creation of artifacts.
It specifies how a system does what it does.
Analysis is the process of gaining a deeper
understanding of a system through dissection.
It specifies why a system does what it does
(or fails to do what a model says it should do).
 Embedded System Design Flow
Modeling
the system, and algorithms involved;
Environ Refining (or partitioning)
-ment
the function into smaller, interacting pieces
Test Bench Design
Abstractions from the Design, Communication,
Storage, and Computation resources
HW-SW partitioning: Allocation
(1) HW
(2) SW
Determine power and performance bounds
Scheduling
When are functions executed
Resource Arbitration
Mapping (Implementing)
(1) software, (2) Hardware,
(3) Coherence/Communication
Testing/Validation
DSP Insitu with Design
Code
 Embedded Platforms

General Purpose Porcessor (GPP) and Graphics

Processing Units (GPU): one processor
architecture for all programs
Field Programmable Gate Array (FPGA):
Program the logic gates to implement your
algorithm.
Application Specific Integrated Circuits(ASIC): A
fully customized chip to implement your system.

How to choose a platform?

 Design Considerations

Design complexity
Performance
Time-to-market
Cost including Non Recurring Engineering
Others: power, signal integrity, testability, etc.
 Assignment 1
Due June 6th
Install CCS and the Texas Instruments tools and
libraries required for project 3 and send a
progress report by Monday Feb 28th.

Laplante: 1.1, 1.2, 1.3, 1.6, 1.8. 1.9

Assumptions can be made, however you should
include a reference to back your assumptions.
 Ungraded assignments

Create an AWS account (for GPU labs)

Download the software needed for project 3.
Get the MSP430 F5529 evaluation kit
Start exploring TI RTOS. Documentation will be
posted on Canvas.

More documentation will be provided on Canvas.