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

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. G0 Input What is the optimized delay? Do not run TRIO or other optimization tools ! DEM - Delay Estimation Models for Interconnects G l CL Rd0 driver effective resistance of the input stage G0 Rd driver effective resistance of G l interconnect wire length CL loading capacitance

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

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

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