Making the Right Architectural Decisions

1
Making the Right Architectural Decisions

• Jon McDonald

2
Why Build Transaction Level Platform?

• The higher you go toward system-level
  abstraction, the greater the leverage
• Optimize system architecture for area,
  performance and power
• Enable early software validation/debug against
  fast abstracted model
• Reduce verification time
• By quickly building and validating a transaction
  level model
• By reusing the model for validating the
  implementation

Source 3rd party ESL survey, Jan 2009
3
System Architecture Optimization

• Optimizing those system architecture attributes
  impacting area, timing and power
• 10X power variation resulted from system
  architecture tradeoffs in the following example

Only Transaction Level Platform Allows Users to
Quickly Modify and Evaluate Various System
Architectures
4
Hardware/Software Optimization

• Addressing hardware/software architecture
  tradeoffs
• 2X power variation resulted from
  hardware/software tradeoffs in the following
  example

Only Transaction Level Platform Allows Users to
Quickly Modify and Evaluate Various
Hardware/Software Configurations
5
Application Software Dependent Performance
Power
500
1,600
5,000
JPEG
IMAGE
NETWORK
Execution Time
Source IEEE TRANSACTIONS ON VERY LARGE SCALE
INTEGRATION (VLSI) SYSTEMS Tony Givargis, Frank
Vahid, and Jörg Henkel,

• Different Applications running on the same
  platform have significant different profiles

6
Software Compiler Dependent Power

• Image Recognition Package running on an ARM
• O0 - No Optimizations
• O3 - Rename registers, inline functions
• Different compiler options may result in
  different profiles (cache access)

Source POWER ESTIMATION AND POWER OPTIMIZATION
POLICIES FOR PROCESSOR-BASED SYSTEMS José L.
Ayala Rodrigo Universidad Politécnica de Madrid
7
Evaluating Architectural Trade-offs

• New powerful platform targeting many applications
• Problem Too many architectural options
• Multiple processors, communication channels
  options and arbitration schemes
• Solution
• Select the right architectural options
• Optimize architecture for many scenarios
• The Challenge
• Trade-off analysis at the RTL is too long
• Long design creation
• Long simulation time
• Need
• Define system overloading scenarios
• Optimize the architecture long before RTL

CPU
SRAM
MEM CTRL
CPU
On Chip Bus
Snoop
L2Cache
CPU
Memory
Ethernet Bridge
Hardware Acceleration
8
How Architectural Analysis Helped

• Enabled quickly creation of abstracted models
• Assembled the models to form the TLM reference
  platform
• Quantified the impact of architectural trade-offs
• Latency
• Utilization
• Bandwidth
• Power
• Allowed choosing the right architecture in terms
  of
• Number of processors
• Type of communication
• Right arbitration schemes

9
Architectural Analysis Latency
10
Architectural Analysis Power
11
Architectural Analysis Cache, DDR Statistics
12
Evaluating Hardware Software Trade-offs

• Problem Vector-gtBitmap conversion function in
  software is to slow
• Solution Implement the conversion function in
  hardware
• The Challenge Each exploration cycle at the RTL
  may take days
• Lengthy modifications time at the RTL
• RTL simulation too slow to verify system
  performance
• Need Much faster way to explore the HW/SW
  trade-off

Software
Hardware Acceleration
Processor
On Chip Bus
DMA
FLASH
MEM CTRL
SDRAM
SRAM
13
How Architectural Analysis Helped

• Build a TLM platform
• Define the bus architecture
• Quickly exchange SW and HW sources
• Identify parts moved to HW
• Test performance tradeoffs
• Execution time data transfers
• Combined impact on the system
• Benefit Each TLM exploration cycle takes just
  minutes
• TLM simulation takes 4 seconds
• 4Mbyte SW/HW transfers

Software
C/C Code
C/C Code
14
Verifying RTL Correctness Top-Down

• Architecture performance and functionality
  optimized at the TLM
• Problem Tight schedule for RTL implementation
• Solution
• Fork RTL blocks implementation to various teams
• The Challenge
• How to keep each of the blocks in sync with the
  architecture model?
• Need
• Resolve inconsistencies among independent groups
• Correct any divergence from platform early in the
  design cycle

Architecture Level Model
RTL Model
15
How Architectural Analysis Helped
Architecture Level Model

• Used OVM for RTL verification
• Reused the TLM as the predictor of RTL behavior
• Quickly resolved RTL/TLM behavioral discrepancies

RTL Model
RTL Verification Using OVM
16
Vista Architectural Design Capabilities
Modeling
Assembly
Debug
Analysis
Policies
Transaction Level Platform
TLM
TLM
Processor
On Chip Bus
TLM
TLM
TLM
TLM
Power
Vista Model Builder
Virtual Platform
Performance (latency, utilization, bandwidth)
Software
RTL IP
17
Vista Scalable TLM Models

• Based on SystemC and the OSCI TLM 2.0 standard

• Scalability is accomplished by
• Modeling the core Function
• Providing the Communication Layer
• Adding a separate Timing/Power model

Function
18
Vista Scalable TLM Timing Model
Function

• Single transaction level timing model supporting
• LT (loosely time)
• AT (approximated time)
• GUI based timing definition policies
• Policy types
• Delay, Sequential, Split, Pipeline
• Timing values
• Wait states, Latency, Data Delay

Vista Model Builder
Modeling Policies
19
Vista Scalable TLM Power Model

• Transaction-level modeling of all power types
• Static (leakage) power
• Clock tree power
• Dynamic power (per transaction)
• Dynamic power is assigned to each transaction
  type
• Vista TLM power model is
• Reactive to incoming traffic and inner states
• Supports voltage and frequency scaling

Power Policies
20
Architectural Optimization Flow
Model Builder

• Model TLM Timing and Power via policies
• Assemble the transaction level reference platform
• Analyze Timing/Power in a system context
• Modify Timing/Power policies or the platform
  architecture
• Quickly iterate optimizing for timing and power

Quick Optimization of Power and Performance
before RTL
21
Vista Wide Range of Analysis Toolsets

• Functional Analysis
• Data ID and Tracing
• Timing/Performance Analysis
• Throughput
• Latencies
• Bus Utilization
• State Distribution
• Power Analysis
• Dynamic, Static and Clock Power
• Instance Power
• Mean and Peak values
• System and software power profiles
• Hot Spot analysis
• Voltage and frequency scaling (DVFS)
• Power domain management

22
Vista - Optimization Philosophy
Software for System Scenarios
Use policies to model power/timing of new IP
Power Domain
Use accurate power/timing models for legacy IP
Interconnect Fabric

• Analyze power/timing profiles
• typical system scenarios
• running software application

Voltage Scaling 0.8-1.1 V
Explore various power/timing domain management
strategies and voltage/frequency scaling
techniques
23
Vista enables HW/SW Co-Development

• Vista produces SystemC virtual reference platform
  
• Available for early software development and
  validation
• Accurate enough for tuning SW for power and
  performance

Application OS Drivers
24
Architectural Design Analysis Summary

• Optimize and verify the system architecture at
  the transaction level
• HW/SW partitioning and analysis
• Architectural exploration
• Architectural verification and performance
  analysis
• Develop SW early in the design cycle
• Accurate virtual platform
• Verify the HW RTL implementation
• Using TLM model as a predicator during RTL
  verification

25
(No Transcript)