임베디드시스템소프트웨어설계 -...
TRANSCRIPT
Embedded System Lab. II 2
주요내용
주요내용
임베디드시스템특성
임베디드시스템설계과정
임베디드시스템설계핵심요소
프로세서선택
운영체제선택
소프트웨어/하드웨어분할개발툴/디버깅/테스트
Embedded System Lab. II 3
왜 embedded system인가?Embedded systems are key elements of our society today
An adequate supply of competent designers is a rate limiting factor in our economies ability to grow
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:
IgnoredConceded to Electrical Engineering DepartmentsTreated 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 demandIt’s a really fun topic!
Embedded System Lab. II 4
Embedded System은무엇이다른가?Dedicated to a specific task or tasksRich variety of microprocessors ( over 300 types )Designs are cost-sensitiveHave real-time performance constraintsUsed with Real-Time Operating Systems (RTOS)Software failure can be life-threateningMay have constraints on power consumptionOperate over a wide-range of environmental conditionsFewer system resources than a desktop systemAll code might be stored in ROMRequire specialized design toolsMay have on-chip debugging resources
Embedded System Lab. II 5
Embedded System의특성In general, there is no architectural link to standard platforms
PC ( Win9X, NT, XP, Linux), MAC, HP, Sun are considered the standard platformsAlmost every embedded design ( hardware and software ) is uniqueThe hardware and software are highly integrated and interdependent
Typically, have moderate to severe real-time constraintsReal-time means system must be able to respond to the outside world
May or may not have Operating System ( O/S ) services availableNo printf() for debugging when there is no terminal!
Tolerance for bugs is 1000X ( or more ) lower in embedded systems than in desktop computers.
May be life-threatening consequences if system failsOften engineered for the highest possible performance at the lowest costPerformance may not be an important consideration
Most likely to have power constraints
Embedded System Lab. II 6
임베디드시스템설계
임베디드시스템설계흐름
소프트웨어/하드웨어설계팀의활동이유사소프트웨어/하드웨어구별이모호해지고, Co-Design의개념이더욱강해짐
Embedded System Lab. II 7
임베디드시스템설계
전형적인임베디드시스템설계라이프사이클
7개단계로구성제품사양작성
설계를소프트웨어부분과하드웨어부분으로구분
소프트웨어와하드웨어구분의반복과미세조정
독립적인하드웨어설계부분과소프트웨어설계부분구현
소프트웨어설계부분과하드웨어설계부분통합
테스트와출시
지속적유지와업그레이드
Embedded System Lab. II 8
임베디드시스템설계
AMD사의 daniel Mann의임베디드시스템설계라이프사이클
Literature
Compiler Tool Chain
Architectural Simulator Evaluation Board
Customer Benchmarks
Processor Selection Phase Enter Here
Packaged benchmarksPast ExperienceOther Similar DesignsApplications supportInstruction Set SimulatorBenchmarking tools
Design Win
Compiler Tool Chain
Instruction Set Simulator Evaluation Board Out-of-Circuit Emulation
Initial Software
Software Design Team
Logic Simulator Logic Analyzer Oscilloscope
Initial hardware without working memory system
Hardware Designer(s)ASIC
Logic Analyzer In-Circuit Emulator Oscilloscope
Software running onHardware
Design Phase
In-Circuit Emulation Logic Analyzer/Preprocessor JTAG Emulation ROM Emulation MiniMON29K
SW/HW Integration Phase
Software Performance Analysis
Maintenance and upgrade of existing products Courtesy ofDaniel Mann
Embedded System Lab. II 9
임베디드시스템설계
임베디드시스템설계시핵심
하드웨어와소프트웨어가개발할기능을어떤식으로분할할것인가 ?적절한프로세서선택
적절한운영체제선택
적절한디버깅/개발툴선택
Embedded System Lab. II 10
임베디드시스템
임베디드시스템설계시핵심요소적절한프로세서선택쉽게구할수있는가?성능은충분한가?적절한운영체제가지원하는가?적절한툴에의해서지원되는가?
적절한운영체제선택
적절한디버깅/개발툴선택컴파일러툴 –프로세서성능에큰영향을미침하드웨어/소프트웨어디버깅툴
ROM Emulator논리분석기
성능분석기
ICE(In Circuit Emulator)온칩(on-chip) 하드웨어디버깅리소스인터페이스
성능측정툴
Embedded System Lab. II 11
적절한프로세서선택
PowerBudget
Cost ofGoods
Real-timeConstraints Legacy
Code
PerformanceTime toMarket
Landmines
Tool Support
Embedded System Lab. II 12
임베디드프로세서선택-1Issue 1: 성능측면요구사항
Width of data path Clock speed: RAW MIPSProcessor architecture issuesSingle or multiple processors
Embedded System Lab. II 13
임베디드프로세서선택-2Issue 2: Integration of functions
Microprocessor or micro-controller?Review:
A microprocessor contains the basic CPU functionality, and little moreA micro-controller combines the CPU core with peripheral devices
The microprocessor is usually the leading edge of performance Lowest level of integrationHighest cost
Higher levels of integration implyLower system costsGreater reliability
As uP matures the core moves into the uC families
Embedded System Lab. II 14
임베디드프로세서선택-3Higher level of integration ( continued )
Less powerFasterHigher processor costs
Issue 3: Use a microcontrollerPeripheral choices ( timers, ports, serial comm., A/D, etc. )On-chip, RAM, ROM, FlashPower requirementsSleep modesCommercially available or build to order ( Motorola 683XX)
Embedded System Lab. II 15
임베디드 프로세서 선택-4
Micro-controller vs System-on-SiliconApplication Specific Integrated Circuit (ASIC)
Processor is soft, the processor exists as an encoded HDLLicensed foundries can fabricate CPU core design into actual
Intellectual Property from ARM, MIPS, Motorola Mcore, ARCCompanies do not build ASICs, called Fabless vendors
Customizable CPUsMultiple CPU cores
Mix RISC and DSPsDesigns out with 64 (and more ) 32-bit RISC and DSP cores
Embedded System Lab. II 16
임베디드프로세서선택-5Issues 4 and up: Software considerations
Legacy code base for existing architectureC code may or may not be portableAssembly code is definitely not portable
Instruction set architecture issuesCertain ISAs may be better for certain problemsEngineers may be more familiar with certain instruction sets
Embedded System Lab. II 17
임베디드프로세서선택-6Not so obvious considerations:
Compatibility with existing toolsProcessor vendor’s roadmap for the future and long-term supportDesign assistance, availability of IPLegacy code
“C is portable”, assembly code is notPricing and availabilityAvailability 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 18
H/W 및 SW 분할Recall the beginning phase of the embedded lifecycleA significant effort usually goes into partitioning the “algorithm” between the hardware components and the software componentsCritical 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 processTools can be used to create a generalized algorithmic solution (UML) and then partitioned into software and hardware components
Embedded System Lab. II 19
H/W 및 SW 분할The hardware and software in an embedded system work together tosolve 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 expensiveReconfigurable hardware is fast, flexible and more expensiveSoftware is slower, more flexible and cheaper
Embedded System Lab. II 20
H/W 및 SW 분할There has been a revolution in hardware design called Hardware Description Languages (HDL)
Commonly known as Verilog and VHDLLike C, but includes extensions for real time and other hardware realitiesAbstracts the design of hardware away from gates and wires to algorithms and state machines
Hardware design is described in HDL and then compiles to a recipe for the silicon FAB to build the circuit
Called Silicon CompilationA 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 21
새로운 HW/SW 설계 흐름
Co-designPhase
•Define the IP •Partition IP between HW and SW
SW Process
HW Process
• Design Algorithm• Write C/C++ Code
• Design Algorithm• Write HDL Code( Dialect of C )
• Write test vectors• Run Simulations
• Write stub-code to simulate HW
• Compile to Object code
•Compile to Sifoundry database
Integrate
Iterate Software
Re-spin the ASIC
Key Point The differences between the process of designing hardware (ASIC ) and the process of designing software are disappearing
Embedded System Lab. II 22
Situation Worse in S/W
05
1015202530354045
1980 1982 1984 1986 1988 1990 1992 1994
Hardware
Software
DoD Embedded System CostsB
illio
n $/
Yea
r
Embedded System Lab. II 23
On-going Paradigm Shift inEmbedded System Design
Change in business model due to SoCsCurrently many IC companies have a chance to sell devices for a single boardIn future, a single vendor will create a System-on-ChipBut, how will it have knowledge of all the domains?
Component-based designComponents encapsulate the intellectual property
PlatformsIntegrated HW/SW/IPApplication focusRapid low-cost customization
Embedded System Lab. II 24
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 26
UML and Co-designTwo new technologies have emerged that address this desire to focus on the algorithm and not the partition
Unified Modeling Language (UML)iLogix, ObjecTime, Cadence, CoWare
HW/SW CodesignSynopsys, 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 softwareOutput of UML tool is C++ application code and/or VHDL code
Partition decisions are made by which code is generatedObjective: Design the algorithm in an implementation independent way
Let the automatic code generator do the grunt work
Embedded System Lab. II 27
Unified Modeling LanguageUML 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 machineVending machineGas pumpFlight control system
Embedded System Lab. II 28
HW/SW Co-verificationAfter 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 costlyFixing 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 29
임베디드시스템설계 -디버깅임베디드시스템설계시간
시스템설계에소요되는시간을%로나타내면..(다음 page)곡선은각단계에서결함을고치는데소요되는비용
단계가진행됨에따라디버깅에소요되는시간/비용이크게증가임베디드시스템설계자의 60%가새제품을만들기보다는기존제품을업그레이드하고유지보수하는일을함
Embedded System Lab. II 30
임베디드 시스템 설계 - 디버깅(2)
SystemSpecification
& Design
HW & SWDesign/Debug
PrototypeDebug
Source: Dataquest Cost to fixa problem
12%37% 20% 31%
51% of Time51% of Time
SystemTest
Maintenance and upgrade
Embedded System Lab. II 31
임베디드시스템 IntegrationHardware/Software integration
The separate hardware designers, firmware designers and softwaredesigners have completed unit testing their codeThe hardware has been built and passes the smoke test
The hardware is turned over to the software team Load the software imageValidate the correctness of the hardware performance against the software designIntegrate their software with the hardwareFind the bugsTest for performance and reliability
Embedded System Lab. II 32
임베디드시스템디버깅
Debugging embedded systems is made more difficult because of theadded dimension brought about by untested hardwareThe process of debugging an embedded system is usually referred to as Hardware/Software Integration
Identifies this as a unique process
New Test? Run Test
PassTest?
Debug
Re-design physical h/w and/or s/w
The Integration “Loop”
Yes
Yes
No
NoStop
Start
Embedded System Lab. II 33
하드웨어디버깅 - 1Use an oscilloscope to look at the parametric performance of thehardware system
Is the power supply voltage stable?Minimal AC rippleWithin limits
Do the bus signals look clean?Ringing on the waveform is within boundsSystem noise is within acceptable boundsAll busses are properly terminated, no reflections
Is the clock(s) distribution clean?Stable waveform without noise, undershoot or overshootClock skew within acceptable limits
Embedded System Lab. II 34
하드웨어디버깅 - 2Verify that the processor to memory interface is stable
Memory set-up times are within acceptable limitsHold times are long enoughProper timing on reads and writesUse an In-Circuit Emulator to force simple memory test programs
No need to load a program to test memoryUse 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 35
하드웨어디버깅 - 3Use emulator to force accesses to peripheral devices
Memory access conflictsAll glue logic PAL equations are correctRead and Write to ASIC registersRead 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 reliabilityWill not verify functionality
Embedded System Lab. II 36
운영체제선택
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 tasksReliable
An RTOS provides mechanisms to handle faults, bugs, and other unexpected events that inevitably affect any system of embedded softwareWhen 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 37
RTOS - Pre-emptive scheduleGeneral purpose operating systems are very democratic
Every task or process has equal access to the CPUScheduling decisions are based upon time sharing
Tasks get to execute without interruption until their time slice is upProblem: 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 tasksExtends from application level code to drivers and interrupts
Embedded System Lab. II 38
RTOS - PredictabilityRTOSes must provide the designers with predictable performance data for system latenciesNeed to know best case and worst case scenarios for
Task switching timesElapsed time from the completion of the last instruction of the prior task to the beginning of execution of the first task of the replacement processMeasure of the overhead caused by the RTOS
Interrupt handlingElapsed time from the arrival of the interrupt signal to the beginning of execution of the first instruction of the interrupt handlerWorst case timing for a lower priority interrupt must take into account the time required to process all higher priority interrupts
Embedded System Lab. II 39
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 )
Example: WinCE royalty ~$15 per copy volumes > 10000
Cost of toolsSome RTOS vendors supply complete development and debug environments for their customers
One-stop shoppingProducts are well-integrated and work together
Board support packages (BSP)Integrating an RTOS with your hardware platform ( target system ) is a non-trivial exerciseRequires 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 40
RTOS 선택 - CPU issues Has an RTOS been written and fine-tuned to your CPU choice?
Take advantage of specialized performance hardware on CPU?Example:
May contain shadow registers for rapid task switchingMay contain special registers for storing task tables context switching.
Key kernel functions written in assembly language for maximum performanceHas performance of RTOS been fully characterized with your CPU?Does the RTOS support the peripheral register set on your microcontroller?
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 41
RTOS 선택 - Application supportHow 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 applicationsProtocol stacks for telecomm and datacomm ( TCP/IP )
Architecture of RTOSFlat memory model
Applications and RTOS are built and linked as a single executableEntire address space of processor is available to O/S and all applicationsGenerally fast, but very susceptible to crashes due to buggy code
Errant pointers can overwrite critical kernel code