hardware/software codesign of embedded systems

University of Ottawa, SITE, 2008

VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS

Hardware/Software Codesign of

Embedded Systems

InterfaceSystem on ChipVoicu Groza

School of Information Technology and Engineering

[email protected]



Presentation Outline

• Hardware-Software Codesign

• HW-SW Interface

• System-on-Chip



• Codesign tools automatically produce an optimized design from some initial high level specification!!!????

• Realistic goal: to incorporate the support for shifting functionality and implementation between HW & SW, with effective and efficient evaluation. The prototype is the output, based on currently available platforms (software compilers and commercial hardware synthesis tools).

• Codesign does not aim to reinvent the wheel of system design, but the necessary flexibility must be effectively incorporated.

PROM

High level system

description

CODESIGNTOOLS

HW SW

VH

DL

C

compilerHWsynthesis

ASIC/FPGA

HW/SW CoDesign Utopian View



•Combined•Concurrent •Cooperative•Unification

Design of HW/SW

HW SW

Classic Design

HW SW

HW/SW CODESIGN

= Applying Concurrent Engineering techniques in designing complex HW/SW products



System Specification

Hardware/Software Partitioning

Hardware/Software Partitioning

Hardware Description Software Description

HW Synthesis & ConfigHW Synthesis & ConfigSW Generation & ParameterizationSW Generation & Parameterization

Interface SynthesisInterface Synthesis

Hardware/Software Integration and CosimulationHardware/Software Integration and Cosimulation

Config. Modules SW Components

HW/SW Interfaces HW ComponentsHW Components

Integrated SystemSystem EvaluationSystem Evaluation Design VerificationDesign Verification

HW/SW INTERFACES

Analysis of Constraints and RequirementsAnalysis of Constraints and Requirements



HW/SW Interface

•CFSM Events

•Event Implementation

•Synthesize Glue Between IPs



HW/SW Interface Synthesis



A B

IP

A B

Synthesize Glue between IPstype yow { byte r, byte s }

• At system level, A and B are abstract

• In implementation, A & B are concrete

• Concrete IP have different interfaces

• May map to either HW or SW

• To make IP integration effective,

must synthesize interface

A B

Concrete IPImplementations

HW

SWOR



A B

IP

A B

Synthesize glue between IPs

Abstract IPtype yow { byte r, byte s }

ProtocolSpecificationsfor Concrete IPs

A B

Concrete IPImplementations

Synthesize!Glue

Glue HW

SWOR



A Vision for System Design

USB

System Bus

WirelessDSP

Proc Proc ASIC

Memory

process mapping

communication mapping



HW/SW Interface• Three classes of partitioned CFSMs:

– SW: mapped to software– HW: mapped to hardware– MP: mapped to micro-controller peripherals

• RTOS functions:– Enable communication between SW-CFSMs and

SW-CFSMs, HW-CFSMs, MP-CFSMs• define emits and detects using

– memory, – I/O ports and – interrupts

– Coordinate SW - CFSMs• keep track which SW-CFSMs are ready to execute decide

which one to execute



Events: SW to SW

• For every event, RTOS maintains– global values– local flags

CFSM1

CFSM2

CFSM3

emit x( 3 ) x

x

x

3

detect x



Events: SW to SW

• Implement atomicity by double buffering:– always read from frozen– others always write to live– at the beginning of task execution, switch

CFSM

frozenlive



Event Implementation

• SW to HW – allocate I/O port bits for value and

occurrence flag• write value to I/O port• create a pulse on occurrence flag

• SW to/from MP– use emit, detect functions from the library



Events: HW to SW• Event can be polled or driving an interrupt• For polled events:

– allocate I/O port bits for value, occurrence and acknowledge flags

– generate the polling task that acknowledges and emits all polled events that have occurred

• For events driving an interrupt:– allocate I/O port bits for value, – allocate an interrupt vector,– create an Interrupt Service Routine that emits an

event



Interfaces among Partitions• Automatically generated in both HW and SW (RTOS)• Hardware: standardized strobe/data protocol

(corresponding to the event/value primitive)• Allows one to use hand-designed modules

(following the interfacing convention)

SenderSender ReceiverReceiverAA BB CC

Sender’s domainSender’s domain Channel’s domainChannel’s domainReceiver’s domainReceiver’s domain



Example of Interface: HW to SW

HWHW SWSW

xx

ackack

yy

(11 + 0 -) / 0(11 + 0 -) / 0- 1 / 0- 1 / 0

- 0 / 1- 0 / 1

1 1 0 / 10 / 1x ack / yx ack / y

x x

yy

ackack

HWtoSWHWtoSW

1100



Events: Interrupts

Two user-selectable choices:– Minimize blocking for other tasks and ISRs:

ISR() { emit x

}

– Minimize latency for this event:ISR() { emit x execute SW-CFSM

}

X RTOS

X

HW-CFSM

SW-CFSM

IRQ



HW/SW Interface Architecture

mC

decoder

busprot.conv. oe

decoderwe

address bus

data bus

HW->SWpolledevent,value

HW->SWintr. event

SW->HWevent,value

irq

SW HW

decoder/mux



Micro-controller peripherals• Custom HW (fully programmable, expensive)• On-chip or off-chip peripheral (partially

programmable, inexpensive)

CPUA/D

Timer

I/O ports

RAM

EPROM



Peripheral modeling approach• Ideally: implement specified function using

peripherals (if possible)• Currently: use three models

– Behavioral (Ptolemy) model for co-simulation– CFSM model for RTL co-simulation and rapid prototyping– C model for implementation (programming and

interfacing with the peripheral)

• Parameters customize all models simultaneously(plug-in replacement of abstraction levels)

• Synthesizable CFSM model key to limited re-targetability



Peripheral modeling approach• The user must

– decide in advance which functions may need to be implemented on a library peripheral

– choose the best fitting model from a library– co-simulate to decide implementation

(SW, custom HW, peripheral, …)

• The co-design environment takes care of:– synthesizing in SW or HW– extracting peripheral programming SW from library

(may be partially micro-controller independent)

– interfacing transparently



Communication synthesis

Mapping of Behavior to Architecture

FunctionalPrototype

Co-Simulation

Communication Communication SynthesisSynthesis

Behavioral Description

Architectural Description



Communication Infrastructure

consumerportBproducer portA Message1

synthesized sw/hw software library hardware library

inter face glue

NetComm.

Chip

Net / Message1on-chipNetComm.

ProcessorY

Net dev.driver

portB

protocol

scheduler

initiali-zation

messagerouter

consumerProcessorX

producer

Net dev.driver

portA

protocol

scheduler

initiali-zation

messagerouter

Designer maps – processes to processors and – messages to busses/protocols



System on a Chip

• Rationale

• Typical SoC

• Core-Based Design



Systems-on-chip

• Started with the idea of integrating all components in a board into a single chip.

• In the last 20 years the technologies implementing embedded systems evolved from microcontrollers and discrete components to fully integrated systems-on-chip (SoC)

• SoCs and related technologies are the engines of embedded systems in the foreseeable future.

• To increase the productivity for future designs, the approach of reusable components was adopted = intellectual property cores (IPs).



Why SoC?

• System architects cannot afford design restarts.

• HW and SW design teams cannot afford n design iterations or to learn all the details about every potential IP core.

• System managers cannot afford to reinvest in completely new tools.

• IC business managers cannot afford missing customer market windows or foundry schedules.

• Industry shifts from ASICs to systems-on-a-chip.



SYSTEM-ON-A-CHIP (SOC) Rationale • Industry shifts from ASICs to systems-on-a-chip,• New concepts, such as design re-use, Intellectual Property

(IP) utilization, and system-level co-design have been widely embraced, while practical solutions have yet to be developed.

• System architects cannot afford design restarts. • Hardware and software design teams cannot afford

endless design iterations or to learn all the details about every potential IP core.

• EDA system managers cannot afford to reinvest in completely new tools.

• IC business managers cannot afford missing customer market windows or foundry schedules.



SoC Architecture

• Heterogeneous processors – those used to run the end application and – those dedicated to execute specific functions that could

have been designed in hardware.

• Application-specific Intellectual Property (IP) cores• Communication interconnect.



SOC Design• Language-independent methodology for system specification

– Accurately capture a concept into an architecture-independent specification

– Easy definition of blocks and modules– Facilitate concurrent execution of blocks + separate the behavior and

communication of those blocks.

• Provides the ability to animate the system specification and validate/debug the required product functionality prior to costly design implementation.

• The specification allows existing modules, with different abstraction levels, to be re-used.

• A complete test bench, for checking the system, is developed at this stage.

• Open SystemC community recommends to using C and C++



Optimal SOC Design-to-Implementation Process

Top-Down Design Flow

• design (capturing and animating the system specification),

• co-design – hardware/software partitioning– interface design– co-simulation

• co-implementation (design refinement in parallel and co-verification)

• IP re-use.



SOC Co-Design • Different architectures (such as processor cores: ARM,

DSP) are selected for possible implementation, to explore various HW/SW partitioning tradeoffs.

• Select the corresponding communication mechanisms (memory mapped I/O, fast interrupt request etc.,) for a given target core

• Generate the corresponding software device drivers and the corresponding hardware glue logic to allow for quick exploration of different partitioning schemes.

• System verification at different abstraction levels. – Un-timed models– Instruction accurate models– Bus cycle accurate models

• Virtual prototype at the earliest stage of design => faster simulation. Traditional hardware-software co-verification with the hardware in HDL code running in an RTL simulator



SOC Co-Implementation • Once the HW/SW partitioning is agreed to, the different

SW development teams and HW design teams work in parallel to further optimize the software and gradually refine the hardware while constantly remaining consistent with the original system specification.

• Changes in SW are communicated to the HW team and resultant changes in the HW are made. The converse should be true for HW originated changes.

• The output of the HW portion is synthesizeable RTL and the process flow therefore allows co-verification of HW and the actual binary code of the software running on a model of the processor core.

• IP re-use at all levels (silicon IP, gate level IP, RTL IP)



SYSTEM-ON-A-CHIP (SOC) Design Forms• vendor design• partial integration • desktop design

SOC Vendor Design• An ASIC vendor or a design services group designs the

core and ASIC to meet a customer’s functional specification.

• Gives the system designer little or no control over the design schedule and may result in a longer time to market and less design flexibility

• Can lead to the lowest production cost per die• May result in high engineering costs, to be used for high-

volume applications.



SOC Partial Integration

• The system designer creates most or all the ASIC gates, and the ASIC vendor designs and integrates the core with the customer’s ASIC logic.

• Provides a more flexible division of labor, and the system designer has some control over the design schedule.

• Dominant approach in the past

SOC Desktop Design• Gives the system designer the most flexibility and enables the fastest time to

market• The ASIC vendor designs the core, and the system designer builds the

ASIC logic and integrates the core, using a standard ASIC design flow.• The ASIC vendor is no longer the design schedule gatekeeper. • This approach incurs the lowest engineering cost and is suitable for lower-

volume solutions.



Intellectual Property (IP) Cores• Hard cores are provided as black boxes, usually in

layout form in a given technology and with an encrypted simulation model. Examples of hard cores are microprocessors, phase-locked loops mixed signal blocks.

• Firm cores are provided as a synthesized netlist in a hardware-description language (HDL), that is, after logic synthesis and technology mapping, but without layout information. These cores can be simulated and changed if necessary.

• Soft cores are given as register-transfer level HDLs, and the user is responsible for its synthesis and layout. Usually along with the soft cores, the IP providers also supply synthesis and layout scripts and timing assertions.



Types of Cores • Synthesizable core• Soft core • Firm core • Hard core

• Comes in a technology-independent high-level description language form.

• The core’s lay-out is completely flexible, but its speed and density are limited by the characteristics of the ASIC cell library in which it is implemented.

• Require ground-up synthesis, test, static timing analysis, and user verification.

• Their flexibility limits their “drop-in” design usability and their ability to leverage performance and area optimization characteristics.



• Is a technology-dependent gate-level netlist.• May include a small amount of high-level technology-

independent code that a designer can use to parameterize the core during synthesis.

• Because of the core’s technology-dependent nature, its size and speed are more predictable than those of synthesizable cores.

• The soft core’s layout is flexible, but floor-planning guidelines may be necessary to achieve performance targets.




• Comes in the form of an encrypted or abstracted black box that protects the core’s intellectual property content.

• Designers incorporate a firm core into an ASIC design (in the same manner as a library element).

• The ASIC vendor lays out the core, using a technology-dependent gate-level netlist. This provides flexibility in the chip layout process because the core form factor is not fixed.

• A firm core’s size, aspect ratio, and pin location can be changed to meet a customer’s chip layout needs, and floor-planning guidelines assist the chip designer in making trade-offs.

• The technology-specific nature of a firm core makes it highly predictable in performance and area.

• Because layout uses a gate-level netlist, a firm core has the same routability as a soft core.

Types of Cores• Synthesizable core• Soft core • Firm core • Hard core



• Is an encrypted or abstracted black box, which designers incorporate into an ASIC design in the same manner as a standard cell library element.

• Have a fixed, custom physical layout. • The technology-specific layout allows maximum optimization

in terms of performance and density.• Have the most limited vendor portability and greatest difficulty

of reuse when moving to a new process technology. • May contain significant routing blockages (poor porosity),

making the placement of other blocks and chip-level routing difficult.




IP-Based Design of Implementation

DSP RAMDSP RAM

ExternalExternalI/OI/O

System System RAMRAM

DSPDSPProcessorProcessor

Pro

cess

or B

usPr

oces

sor B

us

ControlControlProcessorProcessor

MPEGMPEG

PeripheralPeripheral

AudioAudioDecodeDecode

Which DSPProcessor? C50?

Can DSP be done onMicrocontroller?

Which Bus? PI?AMBA?

Dedicated Bus forDSP?

WhichMicrocontroller?

ARM? HC12?

Do I need a dedicated Audio Decoder?Can decode be done on Microcontroller?

How fast will myUser Interface

Software run? HowMuch can I fit on my

Microcontroller?

Can I Buyan MPEG2

Processor?Which One?



• Economics• Productivity• Process • IP Delivery & Reuse•Tools & Methodology•Manufacturing

How do we move SoC Design from the pilot line to production ?How do we move SoC Design from the pilot line to production ?

Source:M.Pinto, CTO, Agere

Issues Limiting SOC Ramp



Validating Designs

• By construction– property is inherent.

• By verification– property is provable.

• By simulation– check behavior for all inputs.

• By intuition– property is true. I just know it is.

• By assertion– property is true. Wanna make something of it?

• By intimidation– Don’t even try to doubt whether it is true

It is generally better to be higher in this list

SOURCE: Alberto Sangiovanni-Vincentelli,University of California at Berkeley



State-of-the-Practice• DSP Tools: develop algorithms by creating and simulating block diagrams, and most generate C or HDL code: Matlab™ from Mathworks Inc., Signal Processing WorkSystem of Cadence Design Systems, COSSAP from Synopsys.

State Diagram Entry Tools support system-level block diagram entry and simulation, Statemate Magnum/i-Logix, Stateflow/Mathworks HDL Simulators, Verilog-XL™ & Leapfrog™ VHDL of Cadence Design Syst, VCS and VSS from Synopsys, MTI from Mentor Graphics.

Software Development Tools (IDE) compilers, real time operating systems, and various tools used to enable simulation and debugging with the instruction set simulator of the processor (WindRiver, ARM, etc.) Co-Verification Tools of what have been already completely designed: CoWare N2C, Eaglei™ from Synopsys, Seamless CVE™ from Mentor Graphics,.



CANADIAN MICROELECTRONICS CORPORATION

Rapid-Prototyping Platform



PC/DataBased

PC-1

laptop

InternetAccess

PC-2

Printer

Telecom Based

VideoPhone

VoicePhone

PDA

Intercom

Appliance Based

Sprinklers

Toasters

Ovens

Clocks

ClimateControl

UtilityCustomization

Security Based

DoorSensorsMotion

Detectors WindowSensors

LightControl

AudioAlarms

Video surveillance

SmokeDetectors

Entertainment Based

Stereo

TV

Cam Corder

StillCamera

VideoGame

VCR

DVDPlayer

Web-TVSTB

Home Networking

SOURCE: Alberto Sangiovanni-Vincentelli,University of California at Berkeley



Conclusions

• Computer-aided SW/HW Engineering (CASHE) framework/tools still “under construction”

• Current combination of EDA/CAD tools – are too slow => distributed systems – have incompatible formats => too many translators

• First integrated EDA environments for dedicated SoC applications

• Codesign will become reality as soon as corporate entities recognize its full benefits



THE Conclusion

• HW/SW Codesign for Embedded Systems is a “cut & paste” technology

• To fit these parts in the big picture, one has to understand them, i.e., to know

– Electronics,– Logic design, – Computer architecture, – Software engineering.



Problem: atomicity of transition

• TASK 1 detects y AND NOT x, which is never true

• To avoid, need atomic detects

TASK 1detect x

detect y

TASK 2

emit x

TASK 3

if detect x then emit y

hardware/software codesign of embedded systems

Documents