Quick example

1
SE 746-NT Embedded Software Systems
Development Robert Oshana Lecture
8 For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu
2
Lecture 8

• The embedded
• design life cycle

3
Agenda

• Product specification
• Hardware/software partitioning
• Hardware/software integration

Chapter 1
4
Embedded design life cycle

• Not as simple as we think (see figure)
• Much iteration and optimization
• Defects can force you back to beginning
• Performance problems
• Rewrite algorithms
• Design custom hardware
• Speed up processor
• New processor

5
Phase representation of the life cycle
6
Embedded design life cycle

• Economics and reality of design requirements can
  force decisions to be made before designers can
  consider the best design trade-offs
• If its only performance and cost, then often a
  clean sheet of paper
• Maintenance and upgrade can be a burden

7
Tools used in the design process
8
Product specification

• RD engineers want everything
• Wastes time and resource
• Marketing and sales will usually execute the
  product specification
• Engineers, however, should be involved in some
  customer tours
• CPIF
• Hearing the customer is good

9
Common success factors

• Design team shares a common vision of the product
• Failed projects did not share a common vision of
  project goals
• Low cost medium performance versus time to market
  versus high performance and medium cost
• Often overlooked part of the product
  specification phase is the development tools
  required

10
Common success factors

• Embedded systems projects are late to market
  because engineers do not have access to the best
  tools
• Should be part of the product specification
• Prevents unrealistic expectations
• Is/is not list or musts and wants

11
Hardware/software partitioning

• Embedded design usually involves hardware and
  software
• What is the partitioning decision?
• Different than application developers
• Hard to think about h/w enhanced to address parts
  of a problem
• The old days of co-processors (FPUs)

12
Example of h/w s/w paritioning

• Modem for a PC
• 1. Purchase a modem that plugs into an ISA slot
• Contains modulation/demodulation circuitry on the
  board
• 2. Winmodem that plugs into PCI slot (less ) and
  uses computers CPU to directly handle modem
  functions

13
Algorithm

• Steps required to implement a design
• Combination of hardware components and software
  components
• Hardware/software partitioning involves how to
  partition the algorithm (software only, hardware
  only, combination)

14
Laser printer design

• First understand the algorithm (see figure)
• Software only
• Processor places incoming data stream into a
  memory buffer (RS-232, USB, etc)
• Processor services data port and converts to
  modulation and control signals
• Send data/signal to laser tube, rotating mirror,
  rotating drum, etc
• This might bog down the micro (limit performance)

15
Laser printer design
16
Laser printer design

• Improve performance by adding more processors
• More speed but better?
• Identify certain tasks critical to performance
  and use a hardware block to implement
• Maybe this is writing the laser dots to the
  photosensitive surface of printer drum
• Frees up processor to do other things

17
Laser printer design

• But its more costly and complicated to fix
  hardware as opposed to s/w
• Custom solutions like ASIC more complicated still
• So do we fine tune the software?
• Time required to analyze the code and decide if
  this is the best solution

18
Laser printer design

• If a new processor is needed
• New tools
• New board layouts
• Wider data paths
• Greater complexity
• Specialized hardware gt several orders of
  magnitude increase
• Hard to get 100X or 1000X performance by fine
  tuning software

19
Laser printer design

• These two different philosophies are actually
  implemented today!
• Ability to fine tune software
• Throwing ASIC designers at the problem
• Both have competitive products
• Different design strategy for partitioning the
  design into hardware and software

20
Embedded design requirements

• Price sensitive
• Leading edge performers
• Non-standard
• Market competitive
• Proprietary
• These are conflicting in many ways!

21
Embedded design requirements

• Algorithm partitioning depends on which processor
  is used in the design
• Several hundred to choose from!!
• Choice of CPU impacts the partitioning decision
  which impacts the tools decisions, etc

22
Embedded design requirements

• n-space of possible choices
• Experience required to arrive at optimal design
• Solution surface is smooth
• Adequate solution not far off from the best
  solution
• Constraints dictate the decision path

23
Iteration and implementation

• Hardware and software paths begin to diverge
• Early design work before the walls go up (between
  h/w and s/w)
• Design still very fluid
• Major blocks partitioned
• Boundary can still be moved
• Iteration is common

24
Iteration and implementation

• Hardware team
• Simulation tools to model performance
• Software team
• Running code benchmarks on self contained systems
  (eval boards)
• Convenient development environment until the
  hardware arrives!
• Tools are helping (keep h/w, s/w engaged longer)
• More to come later

25
Hardware/software integration

• Special tools and methods to manage the
  complexity
• Process of integrating h/w and s/w requires
  debugging and discovery
• Did the software team really understand the
  hardware spec

26
Hardware/software integration

• Real-time nature of embedded systems leads to
  highly complex, non-deterministic behavior
• Can only be analyzed as it occurs
• Accurately modeling and simulating behavior may
  be very time consuming
• But tools are getting better

27
Example integration issue

• Big endian/little endian
• Hardware assumes big
• Software assumes little
• Correct in isolation but fails during integration
• Interface misunderstood

28
Endianness
29
Where design time is spent
30
Debugging an embedded system

• In many ways, similar to debugging a host based
  application
• Debugger can exist as two pieces
• Debug kernel in the target
• Host application
• Cant always use printf()
• Many embedded systems impossible to debug unless
  operating at full speed

31
Debugging an embedded system

• Running the system with the debugger will slow it
  down (1 or more orders of magnitude)
• Scaling back real-time is hard
• On-chip hooks available for embedded systems
• Vendors must provide a solution that can
  demonstrate complex tool chain for designing and
  debugging its silicon

32
Debugging an embedded system

• Three requirements
• Run control (start, stop, poke memory)
• Memory substitution (replacing ROM based emulator
  with RAM for rapid/easy code download, debug and
  repair
• Real-time analysis (following code flow in real
  time with real-time trace)

33
Debugging an embedded system

• Integrating an RTOS cause further issues
• Behavior of RTOS hidden from designers
• Special tools required (from vendor)
• Other debugging methods are pretty much the same
• Many problems are underlying h/w or RTOS

34
Product testing and release

• Testing is important when performance is key
• Testing and reliability more stringent
• PCs fail often but how about IDE disk drive,
  CD-ROM, scanner, printer?
• These are embedded systems

35
Product testing and release

• Is system performing at close to its optimal
  capabilities?
• Many desktop applications have small memory leaks
• Many resources (memory) make this unlikely
• Not so in embedded systems

36
Who does the testing?

• Many of the elements of reliability and
  performance testing map directly to the best
  practices for host based software development
• Differences exist in embedded systems

37
Compliance testing

• Embedded systems radiate a lot of radio frequency
  energy
• all electronic devices must be turned off
• If embedded designer does not consider these
  things, compliance engineering (CE) will fail
• Software must be running to pass this test
• This is often overlooked

38
Maintaining and upgrading

• Not many tools to support applications already in
  the field
• 60 of embedded engineer maintain systems
• Original engineer long gone
• Must rely on experience, any existing
  documentation, etc
• Tools must help here

39
Maintaining and upgrading

• time to market must become time to reverse
  engineer and time to insight

40
SE 746-NT Embedded Software Systems
Development Robert Oshana 10 minute
break For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu