Download Design Productivity Crisis

GTX: The MARCO GSRC
Technology Extrapolation System
Abstract
Andrew E. Caldwell, Farinaz Koushanfar, Andrew B. Kahng, Hua Lu, Igor L. Markov, Michael R. Oliver, Dirk Stroobandt
http://www.gigascale.org/gtx
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



"inference chains"
sensitivity to technology and design decisions
compatibility and accuracy of system models
Are properly extrapolated via:
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
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.




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”
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.)
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.
DARPA