Calibrating Achievable Design Technology Extrapolation the Bookshelf and

Calibrating Achievable Design: Technology Extrapolation, the Bookshelf, and Metrics Theme Summary Cong, Dai, Kahng, Keutzer, Maly 1

Mission Enable the understanding of achievable design 2

Motivations u u 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 u 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) 3

Vision u GTX – – u 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 u 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 u Our partners, colleagues involved and engaged!!! 4

Commitments and Organization u GSRC PIs – – – u u 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 u Browsing, feedback, proselytizing from everyone … ? 5

GTX: Technology Extrapolation 6

Team Status u GTX Engine and GUI – Mike Oliver (design, implementation) – Andy Caldwell and Igor Markov (design) u GTX Rules – Farinaz Koushanfar, Hua Lu, Dr. Dirk Stroobandt u 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 7

Soft Block Packer (UCSC) u A Result of Soft Block Packing Using Simulated Annealing with Cost Function: Cost = Total Packing Area 8

DEM - Delay Estimation Models for Interconnects G 0 G l CL Input u u Rd 0 Rd l CL driver effective resistance of the input stage G 0 driver effective resistance of G interconnect wire length loading capacitance What is the optimized delay? Do not run TRIO or other optimization tools ! 9

Some Applications of DEM’s u u 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 u u u Interconnect Planning Ground-truth study -- GTX (Ground Truths/Technology Extrapolation) …. . . 10

DEM Library -Delay Estimation Models for Interconnects u 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) u Functions: – Tows, Lcrit, Tsdws, Tbisws, …… 11

Wireability Analysis u 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 u Given: – – u # 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 ? 12

Wireability Analysis u Given: – – u # 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? u u These questions are now addressed in GTX via code rules Still to do: improved model of vertical interconnect 13

Whitepaper Trail of GTX u u u “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 alt. PSM on speed, density, perf” “appropriate choice of fault models for XXX” (DSM test) 14

The Bookshelf 15

Use Scenarios u Steering committee solicits submissions – bookshelf supports encyclopedic and unbiased coverage u Researchers volunteer to submit their codes as entries – bookshelf gives additional credit to past work u Industrial affiliates publish benchmarks – publicity to the company and a boost for academic research u Students using bookshelf working on dissertation – bookshelf offers reference and educational help u Reviewers use Bookshelf to evaluate a new paper – bookshelf helps easy evaluation u Researchers compare new algos to what’s in Bookshelf – bookshelf ensures competitiveness 16

Current State u 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) u Outreach to academic groups – advisory role for slot definition u u and industrial affiliates problem statements format specifications – contribution of reference data, entries – prototype content of file format slots has been distributed u Current infrastructure is Web-accessible tree 17

Open Issues u 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 ICCAD 99 was dinged) u Integration of the bookshelf – with the development model supported by GSRC – common data models and file formats u Scalability and infrastructure for reuse – not frightening anyone away with excessive requirements u Policy for dealing with restrictions on reuse 18

Sketch of a Slot u u u 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 19

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

New Common Data Formats u John Lillis at UIC – Single-tree Interconnect Synthesis (. pins, . topo, . target) – http: //www. eecs. uic. edu/~ajaganna/gsrc/new_formats. txt u Patrick Madden at SUNNY Binghamton – Global Routing – http: //sol. cs. binghamton. edu/~pmadden/gsrc/gridgraph. html u Wayne Dai at UCSC – Block Packing (. blks, . bconstr, . areapin) – http: //www. cse. ucsc. edu/~huaizhi/bookshelf/bfp 1. 0 u 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 21

Summary of Bookshelf Status u u 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 u Standards – standards (build system, platform, software, etc. ) near-converged u Commercial backplane – tools (back-end implementation flow) from Synopsys, Cadence – compare against, integrate, mix-and-match with mini-flow above – industry data also sought 22

Metrics 23

Metrics System Architecture Web Browsers Tool xmitter Wrapper, embedded Java Applets Inter/Intra-net Server Reporting Data-Mining AI Metrics Data Warehouse 24

Strategy u u Team: Stefanus Mantik (Ph. D. student), Ox. Sigen Leverage existing infrastructure – Ox. Sigen metrics list, model, prototype servers/reports – standard components (Oracle 8 i, XML encryption, MSFT UPNP) u Validate definitions of metrics with partners – metrics used by designers, std names, appropriate for tool classes u 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 25

First-Year (Milestones) u u u Sept 1999: transmittal API, Oracle 8 i 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 26

Summary of Metrics Status u Metrics infrastructure – – – substantial IP recently obtained from Ox. Sigen 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: Oracle 8 i, XML, Java Ox. Sigen 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 u Need: – buy-in from EDA companies – pull from EDA customers = GSRC sponsors 27

December Show u GSRC Technology Extrapolation system, GTX 1. 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 u 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 u Metrics – integration of Ox. Sigen IP, basic transmit/retrieve/report functionality – GSRC proposal of standard Metrics schema and API – GSRC sites running metricized std implementation methodology 28