GTX: The MARCO GSRC Technology Extrapolation System

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. Introduction Goal: Technology Extrapolation What does the design problem look like? Collect fundamental facts and data points Anchor the process of bounding the achievable envelope of design Can be with respect to: manufacturing process, materials, physical phenomena specific CAD optimizations of circuit topology/embedding system architecture and packaging Are properly extrapolated via: "inference chains" sensitivity to technology and design decisions compatibility and accuracy of system models Drive the EDA vision of future design issues, methodology identify ”ground truths” and infer fundamental limits Example Technology Extrapolation Questions Maximum possible clock frequency for a given process and die size? When does inductance matter? What design tradeoffs will maintain reasonable supply currents? Necessary number of package pins/balls for power/ground distribution? Optimal design strategy from a manufacturing cost point of view? Previous work in VLSI BACPAC, SUSPENS, RIPE, GENESIS, etc. hard-coded models and evaluation sequences implementations often not generally available (cannot verify results) not extensible by others Previous work in Artificial Intelligence TkSolver, DesignSheet, UniCalc Inference engines, constraint programming or expert systems solve very general formulations yet may be limited to predicate logic or systems of equations ( a “placement engine” will not fit) GTX Open knowledge base (uses human-readable ASCII grammar) avoids duplication of effort by allowing reuse storage for rules / relations as well as calibration data from designs / 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) GTX System Overview Knowledge representation: “parameters” and “rules” Parameters: system attributes or variables Rules: take any number of parameters, produce single input laws of physics, models of electrical behavior statistical models (Rent's rule, etc.) Knowledge representation in GTX Human-readable ASCII grammars for parameters and rules Parsed at start-up or entered by user at runtime Include closed-form expressions, vector operations, tables, etc Allow references and comments Enable peer review, verification, reuse and extensions “External executable” rules Assume a callable executable (potentially over the network) Parameters on the command-line, results in a file Allows arbitrarily complex semantics of a rule (e.g., placers, IPEM) “Code” rules Implemented in C++ and linked into the inference engine Useful to implement complex loops Currently used for duplication of BACPAC and new research GTX rules and parameters come in modules A module represents a “topic” Eight modules currently available and more to come System-level Power, Clock and Power, Device and Power, SOI, Domino logic, Global Interconnect, Reliability and Yield, Packaging “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 Results of a study can be plotted Constraints Simulated by rules that compute boolean values Used to limit range during “sweeping” GTX Engine Contains no domain-specific knowledge Evaluates rules in topological order, e.g., for “sweeping” Conclusions and Future Research GTX 1.0 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://www.gigascale.org (Solaris, Linux, Windows NT) and have already been used by our colleagues in academia and industry. GTX: The MARCO GSRC Technology Extrapolation System Andrew E. Caldwell, Farinaz Koushanfar, Andrew B. Kahng, Hua Lu, Igor L. Markov, Michael R. Oliver, Dirk Stroobandt http://www.gigascale.org/gtx