calibrating achievable design technology extrapolation the bookshelf and metrics n.
Skip this Video
Loading SlideShow in 5 Seconds..
Calibrating Achievable Design : Technology Extrapolation, the Bookshelf, and Metrics PowerPoint Presentation
Download Presentation
Calibrating Achievable Design : Technology Extrapolation, the Bookshelf, and Metrics

Loading in 2 Seconds...

play fullscreen
1 / 28

Calibrating Achievable Design : Technology Extrapolation, the Bookshelf, and Metrics - PowerPoint PPT Presentation

  • Uploaded on

Calibrating Achievable Design : Technology Extrapolation, the Bookshelf, and Metrics. Theme Summary Cong, Dai, Kahng, Keutzer, Maly. Mission. Enable the understanding of achievable design. Motivations. Provide system-level design with predictable implementation

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Calibrating Achievable Design : Technology Extrapolation, the Bookshelf, and Metrics

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
calibrating achievable design technology extrapolation the bookshelf and metrics

Calibrating Achievable Design: Technology Extrapolation, the Bookshelf, and Metrics

Theme Summary

Cong, Dai, Kahng, Keutzer, Maly


Enable the understanding of achievable design

  • 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)
  • 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!!!
commitments and organization
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 … ?
team status
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
soft block packer ucsc
Soft Block Packer (UCSC)
  • A Result of Soft Block Packing Using Simulated Annealing with Cost Function: Cost = Total Packing Area
dem delay estimation models for interconnects



What is the optimized delay?

Do not run TRIO or other optimization tools !

DEM - Delay Estimation Models for Interconnects




Rd0 driver effective resistance of the input stage G0

Rd driver effective resistance of G

l interconnect wire length

CL loading capacitance

some applications of dem s
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)
  • …...
dem library delay estimation models for interconnects
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, ……
wireability analysis
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 ?
wireability analysis1
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
whitepaper trail of gtx
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)
use scenarios
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
current state
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
open issues
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
sketch of a slot
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
general guidelines
General Guidelines
  • Introduction
  • Motivation and Main Goals
  • Gotchas
  • Agreements
  • Open issues
  • Availability Status of New Data Formats
  • Resources
  • Appendix A. Note to Developers
new common data formats
New Common Data Formats
  • John Lillis at UIC
    • Single-tree Interconnect Synthesis (.pins, .topo, .target)
  • Patrick Madden at SUNNY Binghamton
    • Global Routing
  • Wayne Dai at UCSC
    • Block Packing (.blks, .bconstr, .areapin)
  • ABKGroup at UCLA
    • Standard-cell placement (core formats)

(.nodes, .nets, .wts, .scl, .pl)

    • Extensions for partitioning (.blk, .fix, .sol)
summary of bookshelf status
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
metrics system architecture
Metrics System Architecture


















Metrics Data Warehouse

  • 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
first year milestones
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
summary of metrics status
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
december show
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