1. Hardware-software Interface Xiaofeng Fan xiaofenf@usc.edu

2. What’s in your mind when programming? PC: Highly 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.

3. Battery EEPROMGPRS Module Air quality sensor Light sensor Temperature &humidity sensor My experience in real project

5. 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

6. 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

7. System Integration Cooperation Find best solution  Always use software solution

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

9. 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

10. 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

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

12. Launching Tasks In Hardware Who sets and clean the Coins_In bit? Software or hardware? 1 t Coins_In T T t1t2 Use a queue bit(R/W1S) rather than R/W bit!

13. 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.

14. 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

15. 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

16. Debug hook Software debug tools Hardware debug tools

17. Software Design Supporting multiple versions of hardware – Switches Interrupt handling – Edge Vs. Level Interrupts Reentrancy – Mutex, intterrupt_disable

18. Switches Compile time switches Build time switches Run time switches Self-adapting switches

19. Compile time switches

20. 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.

21. 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

22. Run time switches Include all information of supported devices in the code Make function call to get the information of the car

23. Self-adapting switches functions

24. 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.

25. Interrupt handling 1 t I/O Up-edge down-edge t1t2t3t4 If(button == 0){ delay_ms(20); if(button==1) temperature++; } while(button == 1){ delay_ms(20); temperature++; } Edge-triggered interrupt Level-triggered interrupt

26. Reentrancy Data modified by thread B will be overwritten ! Solution : Best Practice: Provide atomic access to registers that more than one device can access.

27. 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.

28. 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 single chip multi chip GP vs AS platform Software Vs Hardware Mono Vs Multipr

29. 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

30. Architecture selection (cont’d)

31. 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

32. 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

33. HW/SW Codesign Current Interface-based designHW/SW codesign Approaches to solve the problem: Interface-based design a)Create abstract models of HW/SW b)HW/SW codesign

34. Challenges Partitioning – How to divide software & hardware? No clear boundary Abstractions – How can we create abstractions for hardware/software interface?

35. 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?

36. 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.

37. Interface codesign roadmap Explicit interface Data transfer Synchronization Communication Partitioning

38. 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

39. Data transfer CPU is abstract Hardware and software modules interact by exchanging transactions

40. Sychronization Interconnect and synchronization are abstractions Hardware and software modules interact by exchanging data following protocols

41. 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

42. Partitioning Abstract the functional model in which hardware and software are not partitioned Designers can use high-level language to abstract HW/SW partitioning

43. HW/SW Codesign

44. Full codesign scheme

45. Opportunities and Challenges Improve hardware&software quality Reliability Reusability Challenges: Efficient way to create abstraction Need new technologies to integrate components