METRICS:A System Architecture for Design Process Optimization

METRICS:A System Architecture for Design Process Optimization

Stephen Fenstermaker*, David George*, Andrew B. Kahng, Stefanus Mantik and

Bart Thielges*

UCLA CS Dept., Los Angeles, CA *OxSigen LLC, San Jose, CA

MotivationsMotivations

How do we improve design productivity ?

Does our design technology / capability yield better productivity than it did last year ?

How do we formally capture best known methods, and how do we identify them in the first place ?

Does our design environment support continuous improvement of the design process ?

Does our design environment support what-if / exploratory design ? Does it have early predictors of success / failure?

Currently, there are no standards or infrastructure for measuring and recording the semiconductor design process

Purpose of METRICSPurpose of METRICS

Standard infrastructure for the collection and the storage of design process information

Standard list of design metrics and process metrics

Analyses and reports that are useful for design process optimization

METRICS allows: Collect, Data-Mine, Measure, Diagnose, then Improve

Related WorksRelated Works

OxSigen LLC (Siemens 97-99)

Enterprise- and project-level metrics (“normalized transistors”) Numetrics Management Systems DPMS

Other in-house data collection systems e.g., TI (DAC 96 BOF)

Web-based design support IPSymphony, WELD, VELA, etc.

E-commerce infrastructure Toolwire, iAxess, etc.

Continuous process improvement

Data mining and visualization

OutlineOutline

Data collection process and potential benefits

METRICS system architecture

METRICS standards

Current implementation

Issues and conclusions

Potential Data Collection/DiagnosesPotential Data Collection/Diagnoses

What happened within the tool as it ran? what was CPU/memory/solution quality? what were the key attributes of the instance? what iterations/branches were made, under what conditions?

What else was occurring in the project? spec revisions, constraint and netlist changes, …

User performs same operation repeatedly with nearly identical inputs tool is not acting as expected solution quality is poor, and knobs are being twiddled

BenefitsBenefits

Benefits for project management accurate resource prediction at any point in design

cycle up front estimates for people, time, technology, EDA

licenses, IP re-use... accurate project post-mortems

everything tracked - tools, flows, users, notes no “loose”, random data left at project end

management console web-based, status-at-a-glance of tools, designs and

systems at any point in project

Benefits for tool R&D feedback on the tool usage and parameters used improve benchmarking

OutlineOutline

Data collection process and potential benefits

METRICS system architecture

METRICS standards

Current implementation

Issues and conclusions

METRICS System ArchitectureMETRICS System Architecture

Inter/Intra-net

DBMetrics Data Warehouse

WebServer

JavaApplets

DataMining

Reporting

Transmitter Transmitterwrapper

Tool Tool Tool

TransmitterAPI

XML

METRICS PerformanceMETRICS Performance

Transmitter low CPU overhead

multi-threads / processes – non-blocking scheme buffering – reduce number of transmissions

small memory footprint limited buffer size

Reporting web-based

platform and location independent dynamic report generation

always up-to-date

Example ReportsExample Reports

hen 95%

rat 1% bull 2%

donkey 2%

% aborted per machine

% aborted per task

BA 8%

ATPG 22%

synthesis 20%

physical18%

postSyntTA13%

placedTA7%

funcSim7%

LVS 5%

LVS convergencetime

0 100 200 300 400 500 600

LVS

%

88

90

92

94

96

98

100

Current ResultsCurrent Results

CPU_TIME = 12 + 0.027 NUM_CELLS (corr = 0.93)

More plots are accessible at http://xenon.cs.ucla.edu:8080/metrics

OutlineOutline

Data collection process and potential benefits

METRICS system architecture

METRICS standards

Current implementation

Issues and conclusions

METRICS StandardsMETRICS Standards

Standard metrics naming across tools same name same meaning, independent of tool

supplier generic metrics and tool-specific metrics no more ad hoc, incomparable log files

Standard schema for metrics database

Standard middleware for database interface

For complete current lists see:

http://vlsicad.cs.ucla.edu/GSRC/METRICS

Generic and Specific Tool MetricsGeneric and Specific Tool Metrics

tool_name stringtool_version stringtool_vendor stringcompiled_date mm/dd/yyyystart_time hh:mm:ssend_time hh:mm:sstool_user stringhost_name stringhost_id stringcpu_type stringos_name stringos_version stringcpu_time hh:mm:ss

Generic Tool Metricsnum_cells integernum_nets integerlayout_size doublerow_utilization doublewirelength doubleweighted_wl double

num_layers integernum_violations integernum_vias integerwirelength doublewrong-way_wl doublemax_congestion double

Placement Tool Metrics

Routing Tool Metrics

Partial list of metrics now being collected in Oracle8i

OutlineOutline

Data collection process and potential benefits

METRICS system architecture

METRICS standards

Current implementation

Issues and conclusions

Testbed I: Metricized P&R FlowTestbed I: Metricized P&R Flow

Placed DEF

QP ECO

Legal DEF

CongestionMap

WRoute

Capo Placer

Routed DEF

CongestionAnalysis

Incr. WRoute

Final DEF

METRICS

LEF

DEF

Testbed II: Metricized Cadence SLC FlowTestbed II: Metricized Cadence SLC Flow

DEF

Placed DEF

QP

Pearl

METRICS

QP Opt

CTGen

Incr.

Routed DEF

WRoute

Optimized DEF

LEFGCF,TLF

Clocked DEFConstraints

OutlineOutline

Data collection process and potential benefits

METRICS system architecture

METRICS standards

Current implementation

Issues and conclusions

ConclusionsConclusions

Current status complete prototype of METRICS system with Oracle8i, Java

Servlet, XML parser, and transmittal API library in C++ METRICS wrapper for Cadence and Cadence-UCLA flows,

front-end tools (Ambit BuildGates and NCSim) easiest proof of value: via use of regression suites

Issues for METRICS constituencies to solve security: proprietary and confidential information standardization: flow, terminology, data management, etc. social: “big brother”, collection of social metrics, etc.

Ongoing work with EDA, designer communities to identify tool metrics of interest users: metrics needed for design process insight,

optimization vendors: implementation of the metrics requested, with

standardized naming / semantics

http://vlsicad.cs.ucla.edu/GSRC/METRICS