Thanks to visit codestin.com
Credit goes to www.scribd.com

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

Embedded Systems Design Guide

Uploaded by

Gururaj .d
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)
37 views25 pages

Embedded Systems Design Guide

Uploaded by

Gururaj .d
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

STUDY MATERIAL

ON
ARM MICROCONTROLLER & EMBEDDED
SYSTEMS
(21EC62)
VVCE AUTONOMOUS 2021 SCHEME

MODULE 04
Embedded System Design Components

Version: 1.0
Release Date: 27th June 2024

by
MOHAMED ANEES
Assistant Professor
Department of Electronics & Communication
Vidyavardhaka College of Engineering, Mysore
ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

TABLE OF CONTENTS

1.0 CHARACTERISTICS & QUALITY ATTRIBUTES OF AN EMBEDDED


SYSTEMS ................................................................................................................................. 3
1.1 CHARACTERISTICS OF AN EMBEDDED SYSTEMS .................................................... 3
1.1.1 APPLICATION AND DOMAIN SPECIFIC ................................................................................. 3
1.1.2 REACTIVE AND REAL-TIME..................................................................................................... 3
1.1.3 OPERATES IN HARSH ENVIRONMENTS ................................................................................ 4
1.1.4 DISTRIBUTED .............................................................................................................................. 4
1.1.5 SMALL SIZE AND WEIGHT ....................................................................................................... 5
1.1.6 POWER CONCERNS .................................................................................................................... 5
1.2 QUALITY ATTRIBUTES OF AN EMBEDDED SYSTEMS ............................................. 6
1.2.1 OPERATIONAL QUALITY ATTRIBUTES................................................................................. 6
1.2.2 NON-OPERATIONAL QUALITY ATTRIBUTES ....................................................................... 9

2.0 DOMAIN SPECIFIC EXAMPLES OF EMBEDDED SYSTEM ......................... 11


2.1 CASE STUDY OF WASHING MACHINE ....................................................................... 11
2.2 AUTOMOTIVE–DOMAIN SPECIFIC EXAMPLES ........................................................ 13
3.0 HARDWARE SOFTWARE CO-DESIGN .............................................................. 16
3.1 FUNDAMENTAL ISSUES IN HARDWARE SOFTWARE CO-DESIGN ...................... 16
3.1.1 SELECTING THE MODEL ......................................................................................................... 16
3.1.2 SELECTING THE ARCHITECTURE ......................................................................................... 16
3.1.3 SELECTING THE LANGUAGE ................................................................................................. 18
3.1.4 PARTIONING SYSTEM REQUIREMENTS INTO HARDWARE & SOFTWARE ................. 18
3.2 COMPUTATIONAL MODELS IN EMBEDDED DESIGN ............................................. 19
3.2.1 DATA FLOW GRAPH/DIAGRAM (DFG) MODEL .................................................................. 19
3.2.2 CONTROL DATA FLOW GRAPH/DIAGRAM (CDFG) .......................................................... 20
3.2.3 STATE MACHINE MODEL ....................................................................................................... 21
3.2.4 SEQUENTIAL PROGRAM MODEL .......................................................................................... 25

Dept. of E&CE 2 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.0 CHARACTERISTICS & QUALITY ATTRIBUTES OF AN


EMBEDDED SYSTEMS

1.1 CHARACTERISTICS OF AN EMBEDDED SYSTEMS


1.1.1 APPLICATION AND DOMAIN SPECIFIC
• Embedded systems is designed for specific applications only and cannot be used
for any other purpose. This is the major difference between embedded systems
and general-purpose systems.
• For example, one cannot replace the embedded control unit of your microwave
oven with air conditioner’s embedded control unit, because the embedded control
units of microwave oven and air conditioner are specifically designed to perform
certain specific tasks.

1.1.2 REACTIVE AND REAL-TIME


Reactive Systems
• Embedded systems are in constant interaction with the Real world through
sensors and user-defined input devices which are connected to the input port of
the system.
• Any changes happening in the Real world (which is called an Event) are captured
by the sensors or input devices in Real Time and the control algorithm running
inside the unit reacts in a designed manner. The event may be a periodic or an
aperiodic. In case if it is aperiodic, one cannot miss the data.
• Embedded systems produce changes in output in response to the changes in the
input. So they are generally referred to as Reactive Systems.

Real Time Systems


• Real Time System operation means the timing behaviour of the system should be
deterministic; meaning the system should respond to requests or tasks in a
known amount of time.
• A Real Time system should not miss any deadlines for tasks or operations.
• It is not necessary that all embedded systems should be Real Time in operations.
• Embedded applications or systems which are mission critical, like flight control
systems, Antilock Brake Systems (ABS), etc. are examples of Real Time systems.
• The design of an embedded Real time system should take the worst-case
scenario into consideration.

Dept. of E&CE 3 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.1.3 OPERATES IN HARSH ENVIRONMENTS


• It is not necessary that all embedded systems should be deployed in controlled
environments. The environment in which the embedded system deployed may be
a dusty or a high temperature zone or an area subject to vibrations and
shock.
• Systems placed in such areas should be capable of withstanding all these adverse
operating conditions. The designer should take care of the operating conditions of
the area where the system is going to be implemented.
• For example, if the system needs to be deployed in a high temperature zone, then
all the components used in the system should be of high temperature grade. Here
we cannot go to a compromise in cost.
• Power supply fluctuations, corrosion and component aging, etc. are the other
factors that need to be taken into consideration for embedded systems to work in
harsh environments.

1.1.4 DISTRIBUTED
• The term distributed means that embedded systems may be a part of larger
systems. Many numbers of such distributed embedded systems form a single
large, embedded control unit.
• Example 1:
An automatic vending machine is a typical example of this. The vending machine
contains a card reader (for pre-paid vending systems), a vending unit, etc. Each of
them are independent embedded units but they work together to perform the
overall vending function.
• Example 2:
Another example is the Automatic Teller Machine (ATM). An ATM contains a
card reader embedded unit, responsible for reading and validating the user’s ATM
card, transaction unit for performing transactions, a currency counter for
dispatching/vending currency to the authorized person and a printer unit for
printing the transaction details. We can visualize these as independent embedded
systems. But they work together to achieve a common goal.

Dept. of E&CE 4 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.1.5 SMALL SIZE AND WEIGHT


• Product aesthetics is an important factor in choosing a product.
• For example, when you plan to buy a new mobile phone, you may make a
comparative study on the pros and cons of the products available in the market.
Definitely the product aesthetics (size, weight, shape, style, etc.) will be one of
the deciding factors to choose a product. People believe in the phrase “Small is
beautiful”.
• Moreover it is more convenient to handle a compact device than a bulky product.
In embedded domain also compactness is a significant deciding factor. Most of
the applications demand small sized and low weight products.

1.1.6 POWER CONCERNS


• Power management is another important factor that needs to be considered in
designing embedded systems.
• Embedded systems should be designed in such a way as to minimize the heat
dissipation by the system.
• The production of high amount of heat demands cooling requirements like
cooling fans which in turn occupies additional space and make the system bulky.
• Nowadays ultra-low power components are available in the market. Select the
design according to the low power components like low dropout regulators, and
controllers/processors with power saving modes.
• Also power management is a critical constraint in battery operated applications.
The more the power consumption the less is the battery life.

Dept. of E&CE 5 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.2 QUALITY ATTRIBUTES OF AN EMBEDDED SYSTEMS

1.2.1 OPERATIONAL QUALITY ATTRIBUTES


The operational quality attributes represent the relevant quality attributes related to
the Embedded System when it is in the operational mode or ‘online’ mode.

1.2.1.1 RESPONSE
• Response is a measure of quickness of the system. It is a way to measure how
fast your system is tracking the changes in input variables. Most of the
embedded systems demand fast response which should be almost Real Time.

• For example, an embedded system deployed in flight control application should


respond in a Real Time manner. Any response delay in the system will create
potential impact to the safety of the flight as well as the passengers.

• It is not necessary that all embedded systems should be Real Time in response.
For example, the response time requirement for an electronic toy is not at all
time critical. There is no specific deadline that this system should respond
within this timeline.

1.2.1.2 THROUGHPUT
• Throughput deals with the efficiency of a system. In general, it can be defined
as the rate of production or operation of a defined process over a stated period.
The rates can be expressed in terms of units of products, batches produced, or
any other meaningful measurements.

• In the case of a Card Reader, throughput means how many transactions the
Reader can perform in a minute or in an hour or in a day.

• Throughput is generally measured in terms of ‘Benchmark’. A ‘Benchmark’


is a reference point by which something can be measured. Benchmark can be a
set of performance criteria that a product is expected to meet or a standard
product that can be used for comparing other products of the same product line.

Dept. of E&CE 6 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.2.1.3 RELIABILITY
• Reliability is a measure of how much % you can rely upon the proper
functioning of the system or what is the % susceptibility of the system to
failures. Mean Time Between Failures (MTBF) and Mean Time To Repair (
MTTR) are the terms used in defining system reliability.
• MTBF gives the frequency of failures in hours/weeks/months.
• MTTR specifies how long the system is allowed to be out of order following a
failure. For an embedded system with critical application need, it should be of
the order of minutes.

1.2.1.4 MAINTAINABILITY
• Maintainability deals with support and maintenance to the end user or client
in case of technical issues and product failures or based on a routine system
check-up.
• A more reliable system means a system with less corrective maintainability
requirements and vice versa. As the reliability of the system increases, the
chances of failure and non-functioning also reduces, thereby the need for
maintainability is also reduced.
• Maintainability can be broadly classified into two categories, namely,
a) ‘Scheduled or Periodic Maintenance (preventive maintenance)’
An inkjet printer uses ink cartridges, which are consumable components
and as per the printer manufacturer the end user should replace the cartridge
after each ‘n’ number of printouts to get quality prints. This is an example
for ‘Scheduled or Periodic maintenance’.
b) ‘Maintenance to unexpected failures (corrective maintenance)’
If the paper feeding part of the printer fails, the printer fails to print, and it
requires immediate repairs to rectify this problem. This is an example of
‘Maintenance to unexpected failure’.
• In any embedded system design, the ideal value for availability is expressed as
𝐌𝐓𝐁𝐅
𝐀𝐢 =
𝐌𝐓𝐁𝐅 + 𝐌𝐓𝐓𝐑

where Ai = Availability in the ideal condition


MTBF = Mean Time Between Failures
MTTR = Mean Time To Repair

Dept. of E&CE 7 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.2.1.5 SECURITY
• ‘Confidentiality’, ‘Integrity’, and ‘Availability’ are the three major measures of
information security.
• Confidentiality deals with the protection of data and application from
unauthorised disclosure.
• Integrity deals with the protection of data and application from unauthorised
modification.
• Availability deals with protection of data and application from unauthorised
users.
• Example: Personal Digital Assistant (PDA)
- The PDA can be either a shared resource (e.g., PDAs used in LAB setups) or
an individual one.
- If it is a shared one there should be some mechanism in the form of a user
name and password to access into a particular person’s profile–This is an
example of ‘Availability’.
- Also, all data and applications present in the PDA need not be accessible to
all users. Some of them are specifically accessible to administrators only. For
achieving this, Administrator and user levels of security should be
implemented –An example of Confidentiality.
- Some data present in the PDA may be visible to all users but there may not
be necessary permissions to alter the data by the users. That is Read Only
access is allocated to all users–An example of Integrity.

1.2.1.6 SAFETY
• Safety deals with the possible damage that can happen to the operators, public
and the environment due to the breakdown of an embedded system or due to the
emission of radioactive or hazardous materials from the embedded products.
• The breakdown of an embedded system may occur due to a hardware failure or
a firmware failure.
• Safety analysis is a must in product engineering to evaluate the anticipated
damages and determine the best course of action to bring down the
consequences of the damages to an acceptable level. As stated before, some of
the safety threats are sudden (like product breakdown) and some of them are
gradual (like hazardous emissions from the product).

Dept. of E&CE 8 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.2.2 NON-OPERATIONAL QUALITY ATTRIBUTES

1.2.2.1 TESTABILITY & DEBUG-ABILITY


• Testability deals with how easily one can test the design, application and by
which means one can test it. For an embedded product, testability is applicable
to both the embedded hardware and firmware.
- Embedded hardware testing ensures that the peripherals and the total
hardware functions in the desired manner.
- Firmware testing ensures that the firmware is functioning in the expected
way.
• Debug-ability has two aspects in the embedded system development context,
namely, hardware level debugging and firmware level debugging.
- Hardware debugging is used for figuring out the issues created by hardware
problems.
- Firmware debugging is employed to figure out the probable errors that
appear because of flaws in the firmware.

1.2.2.2 EVOLVABILITY
For an embedded system, the quality attribute ‘Evolvability’ refers to the ease with
which the embedded product (including firmware and hardware) can be modified to
take advantage of new firmware or hardware technologies.

1.2.2.3 PORTABILITY
• Portability is a measure of ‘system independence’. An embedded product is said
to be portable if the product is capable of functioning ‘as such’ in various
environments, target processors/controllers and embedded operating systems.
• The ease with which an embedded product can be ported on to a new platform is
a direct measure of the re-work required.
• A standard embedded product should always be flexible and portable.
• In embedded products, the term ‘porting’ represents the migration of the
embedded firmware written for one target processor (e.g., Intel x86) to a different
target processor (say an ARM Cortex M3 processor from Freescale).

Dept. of E&CE 9 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

1.2.2.4 TIME TO PROTOTYPE AND MARKET


• Time-to-market is the time elapsed between the conceptualisation of a product
and the time at which the product is ready for selling (for commercial product)
or use (for non-commercial products).
• The commercial embedded product market is highly competitive and time to
market the product is a critical factor in the success of a commercial embedded
product. There may be multiple players in the embedded industry who develop
products of the same category (like mobile phone, portable media players, etc.).
• If you come up with a new design and if it takes long time to develop and
market it, the competitor product may take advantage of it with their product.
• Also, embedded technology is one where rapid technology change is happening.
If you start your design by making use of a new technology and if it takes long
time to develop and market the product, by the time you market the product, the
technology might have superseded with a new technology.
• Product prototyping helps a lot in reducing time-to-market. Prototyping is an
informal kind of rapid product development in which the important features of
the product under consideration are developed. If the prototype is developed
faster, the actual estimated development time can be brought down significantly.

1.2.2.5 PER UNIT AND TOTAL COST


• Cost is a factor which is closely monitored by both end user and product
manufacturer.
• Cost is a highly sensitive factor for commercial products. Any failure to position
the cost of a commercial product at a nominal rate may lead to the failure of the
product in the market.
• A proper market study and cost-benefit analysis should be carried out before
taking a decision on the per-unit cost of the embedded product.
• From a designer/product development company perspective the ultimate aim of
a product is to generate marginal profit. So the budget and total system cost
should be properly balanced to provide a marginal profit.

Dept. of E&CE 10 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

2.0 DOMAIN SPECIFIC EXAMPLES OF EMBEDDED SYSTEM

2.1 CASE STUDY OF WASHING MACHINE


• A washing machine is a typical example of an embedded system providing
extensive support in home automation applications.
• The functional block diagram of a washing machine is shown in Fig.

Fig.: Functional block diagram of washing machine

Mechanical Design
• The actuator part of the washing machine consists of a motorized agitator,
tumble tub, water drawing pump and inlet valve to control the flow of water
into the unit.
• The mechanism includes the motor, transmission, clutch, pump, agitator,
inner-tub, outer tub and water inlet valve.
• The water inlet valve connects to the water supply line used at home and
regulates the flow of water into the tub.

Sensors
• The sensor part consists of the water temperature sensor, level sensor, etc.

Dept. of E&CE 11 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

Control Unit
• The control part contains a microcontroller-based board with interfaces to the sensors
and actuators. The integrated control panel consists of a microprocessor/controller-
based board with I/O interfaces and a control algorithm running in it.
• The sensor data is fed back to the control unit and the control unit generates the
necessary actuator outputs. The control unit also provides connectivity to user interfaces
like keypad for setting the washing time, selecting the type of material to be washed
like light, medium, heavy duty, etc.
• The basic controls consist of a timer, cycle selector mechanism, water temperature
selector, load size selector and start button.

User Interfaces
• User feedback is reflected through the display unit and LEDs connected to the
control board.
• Input interface includes the keyboard which consists of wash type selector namely*
Wash, Spin and Rinse, cloth type selector namely* Light, Medium, Heavy duty, and
washing time setting, etc.
• The output interface consists of LED/LCD displays, status indication LEDs, etc.
connected to the I/O bus of the controller.

Phases of Washing
• First Phase – Washing
- Washing machines come in different designs, like top loading and front-loading
machines.
- In top loading models the agitator of the machine twists back and forth and pulls
the cloth down to the bottom of the tub. On reaching the bottom of the tub the
clothes work their way back up to the top of the tub where the agitator grabs
them again and repeats the mechanism.
- In the front-loading machines, the clothes are tumbled and plunged into the
water over and over again.

• Second Phase – Spin


- In the second phase of washing, water is pumped out from the tub and the inner
tub uses centrifugal force to wring out more water from the clothes by spinning
at several hundred Rotations Per Minute (RPM). This is called a ‘Spin Phase’.

• Third Phase – Rinse and Drain


- The inner tub of the machine contains a number of holes and during the spin
cycle the inner tub spins and forces the water out through these holes to the
stationary outer tub from which it is drained off through the outlet pipe.

Dept. of E&CE 12 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

2.2 AUTOMOTIVE–DOMAIN SPECIFIC EXAMPLES

Inner Workings of Automotive Embedded Systems


• Automotive embedded systems are the ones where electronics take control over the
mechanical and electrical systems. Figure gives an overview of the various types of
electronic control units employed in automotive applications.

• Automotive embedded systems are normally built around microcontrollers or DSPs


or a hybrid of the two and are generally known as Electronic Control Units
(ECUs).

• The number of embedded controllers in an ordinary vehicle varies from 20 to 40


whereas a luxury vehicle like Mercedes S and BMW 7 may contain over 100
embedded controllers.

• Government regulations on fuel economy, environmental factors and emission


standards and increasing customer demands on safety, comfort and infotainment
forces the automotive manufactures to opt for sophisticated embedded control units
within the vehicle.

• The various types of electronic control units (ECUs) used in the automotive
embedded industry can be broadly classified into two – High-speed embedded
control units and Low-speed embedded control units.
- High-speed Electronic Control Units (HECUs) are deployed in critical
control units requiring fast response. They include fuel injection systems,
antilock brake systems, engine control, electronic throttle, steering controls,
transmission control unit and central control unit.

Dept. of E&CE 13 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

- Low-Speed Electronic Control Units ( LECUs) are deployed in applications


where response time is not so critical. They generally are built around low-cost
microcontrollers and digital signal processors. Audio controllers, passenger
and driver door locks, door glass controls (power windows), wiper control,
mirror control, seat control systems, head lamp and tail lamp controls, sunroof
control unit, etc. are examples of LECUs.

Automotive Communication Buses


Automotive applications make use of serial buses for communication, which greatly
reduces the amount of wiring required inside a vehicle. The different types of serial
interface buses deployed in automotive embedded applications are as follows:

a) Controller Area Network (CAN)


- The CAN bus was originally proposed by Robert Bosch, pioneer in the
Automotive embedded solution providers.
- It supports medium speed (ISO11519-class B with data rates up to 125 Kbps)
and high speed (ISO11898 class C with data rates up to 1Mbps) data transfer.
- CAN is an event-driven protocol interface with support for error handling in
data transmission.
- It is generally employed in safety systems like airbag control; power train
systems like engine control and Antilock Brake System (ABS); and navigation
systems like GPS.

b) Local Interconnect Network (LIN)


- LIN bus is a single master multiple slave (up to 16 independent slave nodes)
communication interface.
- LIN is a low speed, single wire communication interface with support for data
rates up to 20 Kbps and is used for sensor/actuator interfacing.
- LIN bus follows the master communication triggering technique to eliminate the
possible bus arbitration problem that can occur by the simultaneous talking of
different slave nodes connected to a single interface bus.
- LIN bus is employed in applications like mirror controls, fan controls, seat
positioning controls, window controls, and position controls where response
time is not a critical issue.

Dept. of E&CE 14 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

c) Media Oriented System Transport (MOST) Bus


- The Media Oriented System Transport (MOST) is targeted for high-bandwidth
automotive multimedia networking (e.g. audio/video, infotainment system
interfacing), used primarily in European cars.
- A MOST bus is a multimedia fibre optic point-to-point network implemented in
a star, ring or daisy-chained topology over optical fibre cables.
- The MOST bus specifications define the physical (electrical and optical
parameters) layer as well as the application layer, network layer, and media
access control.
- MOST bus is an optical fibre cable connected between the Electrical Optical
Converter (EOC) and Optical Electrical Converter (OEC), which would
translate into the optical cable MOST bus.

Dept. of E&CE 15 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.0 HARDWARE SOFTWARE CO-DESIGN

3.1 FUNDAMENTAL ISSUES IN HARDWARE SOFTWARE CO-DESIGN


The hardware software co-design is a problem statement and when we try to solve this
problem statement in real life, we may come across multiple issues in the design. The
following section illustrates some of the fundamental issues in hardware software co-
design.

3.1.1 SELECTING THE MODEL


• In hardware software co-design, models are used for capturing and describing
the system characteristics.
• A model is a formal system consisting of objects and composition rules. It is
hard to decide 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 reason
being the objective varies with each phase.
• For example at the specification stage, only the functionality of the system is in
focus and not the implementation information. When the design moves to the
implementation aspect, the information about the system components is
revealed and the designer has to switch to a model capable of capturing the
system’s structure.

3.1.2 SELECTING THE ARCHITECTURE


The architecture specifies how a system is going to be implemented 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.

a) Controller Architecture
The Controller Architecture implements the finite state machine model using a state
register and two combinational circuits. The state register holds the present state
and the combinational circuits implement the logic for the next state and output.

Dept. of E&CE 16 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

b) Datapath Architecture
• The Datapath Architecture is best suited for implementing the data flow graph
model where the output is generated as a result of a set of predefined
computations on the input data. A datapath represents a channel between the
input and output.
• In datapath architecture the datapath may contain registers, counters, register
files, memories and ports along with high-speed arithmetic units. Ports connect
the datapath to multiple buses. Most of the time the arithmetic units are connected
in parallel with pipelining support for bringing high performance.

c) Finite State Machine Datapath (FSMD)


• The Finite State Machine Datapath (FSMD) architecture combines the
controller architecture with datapath architecture. It implements a
controller with datapath.
• The controller generates the control input whereas the datapath processes the
data.
• The datapath contains two types of I/O ports.
- One acts as the control port for receiving/sending the control signals
from/to the controller unit.
- Second, I/O port interfaces the datapath with external world for data
input and data output.
• Normally the datapath is implemented in a chip and the I/O pins of the chip act
as the data input output ports for the chip resident data path.
d) Complex Instruction Set Computing (CISC) Architecture
• The Complex Instruction Set Computing (CISC) architecture uses an instruction
set representing complex operations. It is possible for a CISC instruction set to
perform a large complex operation with a single instruction.
• The use of a single complex instruction in place of multiple simple instructions
greatly reduces the program memory access and program memory size
requirement. However it requires additional silicon for implementing microcode
decoder for decoding the CISC instruction. The datapath for the CISC processor
is complex.
• On the other hand, RISC architecture uses instruction set representing simple
operations and it requires the execution of multiple RISC instructions to perform
a complex operation. The data path of RISC architecture contains a large register

Dept. of E&CE 17 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

file for storing the operands and output. RISC instruction set is designed to
operate on registers. RISC architecture supports extensive pipelining.

e) Very Long Instruction Word ( VLIW)


The Very Long Instruction Word (VLIW) architecture implements multiple functional
units (ALUs, multipliers, etc.) in the datapath. The VLIW instruction packages one
standard instruction per functional unit of the datapath.

f) Parallel processing architecture


• Parallel processing architecture implements multiple concurrent Processing
Elements (PEs) and each processing element may associate a datapath containing
register and local memory.
• Single Instruction Multiple Data (SIMD) and Multiple Instruction Multiple
Data (MIMD) architectures are examples for parallel processing architecture.
• In SIMD architecture, a single instruction is executed in parallel with the help of
the Processing Elements. On the other hand, the processing elements of the
MIMD architecture execute different instructions at a given point of time.

3.1.3 SELECTING THE LANGUAGE


• A programming language captures a ‘Computational Model’ and maps it into
architecture. There is no hard and fast rule to specify this language should be
used for capturing this model.
• 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.

3.1.4 PARTIONING SYSTEM REQUIREMENTS INTO HARDWARE &


SOFTWARE
So far, we have discussed the models for capturing the system requirements and the
architecture for implementing the system. From an implementation perspective, it may
be possible to implement the system requirements in either hardware or software
(firmware). It is a tough decision-making task to figure out which one to opt for.
Various hardware software trade-offs are used for deciding on the hardware-software
partitioning. We will discuss them in detail in a later section of this chapter.

Dept. of E&CE 18 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.2 COMPUTATIONAL MODELS IN EMBEDDED DESIGN


Data Flow Graph (DFG) model, State Machine model, Concurrent Process model,
Sequential Program model, Object Oriented model, etc. are the commonly used
computational models in embedded system design.

3.2.1 DATA FLOW GRAPH/DIAGRAM (DFG) MODEL


• The Data Flow Graph ( DFG) model translates the data processing requirements
into a data flow graph.
• The Data Flow Graph (DFG) model is a data driven model in which the
program execution is determined by data.
• This model emphasizes on the data and operations on the data which
transforms the input data to output data.
• Operation on the data (process) is represented using a block (circle).
• 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.
• Example: DSP applications typically use the DFG model.
• Suppose one of the functions in an application contains the computational
requirement 𝒙 = 𝒂 + 𝒃 and 𝒚 = 𝒙 − 𝒄. Figure illustrates the implementation of a
DFG model for implementing these requirements.

Fig. Data Flow Graph (DFG) Model


• In a DFG model, a data path is the data flow path from input to output.
• A DFG model is said to be acyclic DFG (ADFG) if it doesn’t contain multiple
values for the input variable and multiple output values for a given set of input(s).
• Feedback inputs (Output is fed back to Input), events, etc. are examples of non-
acyclic inputs.
• A DFG model translates the program as a single sequential process execution.

Dept. of E&CE 19 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.2.2 CONTROL DATA FLOW GRAPH/DIAGRAM (CDFG)


• The Control DFG (CDFG) model is used for modelling applications involving
conditional program execution.
• CDFG models contains both data operations and control operations.
• The CDFG 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.
• Let us have a look at the implementation of the CDFG for the following
requirement.
If 𝑓𝑙𝑎𝑔 = 1, 𝒙 = 𝒂 + 𝒃; else 𝒚 = 𝒂 − 𝒃; The CDFG model is as shown in fig.

Fig.: Control Data Flow Graph (CDFG) Model

• Real-world Example - Capturing and saving of the image to a format set by the
user in a digital still camera.
- Analog Front End converts the CCD sensor generated analog signal to
Digital Signal.
- The decision on in which format the image is stored (formats like JPEG,
TIFF, BMP, etc.) is controlled by the camera settings, configured by the
user.

Dept. of E&CE 20 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.2.3 STATE MACHINE MODEL


• The State Machine model is used for modelling reactive or event-driven
embedded systems whose processing behaviour are dependent on state
transitions.
• The State Machine model describes the system behaviour 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.
• A Finite State Machine (FSM) model is one in which the number of states are
finite.
3.2.3.1 FSM MODEL FOR AUTOMATIC SEAT BELT WARNING SYSTEM
• Consider the design of an embedded system for driver/passenger ‘Seat Belt
Warning’ in an automotive using the FSM model.
• The system requirements are captured as.
1. 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.
2. 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.
• States are ‘Alarm Off’, ‘Waiting’ and ‘Alarm On’.
• Events are ‘Ignition Key ON’ ‘Ignition Key OFF’, ’10 Sec Timer Expire’,
‘Alarm Time Expire’ and ‘Seat Belt ON’.
• Using the FSM, the system requirements can be modelled as given in Fig.

Fig.: FSM Model for Automatic Seat Belt Warning System


Dept. of E&CE 21 VVCE Mysore
ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

• The ‘Ignition Key ON’ event triggers the 10 second timer and transitions the
state to ‘Waiting’.
• If a ‘Seat Belt ON’ or ‘Ignition Key OFF’ event occurs during the wait state,
the state transitions into ‘Alarm OFF’.
• When the wait timer expires in the waiting state, the event ‘Timer Expire’ is
generated and it transitions the state to ‘Alarm ON’ from the ‘Waiting’ state.
• The ‘Alarm ON’ state continues until a ‘Seat Belt ON’ or ‘Ignition Key
OFF’ event or ‘Alarm Time Expire’ event, whichever occurs first.
• The occurrence of any of these events transitions the state to ‘Alarm OFF’.
The wait state is implemented using a timer.
• The timer also has certain set of states and events for state transitions. Using
the FSM model, the timer can be modelled as shown in Fig.

Fig.: FSM Model for Timer

• As seen from the FSM, the timer state can be either ‘IDLE’ or ‘READY’ or
‘RUNNING’.
• During the normal condition when the timer is not running, it is said to be in
the ‘IDLE’ state. The timer is said to be in the ‘READY’ state when the timer
is loaded with the count corresponding to the required time delay.
• The timer remains in the ‘READY’ state until a ‘Start Timer’ event occurs.
• The timer changes its state to ‘RUNNING’ from the ‘READY’ state on
receiving a ‘Start Timer’ event and remains in the ‘RUNNING’ state until
the timer count expires, or a ‘Stop Timer’ even occurs.
• The timer state changes to ‘IDLE’ from ‘RUNNING’ on receiving a ‘Stop
Timer’ or ‘Timer Expire’ event.

Dept. of E&CE 22 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.2.3.2 FSM MODEL FOR TEA/COFFEE VENDING MACHINE


Design an automatic tea/coffee vending machine based on FSM model for the
following requirement.
a) The tea/coffee vending is initiated by user inserting a 5-rupee coin.
b) After inserting the coin, the user can either select ‘Coffee’ or ‘Tea’ or press
‘Cancel’ to cancel the order and take back the coin.
Solution:
The FSM representation for the above requirement is given in Fig. 7.5.

Fig.: FSM Model for Automatic Tea\Coffee Vending Machine

• It contains four states namely; ‘Wait for coin’ ‘Wait for User Input’,
‘Dispense Tea’ and ‘Dispense Coffee’.
• The event ‘Insert Coin’ (5-rupee coin insertion) transitions the state to ‘Wait
for User Input’.
• The system stays in this state until a user input is received from the buttons
‘Cancel’, ‘Tea’ or ‘Coffee’ (Tea and Coffee are the drink select button).
• If the event triggered in ‘Wait State’ is ‘Cancel’ button press, the coin is
pushed out and the state transitions to ‘Wait for Coin’.
• If the event received in the ‘Wait State’ is either ‘Tea’ button press, or ‘Coffee’
button press, the state changes to ‘Dispense Tea’ and ‘Dispense Coffee’
respectively.
• Once the coffee/tea vending is over, the respective states transitions back to the
‘Wait for Coin’ state.
• The FSM model can be re-designed by adding timeout for the wait-state. If no
user input is received within the timeout period, the coin is returned back and
the state automatically transitions to ‘Wait for Coin’ on the timeout event.

Dept. of E&CE 23 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.2.3.3 FSM MODEL FOR COIN OPERATED TELEPHONE SYSTEM


Design a coin operated public telephone unit based on FSM model for the
following requirements.
1. The calling process is initiated by lifting the receiver (off-hook) of the
telephone unit
2. After lifting the phone, the user needs to insert a 1-rupee coin to make
the call.
3. If the line is busy, the coin is returned on placing the receiver back on
the hook (on-hook).
4. If the line is through, the user is allowed to talk till 60 seconds and at the
end of 45th second, prompt for inserting another 1-rupee coin for
continuing the call is initiated.
5. If the user doesn’t insert another 1-rupee coin, the call is terminated on
completing the 60 seconds time slot.
6. The system is ready to accept new call request when the receiver is
placed back on the hook (on-hook).
7. The system goes to the ‘Out of Order’ state when there is a line fault.

Solution:
The FSM model shown in Fig. 7.6, is a simple representation and it doesn’t take care
of scenarios like, user doesn’t insert a coin within the specified time after lifting the
receiver, user inserts coins other than a one rupee etc.

Fig.: FSM Model for Coin Operated Telephone System

Dept. of E&CE 24 VVCE Mysore


ARM MICROCONTROLLER & EMBEDDED SYSTEMS (21EC62)

3.2.4 SEQUENTIAL PROGRAM MODEL


• In the Sequential Programming Model, the functions or processing requirements
are executed in sequence.
• It is same as the conventional procedural programming. Here the program
instructions are iterated and executed conditionally and the data gets transformed
through a series of operations.
• FSMs are a good choice for sequential program modelling. Another important
tool used for modelling sequential programs is Flow Charts.
• Figure illustrates the flow chart approach for modelling the ‘Seat Belt Warning’
system discussed in section 3.2.3.1

Fig.: Sequential Program Model for seat belt warning system

Dept. of E&CE 25 VVCE Mysore

You might also like