DARPA GTX: The MARCO GSRC Technology Extrapolation System Abstract Technology extrapolation -- i.e., the calibration and prediction of achievable 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 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 u Goal: Technology Extrapolation s What does the design problem look like? s Collect fundamental facts and data points s Anchor the process of bounding the achievable envelope of design s Can be with respect to: t manufacturing process, materials, physical phenomena t specific CAD optimizations of circuit topology/embedding t system architecture and packaging s Are properly extrapolated via: t "inference chains" t sensitivity to technology and design decisions t compatibility and accuracy of system models s Drive the EDA vision of future design issues, methodology t identify ”ground truths” and infer fundamental limits u Example Technology Extrapolation Questions s Maximum possible clock frequency for a given process and die size? s When does inductance matter? s What design tradeoffs will maintain reasonable supply currents? s Necessary number of package pins/balls for power/ground distribution? s Optimal design strategy from a manufacturing cost point of view? u Previous work in VLSI s BACPAC, SUSPENS, RIPE, GENESIS, etc. t hard-coded models and evaluation sequences t implementations often not generally available (cannot verify results) t not extensible by others u Previous work in Artificial Intelligence s TkSolver, DesignSheet, UniCalc s Inference engines, constraint programming or expert systems t solve very general formulations t yet may be limited to predicate logic or systems of equations ( a “placement engine” will not fit) ( a “placement engine” will not fit) u GTX s Open knowledge base (uses human-readable ASCII grammar) t avoids duplication of effort by allowing reuse t storage for rules / relations as well as calibration data from designs / technologies s Flexible inference engine s Empowers users (via powerful GUI) to t change and extend models, add new system variables t define evaluation sequences t perform “studies” (e.g., produce plots, sensitivity analyses etc) GTX System Overview s Knowledge representation: “parameters” and “rules” s Parameters: system attributes or variables s Rules: take any number of parameters, produce single input t laws of physics, models of electrical behavior t statistical models (Rent's rule, etc.) Knowledge representation in GTX u Human-readable ASCII grammars for parameters and rules s Parsed at start-up or entered by user at runtime s Include closed-form expressions, vector operations, tables, etc s Allow references and comments s Enable peer review, verification, reuse and extensions u “External executable” rules s Assume a callable executable (potentially over the network) s Parameters on the command-line, results in a file s Allows arbitrarily complex semantics of a rule (e.g., placers, IPEM) u “Code” rules s Implemented in C++ and linked into the inference engine s Useful to implement complex loops s Currently used for duplication of BACPAC and new research u GTX rules and parameters come in modules s A module represents a “topic” s 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 u “Rule chains” guide inference s Acyclic set of rules - no two rules may compute the same parameter s User-controlled and savable s (Sets of) values of primary inputs must be available s (Sets of) values of rule outputs automatically computed by GTX engine u Studies s Input values + rules that make a rule chain s User-controlled and savable s “Sweeping” of a rule chain t evaluation of all combinations of multi-valued inputs  e.g., sweep over width:=1-10, height:=1-10, with constraint area  20 s Results of a study can be plotted u Constraints s Simulated by rules that compute boolean values s Used to limit range during “sweeping” GTX Engine u Contains no domain-specific knowledge u 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 (Solaris, Linux, Windows NT) and have already been used by our colleagues in academia and industry. 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 (Solaris, Linux, Windows NT) and have already been used by our colleagues in academia and industry. Andrew E. Caldwell, Farinaz Koushanfar, Andrew B. Kahng, Hua Lu, Igor L. Markov, Michael R. Oliver, Dirk Stroobandt