1 Embedded System • A specialized computer system that is part of a larger system or machine. Typically, an embedded system is housed on a single microprocessor board with the programs stored in ROM. Some embedded systems include an operating system, but many are so specialized that the entire logic can be implemented as a single program.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Embedded System
• A specialized computer system that is part of a larger system or machine. Typically, an embedded system is housed on a single microprocessor board with the programs stored in ROM. Some embedded systems include an operating system, but many are so specialized that the entire logic can be implemented as a single program.
2
Embedded System TestingWei-Tek Tsai
Department of Computer Science and Engineering
Arizona State University
Tempe, AZ 85287
3
Embedded System(cont’)
4
Embedded System(cont’)
• Differences with desktop computing– The human interface may be as simple as a flashing light
or as complicated as real-time robotic vision. – The diagnostic port may be used for diagnosing the
system that is being controlled -- not just for diagnosing the computer.
– Special-purpose field programmable (FPGA), application specific (ASIC), or even non-digital hardware may be used to increase performance or safety.
– Software often has a fixed function, and is specific to the application.
5
Embedded System(cont’)
6
Embedded System(cont’)
• Characteristics of Embedded Systems– Application specific
• Jobs are known a priori• Static scheduling of tasks and allocation of resources
– Real time• Hardware/software tradeoff• Exceptions
– Reactive• Interacts with external environment continuously
– Hierarchy of behaviours• Sequential and concurrent subbehaviours
7
Embedded System(cont’)
• Characteristics of digital systems– Application domain
• General purpose• Dedicated computing and control systems• Emulation and prototyping systems
– Degree of programmability• Application level• Instruction level• Hardware level
– Hardware fabrication technology• Bipolar versus CMOS
– Level of integration• Discrete components versus integrated
• Programmable HW; configurable gate level interconnection of circuits after manufacturing
• Consists of a matrix of cells: Configurable Logic Blocks(CLBs) and I/O Blocks(IOBs), with programmable switches to provide the desired connections between blocks
• Slower than non-programmable devices, but allows prototype to be designed quickly(circuit design, implementation, verification on desktop workstations)
9
Embedded System(cont’)
– ASIC(Application Specific Integrated Circuit)• Custom designed chip to implement a digital
function/system
• Hardwired(non-programmable) gives the best performance
• Must produce in volume to cover non-recurrent engineering design cost
10
Embedded System(cont’)
– ASIP(Application Specific Instruction Processor)
• A microprocessor with special architecture design, and instruction set chosen for a specific domain of programs
• Easier to cover non-recurrent engineering cost since ASIP has multiple applications
11
Embedded System(cont’)
• HW/SW Co-Design– Meeting system level objectives by exploiting
the synergism of HW and SW through their concurrent design
– Simultaneously design the software architecture of an application and the HW on which that SW is implementation to meet performance, cost, or reliability goals
12
Embedded System(cont’)
– HW/SW Co-Simulation• The joint simulation of HW and SW components
and their interaction
13
Embedded System(cont’)
• Design requirements– Real time/reaction operation– Small size, low weight– Safe and reliable– Harsh environment– Cost sensitivity
14
Embedded System(cont’)
– Real time/reactive operation• Real time system operation: the correctness of a computation
depends, in part, on the time at which it is delivered
• Reactive computation: the software executes in response to external events
• Challenge: Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics (e.g., cache memory [Philip Koopman, "Perils of the PC Cache", Embedded Systems Programming, May 1993, 6(5) 26-34]).
H/S interaction• Today’s embedded system designers face the difficult task
of integrating and verifying application-specific software and hardware with intellectual property (IP) such as protocol stacks and commercial real-time operating systems (RTOSs). When the system design includes developing application-specific integrated circuits (ASICS), engineers often postpone the integration and verification task until a hardware prototype is available. Waiting until this stage to debug adds unnecessary costs and delays. However, new methodologies allow integration teams to verify their embedded systems applications while meeting design and time-to-market goals.
39
H/S interaction(cont’)
• Semiconductior manufactures should not ignore embedded software
• Software experts are unlikely to solve the embedded software problem on their own
• Hardware experts have sth to teach to the SW world– Concurrency– Reusability– Reliability– Heterogeneity
44
H/S interaction(cont’)• What an embedded program might look like
45
H/S interaction(cont’)• Simple example: controlling an inverted
pendulum with embedded SW
46
H/S interaction(cont’)
• Metaphor for:– Disk drive controllers– Manufacturing equipment– Automotive:
• Drive-by-wire devices
• Engine control
• Antilock braking systems, traction control
47
H/S interaction(cont’)
– Avionics• Fly-by-wire devices
• Navigation
• Flight control
– Certain “software radio” functions– Printing and paper handling– Signal processing(audio, video, radio)– …
48
H/S interaction(cont’)
• System HW/SW design methodology– Specification capture
• Create model
• Select language for specification
– Exploration• Allocate architectural components
• Partition the specification to the architectural components
49
H/S interaction(cont’)
– Refinement of specification– Hardware and software design
• Synthesis
• Simulation
– Physical design• Generate manufacture data for hardware
• Compile code for instruction sequence
50
H/S interaction(cont’)• Co-design, particularly important when designing
embedded systems or systems-on-a-chip• There are many areas in which the co-design principle can
bring product enhancements • Massive parallelism, distributed algorithms and special
architectures • Efficient interfaces are required • Low-Power Processors • Reconfigurable Systems are capable of adapting to
changing environments or to incomplete specifications• Parallel I/O on multiple PC's
51
H/S interaction(cont’)
52
H/S interaction(cont’)
• Hardware/software codesign– the cooperative design of hardware and software
components;
– the unification of currently separate hardware and software paths;
– the movement of functionality between hardware and software;
– the meeting of system-level objectives by exploiting the synergism of hardware and software through their concurrent design.
53
H/W interaction(cont’)
• Why is it important?– Reconfiguration: exploiting the synergy
between hardware and software
54
H/S interaction(cont’)
– Embedded systems are application specific systems which contain both hardware and software tailored for a particular task and generally part of a larger system
– Reusability: to provide design approaches that scale up, without a total redesign for a legacy product
55
H/S interaction(cont’)
• Existing Problems– Model Continuity Problem
56
H/S interaction(cont’)
• Importance of Model Continuity– many complex systems do not perform as
expected in their operational environment; – continuity allows the validation of system level
models at all levels of hardware/software implementation;
– trade-offs are easier to evaluate at several stages
57
H/S interaction(cont’)
• Consequences of losing such model continuity– cost increases and schedule over-runs (due to
modifications late in phases);
– the ability to explore hardware/software trade-offs is restricted (e.g. movement of functionality between, modification of interfaces);
– state of the art applications require a case-by-case analysis;
– different design cultures hamper integration
58
H/S interaction(cont’)
• Solution– Unified Design Environment: it is emphasized
that hardware design and software design use the same integrated infrastructure, resulting in an improvement of overall system performance, reliability, and cost effectiveness.
59
H/S interaction(cont’)
• Typical context for co-design process
An “ideal” process flow
60
Memory Constraints
• Memory is usually a critical resource and the memory size is often very restricted
• Both static and dynamic memory usage within a task and the dynamic memory usage due to communication should be considered
• Mapping is also a problem
61
Fault-tolerance
• Allowable system failure probability is 10-10 per hour
• One for one redundancy: each hardware module has a redundant hardware module
• N + X redundancy: if N hardware modules are required to perform system functions, the system is configured with N + X hardware modules; typically X is much smaller than N
• Load sharing: under zero fault conditions, all the hardware modules that are equipped to perform system functions, share the load
64
Fault-tolerance(cont’)
– Standby synchronization• Bus cycle level synchronization
• Fault isolation If a unit is actually faulty, many fault triggers will
be generated for that unit. The main objective of fault isolation is to correlate the fault triggers and identify the faulty unit. If fault triggers are fuzzy in nature, the isolation procedure involves interrogating the health of several units. For example, if protocol fault is the only fault reported, all the units in the path from source to destination are probed for health
69
Timing • Real time: A real-time system provides specified system
services with known timing and latency characteristics, so that applications can be designed and developed that meet perscribed timing constraints
• Hard real time: In a hard real-time system, the timing constraints have an upper worst-case value, which if exceeded, cause the application to fundamentally fail
• Soft real time:In a soft real-time system, the timing constraints do not have an upper worst-case value, but meet an acceptable statistical distribution of timings. In this case, occasional longer latencies either do not really cause failures, or the failure rates are acceptable