임베디드시스템소프트웨어설계 -...

41
Embedded System Lab. II 임베디드 임베디드 시스템 시스템 소프트웨어 소프트웨어 설계 설계 경희대학교 컴퓨터공학과 조진성

Upload: tranthu

Post on 13-Feb-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

Embedded System Lab. II

임베디드임베디드 시스템시스템 소프트웨어소프트웨어 설계설계

경희대학교 컴퓨터공학과

조 진 성

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 25

IP-based Design

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