Hardware-software Interface - PowerPoint Presentation

Hardware-software Interface Xiaofeng Fan xiaofenf@usc.edu

What’s in your mind when programming? PC: H ighly reliable Easy 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 tools A 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 NumberDebug 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 bitBest way

Launching Tasks In Hardware Coins detected Set Coins_IN = 1 Set Coins_IN = 0 Coins_IN = 1? … … Yes

Launching Tasks In Hardware Who 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 Alignment Normal 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 V ersion 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 S witches Interrupt handling Edge Vs. Level InterruptsReentrancy 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-edge down-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 selection Use 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 Multiprocessor s ingle chip multi chip GP vs AS platform Software Vs Hardware Mono Vs Multipr

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 Codesign Why 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 Codesign Traditional 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 design Create abstract models of HW/SW 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 out Hide the CPU Software Abstraction Hardware Abstraction CPU Drivers, basic I/O,OS, middleware Registers, PINs, Buses Low-level software layer CPU interface Problem?

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 CommunicationPartitioning

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 Reusability Challenges: Efficient way to create abstractionNeed new technologies to integrate components