MARCO GSRC Calibrating Achievable Design Theme

GSRC Technology Extrapolation (GTX)

Design document

revision 2.3, November 08, 1999

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

Contents

This document describes the design of a system for MARCO GSRC Technology Extrapolation (GTX) following the overview document.

• A. The basic representation involves parameter nodes and rules
1. Parameter nodes represent parameters of the system being modeled, e.g., the number of transistors on the chip or the resistivity of wiring on a given layer
2. Rules, as defined in the overview, are ways to derive parameter values from previously known parameter values; this includes algorithms and models, such as explicit arithmetic expressions
• B. Further representations
1. directed hypergraph Rules and parameter nodes can be represented by a directed hypergraph where parameter nodes are vertices and rules are hyperedges. Directionality of a hyperedge corresponds to input/output parameters of a rule. It is agreed that all rules have exactly one output parameter (e.g., a vector of doubles, see below)
2. bipartite graph One may find it convenient to represent the above hypergraph by a bipartite graph whose part-0 vertices are vertices of the hypergraph (parameters) and part-1 vertices are hyperedges(rules). A part-0 vertex is connected to a part-1 vertex iff the respective hypergraph node is incident to the respective hyperedge. Directionality of edges is set in the obvious way.

• A. Storing rules and parameter nodes
1. Each parameter node and each rule will be represented by an independent object of an appropriate class
2. Each rule object and each parameter object are assigned
• a global integer index (rules and parameters indexed separately)
• a string-name
• a short description in English
• a reference to the literature
3. rule objects and parameters objects can be retrieved by
• index
• string-name
• B. Instantiation
1. Instantiation of a parameter object can be caused by parsing an ASCII definition, user input and by instantiation of a rule for which not all input or output parameters exist. In the latter case, the string-name and the type can be deduced from the rule description. English descriptions can be added later if an ASCII definitions of the parameter with the same name is parsed.
2. Instantiation of a rule object can be caused by parsing an ASCII description or user input (the latter also results in parsing ASCII description).
• C. Basic differences between rules and parameter nodes
1. Rule objects have an "eval method" that performs a computation representing the rule, given valid input values
2. Parameter node objects hold the default value (if any) of the parameter, its type, units and any range.
• D. Rules can be classified by two attributes
1. Compilation status
• fully compiled, i.e., written in Java, C or C++
• interpreted, i.e., defined by an ASCII string; evaluation tree or similar structures are constructed when parsing the string and is used by the 'eval method' of the rule. A grammar for the ASCII format is be specified in the Appendix.
2. Assumptions about external computations
• self-contained
• with external computations; assumptions must be made about the availability of external computations, such as the name of an executable or the availability of a computation server at a certain port of a certain host
• E. Furthermore, interpreted self-contained nodes can be of the following types
• an explicit arithmetic expression
• a table (with associated interpolation method, e.g., none, linear, spline); throws an exception if input values do not yield a valid output when interpolation method is applied
• optimizations (similar to arithmetic expressions: minimize a given function for given values of some of its inputs, while other inputs are restricted to given segments)
• F. Parameter nodes have types, enabling limited type checking by the engine. For example, 3.1415 passed to a rule that expected an integer (e.g. a year) will cause an error condition.  The available  types are currently integer, double, string , boolean. Moreover types may be placed in vectors, e.g. vector<double> (a 1-dimensional array of doubles) or vector<vector<double>> (a 2-dimensional array).  Currently the underlying type of a vector must be double. The engine conducts limited type checking, which does not relieve rules from the responsibility for range checks of their input parameters. Rules have an ability to throw exceptions if the input values do not allow for a meaningful output.

The main components are the engine, (on the server side in the client-server model), the GUI client and the communication layer between the server and the client. The GTX application is asynchronously driven by GUI via the communication layer. Only the communication layer must be implemented differently to support both the client-server use model and the monolithic application use model. The engine, the state class and the GUI may change minimally if at all. (In the monolithic application model, the only currently-implemented version, the communication layer does not exist -- the GUI simply uses engine methods directly).

• A. The engine
1. Maintains the current values of the parameters, together with the outputs of any requested "sweep studies".  Any parameter may have zero or more values at any given time.
2. Maintains the current collection of rules.
3. Maintains the current rule chain
4. When requested to execute a rule chain, the engine computes the values of all parameters computed by rules in the chain from the input values to the rules.
5. When a rule is parsed, it may appear that a rule with an identical name existed earlier. In this case, the new rule overrides the old rule.
• C. The communication layer
• main purpose: to isolate other parts from changes in the use model
• method of communication between the server and the client (across the network or in the same application)
• expected to be rather simple (currently non-existent)
• D. GUI

The general requirement for GUI is to enable interaction with the user on the main GTX functionalities as set in section II.A. of the overview.

Particular GUI functionalities include, but are not limited to

1. Access to current parameter values, including edits and refreshing affected parameters
2. Access to documentation for parameter nodes and rules
3. User-defined rule chains, user-assisted or fully automatic discovery of rule chains (i.e., forwarding relevant queries to the engine and display results)
4. Evaluation of a given rule or rule chain, including "sweeping"
5. Undo/redo functionalities and browing session history
6. Consistency check for a given set of parameter values
7. New rules specified by the user