Hardware and software co-design - Data Compressor -

UNI TV
CA SE STUDY

Software Modem – Personal Digital Assistants – Set–

Top–Box. – System-on-Silicon – FOSS Tools for
embedded system development.
 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
developments to produce designs that meet
performance criteria and functional specifications
Motivations for Codesign
Factors driving codesign (hardware/software systems):
 Instruction Set Processors (ISPs) available as cores in many design kits
(386s, DSPs, microcontrollers,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

 The importance of codesign in designing
Motivations for Codesign

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
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
Categories of Codesign 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 or concurrent with
execution (called evolvable systems)
Components of the Codesign 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
CPUs
Example: data compressor.
Goal:
Compress data transmitted over serial line.
Receives byte-size input symbols.
Produces output symbols packed into bytes.
Will build software module only here.
Collaboration diagram for compressor
1..m: packed
1..n: input output
symbols symbols

:input :data compressor :output

Huffman coding
Early statistical text compression algorithm.
Select non-uniform size codes.
Use shorter codes for more common symbols.
Use longer codes for less common symbols.
To allow decoding, codes must have unique
prefixes.
No code can be a prefix of a longer valid code.
Huffman example
character P
a .45
P=1
b .24
P=.55
c .11
d .08 P=.31
P=.19
e .07
f .05
P=.12
Example :Huffman code
Read code from root to leaves:
a 1
b 01
c 0000
d 0001
e 0010
f 0011
Huffman coder requirements table
name data compression module
purpose code module for Huffman
compression
inputs encoding table, uncoded
byte-size inputs
outputs packed compression output
symbols
functions Huffman coding
performance fast
manufacturing cost N/A
power N/A
physical size/weight N/A
Building a specification
Collaboration diagram shows only steady-state
input/output.
A real system must:
Accept an encoding table.
Allow a system reset that flushes the compression buffer.
data-compressor class
data-compressor

buffer: data-buffer
table: symbol-table
current-bit: integer

encode(): boolean,
data-buffer
flush()
new-symbol-table()
data-compressor behaviors
encode: Takes one-byte input, generates packed
encoded symbols and a Boolean indicating whether
the buffer is full.
new-symbol-table: installs new symbol table in object,
throws away old table.
flush: returns current state of buffer, including
number of valid bits in buffer.
Auxiliary classes
data-buffer symbol-table

databuf[databuflen] : symbols[nsymbols] :
character data-buffer
len : integer len : integer

insert() value() : symbol

length() : integer load()
Auxiliary class roles
data-buffer holds both packed and unpacked symbols.
Longest Huffman code for 8-bit inputs is 256 bits.
symbol-table indexes encoded verison of each symbol.
load() puts data in a new symbol table.
Class relationships
data-compressor
1
1

1 1

data-buffer symbol-table
Encode behavior
create new buffer return true
T add to buffers
input symbol

encode buffer filled?

F
add to buffer return false
Insert behavior
pack into
input T this buffer
symbol

fills buffer? update

length

F
pack bottom bits
into this buffer,
top bits into
overflow buffer
Program design
In an object-oriented language, we can reflect the
UML specification in the code more directly.
In a non-object-oriented language, we must either:
add code to provide object-oriented features;
diverge from the specification structure.
C++ classes
Class data_buffer {
char databuf[databuflen];
int len;
int length_in_chars() { return len/bitsperbyte; }
public:
void insert(data_buffer,data_buffer&);
int length() { return len; }
int length_in_bytes() { return (int)ceil(len/8.0); }
int initialize();
...
C++ classes, cont’d.
class data_compressor {
data_buffer buffer;
int current_bit;
symbol_table table;
public:
boolean encode(char,data_buffer&);
void new_symbol_table(symbol_table);
int flush(data_buffer&);
data_compressor();
~data_compressor();
}
C code
struct data_compressor_struct {
data_buffer buffer;
int current_bit;
sym_table table;
}
typedef struct data_compressor_struct data_compressor,
*data_compressor_ptr;
boolean data_compressor_encode(data_compressor_ptr
mycmptrs, char isymbol, data_buffer *fullbuf) ...
Testing
Test by encoding, then decoding:

symbol table

input symbols encoder decoder result

compare
Code inspection tests
Look at the code for potential problems:
Can we run past end of symbol table?
What happens when the next symbol does not fill the
buffer? Does fill it?
Do very long encoded symbols work properly? Very
short symbols?
Does flush() work properly?
Program design and analysis
Software modem.
Theory of operation
Frequency-shift keying:
separate frequencies for 0 and 1.

0 1

time
FSK encoding
Generate waveforms based on current bit:

0110101
bit-controlled
waveform
generator
FSK decoding
A/D converter
zero filter detector 0 bit

one filter detector 1 bit

Transmission scheme
Send data in 8-bit bytes. Arbitrary spacing between
bytes.
Byte starts with 0 start bit.
Receiver measures length of start bit to synchronize
itself to remaining 8 bits.

start (0) bit 1 bit 2 bit 3 ... bit 8

Requirements
Inputs Analog sound input, reset button.

Outputs Analog sound output, LED bit display.

Functions Transmitter: Sends data from memory

in 8-bit bytes plus start bit.
Receiver: Automatically detects bytes
and reads bits. Displays current bit on
LED.
Performance 1200 baud.

Manufacturing cost Dominated by microprocessor and

analog I/O
Power Powered by AC.

Physical Small desktop object.

size/weight
Specification
Line-in* 1 1 Receiver

sample-in()
input()
bit-out()

Transmitter 1 1 Line-out*

bit-in()
output()
sample-out()
System architecture
Interrupt handlers for samples:
input and output.
Transmitter.
Receiver.
Transmitter
Waveform generation by table lookup.
float sine_wave[N_SAMP] = { 0.0, 0.5, 0.866, 1, 0.866,
0.5, 0.0, -0.5, -0.866, -1.0, -0.866, -0.5, 0};

time
Receiver
Filters (FIR for simplicity) use circular buffers to hold
data.
Timer measures bit length.
State machine recognizes start bits, data bits.
Hardware platform
CPU.
A/D converter.
D/A converter.
Timer.
Component design and testing
Easy to test transmitter and receiver on host.
Transmitter can be verified with speaker outputs.
Receiver verification tasks:
start bit recognition;
data bit recognition.
System integration and testing
Use loopback mode to test components against each
other.
Loopback in software or by connecting D/A and A/D
converters.
Personal digital assistant

The Palm TX EO Personal Communicator (440)

from AT&T
Typical features
 Touch screen
 Memory cards
 Wired connectivity
 Wireless connectivity
 Synchronization

Uses
 Automobile navigation
 Ruggedized PDAs
 Medical and scientific uses
 Educational uses
 Sporting uses
SET-TOP-BOX
SET-TOP-BOX ARCHITECTURE
 “Briefly,
What OSS/FSSource
is Free/Open programs are programs whose licenses give users the
Software?
freedomto run the program for any purpose, to study and modify the
program, and toredistribute copies of either the original or modified
program (without having topay royalties to previous developers).” David
Wheeler1
WHY FOSS?
 “Open-source software has been called many things: a movement, a fad, a
virus,a Communist conspiracy, even the heart and soul of the Internet. But
one point isoften overlooked: Open-source software is also a highly
effective vehicle for thetransfer of wealth from the industrialized world to
developing countries.”Andrew Leonard13
The FOSS development method
 Reduced duplication of effort
 Building upon the work of others
 Better quality control
 Reduced maintenance costs
The benefits of using FOSS
Besides the low cost of FOSS, there are many other
reasons
 Security
 Reliability/Stability
 Open standards and vendor independence
 Reduced reliance on imports
 Developing local software capacity
 Piracy, IPR, and WTO
 Localization