Transcript 슬라이드 1

Introduction to Embedded System
Design
경희대학교 컴퓨터공학과
조진성
Embedded System Lab. II
주요내용

주요내용



임베디드 시스템 특성
임베디드 시스템 설계 과정
임베디드 시스템 설계 핵심 요소




프로세서 선택
운영체제 선택
소프트웨어/하드웨어 분할
개발 툴/디버깅/테스트
Embedded System Lab. II
2
왜 embedded system인가?

Embedded systems are key elements of our society today



As processing power increases, we’ll be able to do incredible things that
we haven’t begun to imagine.
It is a discipline of Computer Science that has traditionally been:






An adequate supply of competent designers is a rate limiting factor in our
economies ability to grow
Ignored
Conceded to Electrical Engineering Departments
Treated as a cast-off because of its intimacy with “hardware”
Not well understood because of its special niche
Engineers who are experienced embedded system designers are in short
supply and high demand
It’s a really fun topic!
Embedded System Lab. II
3
Embedded System은 무엇이 다른가?












Dedicated to a specific task or tasks
Rich variety of microprocessors ( over 300 types )
Designs are cost-sensitive
Have real-time performance constraints
Used with Real-Time Operating Systems (RTOS)
Software failure can be life-threatening
May have constraints on power consumption
Operate over a wide-range of environmental conditions
Fewer system resources than a desktop system
All code might be stored in ROM
Require specialized design tools
May have on-chip debugging resources
Embedded System Lab. II
4
Embedded System의 특성

In general, there is no architectural link to standard platforms




Typically, have moderate to severe real-time constraints


No printf() for debugging when there is no terminal!
Tolerance for bugs is 1000X ( or more ) lower in embedded systems than
in desktop computers.




Real-time means system must be able to respond to the outside world
May or may not have Operating System ( O/S ) services available


PC ( Win9X, NT, XP, Linux), MAC, HP, Sun are considered the standard
platforms
Almost every embedded design ( hardware and software ) is unique
The hardware and software are highly integrated and interdependent
May be life-threatening consequences if system fails
Often engineered for the highest possible performance at the lowest cost
Performance may not be an important consideration
Most likely to have power constraints
Embedded System Lab. II
5
임베디드 시스템 설계

임베디드 시스템 설계 흐름


소프트웨어/하드웨어 설계팀의 활동이 유사
소프트웨어/하드웨어 구별이 모호해지고, Co-Design의 개념이 더욱 강해짐
Embedded System Lab. II
6
임베디드 시스템 설계

전형적인 임베디드 시스템 설계 라이프 사이클

7개 단계로 구성







제품 사양 작성
설계를 소프트웨어 부분과 하드웨어 부분으로 구분
소프트웨어와 하드웨어 구분의 반복과 미세 조정
독립적인 하드웨어 설계 부분과 소프트웨어 설계 부분 구현
소프트웨어 설계 부분과 하드웨어 설계 부분 통합
테스트와 출시
지속적 유지와 업그레이드
Embedded System Lab. II
7
임베디드 시스템 설계

AMD사의 daniel Mann의 임베디드 시스템 설계 라이프 사이클
Processor Selection Phase
Packaged benchmarks
Past Experience
Other Similar Designs
Applications support
Instruction Set Simulator
Benchmarking tools
Enter Here
Literature
Compiler Tool Chain
Architectural Simulator
Evaluation Board
Customer Benchmarks
Design Phase
Design Win
Hardware Designer(s)
Software Design Team
ASIC
Compiler Tool Chain
Instruction Set Simulator
Evaluation Board
Logic Simulator
Logic Analyzer
Out-of-Circuit Emulation
Oscilloscope
Initial hardware without
working memory system
Initial Software
Logic Analyzer
In-Circuit Emulator
Oscilloscope
Software running on
Hardware
Software Performance Analysis
In-Circuit Emulation
Logic Analyzer/Preprocessor
JTAG Emulation
ROM Emulation
MiniMON29K
SW/HW Integration Phase
Maintenance and upgrade of existing products
Embedded System Lab. II
8
Courtesy of
Daniel Mann
임베디드 시스템 설계

임베디드 시스템 설계 시 핵심




하드웨어와 소프트웨어가 개발할 기능을 어떤 식으로 분할 할 것인가 ?
적절한 프로세서 선택
적절한 운영체제 선택
적절한 디버깅/개발 툴 선택
Embedded System Lab. II
9
임베디드 시스템

임베디드 시스템 설계 시 핵심 요소

적절한 프로세서 선택






쉽게 구할 수 있는가?
성능은 충분한가?
적절한 운영체제가 지원하는가?
적절한 툴에 의해서 지원되는가?
적절한 운영체제 선택
적절한 디버깅/개발 툴 선택



컴파일러 툴 – 프로세서 성능에 큰 영향을 미침
하드웨어/소프트웨어 디버깅 툴

ROM Emulator

논리분석기

성능분석기

ICE(In Circuit Emulator)

온칩(on-chip) 하드웨어 디버깅 리소스 인터페이스
성능 측정 툴
Embedded System Lab. II
10
적절한 프로세서 선택
Cost of
Goods
Real-time
Constraints
Legacy
Code
Performance
Time to
Market
Tool
Support
Landmines
Embedded System Lab. II
Power
Budget
11
임베디드 프로세서 선택-1

Issue 1: 성능측면 요구사항




Width of data path
Clock speed: RAW MIPS
Processor architecture issues
Single or multiple processors
Embedded System Lab. II
12
임베디드 프로세서 선택-2

Issue 2: Integration of functions


Microprocessor or micro-controller?
Review:



The microprocessor is usually the leading edge of performance



Lowest level of integration
Highest cost
Higher levels of integration imply



A microprocessor contains the basic CPU functionality, and little more
A micro-controller combines the CPU core with peripheral devices
Lower system costs
Greater reliability
As uP matures the core moves into the uC families
Embedded System Lab. II
13
임베디드 프로세서 선택-3

Higher level of integration ( continued )




Less power
Faster
Higher processor costs
Issue 3: Use a microcontroller





Peripheral choices ( timers, ports, serial comm., A/D, etc. )
On-chip, RAM, ROM, Flash
Power requirements
Sleep modes
Commercially available or build to order ( Motorola 683XX)
Embedded System Lab. II
14
임베디드 프로세서 선택-4

Micro-controller vs System-on-Silicon

Application Specific Integrated Circuit (ASIC)




Processor is soft, the processor exists as an encoded HDL

Licensed foundries can fabricate CPU core design into actual
Intellectual Property from ARM, MIPS, Motorola Mcore, ARC

Companies do not build ASICs, called Fabless vendors
Customizable CPUs
Multiple CPU cores


Mix RISC and DSPs
Designs out with 64 (and more ) 32-bit RISC and DSP cores
Embedded System Lab. II
15
임베디드 프로세서 선택-5

Issues 4 and up: Software considerations

Legacy code base for existing architecture



C code may or may not be portable
Assembly code is definitely not portable
Instruction set architecture issues


Certain ISAs may be better for certain problems
Engineers may be more familiar with certain instruction sets
Embedded System Lab. II
16
임베디드 프로세서 선택-6

Not so obvious considerations:




Compatibility with existing tools
Processor vendor’s roadmap for the future and long-term support
Design assistance, availability of IP
Legacy code





“C is portable”, assembly code is not
Pricing and availability
Availability of third-party tools ( Emulators, debuggers)
Power consumption (power budget)
And… There are lots to choose from!


Currently there are over 100 32-bit embedded processors
About 1000 different total devices
Embedded System Lab. II
17
H/W 및 SW 분할



Recall the beginning phase of the
embedded lifecycle
A significant effort usually goes into
partitioning the “algorithm” between
the hardware components and the
software components
Critical part of the design because
mistakes made here can cause an
inferior product to result



Software team usually tasked with
picking up the pieces
Today, partitioning is becoming an almost seamless process
Tools can be used to create a generalized algorithmic solution (UML) and then
partitioned into software and hardware components
Embedded System Lab. II
18
H/W 및 SW 분할


The hardware and software in an embedded system work together to
solve a problem ( algorithm )
The decision about how to partition the software components and the
hardware components is usually dictated by speed and cost



Dedicated hardware is fast, inflexible and expensive
Reconfigurable hardware is fast, flexible and more expensive
Software is slower, more flexible and cheaper
Embedded System Lab. II
19
H/W 및 SW 분할

There has been a revolution in hardware design called Hardware
Description Languages (HDL)




Hardware design is described in HDL and then compiles to a recipe for
the silicon FAB to build the circuit


Commonly known as Verilog and VHDL
Like C, but includes extensions for real time and other hardware realities
Abstracts the design of hardware away from gates and wires to algorithms
and state machines
Called Silicon Compilation
A single HW designer can now develop an IC that required entire teams
several years ago

This has led to whole new concept of Systems-on-a-chip, or SOC
Embedded System Lab. II
20
새로운 HW/SW 설계 흐름
Iterate Software
SW Process
• Design Algorithm
• Write C/C++ Code
• Write stub-code
to simulate HW
• Compile to Object
code
Co-design
Phase
•Define the IP
•Partition IP between HW and SW
Integrate
• Design Algorithm
• Write HDL Code
( Dialect of C )
• Write test vectors
• Run Simulations
•Compile to Si
foundry database
Re-spin the ASIC
HW Process
Key Point
Embedded System Lab. II
The differences between the process of designing hardware (ASIC )
and the process of designing software are disappearing
21
Situation Worse in S/W
Billion $/Year
DoD Embedded System Costs
45
40
35
30
25
20
15
10
5
0
1980
Embedded System Lab. II
Software
Hardware
1982
1984
1986
22
1988
1990
1992
1994
On-going Paradigm Shift in
Embedded System Design



Embedded System Lab. II
23
Change in business model due to SoCs

Currently many IC companies have
a chance to sell devices for a single
board

In future, a single vendor will create
a System-on-Chip

But, how will it have knowledge of
all the domains?
Component-based design

Components encapsulate the
intellectual property
Platforms

Integrated HW/SW/IP

Application focus

Rapid low-cost customization
What is IP?

Predesigned, preverified silicon circuit block , usually containing 5000
gates, that can be used in building larger application on a semiconductor
chip
Embedded System Lab. II
24
IP-based Design
Embedded System Lab. II
25
UML and Co-design

Two new technologies have emerged that address this desire to focus on
the algorithm and not the partition

Unified Modeling Language (UML)


HW/SW Codesign



Synopsys, Mentor Graphics, VAST
UML products, such as Statemate and Rhapsody (iLogix) and Co-design
products, such as Seamless ( Mentor Graphics ) blur the distinction
between hardware and software
Output of UML tool is C++ application code and/or VHDL code


iLogix, ObjecTime, Cadence, CoWare
Partition decisions are made by which code is generated
Objective: Design the algorithm in an implementation independent way

Let the automatic code generator do the grunt work
Embedded System Lab. II
26
Unified Modeling Language

UML is a way to represent the finite-state behavior of an embedded
system:


A finite state machine is an abstract machine that defines a set of conditions
of existence ( called “states” ), a set of
behaviors or actions performed in
each of these states, and a set of events that cause changes in states
according to a finite and well-defined rule set.
Consider some examples of a finite state machine



Vending machine
Gas pump
Flight control system
Embedded System Lab. II
27
HW/SW Co-verification

After a design is partitioned and separate HW and SW development is
proceeding, how do you know that you’ll get it right?



Re-spinning an ASIC is costly
Fixing a problem in software will reduce performance
HW/SW Co-verification focuses on validating the correctness of the
design across the HW/SW interface
Embedded System Lab. II
28
임베디드 시스템 설계 - 디버깅

임베디드 시스템 설계 시간




시스템 설계에 소요되는 시간을 %로 나타내면..(다음 page)
곡선은 각 단계에서 결함을 고치는데 소요되는 비용
단계가 진행됨에 따라 디버깅에 소요되는 시간/비용이 크게 증가
임베디드 시스템 설계자의 60%가 새 제품을 만들기보다는 기존 제품을 업그레
이드하고 유지보수 하는 일을 함
Embedded System Lab. II
29
임베디드 시스템 설계 - 디버깅(2)
System
Specification
& Design
37%
HW & SW
Design/Debug
20%
Prototype
Debug
31%
System
Test
12%
51% of Time
Source: Dataquest
Embedded System Lab. II
Cost to fix
a problem
30
Maintenance
and upgrade
임베디드 시스템 Integration

Hardware/Software integration



The separate hardware designers, firmware designers and software
designers have completed unit testing their code
The hardware has been built and passes the smoke test
The hardware is turned over to the software team





Load the software image
Validate the correctness of the hardware performance against the software
design
Integrate their software with the hardware
Find the bugs
Test for performance and reliability
Embedded System Lab. II
31
임베디드 시스템 디버깅


Debugging embedded systems is made more difficult because of the
added dimension brought about by untested hardware
The process of debugging an embedded system is usually referred to as
Hardware/Software Integration

Identifies this as a unique process
The Integration “Loop”
Start
Yes
New
Test?
Stop
Embedded System Lab. II
Yes
Run Test
Pass
Test?
Re-design
physical h/w
and/or s/w
No
32
No
Debug
하드웨어 디버깅 - 1

Use an oscilloscope to look at the parametric performance of the
hardware system

Is the power supply voltage stable?



Do the bus signals look clean?




Minimal AC ripple
Within limits
Ringing on the waveform is within bounds
System noise is within acceptable bounds
All busses are properly terminated, no reflections
Is the clock(s) distribution clean?


Stable waveform without noise, undershoot or overshoot
Clock skew within acceptable limits
Embedded System Lab. II
33
하드웨어 디버깅 - 2

Verify that the processor to memory interface is stable




Memory set-up times are within acceptable limits
Hold times are long enough
Proper timing on reads and writes
Use an In-Circuit Emulator to force simple memory test programs


No need to load a program to test memory
Use a Logic Analyzer to look at bus activity to verify that all signals are
understood

Verify that the memory decoding logic is working properly
Embedded System Lab. II
34
하드웨어 디버깅 - 3

Use emulator to force accesses to peripheral devices





Memory access conflicts
All glue logic PAL equations are correct
Read and Write to ASIC registers
Read and write to registers of other peripheral devices
Use an ICE (In Circuit Emulator) to load simple HW test programs
(diagnostics)


Diagnostics will exercise hardware and verify reliability
Will not verify functionality
Embedded System Lab. II
35
운영체제 선택

An RTOS enables a design team to create a complex system that
responds to every event with the right action at the right time, every time.




Provides mechanisms to precisely synchronize a large number of tasks
Reliable
An RTOS provides mechanisms to handle faults, bugs, and other
unexpected events that inevitably affect any system of embedded
software
When the level of complexity of an embedded system is such that
partitioning the software into smaller, independently executing modules
significantly lowers the overall design complexity and leads to greater
system reliability

Time-to-market pressure balances cost of the RTOS
Embedded System Lab. II
36
RTOS - Pre-emptive schedule

General purpose operating systems are very democratic


Every task or process has equal access to the CPU
Scheduling decisions are based upon time sharing



Tasks get to execute without interruption until their time slice is up
Problem: If a less important task is running and a more important, deadline
dependent task is pending, then the higher priority task must wait its turn
RTOSes are different!


Pre-emptive scheduling allows the higher priority task to take over the CPU
from lower priority tasks
Extends from application level code to drivers and interrupts
Embedded System Lab. II
37
RTOS - Predictability


RTOSes must provide the designers with predictable performance data
for system latencies
Need to know best case and worst case scenarios for

Task switching times



Elapsed time from the completion of the last instruction of the prior task to the
beginning of execution of the first task of the replacement process
Measure of the overhead caused by the RTOS
Interrupt handling


Elapsed time from the arrival of the interrupt signal to the beginning of execution of
the first instruction of the interrupt handler
Worst case timing for a lower priority interrupt must take into account the time
required to process all higher priority interrupts
Embedded System Lab. II
38
RTOS 선택 - economic factors

Generally, we view RTOSes as intellectual property

Pay a royalty to RTOS vendor for each copy of the RTOS that you deliver in
your application ( annuity )


Cost of tools

Some RTOS vendors supply complete development and debug environments
for their customers



Example: WinCE royalty ~$15 per copy volumes > 10000
One-stop shopping
Products are well-integrated and work together
Board support packages (BSP)



Integrating an RTOS with your hardware platform ( target system ) is a nontrivial exercise
Requires expert knowledge of the O/S and hardware
Is there an existing BSP for your hardware?

Pay the O/S vendor to do it? ( $50K - $1M )
Embedded System Lab. II
39
RTOS 선택 - CPU issues

Has an RTOS been written and fine-tuned to your CPU choice?


Take advantage of specialized performance hardware on CPU?
Example:





Key kernel functions written in assembly language for maximum performance
Has performance of RTOS been fully characterized with your CPU?
Does the RTOS support the peripheral register set on your
microcontroller?


May contain shadow registers for rapid task switching
May contain special registers for storing task tables context switching.
Example: PowerPC 860 contains 200 registers for peripheral devices ( timers,
ethernet ports, other O/S relevant I/O devices) require support
Support for virtual and protected memory management?
Embedded System Lab. II
40
RTOS 선택 - Application support



How many simultaneous tasks can the RTOS support?
How many interrupts can be supported?
Does RTOS vendor provide support services for specialized applications?



FAA and FDA certification of O/S for mission critical applications
Protocol stacks for telecomm and datacomm ( TCP/IP )
Architecture of RTOS

Flat memory model



Applications and RTOS are built and linked as a single executable
Entire address space of processor is available to O/S and all applications
Generally fast, but very susceptible to crashes due to buggy code

Errant pointers can overwrite critical kernel code
Embedded System Lab. II
41