MARCO GSRC Calibrating Achievable Design Theme

GSRC Technology Extrapolation (GTX)

Overview

revision 1.7, November 08, 1999

Andrew Caldwell, Andrew B. Kahng, Igor Markov and Mike Oliver

Contents

Leading-edge VLSI system design aggressively applies new process technologies and circuit topologies, as well as ever-improving design tools. Estimation of what constitutes "achievable design" -- e.g., power-delay-area envelope for a given behavior or function -- becomes increasingly difficult. Identification of conflicting assumptions within technology and design roadmaps is also difficult. The GTX (GSRC Technology Extrapolation) project in the MARCO GSRC seeks a new level of automation to respond to these challenges.

"Technology Extrapolation" are facts that can be derived from process technology and design process assumptions using a given collection of models and algorithms. Technology Extrapolation pertain to derivable parameters of interest at all levels of architecture, logic design, physical design and manufacturing insofar as they enable prediction of technology's effects on the achievable design envelope.

"Rules" encapsulate various ways to derive parameter values from previously known values; these include both algorithms and models.

Previous efforts to estimate Technology Extrapolation from basic parameters using known rules have been very successful and include works of Bakoglu/Meindl (SUSPENS), Sai-Halasz, Rahmat et al., the various Roadmap efforts and innumerable internal efforts in the industry. Automated estimators include BACPAC, RIPE and GENESYS.

GTX aims to

• improve upon the flexibility of available automatic estimators and the underlying collection of rules
• allow users to experiment with causal relationships between parameters at all levels
• assist users find chains of rules to connect parameters that are not immediately related
• establish a "repository of first choice" for rules and data (calibration points) related to IC technology and technology extrapolation
• allow user extensions and adaptations
• enable widespread use in industry (e.g., for accurate long-range forecasting) and in academia (e.g., for teaching)

The two basic use models include a monolithic single-user application and a client-server version that would allow remote execution and collaborative work. Functionalities are described in II.A.; use models are described in II.B.

• A. Functionalities
1. Computation of technology and design parameters following [chains of] rules, depending on the available and sought values
2. User-assisted discovery of rule chains, in addition to chains entered by user
3. Interactive selection of alternative rules for a particular computation
4. Interactive modification of rule chains, re-evaluation with different input values and saving for further uses (persistence)
5. Suggestion of missing rules if automatic discovery of rule chains fails
6. Application of rules to ranges of input parameters ("sweeping")
7. Ability to interactively add user-defined rules (see also section V.B. below)
8. Multiple types of rules, including symbolic formulae, tables, interpolations and external computations
9. Optimization of parameters given values of other parameters
10. Subsuming of all major "fixed" functionality currently supplied by the GENESYS, RIPE and BACPAC systems, as well as industry efforts such as HIVE/AIM.
11. Appropriate levels of security for user data and rules, including operation on networked and non-networked workstations
12. Session history, undo, redo (these not yet implemented), saving of sessions, data and rules
13. Online documentation for parameters and rules
14. Intuitive graphical user interface (GUI).
See also section IV. Future extensions.
• B. Use models
1. Single-user application
• network connection unnecessary
• user data protected
• optional connections to offload computationally-intensive rules, using data encryption
• rule management tools separate from main application
2. Client-server use model (not implemented)
• user interface runs as client, rules are evaluated on the server
• multiple clients/users
• optionally encrypted communications
• limits on communication bandwidth
• user data available to the server
• user created/modified rules need server support or else must be disabled
It has been a general consensus point that 1) is more important and that we do not need to pursue 2) immediately. However, we are trying to avoid design decisions that would make II.B.2) incompatible with II.A.
• C. Limitations
1. Our implementation for the client-server model will have certain temporary restrictions associated with technical difficulties, e.g., adding and editing rules may not be allowed.
2. General rules are not allowed, e.g., we will not have a rule V=IR that can be applied to parameters with names different from V,I and R (parameters with such general names are likely to be useless). GTX can not substitue I_1 for I and R_2 for R.

In each use model, the functionalities of GTX are supported by a main GTX application and domain-specific [packages of] rules. Rule representation is discussed in Section V. below, and, once it is fixed, rules can be treated as external to the main GTX application --- i.e., the application reads and uses rules, but does not create rules. Rule management tools (e.g., for creation, modification and search) are likely to be separate from the main GTX application.

The following discussion of the main GTX application considers the two use models simultaneously; the single-user model can be viewed as a degenerate case of the client-server model.

GTX application

• rule processing engine on the server side, including all information to be saved
• state object maintaining all information to be saved on server side
• GUI on the client side
• communication layer (currently nonexistent as we have only the single-user application)

• A. State-based communication and sessions. In the multi-user model, the server needs to maintain state in communications with every client. This can be done by instantiating the single-user core for each client and directing communications between clients and relevant copies of single-user core. Assuming this implementation, a session is an association between a client and an existing copy of the single-user core plus all communications that use the association. Sessions are independent.  This should be considered a "future extension"; currently only the single-user model exists.
• B. Sessions are asynchronously driven by clients. The engine evaluates rules on behalf of clients and maintains the communication state. Every computation/query in a session must be initiated by respective client, and results are returned to the same client to be displayed to the user. In practical terms, this means that a particular instance of the single-user core "sleeps" until woken up by a request of its client.

1. Detecting conflicts in supplied data
2. Free exchange of rules and data between users, "user spaces" and "application spaces"
3. Provision of preprogrammed "classic studies" (rule chains that are known to be useful)
4. Interfaces to existing systems (GENESYS, BACPAC, RIPE, ...) as "external computation" rules

This section is now of only historical interest; the application has been implemented in C++.  We preserve it to show the thought process.

• A. The GUI/engine interface is expected to be rather simple with predominantly low-bandwidth queries. Complications would affect the modularity and the feasibility of GTX as specified in III. and II.A.
• B. Serial representations of rules is a major design issue. Our discussion closes with a more detailed look at two potential solutions.
• ASCII representations that are parsed during instantiation of rule classes and can be freely transmitted through the network
• Java or C++ source code that is compiled by the user and supplied to the engine; in this case, the engine would instantiate rule classes by [string] name
The choice between these two options has major implications for GTX implementation, feasible functionalities and user interface.

At this time, our belief is that ASCII representations are necessary; the main arguments for/against both solutions are summarized below. Having the ability to instantiate rules from ASCII definitions does not preclude rules that are compiled from Java/C++ source code and are built into the server (e.g., for rare types of rules). No user interface is planned for source-code rules, and only developers can build source-code rules into the server.

Arguments for user interface for source-code rules
1. Rules can be as flexibile as a Java/C++ program can be
2. No need to construct specialized parsers for rules as rules would be parsed by Java/C++ compilers


Arguments against user interface for source-code rules
A series of specification conflicts and portability issues arise when user interface for source-code rules is required. This is primarily due to user-defined rules mentioned in I.A.7) that may be added during a user session.

3. Users who write rules in source code, need a compiler on their system. Re-distribution of most compilers is not allowed by licensing terms, but many compilers are available for free, e.g. Sun's JVM.
4. Moreover, if a monolithic application distributed in native code, we need to distribute the main GTX application in a form that allows users building versions augmented by their rules.


Arguments for representing rules in ASCII

5. Problems mentioned in V.B.3)-4) are avoided
6. Rule grammars are not complex and constructing a parser should not take much time, e.g. using yacc-like programs
7. Many parsers are available and can be modified to avoid writing a parser from scratch. In particular, using gnuplot code would give us a parser of a reasonably powerful language with variables, library and user-defined functions, "for" loops etc. Gnuplot also has extensive facilities to manipulate in-memory representations of the parsed code (such as equation solving, generic plotting etc)


Arguments against representing rules in ASCII

8. Potentially more difficult implementation, given that a parser is required (the source code option relies on parsers in compilers)
9. Limitations on the algorithms used in rules that are evaluated by the engine (does not limit externally evaluated rules)