1 / 1

GTX: The MARCO GSRC Technology Extrapolation System

Abstract

hu-bowers
Download Presentation

GTX: The MARCO GSRC Technology Extrapolation System

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Abstract Technology extrapolation -- i.e., the calibration and prediction of achievable design in future technology generations -- drives the evolution of VLSI system architectures, design methodologies, and design tools. Via roadmapping efforts such as the International Technology Roadmap for Semiconductors (ITRS), technology extrapolation also influences levels of investment in various areas of academic research, private-sector entrepreneurial activity, and other facets of VLSI design automation. This poster describes the MARCO GSRC Technology Extrapolation System (GTX), which provides a robust, portable framework for the interactive specification and comparison of alternative modeling choices, e.g., for predicting system cycle time, die size, or power dissipation. Unlike previous "hard-coded" systems, GTX allows users to flexibly capture attributes and relationships of VLSI technology and design. The GTX derivation engine performs studies along inference chains composed of user-defined rules. With its supporting grammars, parameter naming conventions, extension mechanisms, etc., GTX is an open source infrastructure allowing added value from its users. Goal: Technology Extrapolation What does the design problem look like? Collect fundamental facts and data points Anchor the process of bounding the envelope of achievable design with respect to: manufacturing process, materials, physical phenomena specific CAD optimizations of circuit topology system architecture and packaging Drive the EDA vision of future design issues, system architectures, design methodologies, and design tools identify “ground truths” and infer fundamental limits What is the most power-efficient noise management strategy? How and when do L, SOI, SER, etc. matter? Will layout tools need to perform process simulation to efficiently model cross-die and cross-wafer manufacturing variation? • GTX rules and parameters • come in modules • A module represents a “topic” • Currently eight modules • System-level Power • Clock and Power • Device and Power • SOI • Domino logic • Global Interconnect • Reliability and Yield • Packaging • Graphical User Interface (GUI) • Provides user interaction • Allows plotting of results • 4 views: • Parameters • Rules • Rule chain • Values in chain GTX: The MARCO GSRCTechnology Extrapolation System Andrew Caldwell, Andrew B. Kahng, Igor L. Markov, Michael R. Oliver and Dirk Stroobandt http://vlsicad.cs.ucla.edu/GSRC/GTX/ Example Questions Previous Work • SUSPENS, Sai-Halasz, BACPAC, RIPE, GENESYS, etc. • Systems are often incomparable • Hard-coded models and evaluation sequences • Implementations often not generally available • Difficult to assess quality of models • Not extensible by others • Near-total duplication of effort • Artificial Intelligence: TkSolver, DesignSheet, UniCalc • inference engines, constraint programming or expert systems • solve very general formulations • yetmay be limited to predicate logic or systems of equations • ( a “placement engine” will not fit) • Knowledge Representation • Human-readable ASCII grammar • Parsed at start-up or entered by user at runtime • Allows references and comments • Enables peer review, verification, reuse and extensions • GTX • Framework for specification and comparison of alternative modeling choices • Open knowledge base (uses human-readable ASCII grammar) • avoids duplication of effort by allowing reuse • storage for rules and calibration data from designs or technologies • Flexible inference engine • Empowers users (via powerful GUI) to • change and extend models, add new system variables • define evaluation sequences • perform “studies” (e.g., produce plots, sensitivity analyses etc.) • Parameters • System attributes or variables • Example of ASCII parameter grammar #parameter dl_chip #type double #units {m} #default 1e-2 #description chip side length #reference #endparameter • Naming convention for parameters • [<preposition>] _ <principal> _ {[<qualifier>] _ <place>} _ {<qualifier>} _ [<adverbial>] _ [<index>] _ [<unit>] • Example: r_int_tot_lyr_pu_dl • GTX Engine • Contains no domain-specific knowledge • Evaluates rules in topological order • Multiple values through “sweeping” GTX System Overview Knowledge and implementation are separated • Benefits: • Relatively easy to understand name • Distinguishable (no two parameters • should have the same name) • r_int (interconnect resistance) • = r_int (interconnect resistivity) ? • Unique (no two names • for the same parameter) • R_int = R_wire ? • Sortable (important • literals come first) Knowledge Implementation Parameters (data) User inputs Engine (derivation) Rules (models) Pre-packaged GUI (presentation) Rule chain (study) • Rules • Take any number of input parameters, • single output • Main: ASCII rules • laws of physics, models of electrical behavior • statistical models (Rent's rule, etc.) • Include closed-form expressions, vector operations, • tables, etc. • Constraints • Simulated by rules that compute boolean values • Used to limit range during “sweeping” • “External executable” rules • Assume a callable executable (e.g., PERL script) • Uses command-line interface and transfer through files • Allows complex semantics of a rule (e.g., placers, IPEM executable) #rule BACPAC_dl_chip #description #output double {m} dl_chip; #inputs double {m^2} dA_chip; #body sqrt(dA_chip) #reference #endrule • “Code” rules • Implemented in C++ and linked into the inference engine • Useful if execution speed is an issue • Rule Chains • “Rule chains” guide inference • Acyclic set of rules - no two rules may compute the same parameter • User-controlled and savable • (Sets of) values of primary inputs must be available • (Sets of) values of rule outputs automatically computed by GTX engine • Studies • Input values + rules that make a rule chain • User-controlled and savable • “Sweeping” of a rule chain • evaluation of all combinations of multi-valued inputs • e.g., sweep over width = 1-10, height = 1-10, with constraint area 20 Conclusions and Future Research GTX is available and successfully replicated results of previous studies in SUSPENS, BACPAC and other works. GTX promotes open knowledge representation that can be easily shared by researchers and used for collaborations. Current implementation and available rule modules can be freely downloaded from http://vlsicad.cs.ucla.edu/GSRC/GTX/ (Solaris, Linux, Windows) and have already been used by our colleagues in academia and industry.

More Related