0% found this document useful (0 votes)
6 views25 pages

Chapter 07 - HWSW Co-Design and Prog Modeling

The document discusses two approaches to embedded system development: the traditional approach, which involves early hardware-software partitioning and less interaction between teams, and the hardware-software co-design approach, which focuses on system-level requirements and trade-offs. It also outlines fundamental issues in co-design such as model selection, architecture selection, and language selection, along with various computational models like Data Flow Graph, Control Data Flow Graph, State Machine, and Concurrent Processing Models. Each model serves different purposes in capturing system behavior and requirements, emphasizing the importance of effective partitioning and task management in embedded systems.

Uploaded by

manojsa861854
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views25 pages

Chapter 07 - HWSW Co-Design and Prog Modeling

The document discusses two approaches to embedded system development: the traditional approach, which involves early hardware-software partitioning and less interaction between teams, and the hardware-software co-design approach, which focuses on system-level requirements and trade-offs. It also outlines fundamental issues in co-design such as model selection, architecture selection, and language selection, along with various computational models like Data Flow Graph, Control Data Flow Graph, State Machine, and Concurrent Processing Models. Each model serves different purposes in capturing system behavior and requirements, emphasizing the importance of effective partitioning and task management in embedded systems.

Uploaded by

manojsa861854
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Traditional Embedded System Development Approach

✓ The hardware software partitioning is done at an early stage


✓ Engineers from the software group take care of the software
architecture development and implementation, and engineers from
the hardware group are responsible for building the hardware
required for the product
✓ There is less interaction between the two teams and the
development happens either serially or in parallel and once the
hardware and software are ready, the integration is performed

1
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Hardware Software Co-design Approach for Embedded


System Development
✓ The product requirements captured from the customer are converted into system
level needs or processing requirements rather than partitioning them to either
h/w or s/w
✓ The system level processing requirements are then transferred into functions
which can be simulated and verified against performance and functionality
✓ The Architecture design follows the system design. The partition of system
level processing requirements into hardware and software takes place during the
this phase
✓ Each system level processing requirement is mapped as either hardware and/or
software requirement
✓ The partitioning is performed based on the hardware-software trade-offs

2
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Fundamental issues in H/w S/w Co-design

❑Model Selection
✓ A Model captures and describes the system characteristics
✓ A model is a formal system consisting of objects and composition
rules
✓ It is hard to make a decision on which model should be followed
in a particular system design.
✓ Most often designers switch between a variety of models from the
requirements specification to the implementation aspect of the
system design
✓ The objectives vary with each phase

3
@ McGraw-Hill Education

Architecture Selection
✓ A model only captures the system characteristics and does not
provide information on ‘how the system can be manufactured?’
✓ The architecture specifies how a system is going to implement in
terms of the number and types of different components and the
interconnection among them
✓ Controller architecture,
✓ Datapath Architecture,
✓ Complex Instruction Set Computing (CISC), Reduced Instruction
Set Computing (RISC),
✓ Very long Instruction Word Computing (VLIW),
✓ Single Instruction Multiple Data (SIMD), Multiple Instruction
Multiple Data (MIMD) etc are the commonly used architectures in
system design
4
@ McGraw-Hill Education

Language Selection
✓ A programming Language captures a ‘Computational Model’ and
maps it into architecture
✓ A model can be captured using multiple programming languages
like C, C++, C#, Java etc for software implementations and
languages like VHDL, System C, Verilog etc for hardware
implementations
✓ Certain languages are good in capturing certain computational
model. For example, C++ is a good candidate for capturing an
object oriented model.
✓ The only pre-requisite in selecting a programming language for
capturing a model is that the language should capture the model
easily

5
@ McGraw-Hill Education

Partitioning of System Requirements into H/w and S/w

Implementation aspect of a System level Requirement


✓ It may be possible to implement the system requirements in either
hardware or software (firmware)
✓ Various hardware software trade-offs like performance, re-
usability, effort etc are used for making a decision on the
hardware-software partitioning

6
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design


Data Flow Graph/Diagram (DFG) Model
✓ Translates the data processing requirements into a data flow graph
✓ A data driven model in which the program execution is
determined by data.
✓ Emphasizes on the data and operations on the data which
transforms the input data to output data.
✓ A visual model in which the operation on the data (process) is
represented using a block (circle) and data flow is represented
using arrows. An inward arrow to the process (circle) represents
input data and an outward arrow from the process (circle)
represents output data in DFG notation
✓ Best suited for modeling Embedded systems which are
computational intensive (like DSP applications) 7
@ McGraw-Hill Education

Computational Models in Embedded Design –


Data Flow Graph/Diagram (DFG) Model

E.g. Model the requirement x = a + b; and y = x - c;

Data path: The data flow path from


a b c input to output
A DFG model is said to be acyclic
DFG (ADFG) if it doesn’t contain
multiple values for the input variable
Data Flow Node + and multiple output values for a
given set of input(s). Feedback inputs
x (``is feed back to Input), events etc
are examples for non-acyclic inputs.
A DFG model translates the program
- Data Flow Node as a single sequential process
execution.

y 8
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design

❑Control Data Flow Graph/Diagram (CDFG) Model


✓ Translates the data processing requirements into a data flow graph
✓ Model applications involving conditional program execution
✓ Contains both data operations and control operations
✓ Uses Data Flow Graph (DFG) as element and conditional
(constructs) as decision makers.
✓ CDFG contains both data flow nodes and decision nodes, whereas
DFG contains only data flow nodes

9
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

✓ A visual model in which the operation on the data (process) is


represented using a block (circle) and data flow is represented
using arrows. An inward arrow to the process (circle) represents
input data and an outward arrow from the process (circle)
represents output data in DFG notation.
✓ The control node is represented by a ‘Diamond’ block which is
the decision making element in a normal flow chart based design
✓ Translates the requirement, which is modeled to a concurrent
process model
✓ The decision on which process is to be executed is determined by
the control node

10
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design –


Control Data Flow Graph/Diagram (CDFG) Model
E.g. Model the requirement If flag = 1, x = a + b; else y = a-b;

flag = 1? Control Node

a T b
F

+ Data Flow Node

- Data Flow Node

11
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design

❑State Machine Model


✓ Based on ‘States’ and ‘State Transition’
✓ Describes the system behavior with ‘States’, ‘Events’, ‘Actions’
and ‘Transitions’
✓ State is a representation of a current situation.
✓ An event is an input to the state. The event acts as stimuli for state
transition.
✓ Transition is the movement from one state to another.
✓ Action is an activity to be performed by the state machine.

12
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design

❑State Machine Model


✓ A Finite State Machine (FSM) Model is one in which the number
of states are finite. In other words the system is described using a
finite number of possible states
✓ Most of the time State Machine model translates the requirements
into sequence driven program
✓ The Hierarchical/Concurrent Finite State Machine Model
(HCFSM) is an extension of the FSM for supporting concurrency
and hierarchy

13
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design

❑State Machine Model


✓ HCFSM extends the conventional state diagrams by the AND, OR
decomposition of States together with inter level transitions and a
broadcast mechanism for communicating between concurrent
processes
✓ HCFSM uses statecharts for capturing the states, transitions,
events and actions. The Harel Statechart, UML State diagram etc
are examples for popular statecharts used for the HCFSM
modeling of embedded systems

14
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design – Finite State


Machine (FSM) Model

E.g. Automatic ‘Seat Belt Warning’ in an automotive


Requirement:
▪When the vehicle ignition is turned on and the seat belt is not
fastened within 10 seconds of ignition ON, the system generates an
alarm signal for 5 seconds.
▪The Alarm is turned off when the alarm time (5 seconds) expires or
if the driver/passenger fastens the belt or if the ignition switch is
turned off, whichever happens first.

15
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Ignition Key ON
Alarm
Ignition Key OFF Waiting
Off
A Seat Belt ON
la
rm

ire
Ig Sea Ti

p
ni t m

Ex
tio Be eE

er
n lt xp

m
K O ire

Ti
ey N
O
FF Alarm
On

16
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design

❑Sequential Program Model


✓ The functions or processing requirements are executed in
sequence
✓ The program instructions are iterated and executed conditionally
and the data gets transformed through a series of operations
✓ FSMs are good choice for sequential Program modeling.
✓ Flow Charts is another important tool used for modeling
sequential program
✓ The FSM approach represents the states, events, transitions and
actions, whereas the Flow Chart models the execution flow

17
@ McGraw-Hill Education

Computational Models in Embedded Design –Sequential


Program Model

E.g. Automatic ‘Seat Belt Warning’ in an automotive


Requirement:
▪When the vehicle ignition is turned on and the seat belt is not
fastened within 10 seconds of ignition ON, the system generates
an alarm signal for 5 seconds.
▪The Alarm is turned off when the alarm time (5 seconds)
expires or if the driver/passenger fastens the belt or if the
ignition switch is turned off, whichever happens first.

18
@ McGraw-Hill Education
Ignition Key ON
Hardware Software Co-Design and Program Modeling
Wait for 10 Seconds

Ignitiont ON?

Y
Seat Belt ON?

N
Set Timer for 5 Seconds
Start Alarm

Ignition ON

NO
Y

YES
NO Seat Belt ON?
N

Timer Expired? YES


Y

Stop Alarm

19
End
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design –Sequential Program Model
E.g. Automatic ‘Seat Belt Warning’ in an automotive

#define ON 1
#define OFF 0
#define YES 1
#define NO 0
void seat_belt_warn()
{
wait_10sec();
if (check_ignition_key()==ON)
{
if (check_seat_belt()==OFF)
{
set_timer(5);
start_alarm();
while ((check_seat_belt()==OFF )&&(check_ignition_key()==OFF )&&
(timer_expire()==NO));
stop_alarm();
}
} 20

}
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design
❑Concurrent/Communicating Process Model
✓ Models concurrently executing tasks/processes The program
instructions are iterated and executed conditionally, and the data
gets transformed through a series of operations
✓ Certain processing requirements are easier to model in concurrent
processing model than the conventional sequential execution.
✓ Sequential execution leads to a single sequential execution of task
and thereby leads to poor processor utilization, when the task
involves I/O waiting, sleeping for specified duration etc.
✓ If the task is split into multiple subtasks, it is possible to tackle the
CPU usage effectively, when the subtask under execution goes to
a wait or sleep mode, by switching the task execution.
✓ Concurrent processing model requires additional overheads in task21
scheduling, task synchronization and communication
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design – Concurrent Processing
Model
E.g. Automatic ‘Seat Belt Warning’ in an automotive

Create and initialize events


wait_timer_expire, ignition_on, ignition_off,
seat_belt_on, seat_belt_off,
alarm_timer_start, alarm_timer_expire
Create task Wait Timer
Create task Ignition Key Status Monitor
Create task Seat Belt Status Monitor
Create task Alarm Control
Create task Alarm Timer

(a)

22
@ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling


Computational Models in Embedded Design – Concurrent Processing Model
E.g. Automatic ‘Seat Belt Warning’ in an automotive
Wait Timer Task Alarm Control Task Alarm Timer Task
Sleep(10s); Wait for the signaling of Wait for the Event alarm_start;
//Signal wait_timer_expire wait_timer_expire Sleep(5s);
Set Event wait_timer_expire; if (ignition_on && seat_belt_off) //Signal alarm_timer_expire
{ Set Event alarm_timer_expire;
Start Alarm();
Set Event alarm_start;
Ignition Key Status Monitor Wait for the signaling of
Task alarm_timer_expire or
while(1) { ignition_off or seat_belt_on;
if (Ignition key ON) Stop Alarm();
{ }
Set Event ignition_on;
Reset Event ignition_off;
} Ignition Seat belt Status Monitor
else Task
{ while(1) {
ignition_off;
Set Event if (Seat Belt ON)
Reset Event ignition_on; {
} Set Event seat_belt_on;
} Reset Event seat_belt_off;
}
else
{
seat_belt_off;
Set Event
Reset Event seat_belt_on;
}
}

(b) 23
@ McGraw-Hill Education

✓The processing requirements are split in to multiple tasks


✓Tasks are executed concurrently
✓‘Events’ are used for synchronizing the execution of tasks

24
@ McGraw-Hill Education

25

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy