Académique Documents
Professionnel Documents
Culture Documents
Processor
Memory
Cores
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
2. Low power and low cost also drive us away from PC architectures
and toward multiprocessors. Personal computers are designed to
satisfy a broad mix of computing requirements and to be very
flexible. Those features increase the complexity and price of the
components. They also cause the processor and other components
to use more energy to perform a given function.
COMPLEX SYSTEMS AND MICROPROCESSORS contd…
■ 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 dramatically affect its performance.
■ 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.
Contd….
1. Requirements
EX:
GPS Moving Map
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.
Hardware
Software
THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
4. Designing Hardware and Software Components
The components will in general include both hardware—FPGAs, boards, and so on and
software modules.
By building up the system in phases and running properly chosen tests, we can often find
bugs more easily.
If we debug only a few modules at a time, we are more likely to uncover the simple bugs
and able to easily recognize them.
Careful attention to inserting appropriate debugging facilities during design can help
ease system integration problems, but the nature of embedded computing means that
this phase will always be a challenge.
WHY DESIGN METHODOLOGIES?
Time-to-market.
Design cost.
Quality.
•Processes evolve over time.
•They change due to external and internal forces.
•Customers may change, requirements change, products change,
and available components change.
•Internally, people learn how to do things better, people move on
to other projects and others come in, and companies are bought
and sold to merge and shape corporate cultures.
•A good methodology is critical to building systems that work
properly.
•Delivering buggy systems to customers always causes
dissatisfaction. But in some applications, such as medical and
automotive systems, bugs create serious safety problems that can
endanger the lives of users
Example 7.1 Loss of the Mars Climate Observer
In September 1999, the Mars Climate Observer, an unmanned U.S.
spacecraft designed to study Mars, was lost—it most likely exploded as it
heated up in the atmosphere of Mars after approaching the planet too
closely. The spacecraft came too close to Mars because of a series of
problems, according to an analysis by IEEE Spectrum and contributing editor
James Oberg [Obe99]. From an embedded systems perspective, the first
problem is best classified as a requirements problem. The contractors who
built the spacecraft at Lockheed Martin calculated values for flight
controllers at the Jet Propulsion Laboratory (JPL). JPL did not specify the
physical units to be used, but they expected them to be in newtons. The
Lockheed Martin engineers returned values in units of pound force. This
discrepancy resulted in trajectory adjustments being 4.45 times larger than
they should have been. The error was not caught by a software
configuration process nor was it caught by manual inspections. Although
there were concerns about the spacecraft’s trajectory, errors in the
calculation of the spacecraft’s position were not caught in time.
DESIGN FLOWS
architecture
coding
testing
maintenance
Waterfall model 5 steps
• Requirements: determine basic characteristics.
• Architecture: decompose into basic modules.
• Coding: implement and integrate.
• Testing: exercise and uncover bugs.
• Maintenance: deploy, fix bugs, upgrade.
Waterfall model critique
• Only local feedback---may need iterations
between coding and requirements, for
example.
• Doesn’t integrate top-down and bottom-up
design.
• Assumes hardware is given.
Most design projects entail experimentation and changes that
require bottom–up feedback. As a result, the waterfall model is
today cited as an unrealistic design process.
specification
prototype
initial system
enhanced system
requirements
design
test
Spiral model critique
• Successive refinement of system.
– Start with mock-ups, move through simple systems to
full-scale systems.
• Provides bottom-up feedback from previous
stages.
• Working through stages may take too much time.
• A spiral methodology with too many spirals may
take too long when design time is a major
requirement.
Successive refinement model
specify specify
architect architect
design design
build build
test test
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
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
• Large projects use many people from multiple
disciplines.
• Work on several tasks at once to reduce
design time.
• Feedback between tasks helps improve
quality, reduce number of later design
problems.
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
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
developed by the
caller goes
communications industry off-hook
for specifying
communication protocols, dial tone
• Event-oriented state
machine model.
The SDL specification language
2.State charts
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
S1 S1
i2
i1 i1 i2
i2
S2 S4 S2 S4
i2
S3 S3
traditional OR state
Statechart AND state
sab
c
S1-3 S1-4 S1 S3
d
b a b a b a c d
c
S2-3 S2-4 S2 S4
d r
r r
S5
S5
traditional AND state
3. AND-OR tables
Leveson et al. [Lev94] used a different format, the AND/OR table,
to describe similar relationships between states
OR
cond1 T -
AND cond2 - T
cond3 - F
System analysis and architecture design
front back
The CRC card methodology is informal, but we should go
through the following steps when using it to analyze a
system:
Quality assurance (QA) makes sure that all stages of the design
process help to deliver a quality product.
Quality Assurance Techniques
ISO 9000
• Developed by International Standards
organization.
• Applies to a broad range industries.
• Concentrates on process.
• Validation based on extensive documentation
of organization’s process.
CMM Capability Maturity Model
• Five levels of organizational maturity:
– Initial: poorly organized process, depends on
individuals.
– Repeatable: basic tracking mechanisms.
– Defined: processes documented and standardized.
– Managed: makes detailed measurements.
– Optimizing: measurements used for improvement.
Verification
requirements
bug
coding bug
time
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.