hardware-software interface xiaofeng fan xiaofenf@usc.edu

Hardware-software Interface

Xiaofeng Fanxiaofenf@usc.edu

What’s in your mind when programming?

PC:Highly reliableEasy to debug

Embedded System:Hardware and functionality need to be improved during the development routine.Hard to debug if there’s some problem related to hardware.

Battery EEPROM GPRS Module

Air quality sensor Light sensor Temperature &humidity sensor

My experience in real project

My experience in real project

Embedded Software Best Practice

• Initiate contact with the hardware engineer early in the design of the hardware.

• Review hardware design documents

Challenge: Both sides should work on the same specification

Register design toolsA Hardware

engineer write the document

A Hardware engineer read and copy the document

Soft engineer read the document and

program

Traditional way to manage the document

Hardware engineer just need input the register and port info into one file

Easy to keep the file up to date

Register design tools

System Integration

Cooperation

Find best solution Always use software solution

Hardware Design

• Notification Of Hardware Events• Launching Tasks In Hardware• Bit Field Alignment• Fixed Bit Positions• Block Version Number• Debug Hooks

Notification of Hardware Events

• Software-initiate events Completing task triggered by software Eg: Printer complete printing task

• External events Events that triggered by external signal Eg: Keyboard, mouse input

Different ways to notify the event

• No notification– Software has to guess when taking next step

• Timed delay– Hard to determine the time main loop

• Status bit – Bad for external events

• Interrupt bit– Best way

Launching Tasks In Hardware

Coins detected

Set Coins_IN = 1

Set Coins_IN = 0

Coins_IN = 1?

… …Yes

Launching Tasks In HardwareWho sets and clean the Coins_In bit?Software or hardware?

1

t

Coins_In

T T

t1 t2

Use a queue bit(R/W1S) rather than R/W bit!

Bit Field AlignmentNormal way:

Bit Field with 4-bits alignment:

Hard to read. Hard to find mistakes.

Easy to read. Can check the correctness quickly.

Fixed Bit Positions

Improvement: O(mn) -> O(n)

Best practice:• Avoid changing bit assignments from one version of the block to the next• Avoid reusing bit position of deleted bits in an existing register

Block Version Number

Version number is stored in a register

Chip-level version number:• Changed if any part of

the system changes.• Update the drives of the

whole system

Block-level version number:• Changed if the specific

block changes.• Update the drives of the

changed block

Debug hook

Software debug tools Hardware debug tools

Software Design

• Supporting multiple versions of hardware– Switches

• Interrupt handling– Edge Vs. Level Interrupts

• Reentrancy – Mutex, intterrupt_disable

Switches

• Compile time switches• Build time switches• Run time switches• Self-adapting switches

Compile time switches

Compile time switches

When using #if, use #elif to test all the possible cases as well, if there’s any unknown case, you should put out an error message.

Build time switches

If the function and variables are different , you should put the function in different files, and choose the specific file when compile and build the project.

• Speedometer_abc.c• Speedometer_vrm.c• Speedometer_xls.c

Run time switches

• Include all information of supported devices in the code

• Make function call to get the information of the car

Self-adapting switches

functions

functions

Interrupt handling

• Edge-triggered interrupt – If there’s an edge(0 to 1 or 1 to 0) detected, it will

trigger an interrupt.• Level-triggered interrupt– If there’s a high-level or low-level signal, it will

trigger an interrupt as long as the level doesn’t change.

Interrupt handling

1

t

I/O

Up-edge Up-edgedown-edge down-edge

t1 t2 t3 t4

If(button == 0){ delay_ms(20); if(button==1)

temperature++;}

while(button == 1){ delay_ms(20); temperature++;}

Edge-triggered interrupt

Level-triggered interrupt

Reentrancy

Data modified by thread B will be overwritten !

Solution :

Best Practice:Provide atomic access to registers that more than one device can access.

Architecture Selection and Mapping

• Select the underlying hardware structure on which run the modelled system

• Map the functionality captured by the system over the components of the selected architecture.

Architecture selectionUse a general purpose, existing platform and map the application on it.

Build a customised architecture strictly optimised for the particular application

Use programmable processors running software

Use dedicated electronics

Monoprocessor

Multiprocessorsingle chip

multi chip

GP vs AS platform

Software VsHardware

Mono VsMultipr

Architecture selection (cont’d)The trade-offs:

• Performance(high speed, low power consumption)

Application specific

General purpose

Hardware

Reconfigurable hardware

Software

• Flexibility(how easy it is to upgrade or modify)

General purpose

Application specific

Software

Reconfigurable hardware

Hardware

high

low

high

low

high

low

high

low

Architecture selection (cont’d)

HW/SW CodesignWhy Codesign?

• Reduce time-to-market• Achieve better designs:

More design alternatives Better solution

• To meet strict design constraints: Timing & performance Power consumption Physical constraints, e.g., size, weight, etc Safety and reliability Cost constraints

HW/SW CodesignTraditional design flow

Specification&Partitioning

HW Design&

Simulation

SW Design&

Simulation

Integration&

Test

Co-simulation&

Co-verification

Specification&Partitioning

SW Design&

Simulation

HW Design&

Simulation

Integration&

Test

Reduced Time

HW/SW Codesign

Current Interface-based design HW/SW codesign

Approaches to solve the problem:

Interface-based designa) Create abstract models of HW/SWb) HW/SW codesign

Challenges

• Partitioning– How to divide software & hardware? No clear boundary

• Abstractions– How can we create abstractions for

hardware/software interface?

Find ways outHide the CPU

SoftwareAbstraction

HardwareAbstraction

CPU

Drivers, basic I/O,OS, middleware

Registers, PINs, Buses

Low-level software layer

CPU interfaceProblem?

Software/Hardware

• Application is a body of software to be Executed on a hardware platform.

• SoC platform include a software layer called hardware-dependent software that must be codesigned with hardware interfaces.

Interface codesign roadmap

• Explicit interface• Data transfer• Synchronization• Communication• Partitioning

Explicit interfaces

• Describe hardware as RTL(Register Transfer Level) modules

• CPU acts as the HW/SW interface• Designer use explicit memory and I/O to detail

the software down to low-level C programs

Data transfer

• CPU is abstract• Hardware and software modules interact by

exchanging transactions

Sychronization

• Interconnect and synchronization are abstractions

• Hardware and software modules interact by exchanging data following protocols

Communication

• Communication protocol is abstraction• Hardware and software modules interact by

exchanging abstract data without protocols• Usually use Specification and Description

Language to abstract communication

Partitioning

• Abstract the functional model in which hardware and software are not partitioned

• Designers can use high-level language to abstract HW/SW partitioning

HW/SW Codesign

Full codesign scheme

Opportunities and Challenges

• Improve hardware&software quality• Reliability • ReusabilityChallenges:• Efficient way to create abstraction• Need new technologies to integrate

components