1

Calibrating Achievable Design:

Technology Extrapolation, the Bookshelf, and Metrics

Theme Summary

Cong, Dai, Kahng, Keutzer, Maly

2

Mission

Enable the understanding of achievable design

3

Motivations

Provide system-level design with predictable implementation Prove GSRC’s real collaboration, effect on real practice GSRC has potential critical mass, ability to influence “Life is short (play hard)”

– be mature, efficient -- don’t waste time or effort

– standard practices, understandings, backplanes for the field enable researchers, tool providers to focus on core competencies, own value-add

Address productivity gap with each initiative– effective research, effective assessment, effective adoption (Bookshelf)

– focusing of effort: distinguish real issues from non-issues (GTX)

– optimize the use of tools, not just the tools themselves (Metrics)

4

Vision GTX

– regularly improved, used across academe/industry– expert distributed ownership of modules (scaling, test, cost, …)– useful inferences have aided prioritization of research, tool devel– contains “living ITRS” (e.g., consistent derivation of Table B-1 ORTC’s)

Bookshelf– culture shift to “publication” of implementations; field adopts mature

reporting, evaluation/comparison of experimental algorithm research– GSRC’s own backplane/sandbox integrated with industry tools/methods– real force behind development, convergence on data model

Metrics– standard metrics, standard COTS-based infrastructure established– GSRC’s own tools, flows all metricized; EDA vendors see the light– new R&D enabled by availability of design process data repositories

Our partners, colleagues involved and engaged!!!

5

Commitments and Organization

GSRC PIs– Jason Cong 33% – Wayne Dai 100% – Andrew Kahng 100%– Kurt Keutzer 20%– Wojciech Maly 50%

Mindshare / joining in from Constructive Fabrics, Test Committed participation from partners/sponsors … ?

– technology extrapolation calibration data, models– Bookshelf (formulations, formats, underlying data model)– metrics for design artifacts, tools and design processes

Browsing, feedback, proselytizing from everyone … ?

6

GTX: Technology Extrapolation

7

Team Status

GTX Engine and GUI– Mike Oliver (design, implementation)

– Andy Caldwell and Igor Markov (design)

GTX Rules– Farinaz Koushanfar, Hua Lu, Dr. Dirk Stroobandt

Theme PIs– Dai: models of block packing

– Cong: executable “rules” for BIS/WS interconnect optimization, via Dr. Wangning Long (based on TRIO package)

– Keutzer: new student to take over device / scaling module ?

– Cheng/Dey/Roy

8

Soft Block Packer (UCSC)

A Result of Soft Block Packing Using Simulated Annealing with Cost Function: Cost = Total Packing Area

9

Rd0 driver effective resistance of the input stage G0 Rd driver effective resistance of G l interconnect wire length CL loading capacitance

G

Input

G0l

CL

What is the optimized delay? Do not run TRIO or other optimization tools !

DEM - Delay Estimation Models for Interconnects

10

Some Applications of DEM’s

Layout-driven RTL and physical level floorplanning Consider interconnect opt. during high / logic level

synthesis– Use DEM to predict accurate interconnect delay without really

going into layout details

– Use accurate interconnect delay to guide synthesis

Interconnect Planning Ground-truth study -- GTX (Ground

Truths/Technology Extrapolation) …...

11

DEM Library -Delay Estimation Models for Interconnects

Capabilities

Delay estimation based on interconnect optimization techniques:– OWS (Optimal Wire Sizing)

• Critical length for buffer insertion under OWS– SDWS (Simultaneous Driver and Wire Sizing)

– BIWS (Buffer Insertion and Wire Sizing)

– BISWS (Buffer Insertion, Sizing and Wire Sizing)

Functions:– Tows, Lcrit, Tsdws, Tbiws, Tbisws, ……

12

Wireability Analysis Observations

– a priori WL estimates (e.g., Donath-type) do not take physical metal layers into account (unlimited wiring capacity assumed)

– choice of wire pitches at layers independent of considering wire lengths on these layers

– effects of vias and repeaters on WL left unstudied

Given:– # layers (or, layer types)

– wire pitch at each layer (at each layer type)

– estimated wirelength distribution

– Which interconnects will be routed on which layer?

Given: – allowed WL intervals for each layer type

– How many layers of each type are needed to handle all wires ?

13

Wireability Analysis Given:

– # tier types, wire pitch at each tier type

– estimated wirelength distribution

– interconnect dimensions and electrical properties

– How many layers of each type are needed to accommodate all wires such that the max-length wire at each tier has same delay for all tier types?

Given: – estimated wirelength distribution, and maximal delay

– What is the optimum number of tiers, and what are the optimal interconnect dimensions for each tier?

These questions are now addressed in GTX via code rules Still to do: improved model of vertical interconnect

14

Whitepaper Trail of GTX “optimum design strategy from manufacturing cost point

of view” “sensitivity analysis of ITRS cycle time projections” “a self-consistent technology roadmap for semiconductors” “wireability analysis and interconnect process

optimization for multi-terminal nets, repeaters and explicit vertical interconnect”

“impact of 1- and 2-exposure altPSM on speed, density, perf”

“appropriate choice of fault models for XXX” (DSM test)

15

The Bookshelf

16

Use Scenarios Steering committee solicits submissions

– bookshelf supports encyclopedic and unbiased coverage Researchers volunteer to submit their codes as entries

– bookshelf gives additional credit to past work Industrial affiliates publish benchmarks

– publicity to the company and a boost for academic research Students using bookshelf working on dissertation

– bookshelf offers reference and educational help Reviewers use Bookshelf to evaluate a new paper

– bookshelf helps easy evaluation Researchers compare new algos to what’s in Bookshelf

– bookshelf ensures competitiveness

17

Current State

Creation of several “charter” slots– hot areas: hypergraph partitioning, standard-cell placement,

single-tree interconnect synthesis, block placement/packing– emphasis on high quality, exemplary behaviors (e.g., source code release)– will meet stated goal for December (3-5 slots instantiated)

Outreach to academic groups and industrial affiliates– advisory role for slot definition

problem statements format specifications

– contribution of reference data, entries– prototype content of file format slots has been distributed

Current infrastructure is Web-accessible tree

18

Open Issues

How to achieve visibility, critical mass ?– support by contributions

– support by editorial policies, conference review policies

– need publicity and consistent message (N.B.: embedded tutorial at ICCAD99 was dinged)

Integration of the bookshelf– with the development model supported by GSRC

– common data models and file formats

Scalability and infrastructure for reuse– not frightening anyone away with excessive requirements

Policy for dealing with restrictions on reuse

19

Sketch of a Slot

Introduction and overview New Placement Formats Publicly available instances, solutions and reference

performance results Executable Utilities (converters, generators, statistics

browsers, evaluators, constraint verifiers) Optimizers and other non-trivial executables Common in-memory representations, parsers and other

source codes

20

General Guidelines

Introduction Motivation and Main Goals Gotchas Agreements Open issues Availability Status of New Data Formats Resources Appendix A. Note to Developers

21

New Common Data Formats

John Lillis at UIC– Single-tree Interconnect Synthesis (.pins, .topo, .target)– http://www.eecs.uic.edu/~ajaganna/gsrc/new_formats.txt

Patrick Madden at SUNNY Binghamton– Global Routing– http://sol.cs.binghamton.edu/~pmadden/gsrc/gridgraph.html

Wayne Dai at UCSC– Block Packing (.blks, .bconstr, .areapin) – http://www.cse.ucsc.edu/~huaizhi/bookshelf/bfp1.0

ABKGroup at UCLA– Standard-cell placement (core formats)

(.nodes, .nets, .wts, .scl, .pl)– http://vlsicad.cs.ucla.edu/GSRC/bookshelf/Slots/Placement– Extensions for partitioning (.blk, .fix, .sol)– http://vlsicad.cs.ucla.edu/GSRC/bookshelf/Slots/Partitioning

22

Summary of Bookshelf Status Initial bookshelf slots: Proselytizing: Tim Cheng at ITC, etc. Insertion into review processes ? Active convergence on data formats, tool linkages

– UIC, UCLA, SUNY Binghamton, UCSC in initial loop– 2 Ph.D. students + outsourcing to interested/engaged researchers– practical driver for efforts toward GSRC-standard data model and

API Standards

– standards (build system, platform, software, etc.) near-converged Commercial backplane

– tools (back-end implementation flow) from Synopsys, Cadence– compare against, integrate, mix-and-match with mini-flow above– industry data also sought

23

Metrics

24Metrics Data Warehouse

Tool Tool Tool

xmitter xmitter xmitter

Data-Mining

Reporting

Inter/Intra-net

Server

JavaApplets

WebBrowsers

Wrapper,embedded

AI

Metrics System Architecture

25

Strategy Team: Stefanus Mantik (Ph.D. student), OxSigen Leverage existing infrastructure

– OxSigen metrics list, model, prototype servers/reports– standard components (Oracle8i, XML encryption, MSFT UPNP)

Validate definitions of metrics with partners– metrics used by designers, std names, appropriate for tool classes

Develop solutions for basic decisions– protocols for metrics transmittal, retrieval– security, access levels– data integrity (bad data, optimization of transmission, …– consistency of metrics names, semantics between different tools– (identifying the right data, getting it out of tools) – (does tool context contain enough data? (e.g., P&R knows “datapath”?))– maintenance, evolution of metrics set, schema and APIs

26

First-Year (Milestones)

Sept 1999: transmittal API, Oracle8i install Oct 1999: DB interface for transmittal, table structures,

GSRC-endorsed standards (metrics schema, API), metricize one or two GSRC tools

Nov 1999: completion of transmittal side, initial website for retrieval

27

Summary of Metrics Status

Metrics infrastructure – substantial IP recently obtained from OxSigen LLC (used at Siemens)

– Metrics warehouse: data model, schema, API, servlets

– Metrics transmitter: applets to write metrics, embeddable in tools

– Off-the-shelf standard components: Oracle8i, XML, Java

– OxSigen scripts + extensions wrapped around today’s tool logfiles : metricizes the baseline (Synopsys/Cadence) GSRC back-end flow

– 1 Ph.D. student will do thesis on Metrics in EDA

Need:– buy-in from EDA companies

– pull from EDA customers = GSRC sponsors

28

December Show GSRC Technology Extrapolation system, GTX1.0

– arbitrary tradeoff studies, parameter optimizations– platform-independent engine, GUI; flexible definition/display of studies– param/rule definition: interactive, code/table/ASCII based– accurate models of (1) optimization effects in layers between individual wires/devices and system architecture

(UCLA DEM, UCSC soft-block packer); (2) global interconnect resource; etc.– documented, comprehensive; distributed participation– insights on sensitivities, accuracy of existing extrapolations; “new” ones

Bookshelf– publicize, internalize, externalize desired culture/behavior goals– 3-5 slots instantiated with entries from multiple investigators– mini-flow built around partitioning / soft-block packing / cell placement / interconnect opt / global routing– evidence of driving force toward data model, tool/flow backplane

Metrics– integration of OxSigen IP, basic transmit/retrieve/report functionality– GSRC proposal of standard Metrics schema and API– GSRC sites running metricized std implementation methodology