Drip: A Schematic Drawing Interpreter

M A R C H 1 9 9 5 WRL Researh Report 95/1 Drip: A Shemati Drawing Interpreter Ramsey W. Haddad d i g i t a l Western Researh Laboratory 250 University Avenue Palo Alto, California 94301 USA

The Western Researh Laboratory (WRL) is a omputer systems researh group that was founded by Digital Equipment Corporation in 1982. Our fous is omputer siene researh relevant to the design and appliation of high performane sientifi omputers. We test our ideas by designing, building, and using real systems. The systems we build are researh prototypes; they are not intended to beome produts. There are two other researh laboratories loated in Palo Alto, the Network Systems Lab (NSL) and the Systems Researh Center (SRC). Another Digital researh group is loated in Cambridge, Massahusetts (CRL). Our researh is direted towards mainstream high-performane omputer systems. Our prototypes are intended to foreshadow the future omputing environments used by many Digital ustomers. The long-term goal of WRL is to aid and aelerate the development of high-performane uni- and multi-proessors. The researh projets within WRL will address various aspets of high-performane omputing. We believe that signifiant advanes in omputer systems do not ome from any single tehnologial advane. Tehnologies, both hardware and software, do not all advane at the same pae. System design is the art of omposing systems whih use eah level of tehnology in an appropriate balane. A major advane in overall system performane will require reexamination of all aspets of the system. We do work in the design, fabriation and pakaging of hardware; language proessing and saling issues in system software design; and the exploration of new appliations areas that are opening up with the advent of higher performane systems. Researhers at WRL ooperate losely and move freely among the various levels of system design. This allows us to explore a wide range of tradeoffs to meet system goals. We publish the results of our work in a variety of journals, onferenes, researh reports, and tehnial notes. This doument is a researh report. Researh reports are normally aounts of ompleted researh and may inlude material from earlier tehnial notes. We use tehnial notes for rapid distribution of tehnial material; usually this represents researh in progress. Researh reports and tehnial notes may be ordered from us. You may mail your order to: Tehnial Report Distribution DEC Western Researh Laboratory, WRL-2 250 University Avenue Palo Alto, California 94301 USA Reports and tehnial notes may also be ordered by eletroni mail. Use one of the following addresses: Digital E-net: Internet: JOVE::WRL-TECHREPORTS WRL-Tehreports@dewrl.pa.de.om UUCP: depa!wrl-tehreports To obtain more details on ordering by eletroni mail, send a message to one of these addresses with the word help in the Subjet line; you will reeive detailed instrutions. Reports and tehnial notes may also be aessed via the World Wide Web: http://www.researh.digital.om/wrl/home.html.

Ramsey W. Haddad Marh, 1995 Abstrat This paper presents a design apture system in whih shematis are translated into a proedural netlist speifiation language. The iruit designer draws shematis with a standard strutured graphis editor that knows nothing about netlists or shematis. The translator program analyzes the strutured graphis output file and translates it into a proedural netlist speifiation. d i g i t a l Western Researh Laboratory 250 University Avenue Palo Alto, California 94301 USA

ii

Table of Contents 1. Introdution 1 2. Basis 2 2.1. Simple Example 2 2.2. Strutured Graphis 3 3. Generating Proedures 4 3.1. Frames and Evaluation 4 3.2. 2D Ordering 5 4. Drawing Interpretation 7 4.1. Ions 8 5. Analysis of Non-Evaluation Objets 9 5.1. Binding Text to Objets 9 5.2. Wires 10 5.3. Wire Subsripting 11 6. Error Reporting 11 7. Experienes 12 Aknowledgements 12 Referenes 12 iii

iv

List of Figures Figure 1: Code Generated for "CELL: orn" 2 Figure 2: 2D ordering of objets 5 Figure 3: Inomparable Retangles 6 Figure 4: "onforming" ions 8 Figure 5: Sample "non-onforming" ions 9 Figure 6: Code Generated by "Ion" Region Proedure for Figure 4 9 Figure 7: Juntions and Connetors 10 Figure 8: Wire Subsripting 11 v

vi

1. Introdution In the history of design apture systems [5], many of them are limited to being either entirely text-based or entirely shemati-based. This is very limiting in that there is no single best hoie between these two methods. Typially, some portions of a design are best represented as text and others are best represented as shematis. For example, the low-level unique ells of a design rafted by iruit designers are usually best represented as a shemati. A quik test of this is to show a iruit designer the text-based equivalent design of suh a ell and ask what it does. Her first step will be to translate the design into a shemati - only then an she an easily determine the funtion. This suggests that the shemati was the orret representation in the first plae. On the other hand, ells suh as ontrol equations are more onise and easily modifiable in a textual representation. A good system must allow the designer to mix between text-based and shemati-based representations on a ell by ell basis. Another important aspet of many designs is the frequent need to reuse an already existing ell, but with a few small hanges. A poor CAD system would require the designer to opy an existing ell, rename it and modify it for the new use. When this happens often enough, the proess beomes tedious and updating modifiations beomes very diffiult. Thus, a good system must allow the designer to speify ells in a parameterized manner [7], so that the CAD system an generate many variations from one basi design. One the parameterization of ells is allowed, the question arises as to how powerful a desription language should be allowed to desribe the parameterization. Anything short of a full programming language is awkwardly restritive. One the parameterization has the power of a full programming language, the designer is not only designing a iruit, but is also writing a omputer program. Combining all these ideas results in a system similar to one developed at Xerox PARC [1, 2]. With their shemati editor, parameterized ells are designed using the full power of a programming language. One drawbak of suh a system, however, is that it involved a fairly tight oupling of the graphis editor to the design apture system and used a large number of expliit but non-visible bindings between text and objets that ould lead to frequently misleading shematis. In the layout generation system [8] developed for our miroproessor design projets [4], we modify this approah. A design is represented by a set of proedures. When ompiled and exeuted, they build an annotated hierarhial netlist as internal data strutures. To augment this text-based approah, designers an use shematis as a graphial proedure language. The designer reates these shematis with a standard strutured graphis editor. The drawing translator drip analyzes the shematis reated with the graphis editor to generate the equivalent textual desription. This approah is similar to that taken by WireC [6] and its predeessor, WireLisp [3, 10]. Drip has a more general evaluation mehanism than WireC, and uses a very different understanding of order of evaluation for objets, inluding an intuitive 2D ordering. This enables us to, for example, allow multiple proedure definitions in one shemati file and to separate the loations of the delaration of an ion and the definition of the proedure orresponding to that ion. 1

The mehanis and design issues surrounding the drawing translator are the fous of this paper. We will mention aspets of the overall layout generation system that drip is a part of only as neessary; another paper [8] desribes this overall system more ompletely. 2. Basis 2.1. Simple Example 1 Cell* orn (int n, Power *p) { 2 har key[500]; // the ell ahe key 3 sprintf(key,"orn_%s_%s",tostring(n),tostring(p)); 4 CACHECELL; 5 LOCAL(GenW0, bit()); 6 INPUT(i, L1(n)); 7 INPUT(Gnd, signal); 8 INPUT(Vee1, signal); 9 INPUT(Vs, signal); 10 INPUT(Vr1, signal); 11 OUTPUT(o, L1()); 12 LOCAL(, L2()); 13 { 14 for (int k=0; k<n; k++) 15 {instane = ell->addinstane(npn(p)); 16 instane->setbinding("b",i(k),"",gnd,"e",);} 17 } 18 {instane = ell->addinstane(res(p)); 19 instane->setbinding("r0",gnd,"r1",genw0);} 20 {instane = ell->addinstane(ls(p)); 21 instane->setbinding("a",genw0,"b",o);} 22 {instane = ell->addinstane(isr(p)); 23 instane->setbinding("in",);} 24 {instane = ell->addinstane(npn(p)); 25 instane->setbinding("b",vr1,"",genw0,"e",);} 26 SetLayoutKey(ell,"Leaf"); 27 ENDCELL Inputs: L1(n) i; Internals: L2() ; Publis: signal Gnd,Vee1,Vs,Vr1; :for (int k=0; k<n; k++) Gnd i[k] b Npn (p) e Layout:"Leaf" Gnd r0 (p) Res r1 (p) a LS in ISr(p) Outputs: L1() o; Vr1 (p) Npn b o CELL: orn(int n, Power *p) b e Figure 1: Code Generated for "CELL: orn" Figure 1 shows a sample shemati and the ode generated when drip analyzes it. The resulting proedure orn generates and returns the netlist for an n-way OR gate. Most of the wires are delared in the shemati and hene also in the generated C++ proedure. The ode that is generated from the delarations of "Inputs" (line 6), "Publis" (lines 7-10), "Outputs" (line 11), and "Internals" (line 12) is easily identifiable. One wire, onneting the bottom of the resistor to the npn transistor, is drawn but not delared in the shemati. Hene, drip assigns it a generated name and delares the wire (line 5). For eah of the 5 ions in the shemati drip generates a all to the appropriate netlist generation proedure for that subell (lines 15, 18, 20, 22 and 24). It passes the parameter "p" to these subell generators. drip generates ode to bind the external wires of the sub-ells to the appropriate wires in the urrent ell (lines 16, 19, 21, 23 and 25). But a number of issues raised in this simple example are not so lear: How does drip deide in what order to generate the different piees of ode? How does drip know what proedures to all to generate sub-ells? How does drip know whih wires to bind to whih terminals? What tradeoffs are made in answering these questions? There are a number of philosophies that guided the design of the drawing interpreter. 2

The graphi editors should not have to know any of the semantis of the drawing translator or the underlying language. The drawings should have no "hidden information": a human should be able to understand the drawing ompletely by looking at a paper opy. The drawing translator should be robust. That is, it should be fairly insensitive to minor hanges to the drawing; two drawings that look the same to the naked eye should not have different interpretations. The drawing translator should be able to translate drawings from a number of graphis editors. The drawing translator should be strit: if some graphial situation is ambiguous, forbid it. This helps ensure the readability of the final graphi language. The drawing translator should behave in aord with people s intuition and expetations. We only break these guidelines when useability or strong traditions demand. 2.2. Strutured Graphis One goal is for the shemati translator drip to be as independent of the drawing program as possible. As a first step, drip is an entirely separate program from our drawing program -- the generi idraw variant of Unidraw [9]. The only way that the two programs an ommuniate is through files. The shemati translator reads the output files of the drawing program, muh as a ompiler reads files written by a text editor. To fore independene, another goal is that the shemati translator be easily retargetable to other drawing programs. Drip ensures this by parsing all input files into an intermediate representation and performing all other operations on this intermediate representation. This representation is a strutured graphis world with a very small set of primitive objets (lines, irles, retangles, and text) and the ability to group primitives together into a single objet. All other graphi primitives that may be present in the input file are regarded as ornamental and are filtered out in the proess of translating into the intermediate representation. Any graphis editor whose output an be easily parsed into this representation an be used for shemati generation. This simple strutured graphis world prevents any strong oupling between the editor and the translator. It also removes a lot of hidden hints that a translator might otherwise be able to utilize. The only hidden hint is the grouping of objets. Hene, grouping is limited to a very narrow funtion, delimiting ions, whih is disussed in Setion 4.1. That the translator has to start with so little information helps to ensure that the resulting graphial language is visually intuitive. 3

3. Generating Proedures From the outset, we must aept that the goal is to generate omputer proedures. It is not the purpose of the shemati system to fool the designer into thinking that she is not really writing a C++ proedure. Rather, the visual layout assists the designer in effiiently speifying the proedure orretly. Also, the shemati provides a single representation of the design, so that all later modifiations only need to be made in one plae. But, ultimately, what is speified must be a omplete and orret proedure. The role of the drawing translator is to provide a shemati world that allows the designer to be onise and yet preise, and to allow easily understood graphial drawings that an be fairly dense. These goals drive the overall arhiteture of the translation proess. 3.1. Frames and Evaluation The first onept that must be understood is that of a frame. Every retangle that is not grouped within an ion is alled a frame. Frames partition the page into different regions. Eah region is allowed to have its own region interpretation proedure. One reason for reating different regions with frames is preisely that the designer wants different regions to have different interpretation proedures. A seond use of frames is to group the objets of a region together into a single programming language "statement". A third use of frames is to ontrol the order of interpretation of objets. Frames partition the page into a hierarhial tree based on inlusion. To ensure this, there is a simple rule: given a frame and any other objet, the sides of the frame may not interset the sides of the bounding box of the objet. With this rule, the answer as to whether or not an objet is inside a given frame is always well-defined. For eah objet, drip an easily determine the minimal frame in whih it lies, and build a tree of objets with that frame as its parent. At the topmost level of the tree, is a root frame whih enloses the entire page. Some objets in a frame are text strings of the form "keyword: ontents". These text strings perform two different roles depending on the keyword. If the keyword is the name of a region interpretation proedure (e.g. "ell"), then the text string is simultaneously delaring the region proedure to be used for evaluating the ontents of its minimally enlosing frame, and the text string is passing arguments to that region proedure. There are two domain-independent region proedures: The "omment" proedure is the simplest. Everything inside the frame is treated as a omment; there is no C++ output generated. Its ontents are not evaluated. The "sub" proedure is the default for the root frame. Its purpose is to ensure that we properly iterate through and evaluate all its hildren, whih may only be text proedures and sub-frames. They are evaluated in the 2D order desribed in Setion 3.2. If, on the other hand, the keyword is the name of a text interpretation proedure (e.g. "Inputs", "Layout"), then the "ontents" are being passed to the speified text proedure for translation into generated ode. There are three domain independent text proedures. The text proedure "ode" passes its "ontents" straight through to the final C++ program. As a short-ut, text beginning with a olon is equivalent to text beginning with a "ode" keyword. 4

The text proedure "inlude" takes a omma separated list of file names. These shemati files are read and translated into C++ ode in order by drip. For 2D ordering purposes (see Setion 3.2), the ode is generated as if the shemati files fit in a frame at the same position and size as the text string that ontains the "inlude" keyword. The text proedure "omm" generates C++ omments that ontain its text arguments. Text proedures, ions, and sub-frames are diretly evaluated and generate ode. These are alled evaluation objets. All other objets in a frame are analyzed only in order to attah parameters and properties on the evaluation objets before their evaluation. 3.2. 2D Ordering Sine our graphial representation is really a poorly disguised C++ program, the order in whih we generate lines of the program is very important. This setion how we order all the objets within a frame for evaluation. In standard programming languages, the program itself is usually speified as ASCII text. Sine these text files are one-dimensional, the order of evaluation is easy: from the beginning to the end of the file. In a graphial language, the user has more degrees of freedom in plaing the language onstruts. Thus it is less obvious in what order to evaluate the onstruts. The first temptation is to sort by the upper-left orners of the bounding boxes of the objets, using the Y-oordinate as the most signifiant key and the X-oordinate as the least signifiant key. This is not entirely satisfatory. It is not as robust as we would like. Nor does it always order objets in the order we d like. R1 R2 R6 R5 R3 R4 R7 R8 R9 R10 R11 R12 R13 R14 Figure 2: 2D ordering of objets We needed to ome up with a better 2D ordering. Our resulting ordering system is easy to explain, robust and losely follows our intuitive reading order. This ordering works very well 5

for non-overlapping retangles. When sorting evaluation objets, we use the bounding boxes of the graphial element. An example showing the ordering we use is shown in Figure 2. At the ore of this ordering are these three rules: Case 1 When two retangles an be be separated by a vertial line and their projetions onto that line interset, we order them left to right. Example: in Figure 2, R1 preedes R5. Case 2 When two retangles an be be separated by a horizontal line and their projetions onto that line interset, we order them top to bottom. Example: in Figure 2, R8 preedes R12. Case 3 When one retangle is ompletely above and to the left of the other retangle, we order them left to right (or top to bottom, sine that is equivalent). Example: in Figure 2, R4 preedes R13. But, what about R2 vs R3? These are onsidered inomparable and so we leave them unordered for now. The final ordering is found by the following proedure: repeat until done: if only one retangle has no retangles that preede it then shedule that retangle else of all the retangles that have no retangles that preede them, shedule the one that has the highest upper-left orner Figure 3: Inomparable Retangles If we are in the else lause, then the retangles that have no retangles that preede them must be strethed out diagonally as shown in Figure 3. In this ase, the algorithm piks the uppermost one - whih is the same as the rightmost one. We an see why we didn t add a fourth ordering rule to deide on the inomparable retangles by looking arefully at Figure 2. Assume that we had said Case 4 When one retangle is ompletely above and to the right of the other retangle, we order them from top to bottom. Example: in Figure 2, R2 preedes R3. 6

Looking at Figure 2, the rules would now say that retangle R6 before retangle R4 - yielding a irular order given the previous rules. Or, similarly, assume we had instead hosen the rule Case 4 When one retangle is ompletely above and to the right of the other retangle, we order them from left to right. Example: in Figure 2, R3 preedes R6. Looking at Figure 2, the rules would now say that retangle R11 before retangle R4 - yielding a irular order given the previous rules. So we annot add a fourth rule to give us a total ordering without leading to a irular ordering. 4. Drawing Interpretation There is nothing in this evaluation proedure that is speifi to the appliation of shemati apture. It an be used as the basis for graphial programming environments in a number of areas. It is the details of the region and text proedures that define the domain. With a different set of region and text proedures, this graphial programming environment ould be retargeted for other uses. Sine this paper is mainly onerned with the domain of shemati apture, we now examine some of our domain-speifi interpretation proedures. Some interpretation proedures work on a string of text of the form "key: text", as mnetions previously. Here, the key defines how the text is to interpreted for ode generation. The domainspeifi text proedures "inputs", "outputs", "publis", "internals" are all used to delare the wires of a ell. The proedures "layout" and "model" generate ode to annotate the netlist for later CAD system funtions; "layout" speifies what method should be used to generate layout of a ell, and "model" speifies how a ell should be modeled by the simulator. These funtions were used frequently enough to warrant a text proedure, rather than foring the designer to write out the C++ equivalents. The more interesting interpretation proedures work on the ontents of regions. We settled on a simple olletion of region proedures: "basi", "blok", "ell", "plain", and "ion". We have mentioned that region proedures an be expliitly delared. When there is no label with a speifi delaration, a frame s region proedure is inherited from that of its parent frame. The "basi" proedure does our basi shemati evaluation with no extras. It first analyzes all non-evaluation objets in the region: wires, onnetors, wire labels, ion parameters. It binds wire names to wires and proedure arguments to ions. It propagates wire names along omplex wires and attahes them to ion onnetors. Any unlabeled hildren frames inherit a "blok" label. Finally, all hildren that are evaluation objets are evaluated in the 2D order desribed in Setion 3.2. The "blok" proedure is just like the "basi" proedure, exept that the ode it generates is turned into a single C++ "statement" by enlosing it all with {}. The "ell" proedure is used at the top level of a netlist generation proedure definition. It first auses the generation of a C++ proedure preamble, then it behaves like the "basi" proedure, and finally it generates a proedure postamble. 7

The "plain" proedure is just like the "ell" proedure, exept that it auses a less speialized proedure preamble and postamble to be generated. The "ion" proedures generates a C++ forward delaration for a the netlist generation proedure whih is produed by a "ell" proedure. 4.1. Ions An ion is a grouping of objets whih defines the interfae to a ell in the netlist. Ions are used in two irumstanes. In "ell" regions, an ion represents an instane of a subell, bound to wires in the urrent ell at its onnetors. In "ion" regions, the idential graphial objet generates a delaration for the netlist proedure defined by a "ell". Following the program analogy, "ion" regions are often olleted in a drawing whih is the graphial equivalent of a C++ ".h" file, defining the proedural interfaes to a olletion of ell generators. A well-formed ion should onsist of n irles, n+1 piees of text, and any number of other non-irle, non-text objets. The irles are ions onnetors, to whih wires an be attahed. Eah onnetor must be labeled by the name of an external wire of the ell represented by the ion. The text binding proedure desribed in Setion 5.1 will be used to bind n of the text objets to the n irles. The remaining unbound text is taken to be the name of the ion. Some onforming ions are shown in Figure 4. sslave i o o_ ICON:sSlave() i so Reg si ICON:Reg(int size=1,har* tl="yd") Figure 4: "onforming" ions o s d12l3 d ICON:d12L3() Unaltered, this sheme imposes some limitations on ions that many users find unaeptable. There are some triks to get around them that don t onform to our guiding philosophies: Some ommon ions are well known, as are the meaning of their onnetors, e.g. the npn transistors in Figure 5. Requiring a name would ause lutter that is annoying to many designers. The solution in this ase is to set the olor of the text to "white", thus making it invisible. Unless the ion is very standard, this pratie is strongly disouraged. Sometimes we need irles that are not onnetors in our ion, e.g. the ISr in Figure 5. These irles must not be bound to text. In this ase, the extra irles should be hidden within a sub-group of the ion s group. The ion interpreter and text binder do not searh within subgroups of the ion. Sometimes we need text that is not a onnetor or ion label in our ion, e.g. the "+" and "-" in the VSr in Figure 5. Just as with irles, these are hidden from the interpreter in sub-groups of the ion s group. By the time that the "basi" region proedure attempts to evaluate an ion, drip will already have bound wirenames to the wires in the region and propagated them all the way to the ion onnetors, as desribed in Setion 5. So for eah ion onnetor, we know the name in the 8

bnpn e Npn ICON: Npn b e in ISr ICON: ISr vp VSr + - vm ICON: VSr Figure 5: Sample "non-onforming" ions urrent ell of the wire that is attahed to it. From the text binding of the ion ontents, we know the name of the wire that the onnetor represents in the ell generated by the proedure that the ion invokes. Finally, sine we bind these two wires by name, we an generate the ode shown in Figure 1, lines 16, 19, 21, 23 and 25. Note that the ode generated by a single ion is always enlosed with {} and is thus a single C++ statement. 1 Cell* sslave (); 2 Cell* Reg (int size=1,har* tl="yd"); 3 Cell* d12l3 (); Figure 6: Code Generated by "Ion" Region Proedure for Figure 4 In Figures 4 and 5 we see the use of the "ion" region proedure. This region proedure has two tasks. First, it generates a forward referene to the orresponding netlist generation proedure. The ode emitted is a delaration of the proedure with its arguments, inluding any default arguments. This ode will typially appear in a ".h" file. The ode generated by this region proedure for Figure 4 is shown in Figure 6. Seond, The "ion" frame proedure analyzes any ions ontained in it to make sure that they are well-formed and that the name of the ion is the same as the netlist proedure that is named in the "Ion:" delaration. If the designer wants to opy and paste an ion for use in the urrent design, an "ion" frame proedure that has already suessfully passed through drip is a very safe plae from whih to opy the ion. 5. Analysis of Non-Evaluation Objets During the exeution of the "basi" region proedure, the first task is to analyze the nonevaluation objets. These are: lines, whih represent wires; irles, whih represent wire onnetors; and text whih is not of the "keyword: ontents" form. The role of a partiular text objet is easily determined from its syntax. Text enlosed in parenthesis represents an argument to be passed to an ion. Text beginning with a "." or a "[" is used for wire subsripting, whih will be disussed in Setion 5.3. Text that is a normal identifier, or a normal identifier with subsripting, is a wire name. 5.1. Binding Text to Objets The main work in analyzing non-evaluation objets is determining to what objets the nonevaluation text should be attahed. Binding text to objets is neessary for several different tasks. For the analysis phase of "basi" we need to be able to bind labels to wires and bind arguments to ions. For ion analysis we need to bind labels to ion onnetors. Given three different uses, we hoose to use the same algorithm for all three. This makes it easier for the designer to understand the translator behavior. 9

We do not allow the drawings to have hidden information, so drip must base its binding deisions only on the positions of the text in relation to the other objets. The algorithm is straightforward. The binding subroutine will be given a olletion of text and a olletion of relevant objets to bind the text to. For eah piee of text it finds the losest relevant objet. If no other text has the same losest objet, then the objet and the text are bound. When multiple piees of text have the same losest objet, this is usually reported as an error. (We allow one exeption: in the ase of a wire that has the idential label repeated multiple times, we don t flag an error.) The distane from text to an objet is omputed as follows: replae the text with the line that results from underlining the text and replae the objet with a retangular bounding box, then find the manhattan distane from the line to the box. One drawbak of suh a simple method is that it doesn t bind text to seond losest objets in ases that are intuitive to humans. More ompliated algorithms were experimented with. They led to suffiient unpreditability at the user level, that they aused more harm than good. The great advantage of our method is that a user looking at the printed opy an easily understand exatly what text is bound to what objet. 5.2. Wires Inputs: L2(2) l; L1() a,b,d; a b Npn e l[0] b Npn Layout: "Leaf" e Publis: signal Gnd,Vee1,Vs,Vr1,Vr2; omment: T and L juntions Wires that meet at T and L juntions are onneted together. Vr1 Npn b e b b Npn Vr1 Npn e l[1] b Npn e b e Gnd d b Npn e Vr2 b Npn in ISr r0 Res r1 e Outputs: L1() o; a EF Vr1 Npn b e Gnd ell: smux2() b o ell: fragment() omment: onnetors irpipe rdkill rapipe alukill ammwpipe memwbkill Connetors an also be used outside of ions. Wires that have + juntions are not onsidered onneted. With a onnetor at the + juntion, the wires are onsidered onneted. si daess odelaymem si so aml memk ral aluk irl rdk rrs rrs rrsi rrsi rrt rrt rrti rrti Bypass rrw rrw rrwi rrwi byps rasrselw wei wei bypt ratarselw we we wlk wlk si mwl wbk aml memk ral aluk irl rdk so so Figure 7: Juntions and Connetors When binding labels to wires, the binding algorithm attahes eah label to a single line or irle. However, the translator needs to understand that the label applies to the entire ondution path. A ondution path onsist of many lines and irles that are onneted together. The rules we use for onnetivity analysis are straightforward (see Figure 7). 1. Two wires that meet at a T-juntion or an L-juntion are onneted at that juntion. 2. Two wires that meet at a "+"-juntion are not-onneted. 3. If a wire intersets a irular onnetor, they are onneted. 4. Transitivity: if A is onneted to B and B is onneted to C, A is onneted to C. 10

5.3. Wire Subsripting omment: subwires This ell shows how wires an be broken down into subwires. zz[a,b] means the b bits of the wire zz that start with bit a. Inputs: bits(5) s; signal inv; Publis: signal Gnd,Vee1,Vs,Vr1,Vr2; Internals: bits(4) xx, yy; bits(2) zz; bits(5) out, out_; Outputs: bits(32) sa; s inv sa out deomp inv out_ out out_ [0,2] [0,2] [2,2] [2,2] s_ dl24 s d s_ dl24 s d xx yy zz bshls d0 d1 sel d2 sa Model: "bshde" [4] [4] b b a a Fuse Fuse [0] [1] ell: bshde Figure 8: Wire Subsripting In our CAD system, a wire may be an array or ompliated struture of sub-wires. In a shemati we may want to tear a wire into sub-wires. An example is shown in Figure 8. Now we will have a set of onneted lines, some of whih represent a olletion of nets, some of whih represent a subset of them. Whih line represents what nets? For a onneted set of ondutors that use subsripting, some basi rules must hold: The ondutors must form a tree. There may be exatly one non-subsript label on any of the ondutors. Eah ondutor is allowed at most one label, whether it is a subsript label or a non-subsript label. Given these rules, we an hoose the non-subsript labeled ondutor as the root of the tree. The label on any ondutor is the onatenation of all the labels along the path from the root of the tree to the ondutor, inlusive. This algorithm is intuitive, robust and works for multiple levels of subsripting. 6. Error Reporting The main objetion that designers have after the above system is explained to them, is that the deoupling of editor and interpreter makes it harder to deal with shemati errors found by the interpreter. Sine our deoupling is in part modeled on the separation of text editor and ompiler that programmers are very used to, we similarly mimi the error reporting mehanisms of emas. When programming with emas, the ompiler reports errors in suh a format that the programmer an use emas to single-step through the lines in the ode that have errors. Similarly, whenever drip enounters an error, it writes an entry into an error file. This entry ontains an error message, a soure shemati file name, and desriptions of polygons with whih to highlight the error region of the shemati. 11

Sine out editor did not have the ability to handle error files, we had to ustomize it. We added ommands to load an error file, and single step through the errors. The editor pulls up the shemati with the error, overlays the highlighting polygons, and pops up a window with the error message. The designer an fix the error and then step to the next one. 7. Experienes This system was suessfully used at our laboratory for a period of four years, enompassing two miroproessor projets, BIPS0 [4] and BIPS1. Eah design used over one hundred shematially speified netlist generation proedures. Another bonus effet of the separation between the shematis and the generated C++ ode that is provided by the interpreter was that the frequent hanges to the CAD system libraries and their interfaes usually only required modifiations to drip s interpretation proedures, rather than to every shemati. Aknowledgements drip desended from moog. moog was a drawing interpreter written by Mike Nielsen and Jeremy Dion for use with the artemis graphis editor. Under the guidane of Jeremy Dion, Kamal Chaudhary wrote a preliminary drawing interpreter moo, that would be more graphis editor independent. Ramsey Haddad extended moo. Ramsey Haddad and Louis Monier rewrote it, reating drip. drip was further improved by inorporating ideas from a number of users: Mary Jo Doherty, Alan Eustae, Norm Jouppi, Jim Keller, Suresh Menon, Silvio Turrini. Jeremy Dion and Louis Monier made numerous helpful suggestions on the paper. Referenes [1] R. Barth, B. Serlet, P. Sindhu. Parameterized Shematis. In 25th Design Automation Conferene, pages 243-249. Sydney, June, 1988. [2] R. Barth, L. Monier, B. Serlet. Pathwork: Layout From Shemati Annotations. In 25th Design Automation Conferene, pages 250-255. Sydney, June, 1988. [3] C. Ebeling, Z. Wu. WireLisp: Combining Graphis and Proedures in a Ciruit Speifiation Language. In Proeedings of the ICCAD, pages 322-325. IEEE, 1989. [4] N.P. Jouppi, P. Boyle, J. Dion, M.J. Doherty, A. Eustae, R.W. Haddad, R. Mayo, S. Menon, L.M. Monier, D. Stark, S. Turrini, J.L. Yang, W.R. Hamburgen, J.S. Fith, R. Kao. A 300-MHz 115-W 32-b Bipolar ECL Miroproessor. IEEE Journal of Solid-State Ciruits 28(11), November, 1993. [5] R. Mayo. Moha hip: A system for the graphial design of VLSI module generators. In Proeedings of the ICCAD, pages 74-77. IEEE, 1986. [6] L. MMurhie, C. Ebeling. WireC Tutorial and Referene Manual. Tehnial Report 94-09-09, University of Washington, Department of Computer Siene and Engineering, September, 1994. [7] L. Monier. Layout Generation Through Parameterized Shematis. In 7th Australian Miroeletronis Conferene, pages 157-164. Sydney, May, 1988. [8] L. Monier, J. Dion. Reursive Layout Generation. WRL Researh Report (95/2), 1995. 12

[9] J. Vlissides, M. Linton. Unidraw: A Framework for Building Domain-Speifi Graphial Editors. ACM Transations on Information Systems 8(3):237--268, July, 1990. [10] Z. Wu, C. Ebeling. Drawing Wirelisp. Tehnial Report 89-12-03, University of Washington, Department of Computer Siene and Engineering, Deember, 1989. 13

14

WRL Researh Reports Titan System Manual. The USENET Cookbook: an Experiment in Mihael J. K. Nielsen. Eletroni Publiation. WRL Researh Report 86/1, September 1986. Brian K. Reid. WRL Researh Report 87/7, Deember 1987. Global Register Alloation at Link Time. David W. Wall. MultiTitan: Four Arhiteture Papers. WRL Researh Report 86/3, Otober 1986. Norman P. Jouppi, Jeremy Dion, David Boggs, Mihael J. K. Nielsen. Optimal Finned Heat Sinks. WRL Researh Report 87/8, April 1988. William R. Hamburgen. WRL Researh Report 86/4, Otober 1986. Fast Printed Ciruit Board Routing. Jeremy Dion. The Mahler Experiene: Using an Intermediate WRL Researh Report 88/1, Marh 1988. Language as the Mahine Desription. David W. Wall and Mihael L. Powell. Compating Garbage Colletion with Ambiguous WRL Researh Report 87/1, August 1987. Roots. Joel F. Bartlett. The Paket Filter: An Effiient Mehanism for WRL Researh Report 88/2, February 1988. User-level Network Code. Jeffrey C. Mogul, Rihard F. Rashid, Mihael The Experimental Literature of The Internet: An J. Aetta. Annotated Bibliography. WRL Researh Report 87/2, November 1987. Jeffrey C. Mogul. WRL Researh Report 88/3, August 1988. Fragmentation Considered Harmful. Christopher A. Kent, Jeffrey C. Mogul. Measured Capaity of an Ethernet: Myths and WRL Researh Report 87/3, Deember 1987. Reality. David R. Boggs, Jeffrey C. Mogul, Christopher Cahe Coherene in Distributed Systems. A. Kent. Christopher A. Kent. WRL Researh Report 88/4, September 1988. WRL Researh Report 87/4, Deember 1987. Visa Protools for Controlling Inter-Organizational Register Windows vs. Register Alloation. Datagram Flow: Extended Desription. David W. Wall. Deborah Estrin, Jeffrey C. Mogul, Gene Tsudik, WRL Researh Report 87/5, Deember 1987. Kamaljit Anand. WRL Researh Report 88/5, Deember 1988. Editing Graphial Objets Using Proedural Representations. SCHEME->C A Portable Sheme-to-C Compiler. Paul J. Asente. Joel F. Bartlett. WRL Researh Report 87/6, November 1987. WRL Researh Report 89/1, January 1989. 15

Optimal Group Distribution in Carry-Skip Ad- The Distribution of Instrution-Level and Mahine ders. Parallelism and Its Effet on Performane. Silvio Turrini. Norman P. Jouppi. WRL Researh Report 89/2, February 1989. WRL Researh Report 89/13, July 1989. Preise Roboti Paste Dot Dispensing. Long Address Traes from RISC Mahines: William R. Hamburgen. Generation and Analysis. WRL Researh Report 89/3, February 1989. Anita Borg, R.E.Kessler, Georgia Lazana, and David W. Wall. Simple and Flexible Datagram Aess Controls for WRL Researh Report 89/14, September 1989. Unix-based Gateways. Jeffrey C. Mogul. Link-Time Code Modifiation. WRL Researh Report 89/4, Marh 1989. David W. Wall. WRL Researh Report 89/17, September 1989. Spritely NFS: Implementation and Performane of Cahe-Consisteny Protools. Noise Issues in the ECL Ciruit Family. V. Srinivasan and Jeffrey C. Mogul. Jeffrey Y.F. Tang and J. Leon Yang. WRL Researh Report 89/5, May 1989. WRL Researh Report 90/1, January 1990. Available Instrution-Level Parallelism for Super- Effiient Generation of Test Patterns Using salar and Superpipelined Mahines. Boolean Satisfiablilty. Norman P. Jouppi and David W. Wall. Tray Larrabee. WRL Researh Report 89/7, July 1989. WRL Researh Report 90/2, February 1990. A Unified Vetor/Salar Floating-Point Arhite- Two Papers on Test Pattern Generation. ture. Tray Larrabee. Norman P. Jouppi, Jonathan Bertoni, and David WRL Researh Report 90/3, Marh 1990. W. Wall. WRL Researh Report 89/8, July 1989. Virtual Memory vs. The File System. Mihael N. Nelson. Arhitetural and Organizational Tradeoffs in the WRL Researh Report 90/4, Marh 1990. Design of the MultiTitan CPU. Norman P. Jouppi. Effiient Use of Workstations for Passive Monitor- WRL Researh Report 89/9, July 1989. ing of Loal Area Networks. Jeffrey C. Mogul. Integration and Pakaging Plateaus of Proessor WRL Researh Report 90/5, July 1990. Performane. Norman P. Jouppi. A One-Dimensional Thermal Model for the VAX WRL Researh Report 89/10, July 1989. 9000 Multi Chip Units. John S. Fith. A 20-MIPS Sustained 32-bit CMOS Miroproes- WRL Researh Report 90/6, July 1990. sor with High Ratio of Sustained to Peak Performane. 1990 DECWRL/Livermore Magi Release. Norman P. Jouppi and Jeffrey Y. F. Tang. Robert N. Mayo, Mihael H. Arnold, Walter S. Sott, WRL Researh Report 89/11, July 1989. Don Stark, Gordon T. Hamahi. WRL Researh Report 90/7, September 1990. 16

Pool Boiling Enhanement Tehniques for Water at Interleaved Fin Thermal Connetors for Multihip Low Pressure. Modules. Wade R. MGillis, John S. Fith, William William R. Hamburgen. R. Hamburgen, Van P. Carey. WRL Researh Report 91/9, August 1991. WRL Researh Report 90/9, Deember 1990. Experiene with a Software-defined Mahine Ar- Writing Fast X Servers for Dumb Color Frame Buf- hiteture. fers. David W. Wall. Joel MCormak. WRL Researh Report 91/10, August 1991. WRL Researh Report 91/1, February 1991. Network Loality at the Sale of Proesses. A Simulation Based Study of TLB Performane. Jeffrey C. Mogul. J. Bradley Chen, Anita Borg, Norman P. Jouppi. WRL Researh Report 91/11, November 1991. WRL Researh Report 91/2, November 1991. Cahe Write Poliies and Performane. Analysis of Power Supply Networks in VLSI Cir- Norman P. Jouppi. uits. WRL Researh Report 91/12, Deember 1991. Don Stark. WRL Researh Report 91/3, April 1991. Pakaging a 150 W Bipolar ECL Miroproessor. William R. Hamburgen, John S. Fith. TurboChannel T1 Adapter. WRL Researh Report 92/1, Marh 1992. David Boggs. WRL Researh Report 91/4, April 1991. Observing TCP Dynamis in Real Networks. Jeffrey C. Mogul. Proedure Merging with Instrution Cahes. WRL Researh Report 92/2, April 1992. Sott MFarling. WRL Researh Report 91/5, Marh 1991. Systems for Late Code Modifiation. David W. Wall. Don t Fidget with Widgets, Draw!. WRL Researh Report 92/3, May 1992. Joel Bartlett. WRL Researh Report 91/6, May 1991. Pieewise Linear Models for Swith-Level Simulation. Pool Boiling on Small Heat Dissipating Elements in Russell Kao. Water at Subatmospheri Pressure. WRL Researh Report 92/5, September 1992. Wade R. MGillis, John S. Fith, William R. Hamburgen, Van P. Carey. A Pratial System for Intermodule Code Optimiza- WRL Researh Report 91/7, June 1991. tion at Link-Time. Amitabh Srivastava and David W. Wall. Inremental, Generational Mostly-Copying Gar- WRL Researh Report 92/6, Deember 1992. bage Colletion in Unooperative Environments. A Smart Frame Buffer. G. May Yip. Joel MCormak & Bob MNamara. WRL Researh Report 91/8, June 1991. WRL Researh Report 93/1, January 1993. Reovery in Spritely NFS. Jeffrey C. Mogul. WRL Researh Report 93/2, June 1993. 17

Tradeoffs in Two-Level On-Chip Cahing. Complexity/Performane Tradeoffs with Non- Norman P. Jouppi & Steven J.E. Wilton. Bloking Loads. WRL Researh Report 93/3, Otober 1993. Keith I. Farkas, Norman P. Jouppi. WRL Researh Report 94/3, Marh 1994. Unreahable Proedures in Objet-oriented Programing. A Better Update Poliy. Amitabh Srivastava. Jeffrey C. Mogul. WRL Researh Report 93/4, August 1993. WRL Researh Report 94/4, April 1994. An Enhaned Aess and Cyle Time Model for Boolean Mathing for Full-Custom ECL Gates. On-Chip Cahes. Robert N. Mayo, Herve Touati. Steven J.E. Wilton and Norman P. Jouppi. WRL Researh Report 94/5, April 1994. WRL Researh Report 93/5, July 1994. Software Methods for System Address Traing: Limits of Instrution-Level Parallelism. Implementation and Validation. David W. Wall. J. Bradley Chen, David W. Wall, and Anita Borg. WRL Researh Report 93/6, November 1993. WRL Researh Report 94/6, September 1994. Fluoroelastomer Pressure Pad Design for Performane Impliations of Multiple Pointer Miroeletroni Appliations. Sizes. Alberto Makino, William R. Hamburgen, John Jeffrey C. Mogul, Joel F. Bartlett, Robert N. Mayo, S. Fith. and Amitabh Srivastava. WRL Researh Report 93/7, November 1993. WRL Researh Report 94/7, Deember 1994. A 300MHz 115W 32b Bipolar ECL Miroproes- How Useful Are Non-bloking Loads, Stream Bufsor. fers, and Speulative Exeution in Multiple Issue Norman P. Jouppi, Patrik Boyle, Jeremy Dion, Mary Proessors?. Jo Doherty, Alan Eustae, Ramsey Haddad, Keith I. Farkas, Norman P. Jouppi, and Paul Chow. Robert Mayo, Suresh Menon, Louis Monier, Don WRL Researh Report 94/8, Deember 1994. Stark, Silvio Turrini, Leon Yang, John Fith, William Hamburgen, Russell Kao, and Rihard Swan. Reursive Layout Generation. WRL Researh Report 93/8, Deember 1993. Louis M. Monier, Jeremy Dion. WRL Researh Report 95/2, Marh 1995. Link-Time Optimization of Address Calulation on a 64-bit Arhiteture. Contour: A Tile-based Gridless Router. Amitabh Srivastava, David W. Wall. Jeremy Dion, Louis M. Monier. WRL Researh Report 94/1, February 1994. WRL Researh Report 95/3, Marh 1995. ATOM: A System for Building Customized Program Analysis Tools. Amitabh Srivastava, Alan Eustae. WRL Researh Report 94/2, Marh 1994. The Case for Persistent-Connetion HTTP. Jeffrey C. Mogul. WRL Researh Report 95/4, May 1995. Network Behavior of a Busy Web Server and its Clients. Jeffrey C. Mogul. WRL Researh Report 95/5, June 1995. 18

WRL Tehnial Notes TCP/IP PrintServer: Print Server Protool. Boiling Binary Mixtures at Subatmospheri Pres- Brian K. Reid and Christopher A. Kent. sures WRL Tehnial Note TN-4, September 1988. Wade R. MGillis, John S. Fith, William R. Hamburgen, Van P. Carey. TCP/IP PrintServer: Server Arhiteture and Im- WRL Tehnial Note TN-23, January 1992. plementation. Christopher A. Kent. A Comparison of Aousti and Infrared Inspetion WRL Tehnial Note TN-7, November 1988. Tehniques for Die Attah John S. Fith. Smart Code, Stupid Memory: A Fast X Server for a WRL Tehnial Note TN-24, January 1992. Dumb Color Frame Buffer. Joel MCormak. TurboChannel Versate Adapter WRL Tehnial Note TN-9, September 1989. David Boggs. WRL Tehnial Note TN-26, January 1992. Why Aren t Operating Systems Getting Faster As Fast As Hardware? A Reovery Protool For Spritely NFS John Ousterhout. Jeffrey C. Mogul. WRL Tehnial Note TN-11, Otober 1989. WRL Tehnial Note TN-27, April 1992. Mostly-Copying Garbage Colletion Piks Up Eletrial Evaluation Of The BIPS-0 Pakage Generations and C++. Patrik D. Boyle. Joel F. Bartlett. WRL Tehnial Note TN-29, July 1992. WRL Tehnial Note TN-12, Otober 1989. Transparent Controls for Interative Graphis The Effet of Context Swithes on Cahe Perfor- Joel F. Bartlett. mane. WRL Tehnial Note TN-30, July 1992. Jeffrey C. Mogul and Anita Borg. WRL Tehnial Note TN-16, Deember 1990. Design Tools for BIPS-0 Jeremy Dion & Louis Monier. MTOOL: A Method For Deteting Memory Bot- WRL Tehnial Note TN-32, Deember 1992. tleneks. Aaron Goldberg and John Hennessy. Link-Time Optimization of Address Calulation on WRL Tehnial Note TN-17, Deember 1990. a 64-Bit Arhiteture Amitabh Srivastava and David W. Wall. Prediting Program Behavior Using Real or Es- WRL Tehnial Note TN-35, June 1993. timated Profiles. David W. Wall. Combining Branh Preditors WRL Tehnial Note TN-18, Deember 1990. Sott MFarling. WRL Tehnial Note TN-36, June 1993. Cahe Replaement with Dynami Exlusion Sott MFarling. Boolean Mathing for Full-Custom ECL Gates WRL Tehnial Note TN-22, November 1991. Robert N. Mayo and Herve Touati. WRL Tehnial Note TN-37, June 1993. 19

Ramonamap - An Example of Graphial Groupware Joel F. Bartlett. WRL Tehnial Note TN-43, Deember 1994. Ciruit and Proess Diretions for Low-Voltage Swing Submiron BiCMOS Norman P. Jouppi, Suresh Menon, and Stefanos Sidiropoulos. WRL Tehnial Note TN-45, Marh 1994. Experiene with a Wireless World Wide Web Client Joel F. Bartlett. WRL Tehnial Note TN-46, Marh 1995. I/O Component Charaterization for I/O Cahe Designs Kathy J. Rihardson. WRL Tehnial Note TN-47, April 1995. Attribute ahes Kathy J. Rihardson, Mihael J. Flynn. WRL Tehnial Note TN-48, April 1995. Operating Systems Support for Busy Internet Servers Jeffrey C. Mogul. WRL Tehnial Note TN-49, May 1995. 20