Hardware Software CoDesign

Lecture -2

October 2017
Course Introduction – Class Example
An Example → Simple 4bit Multiplier → H I N T S

1. Assume for now that you only have an 8085 processor at 1MHz. How would you code
it.
• Think of left shift multiplicand, conditional add

2. Assume you have a 8bit multiplier hardware block, attached to the 8085 processor.
How would you code it.
• Think of sending operands to hardware block, read results.
• Cost of Area at the gain of higher throughput.

3. W hat would you do if you do have h/w flexibility, but not as much as a 8bit multiplier
block. A N D s/w flexibility that it’s ok if it is not a single cycle. In other words, its ok
to have a multiplier throughput of say 500kHz or 256kHz (two flavors).
• Think of sending operands to hardware block, read results.
• W hat will reduce Area at the expense of throughput.
• W hat is the system requirements, W hat is the sweet spot.

4. Assume external h/w also works at 1MHz max..

26
5. Throw power into the equation on a more complex example.
 A Model of the Current
Hardware/Software Design Process
DOD-STD-2167A
HWCI
HW Development Testing
Fabric.
Detailed
Design
Prelim.
Design
Hardware
Require.
Sys/HW
Analysis
Require.
Analysis
System System Operation.
Concepts Integ. and Testing and
Sys/SW test Eval.
Require.
Analysis Software
Require.
Analysis Prelim.
Design
Detailed
Design
Coding,
Unit test.,
SW Development Integ. test CSCI
Testing
[Franke91]
© IEEE 1991
Current Hardware/Software Design
Process
 Basic features of current process:
 System immediately partitioned into hardware and software components
 Hardware and software developed separately
 “Hardware first” approach often adopted
 Implications of these features:
 HW/SW trade-offs restricted
 Impact of HW and SW on each other cannot be assessed easily
 Late system integration
 Consequences these features:
 Poor quality designs
 Costly modifications
 Schedule slippages
Incorrect Assumptions in Current
Hardware/Software Design Process
 Hardware and software can be acquired separately and
independently, with successful and easy integration of the
two later

 Hardware problems can be fixed with simple software

modifications

 Once operational, software rarely needs modification or

maintenance

 Valid and complete software requirements are easy to state

and implement in code
Co-design Definition and Key Concepts
 Co-design

 The meeting of system-level objectives by exploiting the trade-offs

between hardware and software in a system through their
concurrent design

 Key concepts

 Concurrent: hardware and software developed at the same time on

parallel paths

 Integrated: interaction between hardware and software

development to produce design meeting performance criteria and
functional specs
 Directions of the HW/SW
Design Process
Integrated Modeling Substrate
HWCI
HW Development Testing
Fabric.
Detailed
Design
Prelim.
Design
Hardware
Require.
Sys/HW
Analysis
Require.
Analysis Operation.
System System
Integrated Modeling Substrate Testing and
Concepts Integ. and
Sys/SW test Evaluation
Require.
Analysis Software
Require.
Analysis Prelim.
Design
Detailed
Design
Coding,
Unit test.,
SW Development Integ. test CSCI
Testing
[Franke91]
© IEEE 1991
Requirements for the Ideal Codesign Environment
 Unified, unbiased hardware/software representation

 Supports uniform design and analysis techniques for hardware and

software

 Permits system evaluation in an integrated design environment

 Allows easy migration of system tasks to either hardware or software

 Iterative partitioning techniques

 Allow several different designs (HW/SW partitions) to be evaluated

 Aid in determining best implementation for a system

 Partitioning applied to modules to best meet design criteria

(functionality and performance goals)
Requirements for the Ideal Codesign Environment (cont.)

 Integrated modeling substrate

 Supports evaluation at several stages of the design

process

 Supports step-wise development and integration of

hardware and software

 Validation Methodology

 Insures that system implemented meets initial system

requirements
Basic Themes
Modeling :: Because parallelism is important, the choice of an appropriate
modeling paradigm is also important. Different modeling formalisms need to
be developed that capture the various aspects of system behavior.

Analysis and Estimation :: Different models of the same system behavior need
to be analyzed and estimated for performance. Performance would include
tradeoffs for Area, Speed, Power. Cost to build, Time to Market are other
factors.

System-level partitioning, synthesis and interfacing :: The basic steps of co-

synthesis. A range of methodologies are applied for this.

Implementation generation :: Once the architecture has been generated and

trade- offs known, the designs for the hardware and software components
must be created.

Co-simulation and Emulation :: This helps designers to evaluate architectures

and validate assumptions on implementations. Emulation uses FPGA / other
emulation techniques to further speed up execution of system models.
2
 Motivations for Co-design
Factors driving co-design (hardware/software systems):

• Instruction Set Processors (ISPs) available as cores in many design

kits (386s, DSPs, micro-controllers,etc.)

• Systems on Silicon - many transistors available in typical

processes (> 10 million transistors available in IBM ASIC process,
etc.)

• Increasing capacity of field programmable devices - some devices

even able to be reprogrammed on-the-fly (FPGAs, CPLDs, etc.)

• Efficient C compilers for embedded processors

• Hardware synthesis capabilities

Motivations for Co-design (cont.)

• The importance of co-design in designing hardware/software systems:

• Improves design quality, design cycle time, and cost

• Reduces integration and test time

• Supports growing complexity of embedded systems

• Takes advantage of advances in tools and technologies

• Processor cores

• High-level hardware synthesis capabilities

• ASIC development
Cross-fertilization Between Hardware
and Software Design

• Fast growth in both VLSI design and software

engineering has raised awareness of similarities between
the two
• Hardware synthesis
• Programmable logic
• Description languages
• Explicit attempts have been made to “transfer
technology” between the domains
Cross-fertilization Between Hardware
and Software Design (cont.)

VLSI SOFTWARE
DESIGN ENGINEERING

• EDA tool technology has been transferred to SW CAD systems

• Designer support (not automation)
• Graphics-driven design
• Central database for design information
• Tools to check design behavior early in process
Cross-fertilization Between Hardware
and Software Design (cont.)

SOFTWARE VLSI
ENGINEERING DESIGN

• Software technology has been transferred to EDA tools

• Single-language design
 Use of 1 common language for architecture spec. and implementation of a chip

• Compiler-like transformations and techniques

 Dead code elimination
 Loop unrolling

• Design change management

 Information hiding
 Design families
Categorizing Hardware/Software Systems
• Application Domain
• Embedded systems
• Manufacturing control
• Consumer electronics
• Vehicles
• Telecommunications
• Defense Systems
• Instruction Set Architectures
• Reconfigurable Systems
• Degree of programmability
• Access to programming
• Levels of programming
• Implementation Features
• Discrete vs. integrated components
• Fabrication technologies
Embedded Systems
• Embedded Systems
• Application-specific systems which contain
hardware and software tailored for a particular task
and are generally part of a larger system (e.g.,
industrial controllers)
• Characteristics
• Are dedicated to a particular application
• Include processors dedicated to specific functions
• Represent a subset of reactive (responsive to external
inputs) systems
• Contain real-time constraints
• Include requirements that span:
• Performance
• Reliability
• Form factor
Embedded Systems: Specific Trends
• Use of microprocessors only one or two generations
behind state-of-the-art for desktops
• E.g. N/2 bit width where N is the bit width of current
desktop systems
• Contain limited amount of memory
• Must satisfy strict real-time and/or performance
constraints
• Must optimize additional design objectives:
• Cost
• Reliability
• Design time
• Increased use of hardware/software codesign principles
to meet constraints
Embedded Systems: Examples

• Banking and transaction processing applications

• Automobile engine control units

• Signal processing applications

• Home appliances (microwave ovens)

• Industrial controllers in factories

• Cellular communications
Components of the Co-design Problem
• Specification of the system
• Hardware/Software Partitioning
• Architectural assumptions - type of processor, interface
style between hardware and software, etc.
• Partitioning objectives - maximize speedup, latency
requirements, minimize size, cost, etc.
• Partitioning strategies - high level partitioning by hand,
automated partitioning using various techniques, etc.
• Scheduling
• Operation scheduling in hardware
• Instruction scheduling in compilers
• Process scheduling in operating systems
• Modeling the hardware/software system during the design
process
Typical Codesign Process

System
FSM- Description Concurrent processes
directed graphs (Functional) Programming languages

HW/SW Unified representation

Partitioning (Data/control flow)

SW HW
Another
HW/SW Software Interface Hardware
Synthesis Synthesis Synthesis
partition

System Instruction set level

Integration HW/SW evaluation
Categories of Co-design Problems
• Codesign of embedded systems
• Usually consist of sensors, controller, and actuators are reactive
systems
• Usually have real-time constraints
• Usually have dependability constraints
• Codesign of ISAs
• Application-specific instruction set processors (ASIPs)
• Compiler and hardware optimization and trade-offs
• Codesign of Reconfigurable Systems
• Systems that can be personalized after manufacture for a
specific application
• Reconfiguration can be accomplished before execution of
concurrent with execution (called evolvable systems)
Categories of Co-design Problems.. Basic Pitfalls

• Transient Overloads :: Transient Overloads on multiple aspects like power,

memory, out of bandwidth, data loss, missed deadlines of critical tasks.

• Analysis Paralysis :: Since there are many ways of doing it, there could be too
many factors which do not allow the system designer to take decisions. A few
ways of taking ”judgement” decisions are based on fixing a set of topmost
criteria and then working backwards.

• Simulation & Complexity :: Simulation based performance verification, has a

con- ceptual disadvantage that it becomes disabling as complexity increases.
There is a great lot of dependence on the pattern provided for finding corner
cases.

• Applications of the SoC :: Generally an SoC would be implemented with a certain

fixed application in focus. In some cases, the SoC could be used in non-typical or
non-designed for applications. This would break some concurrency conditions
which were not forseen earlier. Basically, for each new application, one needs
to re-run the scenarios in case of using an existing SoC.
3
Embedded Systems: Complexity Issues

• Complexity of embedded systems is continually increasing

• Number of states in these systems (especially in the software) is very large

• Description of a system can be complex, making system analysis extremely

hard

• Complexity management techniques are necessary to model and analyze

these systems

• Systems becoming too complex to achieve accurate “first pass” design using
conventional techniques

• New issues rapidly emerging from new implementation technologies

Techniques to Support Complexity
Management
• Delayed HW/SW partitioning
 Postpone as many decisions as possible that place constraints on the design

• Abstractions and decomposition techniques

• Incremental development
 “Growing” software
 Requiring top-down design

• Description languages

• Simulation

• Standards

• Design methodology management framework

Example …. a touch screen
system

4
 Example

1. Level 0 :: It should work at lowest cost. 5

Example

Problem Statement of a touch screen system – Requirements

1. Level 0 :: It should work at lowest cost.

2. Level 1 :: Some more details :-

(a) System should continuously monitor for a touch.
(b) When screen is touched, find out the X and Y coordinates.
(c) Based on the event(s) of touch and location / pattern, tasks must be performed
/ activated.

3. Level 2 :: Some more details :-

(a) Automated Screen Calibration
(b) Automatically wakes up and goes back to standby to save power
(c) Simple to write software and drivers
(d) Programmable conversion rate

7
 Example

Problem Statement of a touch screen system – Requirements

1. Level 0 :: W hat are the basic components required

(a) An A D C which can do a ”voltage sensing”
i. W hat should be the accuracy, precision of the A D C ? 8b, 12b
ii. Should the A D C be a differential mode or single ended mode.
iii. W hat should be the minimum acceptable frequency for the A D C ?
Depends on how ”Human Machine Interface” like touch screen works.
i v . K B D controller does key debounce at 10 15ms. Should this be a
programmable frequency. In what steps should it be programmable.
W hat complexity will be added to the system. Can we make the system
more simple. W hat is the tradeoff.
(b ) A u P which can take in the Digital Input from A D C and do processing.
(c) Some memory to store successive touch(s) and do a pattern recognition !
(d ) A R O M memory to store program, calibration related data.

9
 Example
Problem Statement of a touch screen system – Requirements
1. Level 0 :: W hat are the basic components required
(a) An A D C which can do a ”voltage sensing”
(b ) A u P which can take in the Digital Input from A D C and do processing.
i. Write a small flow chart on how the data and control would flow from A D C to
u P and control the events based on touch.

ii. Write the software as if it was processor agnostic.

iii. W hat is the complexity of the program.
iv. Is an 8bit general purpose processor ok. W hat will require an upgrade to 16bit
or 32bit general purpose processor.
v. Is there anything in the program which can be hardware accelerated
10 at low cost.
Will a D S P suffice for this application.
(c) Some memory to store successive touch(s) and do a pattern recognition !
(d ) A R O M memory to store program, calibration related data.
Example

Problem Statement of a touch screen system – Design

1. Level 1 :: W hat are the basic components which we can fix (pin down)
(a) The technology node based on requirements
(b) The A D C
(c) The u P or D S P

2. Level 2 :: Can we prototype this system using off the shelf components
(a) Create the I P required to interface A D C with the u P / D S P busses. A dd any
hardware acceleration required.
Example
Problem Statement of a touch screen system – Design Block Diagram

12
 Example

Problem Statement of a touch screen system – Software Design At the top

level, the software provides for the following :-

1. Configure the controller hardware.

2. Determine if the screen is touched.

3. Acquire Stable, debounced position measurements.

4. Calibrate the touch screen.

5. Send changes in touch status and position to the higher level graphics software.

13
Example
Problem Statement of a touch screen system – Software Design
Configure the controller hardware.

1. Create a function named TouchConfigureHardware()

2. Decide – Should the driver be interrupt driven or polling driven.

3. In case of interrupts, the driver would actually use two :-

(a) An interrupt to wake up when the screen is initially touched, known as the PEN
DOWN
interrupt.
(b ) A second interrupt to signal when the A D C is available with the set of data
conversions ( X , Y ) .

Determine if the screen is touched.

1. Create a function named WaitForTouchState ( )

2. When the controller is in the detection mode and a touch is detected, an internal
interrupt can be generated called PEN DOWNIRQ.

3. This detection is based on Y-axis touch plane tied high, X-axis touch plane tied low,
and on the basis of touch the planes are shorted together and Y-axis plane is pulled
low.
14
4. The driver task would not consume any C P U time until the PEN DOWNIRQ event occurs.
It would wake up and go into conversion mode only once the user touches screen.
 Example
Problem Statement of a touch screen system – Software Design
Acquire Stable, debounced position measurements – Reading touch data

1. Create a function named TouchScan(). The outline of the procedure would be :-

(a) Check to see if the screen is touched.
(b) Take several raw readings on each axis for later filtering.
(c) Check to see if the screen is still touched.
(d) (Depending on H / W ) store the readings to a memory block, or use F I F O entries.
(e) (Depending on H / W ) if the A D C output is 12bit, either pack data into 16bit
(aligned) locations or chop/dither them to 8bit.
(f) Taking Stable readings (filtering by using oversampling) is necessary for higher
level drivers to act appropriately. N O T E :: This filtering could be a h/w function
if C P U bandwidth is critical factor.

Calibrate the touch screen.

1. In an ideal scenario, the calibration would be run once during initial product power up
and reference values saved in ”non-volatile” memory.

2. Create a function name C a l ib r a t e To u c h S c r e e n ( ) in case the user

15
wants to calibrate
using a graphical target on screen.
 Example

Problem Statement of a touch screen system – Software Design

Send changes in touch status and position to the higher level graphics software.

1. Create a function named G e t S c a l e d To u c h P o s i t i o n ( ) . This is a routine to

read raw values and convert them to screen co-ordinates.

2. Create a function named TouchTask ( ) . This routine calls the actual task the user
intended to be run while using the touch screen.

16
Acknowledgements

1. Datasheet of I D T MK712 Touch Screen Controller

2. Application Bulletin ” B u r r B rown” now T I (public domain information)

:: Touch Screen Controller Tips.

3. http://www.eetimes.com/design/embedded/4006455/Writing-drivers-fo
common-touch-screen-interface-hardware

4. Slide deck from BITS professors

17