Embed Size (px)
Citation preview
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
