Transcript Final Thesis Defense - University of California, Irvine

Energy-Aware System Design for
Wireless Multimedia
Nikil Dutt
Shivajit Mohapatra
Rajesh Gupta
Nalini Venkatasubramanian
Sumit Gupta
Cristiano Pereira
University of California,
Irvine and San Diego
Hans Van Antwerpen
Ralph Von Vignau
Philips Semiconductors
Talk Outline

Overview


Case Study:


Distributed Wireless Multimedia
The FORGE Framework
IP Reuse at Philips
2
• Power Optimization in battery operated mobile
devices is a crucial research challenge
• Devices operate in dynamic distributed environments.
• Future power management strategies need to be
aware of global system changes.
3
palmtop
AP
Distance Learning
iPAQ
Devices
AP
Power
laptop
Low
response
Video Streaming
Wireless Network
Online Gaming
Wide Area Network
Infrastructure for Mobile Multimedia Environments
request
Online Banking,
Chat
• Best-Effort Service
Low-power
mobile device
4
Enhanced Infrastructure
PROXY-N
services
palmtop
AP
Distance Learning
iPAQ
Caching
compress
encryption
decryption
Online Banking, Data from Compositing
Server
Chat
transcode
Execute Remote Tasks
Devices
AP
Power
PROXY-1
laptop
Low
Video Streaming
Broker
Wireless Network
Online Gaming
Wide Area Network
Directory
Service
Data from
Mobile host
output
Low-power
mobile device
5
Challenges in Wireless Multimedia Processing

Proliferation of Devices

System support for multitude of smart devices that




Need a customizable networking backbone



attach and detach from a distributed infrastructure
produce large volume of information at a high rate
limited by communication and power constraints
QoS driven resource provisioning algorithms for
highly dynamic environments
Need to deal adaptively with incoming requests
Dynamically reconfigure system to service
requests
6
High Data Volume of Multimedia Information
8Kbytes/s
Speech
8000 samples/s
CD Audio
44,100 samples/s, 2 176Kbytes/s
bytes/sample
Satellite
Imagery
180X180 km^2
30m^2 resolution
NTSC Video
30fps, 640X480
pixels, 3bytes/pixel
600MB/image
(60MB
compressed)
30Mbytes/s
(2-8 Mbits/s
compressed)
7
Challenges in Wireless Multimedia Processing

Dealing with Device Mobility

Need high degree of “network awareness”



Service Brokering for QoS Aware Resource Provisioning


Admission control, Load-balancing etc.
Multimedia Processing challenges




congestion rates, mobility patterns etc.
global system state is constantly changing
Soft Real Time Constraints
Synchronization (e.g. lip sync. , floor control)
Support for traditional media (text, images) and continuous
media (audio/video)
Other considerations – Availability, Reliability, CostEffectiveness & Security
8
Distributed Wireless Multimedia

Different forms of information accessible anytime


Services, Networks and Systems


Multiple Sessions with varying characteristics.
Heterogeneous, evolve dynamically
Quality of Service


Constraints: Timing, resource availability, network constraints,
(e.g. bandwidth), security, reliability …
Example: For Multimedia Streaming to Handheld Devices



QoS Parameters: jitter, frame rate, resolution, bit-rate etc.
All these QoS parameters affect user perception.
Power is a new QoS dimension – in distributed
multimedia.

User must be able to watch requested video without running
out of battery
9
Multimedia Streaming Example
MEDIA SERVERS
NETWORK
CLIENTS
Handheld PC
PROXY
ACCESS
POINT
Wired
Network
PDA
Wireless
Network


Phone
We use this framework for examining the design challenges
Proxy node between servers and clients allows dynamic stream
transformations (Transcoding, Adaptation, Annotation etc)
10
Opportunities in Wireless Multimedia System Design

Dynamic nature of multimedia tasks leaves some
computational slack


QoS trade-offs possible for reducing energy consumption


Example: Lower quality video needs less computation/bandwidth
Multimedia Applications Characteristics




Slack = Difference between computational capability and
computational requirements due to deadlines
Kernels of computation-dominated operations
 E.g. MPEG: IDCT, motion compensation, VLD
Predictable, regular behavior (most of the time)
 E.g. VLD, followed by IQ, IDCT
Clear computation and/or data access patterns (cyclic)
 E.g. video frames are traversed in a known order
Exploit multimedia specific characteristics to enable a range
of optimization techniques
11
Implications on Wireless Multimedia System Design


Devise strategies that reduce energy
These strategies must adapt to/optimize for changes in






Application Data (video stream)
OS/Hardware (CPU, Memory, Reconfigurable logic)
Network (congestion, noise, node mobility)
Residual Energy (battery)
Environment (Ambient light, sound)
Strategies can



Change application behavior (compression ratio)
Reduce backlight
Buffer Data (and switch off network card)
12
Abstraction Layers in Distributed Multimedia Systems
Abstraction Layers
Video Player
Client1
Server
Network
Management
Other Tasks
Transcoding
Applications
Admission
Control
Middleware
Clienti
Clientn
DVS
Network
Card
Operating
System
Scheduler
Display
Cache Memory Reg Files CPU
H/W
Challenges



Enable high quality of services (particularly multimedia services) at the
mobile device: High Computational capability
Do so within strict Peak Power and Energy Budgets
Eg.: Play video stream at highest quality (requires computation), while
13
ensuring the entire video plays back (requires energy)
Energy Aware System Design Techniques


Several approaches optimize energy for each component
and each abstraction level
Solutions – at each abstraction level




Architecture:
 Cache/Memory optimizations, Processor architectural
optimizations
Operating System
 Dynamic voltage scaling (DVS)
 Dynamic power management (DPM) of System
components: disks, network interfaces
Middleware solutions
 Adaptive streaming, mobility based adaptations
Application adaptations
 Profiling applications for low power execution
14
Related Work
PROXY-BASED ADAPTATION for POWER AWARENESS
• Shenoy(transcoding), Chandra(netwrk), Mohapatra (OS, arch, network + transcoding)
CROSS-LAYER ADAPTATION
• GRACE (Illinois), FORGE/DYNAMO (UCI)
Quality of Service
Application/user feedback
• Flinn (ICDSP 2001), Yau (ICME 2002)
• Krintz, Wolski (UCSD)
• Noble (SOSP 97, MCSA 1999)
• Li (CASES 2002), Othman (1998)
• Abeni (RTSS 98)
• Nahrstedt
( Grace,
UIUC
- MMCN 2002,
2003)
•Rudenko
( ACM
SAC
99), Satyanarayan
(2001)
• Shenoy (MMCN 2002), RajKumar (ICDCS 2003)
• Mohapatra(ICDCS, MWCN 2003), Xu (DCS 03)
• Efstratiou, Friday (Middleware 2000)
•Forge Project UCI (ACM MM, RTAS, CIPC 03)
• Ellis, Vahdat (EcoSystem, Currentcy, ASPLOS 02)
• Hao, Nahrstedt (ICMCS 99, HPDC 99, Globecom)
•DVS (Shin, Gupta, Weiser, Srivastava, Govil et. al.)
•DPM (Douglis, Hembold, Delaluz, Kumpf et. al.)
•Chandra (MMCN 02), Katz (IEICE 97), Chou(02)
• Soderquist (ACM Multimedia 97)
•Feeney, Nilson ( Infocom 2001)
• Azevedo (AWIA 2001)
• Hughes, Adve (MICRO 01, ICSA 01)
• Brooks (ISCA 2000), Choi (ISLPED 02)
• Leback (ASPLOS 2000), Microsoft’s ACPI
Distributed Adaptation
Cross-Layer Adaptation
Appl.
specific Adaptation
User/Application
DVS, DPM, Driver
Interfaces, system calls
Distributed Middleware
Architecture
(cpu,
memory)
Operating System
Architecture
Talk Outline

Overview


Case Study:


Distributed Wireless Multimedia
The FORGE Framework
IP Reuse at Philips
16
Traditional Approach: A Closer Look
Power Management
Application
Low-power
device
Operating System
Architecture
Network Infrastructure
response
Wide Area
Network
server
Wireless
Network
request
Low-power
mobile device
Wireless Distributed Infrastructure (traditional)
17
Drawbacks
• Limited co-ordination between the different
computation layers (Architecture, OS, application)
• Lack of generalized framework
• Example (DVS in presence of architectural opt.)
• Do not exploit global system knowledge
• Network congestion levels
• Device mobility information
• Data characteristics
Cross-layer coordination directed by a distributed
middleware framework can effectively address
the above limitations.
18
A Global Coordinated Approach in FORGE
Directory
Service
User/Application
device
Distributed
Middleware
network
Proxy
User/Application
Distributed
Middleware
Operating System
Operating System
Architecture
Architecture
LOCAL
CROSS LAYER ADAPTATION
GLOBAL
PROXY BASED ADAPTATION
Build Power-aware Distributed Embedded System framework that can
o Exploit global changes (network congestion, system loads, mobility
patterns) to improve local adaptations
o Distribute local information (e.g. device mobility, residual
power) for improved global adaptations
o Co-ordinate power management strategies at different levels
(application, middleware, OS, architecture)
o Maximize the utility (application QoS, power savings) of a mobile device.
19
FORGE: Layers and Interactions
PROXY-BASED ADAPTATION
CROSS LAYER ADAPTATION
(Local Device)
Proxy Middleware
• Admission Control
• Task Partitioning
• Adaptive network transmission
…
• Transcoded payload/data
U S E R A P P L I C A T I O N S (Utility)
• Settings for transmitted data
•Control information ( n/w trans)
App. specific info
Network
Task
optimization partitioning
Proxy
•Mobility Information,
•Current Residual Power
•Utility levels supported
•User requirements for Adm. Control.
• Video Encoding Info
• Display Settings
• Residual Power Info
• Power API
Collect/update
Local data
Middleware strategies
Middleware Device Runtime
DVS
• NIC Idle periods
User
info
Network
Card
Scheduler
Display
(API Interface)
Device Drivers
OS
Operating System
Cache Memory
RegFiles
CPU
H/W
Arch. Specific Settings
• Arch. Specific Knobs
e.g. Cache config
(Register file sizes, Cache
20
config)
Outline for the rest of the talk



Examine Energy optimization knobs at each
abstraction level
Examine how cross-layer coordination can reduce
energy further
Specifically, we will talk about:
Using Reconfigurable Caches
 Adaptive DVS techniques
 Network Card shut-down by buffering video data
 Reducing Backlight by Video Enhancement

21
Hardware/Architectural Level Knobs

Major sources of power consumption
Display (Backlight)
 Network Interface
 CPU – particularly memory sub-system


We will discuss two Middleware/HW
optimizations:
Quality-Driven Cache Reconfiguration
 Dynamic Backlight Adjustment

22
Quality-Driven Cache Reconfiguration
(Hardware-Level Optimization)

Why caches?




Idea: reconfigure data cache for specific video stream
format requirements
Cache power knobs used: size, associativity



High relative power consumption (above 50%)
Influences external memory power
Goal: Find best configuration for each quality level
Plus: combine with dynamic voltage scaling (DVS)
Application: MPEG decoding


Frame decoding may take less than frame delay
Slack time: θ = Fd – D (between deadline & end of computation)
23
Impact of Cache Parameters on Energy

Profiled short (10sec) video clips (quality: low - high) for all cache
configurations – parameters varied:
•Experimental Setup:



Size: 4KB – 64KB
Associativity: 1 – 32
•Wattch/Simplescalar
•Berkeley MPEG tools
Energy savings: 10-15% (CPU + memory) over 32x32 baseline
Observations:
 Associativity: largest impact on
energy
 Best cache configuration reflects
 internal storage requirements
for different frame sizes
 decoding algorithm internal
organization (data sets)
“Action” clip, high quality
24
Cache Configuration + DVS


Interaction of DVS with cache configurations
 Cache configurations with the largest frame decoding slack
enable largest DVS savings
Results: up to 60% energy savings over base config
Middleware Rule Base for Best Config at each Quality Level
Video Cache
Quality
Quality
High
to Low
Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Size
8
8
8
32
32
32
8
8
Cache
Clock
Voltage Original Optim ized Savings
Associativity Frequency
8
8
8
2
2
2
8
8
100
100
100
66
66
33
33
33
Energy
1
1
1
0.9
0.9
0.9
0.9
0.9
1.29
1.09
0.95
0.54
0.48
0.42
0.29
0.24
Energy
0.76
0.64
0.56
0.26
0.23
0.2
0.14
0.11
47.50%
47.80%
48.00%
57.60%
57.80%
58.00%
57.30%
57.50%
Base configuration: 400MHz, 1.3V, 32 kb, 32 set assoc
25
OS Directed Power Management


OS has a global view of what is going on the
whole system
Applications should communicate:


Quality of service, timing restrictions
The OS decides how to configure the knobs
available

Ex: Processor frequency and voltage scaling
26
Power Aware Software Architecture (PASA)
Adaptable
Applications

Power Aware API

Middleware
PA OS Services
OS
Local
PM

OS
HAL
Power Aware HAL
Hardware
PA-API (Power Aware API)
 Application/OS Interface
 Makes power aware OS services
available to the application writer.
PA-OSL (Power Aware Operating
System Layer)
 Implements modified OS services
and active components such as a
DPM manager.
PA-HAL (Power Aware Hardware
Abstraction Layer)
 OS/Hardware Interface
 Makes power control knobs available
to the OS programmer.
27
Operating system driven DVS



Slow down the CPU based on workload and timing restrictions
(slowdown factors f < 1)
We model real time task sets with periods=deadlines using RMS
We implemented 4 variations of DVS with CPU shutdown:
 Shutdown when idle – as soon as CPU becomes idle
shutdown the processor
 Static slow down factors – calculated offline and based on RM
schedulability analysis (using the WCETs)
 Dynamic slow down – run-time slow down factors are
predicted based on a history of execution times
 Adaptive slow down – A third slowdown factor adapted
according to number of deadline missed in a previous window
of executions.
28
Implementation


We modified the eCos real time operating system running
on a XScale platform (80200EVB) with dynamic
frequency and voltage scaling hardware.
For the DVS techniques, we implemented real tasksets to
validate the software implementation:

MPEG decoding, ADPCM and FFT
29
WCET (us)
Std Dev (us)
Observations
T1
MPEG2
30700
3100
Task Set
 Adaptive slowdown achieves about 30-40 % savings
T2
MPEG2
26300
2100
A: T1,T3,T4
 T3
However,
deadline misses increase
( not shown
here)
ADPCM
9300
3300
B: T2,T3,T4
 T4
OS/Middleware
have to trade-off
FFT
15900 deadline0 misses with
C: T1,T3,T5
T5
13600
800
energyFFT
savings/slowdown factors
Task
Application
Energy Consumption for each scheme
Ratio of energy
consumption between
Normal and Scheme
1
0.8
0.6
0.4
Taskset A
0.2
Taskset B
Taskset C
)
pt
iv
e
(0
.
75
)
+A
da
pt
iv
e
(0
.
80
)
+A
da
+A
da
pt
iv
e
(0
.
85
)
iv
e
pt
+A
da
+A
da
pt
iv
e
(0
.
95
(0
.
90
)
ic
am
+D
yn
tic
+S
ta
td
ow
n
nl
y
O
Scheme
Sh
u
N
or
m
al
0
30
Middleware Controlled Network Data Buffering

Wireless NIC cards consume significantly less energy in
sleep mode (NIC = Network Interface Card)



Transmitting video data in bursts can help save power.



Avg. power consumption in sleep mode = 0.184 W, whereas
Idle & receive modes consume 1.34 & 1.435 W respectively
NIC on device can be transitioned into sleep mode
The middleware on the proxy is used to buffer video data
and transmit it in bursts to the device.
Additionally, based on the residual energy feedback from
the device, the middleware can transcode the video
stream based on Quality/Power Matrix.
31
 Power savings decrease as video quality increases
 Amount of Data Buffering possible is less at higher quality
 This is an ideal model: in practice, network noise will mean that
Power Gains using Buffering for various noise levels
network interface
has to be left on for longer periods of time
Avg. Power Saved (%)
1.25
1.2
1.15
1.1
1.05
1
0.95
0.9
Q5
N=1
Net
Q4
N=3
N=5
wor
Q1
kN
oise
Q3
Q2
Vid
eo
Q6
Q7
Q8
ty
al i
u
q
32
Reducing Backlight for Lower Power



Identify “Groups of Scenes”
with little variance in
luminosity
Increase pixel luminance and
reduce backlight level
To avoid loss of contrast (due
to pixel luminance saturation)


Perform spatial convolution
using high pass filter
This sharpens objects in the
image
Backlight
Modes
Power
Consumed
(in Watts)
Super Bright
High Bright
2.80
2.51
Medium Bright
Low Bright
2.32
2.16
Power Save
1.72
Power consumed at various
backlight levels during
streaming multimedia playback
on the Compaq iPAQ
33
Video Streams used for Experiments
bipolar.mpg
iceegg.mpg
intro.mpg
simpsons.mpg
Snapshots of MPEG-1 video streams used in experiments
MPEG Video Resolution FPS Duratio Luminosity
n (sec)
Variation
Video Type
bipolar.mpg
320 x 240
30
41
Little
Dark, 3D animation
iceegg.mpg
240 x 136
30
59
Moderate
Bright, 3D animation
intro.mpg
160 x 120
30
59
Very High
Flashy, TV show clip
simpsons.mpg
192 x 144
30
27
High
Colorful, 2D animation
Characteristics of video streams used in experiment
34
Three Backlight Compensation Approaches

SBC: Simple Backlight Compensation



CBVLC: Constant Backlight with Video
Luminosity Compensation



Only identify GOS, reduce backlight on handheld
No video stream contrast enhancement
Backlight level set once at start of video stream
Video stream is enhanced (dynamically at the proxy)
DCA: Dual Compensation Approach


Backlight level is dynamically changed based on GOS
Video stream is enhanced based on Backlight level decision
35
Results for Backlight Compensation
High Bright
500
180
450
160
400
350
300
CBVLC
250
SBC
200
DCA
150
100
50
140
120
CBVLC
100
SBC
80
DCA
60
40
20
0
0
iceegg
simpsons
intro
iceegg
bipolar
simpsons
Backlight
Modes
700
600
Power saving (mWatts)
Power Saving (in mWatts)
Power Saving (in mWatts)
Super Bright
500
CBVLC
400
intro
Power
Consumed
(in Watts)
Super Bright
2.80
200
High Bright
2.51
100
Medium Bright
2.32
Low Bright
2.16
Power Save
1.72
SBC
300
DCA
0
iceegg
simpsons
intro
Medium Bright
bipolar
bipolar
36
Summary

We explored ways to reduce power by integrating power
optimization techniques across abstraction layers




HW/OS/Middleware: Cache Reconfiguration, DVS, Backlight
Reduction
OS/Application: Power Aware API for DVS
Middleware/Network: NIC Shutdown using data buffering
Conclusion: A Cross-Layer Coordinated Strategy is
required for maximum energy savings

Information available at different abstraction levels can be used
by either the OS or the middleware to make global decisions
37
Ongoing Work

Exploits repetitive and cyclic characteristics of MPEG-2,
MPEG-4/H.263


Energy Characterization of Security and Digital Media
Protection algorithms



Application and data profiling possible for reducing energy
consumption
Security and IP protection of multimedia content has spawned
a range of security measures
First step: We analyzed the effects of watermarking on energy
and computation time on PDAs
Task partitioning between proxy and handheld for
reducing total energy (=computation+communication)

For Video Streaming, Video Conferencing, Watermarking
38
Talk Outline

Overview


Case Study:


Distributed Wireless Multimedia
The FORGE Framework
IP Reuse at Philips
39
Blowing away the
Barriers to Large
Scale IP Reuse
DATE Conference 2004
Paris, La Defense
Ralph von vignau
5 January 2004
Philips and IP Reuse



Philips Semiconductors is a leading SoC developer
A reuse structure and policy for IP has been
systematically introduced into the development
environment.
There are rules and tools to support the reuse
CoReUse for HW
 MoReUse for SW

41
Philips and IP Reuse Background - 1

Philips Semiconductors has a strategy of
developing products based on System Silicon
Platforms (SSP’s).
Chameleon (MIPS subsystem generator)
 ChipBuilder (ARM based system generator)


Demonstrates the value of automatic methods of
integrating IP blocks into a subsystem along with
it’s verification environment.
42
Philips and IP Reuse Background - 2
“Need a generic framework that enables
platform developers to implement their
system in a consistent, flexible and easyto-use way”
Combining automatic methods of integrating
configurable IP blocks together with their
verification environment
43
Lessons Learned

Factors that enable successful IP reuse
A centrally driven and supported company policy
 Wide deployment with consultancy
 Central repository
 High quality that can be trusted
 Ease of use
 Good documentation
 Central support
 Distributed champions
 Visible improvements and successes

44
The Limits of the Current Policies

A standard set of views is provided for each IP block





However:




Ensures compatibility with the development flows
Supports easier integration
Ensures a minimum of documentation is available
Is supported by checking tools
Verification reuse is not yet included
The checking is done by in-house tools
The rules only apply to in-house IP
A far more radical change is required to move to the
next level of reuse methodology.

Higher automation
45
Requirements for the next Level of
Reuse

Extend reuse both within Philips as well as to
the IP bought for use within Philips



The use of IP from multiple vendors must be made
easier and less costly
Tools from various EDA vendors must be easier
to integrate into a design flow
The verification of IP must be more:
Comprehensive, stretching from unit tests to system
verification
 Reusable in all stages of the SoC development
46

Supportive Standardization
Only if there is an industry drive to common standards for the
Reuse of IP can major improvements be achieved
Although there are several activities and working
groups throughout the industry and standardization
groups, none have the industry focus or time drive
set by the SPIRIT Consortium
WWW.spiritconsortium.com
47
The SPIRIT Consortium

SPIRIT
Structure for Packaging, Integrating and Reusing IP within Tool-flows
 A consortium of leading companies in the EDA,
IP, system and semiconductor industries


Aim

To develop industry standards
Ease integration of semiconductor IP into Systems
 Enable the interoperability of tools for IP integration

48
Reason for the SPIRIT consortium

Industry demands
Complex System-on-Chip and Programmable
Platforms require IP re-use
 Device manufacturers need to be able to select
IP from multiple sources
 Unifying IP descriptions and access to this
information permits best-in-class choices for
both IP and tools

49
SPIRIT Consortium Background


The founding companies decided mutually
to establish a unified set of standards to
increase efficiency of IP based SoC design
Combining technological strengths of
SPIRIT members to
Create standards that will help express complex
IP
 Deliver greater flexibility and efficiency to the
SoC design process

50
Consortium Goals

Develop standards to facilitate IP re-use

Structure for configurable IP design

Separating core functionality from associated
parameters
Defining standard interfaces for tools
 Enable more efficient and cost-effective
integration of IP from multiple sources


Test the proposed standards within
multiple live projects

Providing proof-of-concept
51
Future-world for designers
SPIRIT-enabled IP will facilitate new levels of
design integration &
automation across a wide range of IP, tools and
vendors:

IP providers will ship IP with a machine-readable XML 'databook'



The same design information will be used to generate
varied system information


Designers do not have to study data books to use IP in a System
design.
IP will be automatically configured and integrated into designs.
Simulation models, Documentation, System APIs, Tool Configurations,
SW applications
New specialist design applications will emerge to process52IP
53
The Philips Utilization of the SPIRIT
Standards

Philips has been gaining experience with
automated IP integration:

A Philips in-house tool, Chip Builder is an excellent
example of the technology
Uses architecture templates
 IP generators
 Interconnect generators
 Automated clock insertion and DfT
 Automated pad and ring insertion


Using the SPIRIT standards, Philips intends to
54
The Nx-Builder development
environment

Philips will integrate a selected number of tools
together to form a highly automated SoC design
flow

The Nx-Builder development environment will
support the 3 main phases in the development of
SoC’s:
The architecture exploration and definition of templates
 The integration & verification of IP
 The synthesis and chip design steps


Nx-Builder will provide a highly flexible platform
55
Nx-Builder Goals

Aim is to move to next level of abstraction in SoC development



HW & SW IP, Subsystems and platforms, SoC
Encapsulates architectural rules and IP in an abstract form
Provides basis for derivatives

encapsulated system can be deployed to derivative development teams
Standard Cell
Standard IP
CPU
...
Subsystems
System Silicon Platform
Application
testbench
...
Microcontroller Subsystem
SoC
56
Nx-Builder, its place in the IC design
flow
Upstream
IP & System development using SystemC
Architecture
exploration
System
Definition
SystemC
Simulations
- Identification of new IP
- Decision on IP reuse
- Specifications of new IP
- Access to data base of
SystemC models
SW
Environment
• Verification Software
• Test Suites
• Drivers
Co-Simulation
• SystemC
• Verilog
• VHDL
Optimization of:
• Performance
• IP Reuse
• Development of new IP
57
Nx-Builder, its place in the IC design
flow
IP Integration
GUI using generators for automation
IP
Select
Chip
Configuration
Compile
- GUI Entry or
Configuration file
- Configurable Blocks
- I/Os
- Search in IPYP
Feedback on:
- Gates
- Address Maps
- Block Diagram
Extract
Build SW
- Database
generation
- Extract all IP
from data bases
Simulate
- Chip Model
- System Model
- Test Bench
- Simulations
- Build
Verification
Software
58
Nx-Builder, its place in the IC design
flow
Downstream
Make/Automation scripts
Simulate
- Chip Model
- System Model
- Test Bench
-Simulations
-Prototyping
Synthesis
Timing
Product
Verification
Place &
Route
Scripts for
Industry Standard Tools
59
The Major Focus

Nx-Builder will focus on
Reuse of verification suites at all stages of the
development flow
 Support of verification for SystemC simulations, in
prototyping systems and on the integrated IP
 All IP will have several standard views:

A SystemC model
 An FPGA view for prototyping
 A verification suite view
 RTL, Verilog and/or VHDL
 A metadata description package

60
Platform Example
MPEG-4
ARM9
DMA
ARM7
TDMI
New IP 2
Multi-layer AHB
PCMCIA
Camera
intf.
SDRAM
controller
AHB
ISROM
ISRAM
bridge
VPB1
New IP 1
CTAG
TCB
bridge
VPB2
UART
JTAG
TAP
AHB
IO conf
vectored
interrupt ctl
sys_creg
Clocks
PLL
PLL
CGU
External
int. ctl
VDD
always
61
Summary



Philips is committed to the planned Reuse of IP
and Verification Suites
Philips will exploit the SPIRIT standards to
achieve the next step in Reuse technology
Philips believes the changes induced in the EDA
and IP provider scene through SPIRIT will have
positive effects on the electronic industry as a
whole
62
63
Layered Model for QoS
Application Qos
User
Media Relations
Media Quality …...
(PerceptualQoS)
QoS)
(Perceptual
Application
(ApplicationQoS)
QoS)
(Application
System
(Operating and Communication System)
(System QoS)
(System QoS)
MM devices
(Device QoS)
Network
(Network QoS)
Intraframe
Component Spec
Name
Size
Rate
Importance
Loss Rate
Interframe
Media Characteristics
Synchronization Skew
Integration
Communication
Conversion
Sample Size
Sample Rate
Compression
Transmission Characteristics
End-to-end Delay
Sample Loss Rate
Importance
Cost
Application QoS Parameter Examples
64
QoS Classes

QoS classes can determine



Guaranteed Service Class


Deterministic/Statistical guarantees.
Predictive Service Class


Reliability of offered services
Utilization of resources
QoS parameters based on past behavior
Best-Effort Service Class


Only partial guarantees based on resource availability
QoS parameters are specified with only minimal/no bound
65
What’s New in the Context of Wireless Systems

Earlier optimization metric was Bandwidth


For mobile, wireless devices: Energy is a severely
limited resource


MPEG is a video compression standard
How can we optimize MPEG encoding/decoding to
reduce energy
Traditionally, DSPs and ASICs have been used to
execute Multimedia applications

Mobile handhelds, laptops etc use general purpose
processors
66
Proxy Based Middleware Approach
Power Management
User/Application
Distributed
Middleware
Low-power
device
Operating System
Caching
Compress
Architecture
Network Infrastructure
Encryption
Decryption
Compositing
Transcode
Execute Remote Tasks
Low-power
mobile device
Wide Area
Network
Wireless
Network
Proxy
Proxy-Based Optimization
67
Energy-Sensitive Video Transcoding
►
We conducted a survey to subjectively assess human
perception of video quality on handhelds.
►
►
Hard to programmatically identify video quality parameters
We identified 8 perceptible video quality levels that produced
noticeable difference in power consumption (Compaq iPaq 3600)
VIDEO TRANSCODING PARAMETERS
QUALITY
Q1 (Like original)
Video transformation
parameters
SIF, 30fps, 650Kbps
Avg. Power
(Windows CE)
4.42 W
Avg. Power
(Linux)
6.07 W
Q2 (Excellent)
SIF, 25fps, 450Kbps
4.37 W
5.99 W
Q3 (Very Good)
SIF, 25fps, 350Kbps
4.31 W
5.86 W
Q4 (Good)
HSIF, 24fps, 350Kbps
4.24 W
5.81 W
Q5 (Fair)
HSIF, 24fps, 200Kbps
4.15 W
5.73 W
Q6(Poor)
HSIF, 24fps, 150Kbps
4.06 W
5.63 W
Q7 (Bad)
QSIF, 20fps, 150Kbps
3.95 W
5.5 W
Q8 (Terrible)
QSIF, 20fps,100kbps
3.88 W
5.38 W
Quality/Power Matrix for COMPAQ IPAQ 3600 ( Grand Theft Auto Action Video Sequence)
68
Experimental Setup
Power measurements:

IPAQ 3650 + Cisco 350 Aironet wireless card


Simulation



Wattch / SimpleScalar for ARM
MPEG decoder: Berkeley MPEG tools
Transcoder: TMPGEnc
Video clips
External Voltage
Supply ( 5V )

206Mhz Intel StrongArm, 16MB ROM, 32MB
RAM
High action (e.g. GTA)
 Medium action (sport)
 Low action (news)

Wireless
AP
ViPAQ

802.11b
R=.22ohm
Proxy
VR
DAQ
Cable
BNC-2110
connector
Power measurement system
(Windows XP, 650 MHz)
69