1. Parameters System attributes or variables Example of ASCII parameter grammar #parameter dl_chip #parameter dl_chip #type double #type double #units {m} #units {m} #default 1e-2 #default 1e-2 #description #description chip side length chip side length #reference #reference #endparameter #endparameter Naming convention for parameters [ ] _ _ {[ ] _ } _ { } _ [ ] _ [ ] _ [ ] Example: r_int_tot_lyr_pu_dl GTX: The MARCO GSRC Technology Extrapolation System 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 Andrew Caldwell, Andrew B. Kahng, Igor L. Markov, Michael R. Oliver and Dirk Stroobandt http://vlsicad.cs.ucla.edu/GSRC/GTX/ –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 Parameters (data) Rules (models) Rule chain (study) Knowledge Engine (derivation) GUI (presentation) Implementation User inputs Pre-packaged GTX System Overview Knowledge and implementation are separated 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 How and when do L, SOI, SER, etc. matter? What is the most power-efficient noise management strategy? Will layout tools need to perform process simulation to efficiently model cross-die and cross-wafer manufacturing variation? 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 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 GTX Engine Contains no domain-specific knowledge Evaluates rules in topological order Multiple values through “sweeping” 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. 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 #rule BACPAC_dl_chip #description#output double {m} dl_chip; #inputs double {m^2} dA_chip; #body sqrt(dA_chip) #reference#endrule Example Questions 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.) –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) Graphical User Interface (GUI) Provides user interaction Allows plotting of results 4 views: –Parameters –Rules –Rule chain –Values in chain 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 “Code” rules –Implemented in C++ and linked into the inference engine –Useful if execution speed is an issue Previous Work 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)