EC6703 unit-4

EC6703
EMBEDDED AND REAL
TIME SYSTEMS

UNIT- 4
SYSTEM DESIGN
TECHNIQUES AND
NETWORKS
Prepared by,
S. Rajalakshmi
Assistant Professor/ECE
RMK College of Engineering and Technology
S. Rajalakshmi AP/ECE, RMKCET EC6703-Embedded and Real Time Systems

 Design methodologies
 Design flows
 Requirement Analysis
 Specifications
System analysis and architecture design
Quality Assurance techniques
Distributed embedded systems
MPSoCs and shared memory multiprocessors.
UNIT IV SYSTEM DESIGN TECHNIQUES AND
NETWORKS

In this chapter we consider the techniques required to create
complex embedded systems.
Thus far, our design examples have been small so that important
concepts can be conveyed relatively simply.
However, most real embedded system designs are inherently
complex, given that their functional specifications are rich and they
must obey multiple other requirements on cost, performance, and
so on.
We need methodologies to help guide our design decisions when
designing large systems.
INTRODUCTION

The obvious goal of a design process is to create a product that does
something useful. Typical specifications for a product will include
functionality (e.g., cell phone),
manufacturing cost (must have a retail price below $200),
Performance (must power up within 3 s),
power consumption (must run for 12 h on two AA batteries), or
 other properties.
a design process has several important goals beyond function,
performance, and power. Three of these goals are summarized
below.
■ Time-to-market
-beat competitors to market
■ Design cost
■ Quality

Design flow
• Design flow: sequence of steps in a design
methodology.
• May be partially or fully automated.
– Use tools to transform, verify design.
• Design flow is one component of
methodology. Methodology also includes
management organization, etc.
• Models

1. Waterfall model
• Early model for software development:
requirements
architecture
coding
testing
maintenance
Introduced by Royce , the first model proposed for the software
development process.
The waterfall model gets its name from the largely one-way flow of
work and information from higher levels of abstraction to more detailed
design steps

2.Spiral model
requirements
design
test
system feasibility
specification
prototype
initial system
enhanced system

Successive refinement model
specify
architect
design
build
test
initial system
specify
architect
design
build
test
refined system
The system is built several times. A first system is used as a rough prototype,
and successive models of the system are further refined.

Hardware/software design flow
requirements and
specification
architecture
hardware design software design
integration
testing

Co-design methodology
• Must architect hardware and software
together:
– provide sufficient resources;
– avoid software bottlenecks.
• Can build pieces somewhat independently,
but integration is major step.
• Also requires bottom-up feedback.

Hierarchical design flow
• Embedded systems must be designed across
multiple levels of abstraction:
– system architecture;
– hardware and software systems;
– hardware and software components.
• Often need design flows within design flows.

A hierarchical design flow for an
embedded system.

Concurrent engineering techniques
• Cross-functional teams.
• Concurrent product realization.
• Incremental information sharing.
• Integrated product management.
• Early and continual supplier involvement
• Early and continual customer focus

AT&T PBX concurrent engineering
• Benchmark against competitors.
• Identify breakthrough improvements.
• Characterize current process.
• Create new process.
• Verify new process.
• Implement.
• Measure results and improve.
EX: Concurrent engineering applied to
telephone systems

Requirements analysis
• Requirements: informal description of what
customer wants.
• Specification: precise description of what design
team should deliver.
• The overall goal of creating a requirements
document is effective communication between
the customers and the designers. The designers
should know what they are expected to design
for the customers

Types of requirements
• Functional: input/output relationships.( FFT )
• Non-functional:
– timing;
– power consumption;
– manufacturing cost;
– physical size;
– time-to-market;
– reliability.

Setting requirements
• Customer interviews.
• Comparison with competitors.
• Sales feedback.
• Mock-ups, prototypes.

Specifications
• Capture functional and non-functional
properties:
– verify correctness of spec;
– compare spec to implementation.
• Many specification styles:
– control-oriented vs. data-oriented;
– textual vs. graphical.
• UML is one specification/design language.

1.SDL
• State machine specification
language is the SDL language
which was developed by the
communications industry for
specifying communication
protocols, telephone systems,
and so forth.
• Event-oriented state machine
model.
telephone
on-hook
dial tone
caller goes
off-hook
caller gets
dial tone

The SDL specification language

2.State charts
• Ancestor of UML state diagrams.
• Provided composite states:
– OR states;
– AND states.
• Composite states reduce the size of the state
transition graph.
Other techniques can be used to eliminate clutter and clarify the
important structure of a state-based specification. The State chart is
one well-known technique for state-based specification

3. AND-OR tables
• Alternate way of specifying complex conditions:
cond1 T -
cond2 - T
cond3 - F
AND
OR
Leveson et al. [Lev94] used a different format, the AND/OR table,
to describe similar relationships between states

TCAS II specification
• TCAS II: aircraft collision avoidance system.
• Monitors aircraft and air traffic info.
• Provides audio warnings and directives to
avoid collisions.
• Leveson et al used RMSL language to capture
the TCAS specification.

System analysis and architecture design
• In this section we consider how to turn a
specification into an architecture design.
• we look at how to get a handle on the overall
system architecture.
• The CRC card methodology is a well-known and
useful way to help analyze a system’s structure.
• It is particularly well suited to object-oriented
design since it encourages the encapsulation of
data and functions.

CRC cards
• The acronym CRC stands for the following
three major items that the methodology tries
to identify: CRC:
– Classes;
– Responsibilities of each class;
– Collaborators are other classes that work with a
class.
• Team-oriented methodology.
S. Rajalakshmi AP/ECE, RMKCET
EC6703-Embedded and Real Time Systems

CRC card format
Class name:
Superclasses:
Subclasses:
Responsibilities: Collaborators:
Class name:
Class’s function:
Attributes:
front back

CRC methodology, cont’d.
• Walk through scenarios.
– See what works and doesn’t work.
• Refine the classes, responsibilities, and
collaborators.
• Add class relatoinships:
– superclass, subclass.

EX: CRC cards for elevator
• Real-world classes:
– elevator car, passenger, floor control, car control,
car sensor.
• Architectural classes: car state, floor control
reader, car control reader, car control sender,
scheduler.

Quality Assurance
The quality of a product or service can be judged by how well it
satisfies its intended function.
The quality assurance (QA) process is vital for the delivery of a
satisfactory System.
In this section we will concentrate on portions of the methodology
particularly aimed at improving the quality of the resulting system.
“The pursuit of quality extends throughout the design flow.”
For example, settling on the proper requirements and
specification cannot be overlooked as an important determinant of
quality.
Quality assurance (QA) makes sure that all stages of the design
process help to deliver a quality product.

Quality Assurance (QA)
( EX: The Therac-25 medical imaging system)

Therac-25 Medical Imager
(Leveson and Turner)
• Six known accidents: radiation overdoses
leading to death and serious injury.
• Radiation gun controlled by PDP-11 mini
computer.
• Four major software components:
– stored data;
– scheduler;
– set of tasks;
– interrupt services.

Therac-25 tasks
• Treatment monitor controlled and monitored
setup and delivery of treatment in eight
phases.
• Servo task controlled radiation gun.
• Housekeeper task took care of status
interlocks and limit checks.

Treatment monitor task
• Treat was main monitor task.
– Eight subroutines.
– Treat rescheduled itself after every subroutine.

Software timing race
• Timing-dependent use of mode and energy:
– if keyboard handler sets completion behavior
before operator changes mode/energy data,
Datent task will not detect the change, but Hand
task will.

Software timing errors
• Changes to parameters made by operator may
show on screen but not be sensed by Datent
task.
• One accident caused by entering
mode/energy, changing mode/energy,
returning to command line in 8 seconds.
• Skilled operators typed faster, more likely to
exercise bug.

Leveson and Turner observations
• Performed limited safety analysis: guessed at
error probabilities, etc.
• Did not use mechanical backups to check
machine operation.
• Used overly complex programs written in
unreliable styles.

Quality Assurance Techniques

requirements
bug
Verification
• Verification and testing are important
throughout the design flow.
• Early bugs are more expensive to fix:
time
costtofix
coding bug

Verifying requirements and
specification
• Requirements:
– prototypes;
– prototyping languages;
– pre-existing systems.
• Specifications:
– usage scenarios;
– formal techniques.

Design review
• Uses meetings to catch design flaws.
– Simple, low-cost.
– Proven by experiments to be effective.
• Use other people in the project/company to
help spot design problems.

Design review players
• Designers: present design to rest of team,
make changes.
• Review leader: coordinates process.
• Review scribe: takes notes of meetings.
• Review audience: looks for bugs.

Before the design review
• Design team prepares documents used to
describe the design.
• Leader recruits audience, coordinates
meetings, distributes handouts, etc.
• Audience members familiarize themselves
with the documents before they go to the
meeting.

Design review meeting
• Leader keeps meeting moving; scribe takes
notes.
• Designers present the design:
– use handouts;
– explain what is going on;
– go through details.

Design review audience
• Look for any problems:
– Is the design consistent with the specification?
– Is the interface correct?
– How well is the component’s internal architecture
designed?
– Did they use good design/coding practices?
– Is the testing strategy adequate?

Follow-up
• Designers make suggested changes.
– Document changes.
• Leader checks on results of changes, may
distribute to audience for further review or
additional reviews.

Measurements
• Measurements help ground our beliefs:
– Do our practices really work?
– Do they work where we think they work?
• Types of measurements:
– bugs found at different stages of design;
– bugs as a function of time;
– bugs in different types of components;
– how bugs are found.

NETWORKS AND
MULTIPROCESSORS

Distributed or networked embedded systems
Networks
Interconnection of computers to share software, hardware, data
through a communication medium between them.

Need to have networks in Embedded Systems
Many embedded computing systems have more than 1 CPU ,
to use such systems we need networks to connect processor,
memory and devices
 NODE
 CLUSTER
DISTRIBUTED EMBEDDED SYSTEM
Single task is divided among multiple processors to achieve
common goals.
Processing elements (PEs) (either microprocessors orASICs)
are connected by a network that allows them to
communicate.
Facebook, Google S. Rajalakshmi AP/ECE, RMKCET

Network elements
PE
PE
PE
network
communication link
distributed computing platform:
PEs may be CPUs or ASICs.

Why distributed?
• Higher performance at lower cost.
• Real time performance
• Power consumption

Categories of Multiprocessor

ARM MPcore

Network abstractions
• International Standards Organization (ISO)
developed the Open Systems Interconnection (OSI)
model to describe networks:
– 7-layer model.
• Provides a standard way to classify network
components and operations.

OSI model
physical mechanical, electrical
data link reliable data transport
network end-to-end service
transport connections
presentation data format
session application dialog control
application end-use interface

OSI layers
• Physical: connectors, bit formats, etc.
• Data link: error detection and control across a single
link (single hop).
• Network: end-to-end multi-hop data
communication.
• Transport: provides connections; may optimize
network resources.
• Session: services for end-user applications: data
grouping, checkpointing, etc.
• Presentation: data formats, transformation services.
• Application: interface between network and end-
user programs. S. Rajalakshmi AP/ECE, RMKCET

Point-to-point networks
• One source, one or more destinations, no data
switching (serial port):
PE 1 PE 2 PE 3
link 1 link 2

Bus networks
• Common physical connection:
PE 1 PE 2 PE 3 PE 4
header address data ECC packet format

CAN BUS
Controlled Area Network
Developed by BOSCH for automotive electronics
Low cost, minimum wires,
Serial communication
Multimaster Multislave

NETWORK MODEL OF CAN

Physical layer

DATA FRAME
RTR=0- Read data
RTR=1—Write data

ARBITRATION
CSMA/AMP-Carrier Sense Multiple Access with
Arbitration on Message Passing

CAN ARCHITECTURE

I2C Bus
Inter Integrated Circuit
Serial communication
Synchronous communication
2 wire (SCL-clock,SDL-data) communication
I2C electrical interface
Open collector interface

Ethernet
• Dominant non-telephone LAN.
• Versions: 10 Mb/s, 100 Mb/s, 1 Gb/s
• Goal: reliable communication over an
unreliable medium.

Ethernet topology
• Bus-based system, several possible physical
layers:
A B C

CSMA/CD
• Carrier sense multiple access with collision
detection:
– sense collisions;
– exponentially back off in time;
– retransmit.

Exponential back-off times
time

Ethernet packet format
preamble
start
frame
source
adrs
dest
adrs
data
payload
length padding CRC

Ethernet performance
• Quality-of-service tends to non-linearly
decrease at high load levels.
• Can’t guarantee real-time deadlines. However,
may provide very good service at proper load
levels.

Fieldbus
• Used for industrial control and
instrumentation---factories, etc.
• H1 standard based on 31.25 MB/s twisted pair
medium.
• High Speed Ethernet (HSE) standard based on
100 Mb/s Ethernet.

Multiprocessors
• Why multiprocessors?
• CPUs and accelerators.
• Multiprocessor performance analysis.

Why multiprocessors?
• Better cost/performance.
– Match each CPU to its tasks or use custom logic
(smaller, cheaper).
– CPU cost is a non-linear function of performance.
cost
performance

Why multiprocessors? cont’d.
• Better real-time performance.
– Put time-critical functions on less-loaded
processing elements.
– Remember RMS utilization---extra CPU cycles
must be reserved to meet deadlines.
cost
performance
deadline
deadline w.
RMS overhead

• Using specialized
processors or custom
logic saves power.
• Desktop uniprocessors
are not power-efficient
enough for battery-
powered applications.
[Aus04] © 2004 IEEE Computer Society

• Good for processing I/O in real-time.
• May consume less energy.
• May be better at streaming data.
• May not be able to do all the work on even
the largest single CPU.

Accelerated systems
• Use additional computational unit dedicated
to some functions?
– Hardwired logic.
– Extra CPU.
• Hardware/software co-design: joint design of
hardware and software architectures.

Accelerator vs. co-processor
• A co-processor executes instructions.
– Instructions are dispatched by the CPU.
• An accelerator appears as a device on the bus.
– The accelerator is controlled by registers.

Accelerator implementations
• Application-specific integrated circuit.
• Field-programmable gate array (FPGA).
• Standard component.
– Example: graphics processor.

System design tasks
• Design a heterogeneous multiprocessor
architecture.
– Processing element (PE): CPU, accelerator, etc.
• Program the system.

Accelerated system design
• First, determine that the system really needs
to be accelerated.
– How much faster is the accelerator on the core
function?
– How much data transfer overhead?
• Design the accelerator itself.
• Design CPU interface to accelerator.

Accelerated system platforms
• Several off-the-shelf boards are available for
acceleration in PCs:
– FPGA-based core;
– PC bus interface.

Accelerator/CPU interface
• Accelerator registers provide control registers
for CPU.
• Data registers can be used for small data
objects.
• Accelerator may include special-purpose
read/write logic.
– Especially valuable for large data transfers.

Accelerator speedup
• Critical parameter is speedup: how much
faster is the system with the accelerator?
• Must take into account:
– Accelerator execution time.
– Data transfer time.
– Synchronization with the master CPU.

Accelerator execution time
• Total accelerator execution time:
– taccel = tin + tx + tout
Data input
Accelerated
computation
Data output

Accelerator speedup
• Assume loop is executed n times.
• Compare accelerated system to non-
accelerated system:
– S = n(tCPU - taccel)
– = n[tCPU - (tin + tx + tout)]
Execution time on CPU

Agenda
• Introduction .
• What is SoC ?
• SoC characteristics .
• Benefits and drawbacks .
• Solution .
• Major SoC Applications .
• Summary .

Introduction
• Technological Advances
– today’s chip can contains 100M transistors .
– transistor gate lengths are now in term of nano meters .
– approximately every 18 months the number of transistors on a
chip doubles – Moore’s law .
• The Consequences
– components connected on a Printed Circuit Board can now be
integrated onto single chip .
– hence the development of System-On-Chip design .

What is SoC ?
People A:
The VLSI manufacturing technology advances has made possible to put
millions of transistors on a single die. It enables designers to put systems-
on-a-chip that move everything from the board onto the chip eventually.
People B:
SoC is a high performance microprocessor, since we can program
and give instruction to the uP to do whatever you want to do.
People C:
SoC is the efforts to integrate heterogeneous or different types of silicon
IPs on to the same chip, like memory, uP, random logics, and analog
circuitry.
All of the above are partially right, but not very accurate!!!

What is SoC ?
SoC not only chip, but more on “system”.
SoC = Chip + Software + Integration
The SoC chip includes:
Embedded processor
ASIC Logics and analog circuitry
Embedded memory
The SoC Software includes:
OS, compiler, simulator, firmware, driver, protocol stackIntegrated
development environment (debugger, linker, ICE)Application interface
(C/C++, assembly)
The SoC Integration includes :
The whole system solution
Manufacture consultant
Technical Supporting

System on Chip architecture
Top Level Design
Unit Block Design
Integration and Synthesis
Trial Netlists
System Level Verification
Timing Convergence
& Verification
Fabrication
DVT
DVT Prep
6 12 12 4 14 ?? 5 8 Time in Weeks
Time to Mask order48
61
Unit Block Verification
ASIC Typical Design Steps • Typical ASIC
design can take
up to two years
to complete

System on Chip architecture
Top Level Design
Unit Block Design
Integration and Synthesis
Trial Netlists
System Level Verification
Timing Convergence
& Verification
Fabrication
DVT
DVT Prep
4 14 5 4
Time in Weeks
Time to Mask order24
33
Unit Block Verification
4 2
• With increasing Complexity of IC’s
and decreasing Geometry, IC Vendor
steps of Placement, Layout and
Fabrication are unlikely to be greatly
reduced
• In fact there is a greater risk that
Timing Convergence steps will
involve more iteration.
• Need to reduce time before Vendor
Steps.
• Need to consider Layout issues up-
front.
SoC Typical Design Steps

System on Chip interconnection
• Design reuse is facilitated if “standard” internal
connection buses are used .
• All cores connect to the bus via a standard
interface .
• Any-to-any connections easy but …
– Not all connections are necessary .
– Global clocking scheme .
– Power consumption .
• Standardization is being addressed by the Virtual
Socket Interface Alliance (VSIA)

System on Chip interconnection
• AMBA (Advanced Microcontroller Bus
Architecture) is a collection of buses from ARM
for satisfying a range of different criteria.
• APB (Advanced Peripheral Bus): simple strobed-
access bus with minimal interface complexity.
Suitable for hosting peripherals.
• ASB (Advanced System Bus): a multimaster
synchronous system bus.
• AHB (Advanced High Performance Bus): a high-
throughput synchronous system backbone. Burst
transfers and split transactions.

System on Chip cores
• One solution to the design productivity gap is
to make ASIC designs more standardized by
reusing segments of previously manufactured
chips.
• These segments are known as “blocks”,
“macros”, “cores” or “cells”.
• The blocks can either be developed in-house or
licensed from an IP company.
• Cores are the basic building blocks .

• Soft Macro
– Reusable synthesizable RTL or netlist of generic library elements
– User of the core is responsible for the implementation and layout
• Firm Macro
– Structurally and topologically optimized for performance and area
through floor planning and placement
– Exist as synthesized code or as a netlist of generic library elements
• Hard Macro
– Reusable blocks optimized for performance, power, size and mapped to
a specific process technology
– Exist as fully placed and routed netlist and as a fixed layout such as in
GDSII format .

Reusability
portability
flexibility
Predictability, performance, time to market
Soft
core
Firm
core
Hard
core

• Locating the required cores and associated
contract discussions can be a lengthy process
– Identification of IP vendors
– Evaluation criteria
– Comparative evaluation exercise
– Choice of core
– Contract negotiations
• Reuse restrictions
• Costs: license, royalty, tool costs
– Core integration, simulation and verification

Agenda
• Introduction .
• What is SoC ?
• SoC characteristics .
• Benefits and drawbacks .
• Solution .
• Major SoC Applications .
• Summary .

The Benefits
• There are several benefits in integrating a large
digital system into a single integrated circuit .
• These include
– Lower cost per gate .
– Lower power consumption .
– Faster circuit operation .
– More reliable implementation .
– Smaller physical size .
– Greater design security .

The Drawbacks
• The principle drawbacks of SoC design are
associated with the design pressures imposed
on today’s engineers , such as :
– Time-to-market demands .
– Exponential fabrication cost .
– Increased system complexity .
– Increased verification requirements .

Design gap

Solution is Design Re-use
• Overcome complexity and verification issues by designing
Intellectual Property (IP) to be re-usable .
• Done on such a scale that a new industry has been developed.
• Design activity is split into two groups:
– IP Authors – producers .
– IP Integrators – consumers .
• IP Authors produce fully verified IP libraries
– Thus making overall verification task more manageable
• IP Integrators select, evaluate, integrate IP from multiple
vendors
– IP integrated onto Integration Platform designed with
specific application in mind

Major SoC Applications
• Speech Signal Processing .
• Image and Video Signal Processing .
• Information Technologies
– PC interface (USB, PCI,PCI-Express, IDE,..etc)
Computer peripheries (printer control, LCD monitor
controller, DVD controller,.etc) .
• Data Communication
– Wireline Communication: 10/100 Based-T, xDSL,
Gigabit Ethernet,.. Etc
– Wireless communication: BlueTooth, WLAN,
2G/3G/4G, WiMax, UWB, …,etc

Summary
• Technological advances mean that complete systems
can now be implemented on a single chip .
• The benefits that this brings are significant in terms of
speed , area and power .
• The drawbacks are that these systems are extremely
complex requiring amounts of verification .
• The solution is to design and verify re-useable IP .

EC6703 unit-4

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to EC6703 unit-4

Similar to EC6703 unit-4 (20)

More from RajalakshmiSermadurai

More from RajalakshmiSermadurai (15)

Recently uploaded

Recently uploaded (20)

EC6703 unit-4