ERTS_Unit 1_PPT.pdf

Dr. N.G.P. INSTITUTE OF TECHNOLOGY
COIMBATORE – 641 048
Department of Electronics and communication Engineering
EC8791 – EMBEDDED AND REAL TIME SYSTEMS
VII SEMESTER ECE
By,
U.Vinothkumar AP/ECE

EC6703 - EMBEDDED AND REAL TIME SYSTEMS
OBJECTIVES
 Understand the concepts of embedded system design and analysis
 Learn the architecture and programming of ARM processor
 Be exposed to the basic concepts of embedded programming
 Learn the real time operating systems

EMBEDDED AND REAL TIME SYSTEMS
OUTCOMES
 Describe the architecture and programming of ARM processor
 Outline the concepts of embedded systems
 Explain the basic concepts of real time operating system design
 Model real-time applications using embedded-system concepts

EMBEDDED AND REAL TIME SYSTEMS
SYLLABUS
UNIT: 1 INTRODUCTION TO EMBEDDED COMPUTING AND ARM PROCESSORS
 Complex systems and microprocessors
 Embedded system design process
 Design example: Model train controller
 Design methodologies
 Design flows
 Requirement Analysis
 Specifications
 System analysis and architecture design
 Quality Assurance techniques
 Designing with computing platforms
 consumer electronics architecture
 platform-level performance analysis

Unit : 1
Complex systems and microprocessors
EMBEDDED COMPUTER SYSTEM
 Any Device that includes a programmable computer but is not it self
intended to be a general purpose computer.
 Thus, a PC is not itself an embedded computing system, although PCs are
often used to build embedded computing systems. But a fax machine or a
clock built from a microprocessor is an embedded computing system.
 embedded computing system design is a useful skill for many types of
product design.
 Designers in many fields must be able to identify where microprocessors
can be used, design a hardware platform with I/O devices that can
support the required tasks, and implement software that performs the
required processing.

Embedding Computers
 Whirlwind, a computer designed at MIT in the late 1940s and early 1950s.
 Whirlwind was also the first computer designed to support real-time
operation
 It was originally conceived as a mechanism for controlling an aircraft
simulator
 A microprocessor is a single-chip CPU. Very large scale integration (VLSI)
stet
 The first microprocessor, the Intel 4004,was designed for an embedded
application, namely, a calculator.
 The HP-35 was the first handheld calculator to perform transcendental
functions [Whi72]. It was introduced in 1972, so it used several chips to
implement the CPU, rather than a single-chip microprocessor.
 Microprocessors come in many different levels of sophistication; they are
usually classified by their word size.

BMW 850i brake and stability control system
 The BMW 850i was introduced with a sophisticated system for controlling the
wheels of the car. An antilock brake system (ABS) reduces skidding by
pumping the brakes.
 An automatic stability control (ASC T) system intervenes with the engine
during maneuvering to improve the car’s stability. These systems actively
control critical systems of the car; as control systems, they require inputs
from and output to the automobile.
 The ASC T system’s job is to control the engine power and the brake to
improve the car’s stability during maneuvers. The ASC T controls four
different systems: throttle, ignition timing, differential brake, and (on
automatic transmission cars) gear shifting. The ASC T can be turned off by
the driver, which can be important when operating with tire snow chains.

BMW 850i brake and stability control system

Characteristics of Embedded Computing
Applications
 Embedded computing systems have to provide sophisticated functionality
Complex algorithms : Automobile Engine (Complicated Filtering)
User Interface : GPS System(Multiple Menu, Many Options)
 Embedded computing operations must often be performed to meet
deadlines:
Real Time : Hard RTS, Soft RTS, Firm RTS(Depends on Safety Problems)
Multi Rate : Multi media Applications(several real-time activities going
on at the same time)
 Costs of various sorts are also very important:
Manufacturing cost: Types of Micro processor, Memory, Types of I/O
Power and energy: Battery Life, Heat Consumption

Why Use Microprocessor?
 Very efficient way to implement digital systems.
 Easier to design families of products that can be built to provide various
feature sets at different price point and can be extended to provide new
features to keep up extended to provide new features to keep up with
rapidly changing market.
 The paradox of digital design is that using a predesigned instruction set
processor may in fact result in faster implementation of your application
than designing your own custom logic.
 It is tempting to think that the overhead of fetching, decoding, and
executing instructions is so high that it cannot be recouped.
 microprocessors execute programs very efficiently
 microprocessor manufacturers spend a great deal of money to make their
CPUs run very fast.
 microprocessors are very efficient utilizers of logic.

Why Use Microprocessor?
 CPU’s are flexible
 CPU’s are efficient
 CPU’s are highly optimized
 Programmability
 How many platforms
 Real time
 Low power and Low cost
 Smartphone as platforms

Cyber-physical Systems
 A cyber physical system is that one that combines physical devices, known as the
plant with computers that control the plant.
 Embedded computer is the cyber-part of the cyber physical system.
 Make certain trade-off’s between the design of the control of the plant and the
computational system that implements that control.
Computing as a physical act (Fundamental reasons for why programs take
time to finish, Why they consume energy, and so on)
Physics of Software (software performance, energy consumption, Structure
of programs, Optimizing Programs)

Challenges in Embedded computing
system design
 How much hardware do we need?
(amount of memory, Peripheral devises, cost)
 How do we meet dead lines?
(Increase CPU Clock, Execution time, Speed limit)
 How do we minimize power consumption?
(Run more slowly, missed deadline, slowdown non critical parts)
 How do we design for upgradeability?
(add features by changing software)
 Does it really works
(Reliability in safety critical system)
 Complex Testing (Timing of data)
 Limited observability and controllability (what is going on inside and effect the system
operation)
 Restricted development environments (IDE tool)

Performance of embedded computing
system
 Performance in general purpose computing
It should run fast, asymptotic complexity
no tools to improve performance
 Performance in embedded computing
Meet deadline
real time computing
need tool to help, analyze the Real Time performance
adopt programming disciplines & styles

Performance of embedded computing
system
 Different Levels of abstraction layer
 CPU: The CPU clearly influences the behavior of the program, particularly when the CPU is
a pipelined processor with a cache.
 Platform: The platform includes the bus and I/O devices. The platform components that
surround the CPU are responsible for feeding the CPU and can
 Program: Programs are very large and the CPU sees only a small window of the program
at a time. We must consider the structure of the entire program to determine its overall
behavior.
 Task: We generally run several programs simultaneously on a CPU, creating a multitasking
system. The tasks interact with each other in ways that have profound implications for
performance.
 Multiprocessor: Many embedded systems have more than one processor— they may
include multiple programmable CPUs as well as accelerators. Once again, the interaction
between these processors adds yet more complexity to the analysis of overall system
performance.

THE EMBEDDED SYSTEM DESIGN PROCESS
 Objective
Introduce various steps in embedded system design
Design methodology
 Reason for design methodology
To keep scorecard on a design, optimizing performance,
functional test
Develop CAD tool, breaking the process in to manageable
steps
Members of design team to communicate

Major steps in the embedded system design
process
Fig: Major levels of abstraction in the design process

Major steps in the embedded system design
process
 Top-down approach: Begin with most abstract description of
the system and conclude with concrete details
Requirements: Know the requirements
Specification : What we want, How the system behaves not
how it built
Architecture : it gives system Shape & structure in terms of
larger components
Components : know the components we need & design
those components both software module and specialized
hardware
System integration : build a complete system

Bottom-up design
 Bottom-up: Starts with components to build a system, we do not have
perfect insight in to how later stages of the design process will turn out.
 Decision at one stage of design are based upon estimates of what will
happen latter
 How fast can we make a particular function run?
 How much memory will we need?
 How much system bus capacity do we need?
 If needed backtrack and amend our original decisions to take new facts
into account
The less experience we have with the design of similar systems, the more we
will have to rely on bottom-up design information to help us refine the system.

Major goals of the design
Goals:
 Manufacturing cost
 Performance (both overall speed and deadlines)
 Power consumption.
The tasks we need to perform at every step:
 We must analyze the design at each step to determine how we can meet the
specifications.
 We must then refine the design to add detail.
 And we must verify the design to ensure that it still meets all system goals, such as
cost, speed, and so on.

Requirements
Requirements may be functional or nonfunctional. We must of course capture
the basic functions of the embedded system, but functional description is often not
sufficient.
 Typical nonfunctional requirements include:
 Performance: Speed of the system, usability, ultimate cost.
 Cost: Manufacturing cost ( components & assembly) & nonrecurring
engineering (NRE) cost (personnel & other cost)
 Physical size and weight: depends upon the application
 Power consumption: battery life
 Validating requirements: Mock-Up (Simulate functionality in a restricted
demonstration executed on a PC or a workstation)

Requirements form
 sample requirements form that can be filled out at the start of the project. We can
use the form as a checklist in considering the basic characteristics of the system.
Check the internal Consistency of requirements
Name GPS moving map
Purpose
Inputs
Outputs
Functions
Performance
Manufacturing Cost
Power
Physical size & weight

Requirement analysis of a GPS moving map
 The moving map is a handheld device that displays for the user a map of the
terrain around the user’s current position; the map display changes as the user and
the map device change position. The moving map obtains its position from the
GPS, a satellite-based navigation system. The moving map display might look
something like the following figure.

What requirements might we have for our GPS
moving map? Here is an initial list:
 Functionality: This system is designed for highway driving and similar uses, not nautical or
aviation uses that require more specialized databases and functions. The system should
show major roads and other landmarks available in standard topographic databases.
 User interface: The screen should have at least 400600 pixel resolution. The device
should be controlled by no more than three buttons. A menu system should pop up on
the screen when buttons are pressed to allow the user to make selections to control the
system.
 Performance: The map should scroll smoothly. Upon power-up, a display should take no
more than one second to appear, and the system should be able to verify its position
and display the current map within 15 s.
 Cost: The selling cost (street price) of the unit should be no more than $100.
 Physical size and weight: The device should fit comfortably in the palm of the hand.
 Power consumption: The device should run for at least eight hours on four AA batteries.

Requirement analysis of a GPS moving map
Name GPS moving map
Purpose Consumer-grade moving map for
driving use
Inputs Power button, two control buttons
Outputs Back-lit LCD display 400x600
Functions Uses 5-receiver GPS system; three user-
selectable resolutions; always displays
current latitude and longitude
Performance Updates screen within 0.25 seconds
upon movement
Manufacturing Cost $40
Power 100mW
Physical size and weight No more than 2” 6, ” 12 ounces

Specification
 The specification is more precise—it serves as the contract between the customer and
the architects.
 The specification should be
 Understandable
 Unambiguous
 A specification of the GPS system would include several components:
 Data received from the GPS satellite constellation.
 Map data.
 User interface.
 Operations that must be performed to satisfy customer requests.
 Background actions required to keep the system running, such as operating the
GPS receiver.
 UML, a language for describing specifications

Architectural design
 The specification does not say how the system does things, only what the system
does. Describing how the system implements those functions is the purpose of the
architecture.
 The architecture is a plan for the overall structure of the system that will be used
later to design the components that make up the architecture.
 Sample architecture for the moving map

Hardware & software architecture
 Hardware and software architectures for the moving map.

Designing Hardware and Software Components
 The architectural description tells us what components we need.
 The component design effort builds those components in conformance to
the architecture and specification.
 The components will in general include both hardware—FPGAs, boards,
and so on—and software modules.

System Integration
 Only after the components are built do we have the satisfaction of putting them
together and seeing a working system.
 We need to ensure during the architectural and component design phases that we
make it as easy as possible to assemble the system in phases and test functions
relatively independently.
 System integration is difficult because it usually uncovers problems. It is often hard to
observe the system in sufficient detail to determine exactly what is wrong?
 Careful attention to inserting appropriate debugging facilities during design can help
ease system integration problems

FORMALISMS FOR SYSTEM DESIGN
 A visual language that can be used to capture all these design tasks: the Unified
Modeling Language (UML)
 UML is an object-oriented modeling language
 object-oriented design emphasizes two concepts of importance:
 It encourages the design to be described as a number of interacting objects, rather than a
few large monolithic blocks of code.
 At least some of those objects will correspond to real pieces of software or hardware in the
system.
 Object-oriented (often abbreviated OO) specification can be seen in two
complementary ways:
 Object-oriented specification allows a system to be described in a way that closely models
real-world objects and their interactions.
 Object-oriented specification provides a basic set of primitives that can be used to
describe systems with particular attributes, irrespective of the relationships of those systems’
components to real-world objects.

Relationship between an object-oriented specification
and an object-oriented programming language
 A specification language may not be executable.
 But both object-oriented specification and programming languages provide similar
basic methods for structuring large systems.
 UML is so rich, there are many graphical elements in a UML diagram.

Structural Description
 The principal component of an object-oriented design is, naturally enough, the
object.
 An object includes a set of attributes that define its internal state.
 When implemented in a programming language, these attributes usually become
variables or constants held in a data structure.
 we will add the type of the attribute after the attribute name for clarity, but we do
not always have to specify a type for an attribute

Structural Description - Object
 The text in the folded-corner page icon is a note. it does not correspond to an
object in the system and only serves as a comment.
 The attribute is, in this case, an array of pixels that holds the contents of the display.
 The object is identified in two ways: It has a unique name, and it is a member of a
class. The name is underlined to show that this is a description of an object and not
of a class.
 Class: A class is a form of type definition—all objects derived from the same class
have the same characteristics, although their attributes may have different values.
 A class defines the attributes that an object may have.
 It also defines the operations that determine how the object interacts with the rest
of the world. In a programming language, the operations would become pieces of
code used to manipulate the object.

Structural Description - Class
 The class has the name that we saw used in the d1 object since d1 is an instance of class
Display
 The Display class defines the pixels attribute seen in the object; remember that when we
instantiate the class an object, that object will have its own memory so that different
objects of the same class have their own values for the attributes.
 A class defines both the interface for a particular type of object and that object’s
implementation

Structural Description - Class
 When we use an object, we do not directly manipulate its attributes—we can only
read or modify the object’s state through the operations that define the interface to
the object.
 There are several types of relationships that can exist between objects and classes:
 Association occurs between objects that communicate with each other but have no
ownership relationship between them.
 Aggregation describes a complex object made of smaller objects.
 Composition is a type of aggregation in which the owner does not allow access to the
component objects.
 Generalization allows us to define one class in terms of another.

Behavioral Description
 specify the behavior of the system as well as its structure. One way to specify the
behavior of an operation is a state machine.
 Signal, call, and time-out events in UML.

Signal, Call, and Time out events in UML

Behavioral Description
 A signal is an asynchronous occurrence. It is defined in UML by an object that is
labeled as a <<signal>>. The object in the diagram serves as a declaration of the
event’s existence. Because it is an object, a signal may have parameters that are
passed to the signal’s receiver.
 A call event follows the model of a procedure call in a programming language.
 A time-out event causes the machine to leave a state after a certain amount of
time. The label tm(time-value) on the edge gives the amount of time after which
the transition occurs. A time-out is generally implemented with an external timer
 Occurrence of all types of signals in a UML

A state machine specification in UML
• The state machine specification is to understand the semantics of UML state machines.
• The states in the state machine represent different conceptual operations.

Sequence Diagram
 A sequence diagram is somewhat similar to a hardware timing diagram, although
the time flows vertically in a sequence diagram, whereas time typically flows
horizontally in a timing diagram.

Design Example: Model Train Controller
 The user sends messages to the train with a control box attached to the tracks.
 The control box may have familiar controls such as a throttle, emergency stop
button, and so on.
 Since the train receives its electrical power from the two rails of the track, the
control box can send signals to the train over the tracks by modulating the power
supply voltage.
 As shown in the figure, the control panel sends packets over the tracks to the
receiver on the train.
 The train includes analog electronics to sense the bits being transmitted and a
control system to set the train motor’s speed and direction based on those
commands.
 Each packet includes an address so that the console can control several trains on
the same track; the packet also includes an error correction code (ECC) to guard
against transmission errors.
 This is a one-way communication system—the model train cannot send commands
back to the user.

Requirements:
 The console shall be able to control up to eight trains on a single track.
 The speed of each train shall be controllable by a throttle to at least 63 different
levels in each direction (forward and reverse).
 There shall be an inertia control that shall allow the user to adjust the responsiveness
of the train to commanded changes in speed. Higher inertia means that the train
responds more slowly to a change in the throttle, simulating the inertia of a large
train. The inertia control will provide at least eight different levels.
 There shall be an emergency stop button.
 An error detection scheme will be used to transmit messages.

Requirement Chart

Digital Command Control (DCC)
 DCC was created to provide a standard that could be built by
any manufacturer so that hobbyists could mix and match
components from multiple vendors.
 The DCC standard is given in two documents:
Standard S-9.1, the DCC Electrical Standard, defines how bits are
encoded on the rails for transmission.
Standard S-9.2, the DCC Communication Standard, defines the
packets that carry information.
 The DCC standard does not specify many aspects of a DCC train system. It
doesn’t define the control panel, the type of microprocessor used, the
programming language to be used, or many other aspects of a real model
train system.

DCC Electrical Standard:
 The Electrical Standard deals with voltages and currents on the track.
 The standard must be carefully designed because the main function of the track is
to carry power to the locomotives.
 The signal encoding system should not interfere with power transmission either to
DCC or non-DCC locomotives.
 A key requirement is that the data signal should not change the DC value of the
rails.
 The data signal swings between two voltages around the power supply voltage.
 bits are encoded in the time between transitions, not by voltage levels. A 0 is at
least 100 s while a 1 is nominally 58 s.
 The durations of the high (above nominal voltage) and low (below nominal voltage)
parts of a bit are equal to keep the DC value constant.
 The standard also describes other electrical properties of the system, such as
allowable transition times for signals.

DCC Communication Standard
 The DCC Communication Standard describes how bits are combined into packets and
the meaning of some important packets. Some packet types are left undefined in the
standard but typical uses are given in Recommended Practices documents.
 The basic packet format as a regular expression: PSA(sD) + E
 P is the preamble, which is a sequence of at least 10 1 bits. The command station should send at
least 14 of these 1 bits, some of which may be corrupted during transmission.
 S is the packet start bit. It is a 0 bit.
 A is an address data byte that gives the address of the unit, with the most significant bit of the
address transmitted first. An address is eight bits long. The addresses 00000000, 11111110, and
11111111 are reserved.
 s is the data byte start bit, which, like the packet start bit, is a 0.
 D is the data byte, which includes eight bits. A data byte may contain an address, instruction,
data, or error correction information.
 E is a packet end bit, which is a 1 bit.

DCC Communication Standard
 A packet includes one or more data byte start bit/data byte combinations
 the address data byte is a specific type of data byte.
 A baseline packet is the minimum packet that must be accepted by all DCC implementations.
 A baseline packet has three data bytes: an address data byte that gives the intended receiver
of the packet; the instruction data byte provides a basic instruction; and an error correction
data byte is used to detect and correct transmission errors.
 The instruction data byte carries several pieces of information:
 Bits 0–3 provide a 4-bit speed value.
 Bit 4 has an additional speed bit, which is interpreted as the least significant speed bit.
 Bit 5 gives direction, with 1 for forward and 0 for reverse.
 Bits 7–8 are set at 01 to indicate that this instruction provides speed and direction.
 The error correction data byte is the bitwise exclusive OR of the address and instruction data
bytes. The standard says that the command unit should send packets frequently since a packet
may be corrupted.
 Packets should be separated by at least 5 ms.

Conceptual Specification
 A conceptual specification allows us to understand the system a little better. We will
use the experience gained by writing the conceptual specification to help us write
a detailed specification to be given to a system architect.
 To understand basic concepts in system design.
 A train control system turns commands into packets. A command comes from the
command unit while a packet is transmitted over the rails.
 Commands and packets may not be generated in a 1-to-1 ratio. In fact, the DCC
standard says that command units should resend packets in case a packet is
dropped during transmission.
 There are clearly two major subsystems: the command unit and the train-board
component

 The console needs to perform three functions: read the state of the front panel on
the command unit, format messages, and transmit messages.
 The train receiver must also perform three major functions: receive the message,
interpret the message(taking into account the current speed, inertia setting,
etc.),and actually control the motor.
CLASS DIAGRAM:
 It shows the console class using three classes, one for each of its major components.
These classes must define some behaviors, but for the moment we will concentrate
on the basic characteristics of these classes:
 The Console class describes the command unit’s front panel, which contains the analog
knobs and hardware to interface to the digital parts of the system.
 The Formatter class includes behaviors that know how to read the panel knobs and creates
a bit stream for the required message.
 The Transmitter class interfaces to analog electronics to send the message along the track.

 Class Diagram

 Knobs* describes the actual analog knobs, buttons, and levers on the control panel.
 Sender* describes the analog electronics that send bits along the track.
Likewise, the Train makes use of three other classes that define its components:
 The Receiver class knows how to turn the analog signals on the track into digital form.
 The Controller class includes behaviors that interpret the commands and figures out how
to control the motor.
 The Motor interface class defines how to generate the analog signals required to control
the motor.
We define two classes to represent analog components:
 Detector* detects analog signals on the track and converts them into digital form.
 Pulser* turns digital commands into the analog signals required to control the motor
speed.
 Train set, to help us remember that the system can handle multiple trains.

Detailed Specification
 Add detail to the classes and look at some of the major decisions in the specification
process to get a better handle on how to write good specifications.
 Define the analog components in a little more detail because their characteristics
will strongly influence the Formatter and Controller.

 The Panel has three knobs: train number (which train is currently being controlled),
speed (which can be positive or negative), and inertia. It also has one button for
emergency-stop.
 When we change the train number setting, we also want to reset the other controls
to the proper values for that train so that the previous train’s control settings are not
used to change the current train’s settings.
 To do this, Knobs* must provide a set-knobs behavior that allows the rest of the
system to modify the knob settings.

Design methodologies
Why Design methodologies?
 Product metrics:
 Time to market
 Design Cost
 Quality
 Design Flow: A design flow is a sequence of steps to be followed during a
design. Some of the steps can be performed by tools, such as compilers or
CAD systems; other steps can be performed by hand.
 Software development process Model: Waterfall model & Spiral model

Waterfall model
 Waterfall model: 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
The waterfall development model consists of five major
phases:
 requirements analysis determines the basic
characteristics of the system;
 architecture design decomposes the functionality into
major components;
 coding implements the pieces and integrates them;
 testing uncovers bugs;
 maintenance entails deployment in the field, bug fixes,
and upgrades.

Spiral model
 Spiral model: the spiral model assumes that several
versions of the system will be built.
 As design progresses, more complex systems will be
constructed. At each level of design, the designers go
through requirements, construction, and testing phases.
 At later stages when more complete versions of the
system are constructed, each phase requires more work,
widening the design spiral.
 This successive refinement approach helps the designers
understand the system they are working on through a
series of design cycles.
 The first cycles at the top of the spiral are very small and
short, while the final cycles at the spiral’s bottom add
detail learned from the earlier cycles of the spiral.
 The spiral model is more realistic than the waterfall model
because multiple iterations are often necessary to add
enough detail to complete a design.

Successive refinement
 Successive refinement: In this approach, the system is
built several times.
 A first system is used as a rough prototype, and
successive models of the system are further refined.
 This methodology makes sense when you are relatively
unfamiliar with the application domain for which you
are building the system.

Hardware/Software Design Methodology
 Hardware/Software Design Methodology: Front-end
activities such as specification and architecture
simultaneously consider hardware and software
aspects.
 Similarly, back-end integration and testing consider
the entire system.
 In the middle, however, development of hardware
and software components can go on relatively
independently—while testing of one will require stubs
of the other, most of the hardware and software work
can proceed relatively independently.

Concurrent engineering
 When designing a large system along with many people, it is easy to lose track of the
complete design flow and have each designer take a narrow view of his or her role in
the design flow.
 Concurrent engineering attempts to take a broader approach and optimize the total
flow. Reduced design time is an important goal for concurrent engineering, but it can
help with any aspect of the design that cuts across the design flow, such as reliability,
performance, power consumption, and so on.
 It tries to eliminate “over-the-wall” design steps
Concurrent engineering efforts are comprised of several elements:
 Cross-functional teams
 Concurrent product realization
 Incremental information sharing
 Integrated project management
 Early and continual supplier involvement
 Early and continual customer focus

Requirements analysis
 Requirements are informal descriptions of what the customer wants, while
specifications are more detailed, precise, and consistent descriptions of the system
that can be used to create the architecture.
 Both requirements and specifications are, however, directed to the outward
behavior of the system, not its internal structure.
 We have two types of requirements: functional and nonfunctional.
 A functional requirement states what the system must do, such as compute an FFT.
 A nonfunctional requirement can be any number of other attributes, including
physical size, cost, power consumption, design time, reliability, and so on
A good set of requirements should meet several tests:
 Correctness, Unambiguousness, Completeness, Verifiability, Consistency,
Modifiability, Traceability.

Specifications
 Control-Oriented Specification Languages: State machine specification language
 SDL language, State chart

Specifications : AND State in State chart

Specifications
 AND / OR State Table:

System analysis and architecture design
 How to turn a specification into an architecture design?
 The CRC card methodology is a well-known and useful way to help analyze a system’s
structure.
 The acronym CRC stands for the following three major items that the methodology tries
to identify:
 Classes define the logical groupings of data and functionality.
 Responsibilities describe what the classes do.
 Collaborators are the other classes with which a given class works.
 The name CRC card comes from the fact that the methodology is practiced by having
people write on index cards. (In the United States, the standard size for index cards is 3 5,
so these cards are often called 3 5 cards.)

 The CRC card methodology is informal enough that it will not intimidate non-computer
specialists and will allow you to capture their input.
 Second, it aids even computer specialists by encouraging them to work in a group and
analyze scenarios.
 The walkthrough process used with CRC cards is very useful in scoping out a design and
determining what parts of a system are poorly understood.
 This informal technique is valuable to tool-based design and coding.
 The CRC card methodology is informal, but we should go through the following steps
when using it to analyze a system:
 Develop an initial list of classes
 Write an initial list of responsibilities and collaborators
 Create some usage scenarios
 Walk through the scenarios
 Refine the classes, responsibilities, and collaborators
 Add class relationships

Example CRC Card Analysis:
 Real-world classes: elevator car, passenger, floor control, car control, and car sensor.
 Architectural classes: car state, floor control reader, car control reader, car control
sender, and scheduler.

Quality assurance
 The quality assurance (QA) process is vital for the delivery of a satisfactory system.
Quality Assurance Techniques:
 The International Standards Organization (ISO) has created a set of quality standards
known as ISO 9000.
 ISO 9000 concentrates on processes used to create the product or service. The
processes used to satisfy ISO 9000 affect the entire organization as well as the individual
steps taken during design and manufacturing.
 Following observations about quality management based on ISO 9000:
 Process is crucial
 Documentation is important
 Communication is important
 Many types of techniques can be used to verify system designs and ensure
quality.
 Techniques can be either manual or tool based.

Quality assurance
 One well-known way of measuring the quality of an organization’s software
development process is the Capability Maturity Model (CMM) developed by Carnegie
Mellon University’s Software Engineering Institute.
The following five levels of maturity:
 Initial: A poorly organized process, with very few well-defined processes. Success of a
project depends on the efforts of individuals, not the organization itself.
 Repeatable: This level provides basic tracking mechanisms that allow management to
understand cost, scheduling, and how well the systems under development meet their
goals.
 Defined: The management and engineering processes are documented and
standardized. All projects make use of documented and approved standard methods.
 Managed: This phase makes detailed measurements of the development process and
product quality.
 Optimizing: At the highest level, feedback from detailed measurements is used to
continually improve the organization’s processes.

Design with computing platform
 Example Platform----- Open source platform, Evaluation board
 Choosing platform
 Hardware- CPU,BUS, Memory, I/O Devices
 Software- Runtime component (OS & Code Library..etc) & Support component
(Debugging tools, IDE etc..)
 Intellectual property (We can own but not touch like software netlists and so on)
 Runtime software library
 Software development environment
 Schematics, netlists and other hardware design informations
 Development environment- Cross Compilers, Test bench program
 Load Program in to target
 Start and stop program execute on target
 Examine memory and CPU
 Debugging technique- USB , break point, LED, ICE, Logic Analyzer
 Debugging challenges-- Logical errors, Errors in Real time code

Debugging Challenges: Architecture of a
Logic Analyzer

Consumer electronics architecture
 Services of Consumer electronics:
 Functional Requirements:
 Multimedia--- MP3, JPEG, Dolby Digital, MPEG-2, MPEG-4, H.264 and so on..
 Data storage & management--- compatable file system
 Communications--- USB Interface, Ethernet or Cellular Phone link
 Non-Functional Requirements:
 Display, radio & so on…(Battery operated & strict energy budgets)
 Use Cases:
 User interface & File System
 File System: FAT (File Allocation Table) for DOS OS
 Used in Flash memory & Magnetic Disc (Wear-leaving algorithms)
 Two layer---Bottom (Physical read & write)& TOP ( Logical view)

Platform Level Performance Analysis:
 Bandwidth as performance --- Rate at which we can move data( Unit of clock
cycles)
 Bus Bandwidth---- Increase the clock rate , Increase the amount of data
transferred per clock cycle.
 Bus Bandwidth characteristics--- How long it takes to transfer one unit of data
 Bus Bandwidth Formula--- t=TP
 Component Bandwidth
 Memory aspect Ratio
 Memory access time and bandwidth

ERTS_Unit 1_PPT.pdf

More Related Content

Similar to ERTS_Unit 1_PPT.pdf (20)

Recently uploaded (20)

ERTS_Unit 1_PPT.pdf