Enhancements to GTX Sachin Bansal, Andrew B. Kahng, Igor Markov, Mike Oliver, Dirk Stroobandt Calibrating Achievable De

1. Enhancements to GTXSachin Bansal, Andrew B. Kahng, Igor Markov, Mike Oliver, Dirk Stroobandt Calibrating Achievable Design Theme Rules are now by default localized to a namespace which groups them together according to the model used to compute their outputs. Parameters may also have a namespace: this is useful in identifying parameters which have no interesting “intrinsic” meaning, but are simply intermediate values in a calculation specific to a given model. Example: There are two available rules to compute average interconnection length on chip, one (being used) from the DAVIS model, and the other from SUSPENS. • The graph view shows relationships between parameters and the rules that calculate and/or use them. • Bold font : in the current rule chain • Green dot : enough information for the the value in question to be calculated • Red circle : not enough information “Batch recorder” mode saves most operations that are performed to a file. • Replay of the batch record file enables retracing of a session, automated testing, and canned demos/tutorials where the user steps through the prearranged sequence of events by clicking “OK” in a dialog box. • Further enhancements are needed to allow for meaningful messages in these dialogs, and to incorporate some recent features (such as the graph view) into the macro facility. Example (default) view: sources are children of their sinks, and both rules (blue) and parameters (black) are shown the same time. The user can choose to make sinks children of their sources, or to show only rules or only parameters. • Table: (artificial example) • Year: 1999 2000 2001 2002 2003 2004 2005 • chip side (mm) 20 40 80 160 • chip area(mm2) 400 1600 6400 25600 • How can we change one value, and get the other values to change? • GTX currently uses a single “rule chain” at a time, which is a DAG. • May have to generalize this (how much?) • Also want concise syntax to express exponential change in a timeline, with different rates for different “generations”. Chip side correction rule Chip side • Current syntax not expressive enough to capture rules that compute a whole timeline from one of the values, particularly when formula may change between “generations”. • Currently-existing “external rules” could do this, but involve duplicated code that complicates maintenance, and is not clear enough to users. • Therefore, we wish to extend the syntax of the ASCII rules to take this case specifically into account, allowing for “timelines” and “generations” directly in the syntax itself. Chip area • Requirement that rule chain be a DAG could be loosened to permit rules that have their output as one of their inputs. • This would allow entering one value for chip side, for one year, and computing everything else, by executing the “chip side correction rule”. • Would not allow computing from “chip area” in current example.