1. INTRODUCTION Over the past two years, a new system for describing circuits and generating layout has been developed in the Computer Science Laboratory at Xerox PARC. For the most part, it is a complete system, in the sense that it includes tools for design capture, layout generation, analysis and simulation, timing verification, layout versus schematic comparison, design rules checking, plotting and documentation. Despite this impressive variety of tools, the most original aspects of the system reside in the use of a single data structure, the design capture, and the generation of layout. The system is described thoroughly, albeit without any in-depth examples, in three companion papers: the data structure which is the foundation of our synthesis and analysis tools is described in [1], the details of capturing designs as a mixture of annotated schematics and code are shown in [2], and the general mechanism for generating layout is explained in [3]. This paper describes this DA system through actual examples that illustrate the major underlying principles. Section 2 gives a brief overview of the system. The following section takes a thorough look at the structure of a parameterized shift register; this shows the expressive power of schematics and code. Section 4 covers the assembly of a RAM array to exemplify how the mechanism of schematics annotations can be used to generate layout. This section insists on low-level details, only necessary to optimize layout, which are by no means representative of the feel that a user would get from the system. Circuits described with high-level generators, such as standard cells, data path, and routers, usually carry very few extra annotations. In the last section, we give an idea of how far some of the concepts are carried by describing a finite-state-machine by its transition diagram. 2. OVERVIEW OF THE SYSTEM The design system is based on a unique data structure which captures all aspects of a VLSI circuit in the form of a hierarchical structural description that we simply call a net-list. The data structure can be created directly by executing a program, by extracting and evaluating schematics, or more commonly, by a combination of both. It can then be processed by a variety of processors, such as simulators, analysis and verification tools, and layout generators. The data structure is extensible in the sense that it may carry arbitrary annotations. New classes of objects and processors can be defined dynamically, without having to modify the existing system or source. 2.1 Design Capture The main paradigm of the system is the capture of a design as a mixture of code and parameterized schematics carrying special annotations: we refer to this representation as a net-list generator. The mechanism for this capture is a single graphic editor rather than special-purpose editors for each type of design information; this keeps the user-interface uniform, and frees the designers from the burden of learning different manipulation commands for each type. A major result of the system is that the source is usually very small and understandable, even for fairly large and complex circuits. 2.2 Extraction The concept of extraction usually refers to merging rectangles and tracing connectivity of masks. We call schematic extraction the process of interpreting a circuit description to produce a net-list. This interpretation is very general, and each object has an associated extraction method: rectangles are typically merged to form nets; icons are extracted by executing a specific program, or by extracting another schematic; textual annotations can be attached to any object or instance of an object, and are evaluated during the extraction. The whole process of schematic extraction is analogous to the interpretation of a program in a dynamically-scoped, block-structured language. This process will be described in details in Section 3. Examples of extraction methods for other classes of schematics, sequences and FSM's, are shown in Sections 3.2. and 5. 2.3 Layout Generation Instead of assembling layout as an independent process, and later comparing it against the source description, the system generates layout from the source description. The designer annotates the schematic to specify the desired layout generation method. This is done by including in the schematic a Layout annotation whose value is a key corresponding to a layout generator. Other annotations might provide extra parameters for the layout generation. Defining a new layout generator or modifying an existing one is a straightforward operation, by no means reserved to system implementors. Layout generation is a simple, bottom-up, context-free, recursive process, using a single layout engine. Generators can be mixed freely at any level. All generators perform interface checks during the assembly, and guarantee completion as long as their input is valid. Great confidence in the correctness of the final mask results from the fact that the generated layout is untouched by human hands: if the result is unsatisfactory, the source, either schematics, code, or layout of small cells, is updated, and the generation begun again. 2.4 Programming Notes An important feature of the system is that every feature is accessible by program: creation primitives, interactive commands, processors, ... As a consequence, there is no difference between schematics and code, and the terms interactive and batch processes alone only distinguish the users' patience, since anything can be invoked interactively or imbedded in a program or a command file. The idea is to give users more choices, and not enforce a fixed methodology. Another nice feature of the system is that it scales gracefully: there are usually no hard limits, other than the size of the virtual memory itself, of the form "no more than 2000 pins", or "at most 16 levels of hierarchy". As a consequence, large circuits are almost as safe to layout or simulate than small ones. It is usual to develop a parameterized version of a circuit, debug it, and then simply scale it up without facing a major problem. Part of this is due to the programming style which makes heavy use of dynamic data structures, and part to the Cedar programming environment [4]. 3. AN EXAMPLE: PARAMETERIZED SHIFT REGISTER As an illustration of the expressive power of mixing parameterized schematics and code, we will walk through the description of a simple library element: a shift register. 3.1 The User's Point of View For the designer, the shift register is simply an icon found in a library. This icon accepts a single numerical parameter nb, which specifies its width in bits. After importing the icon into her/his design, the designer affixes to it a satellite, or text, which specifies the value for nb. In this example the text is of the form nb_8, but since it is handed to a general evaluator, could be any valid Cedar expression, such as nb_5+Log(SizeOfBus/2). Once part of a schematic, the shift register provides several things: a complete net-list of a shift register based on primitive elements, including buffers on each control signal; behavioral models at various levels of abstraction; and layout in the form of standard cells. We now follow the extraction of an instance of this icon in order to understand its structure. 3.2 Structure of the Shift Register Every object has an associated extractor which specifies how to obtain the net-list that the object abstracts. In this case, the icon extractor simply refers to a schematic to be extracted. The value of nb is passed along since it is needed to extract the schematic. Figure 3.2.1 shows an instance of the icon with a byte-width, and the parameterized schematic defining it. The schematic defines a shift register as a register (a member of the same library) whose input runs through a multiplexor which selects either the global input (when loading) or the previous output shifted by one position (when shifting). The input wire and the complementary outputs are nb-bit wide buses. Small symbols, called wire icons, describe the structure of wires. For example the wire extractor (0: nb) specifies that the wire Output is made of nb atomic wires, and gives access to its high-order component (index 0) named outMSB. Similarly, the range extractor (1/nb-1: nb) defines a new wire of size nb-1, composed of the nb-1 low-order atomic wires of Output. Notice that the multiplexor, the wire icons and the register are all icons parameterized by expressions using the variable nb, and can be extracted as soon as nb receives a value. Now let's shift our attention to the register. Its icon happens to point to a procedure in the module defining the library. The code, slightly cleaned-up, is shown here. Register: PUBLIC PROC [b: NAT] RETURNS [ct: CellType] = { IF b=0 THEN Error["Please specify a non-zero size for the register"]; ct _ Extract["register.sch", ["b", b]]; -- extract another schematic SpecifyPorts[ -- specify directionality of ports -- ]; AttachBehavioralModel[ct, RegisterSimulationProcs]; }; The most remarkable thing is that this procedure simply asks for the extraction of a schematic with the specified value for the parameter b: it is the strict equivalent of a procedure call. This closes the loop between the graphical and procedural domains, and demonstrates that schematics and code can be used interchangeably. The choice of the most practical representation is left to the designer. The code also characterizes the ports of the cell and attaches a behavioral model to the register. This could be described completely in the schematic, but it is more conveniently done in a program. This justifies the extra step through code. The behavioral model is a procedure written in Cedar which can be used to simulate this block at register level. If no such behavioral model were available, the simulator could flatten the register down to gates or transistors, both of which have their own behavioral model. The register is thus described by the Register.sch cell, which contains only two elements: a sequence of D flip-flops with complementary enable lines, and a driver for the control lines. This graphical sequence of D flip-flops illustrates how generalized interpretation of a picture makes design capture very natural. Imagine the designer editing and thinking, in a natural manner: "I want to create a sequence (new class of cell) of b (Seq: b) such flip-flops (he draws the base cell), so that the input and outputs become buses (he adds sequencing slashes on these wires) but the control wires are shared (clock and enables are untouched)." A different circuit extractor then interprets the picture in order to create a sequence cell: not only is the source smaller and more legible (drawing all the flip-flops would be more tedious, and would prevent any parameterization), but a higher-level abstraction has been captured, and can be used by certain tools. In the left part of Register.sch, we find another parameterized icon featuring a complementary buffer. The parameter d specifies the load that the buffer is to drive in terms of unit gate load. Once again, the icon points to a procedure. SymDriver: PUBLIC PROC [d: NAT] RETURNS [ct: CellType] ~ { SELECT d FROM -- extract another schematic according to the range of d <=0 => Error["Please specify a non-zero strength for symmetrical driver"]; <=3 => ct _ Extract["symDriver3.sch"]; <=6 => ct _ Extract["symDriver6.sch"]; ENDCASE => { -- use constant amplification in 3 stages n2: NAT = (d+3)/4; -- last inverting stage d1: NAT = d+n2; -- logic drive of initial non-inverting driver ct _ Extract["symDriver.sch", ["n2", n2], ["d1", d1]]; }; SpecifyPorts[ -- specify directionality of ports -- ]; AttachBehavioralModel[ct, SymDriverSimulationProcs]; }; This time, the procedure extracts a schematic according to the value of the load: for small and medium loads, it picks fixed buffers of unit or double size; for larger loads, the buffer is itself a schematic which accepts two parameters. The buffer of size n2 is simply a sequence of unit-size buffers. The buffer of size d1 is again a parameterized icon, with a structure similar to the symmetric buffer we just described. It is time to put a halt to this recursive walk through the shift register, but it is clear that after another couple of steps, the shift register would be completely described in term of basic gates and D flip-flops. During this exploration, we came across many parameterized macros from the same library: register, multiplexor, and several types of buffers. This situation is very common and illustrates that such parameterized macros can be re-used very easily. Many common parameterized macros have been assembled into a library which has become one of the most widely used components of this DA system. The library comprises basic gates, registers, multiplexors, comparators, drivers, counters and adders. Several circuits developped at PARC are described mostly in terms of elements of this library. 3.3 Layout This shift register, like any other member of the library, can eventually be reduced to about two dozen basic cells for which layout exists. This is a surprisingly small library of standard cells, but our experience is that the introduction of parameterization is a much better move toward increased productivity than augmenting the library with rarely-used complex gates or fixed-sized macros (e.g. 4-bit multiplexor). To obtain layout for a portion of a design expressed solely in terms of library elements, one adds to the top-level schematic the annotation Layout: StandardCells, together with a few optional parameters such as the number of rows. These annotations are preserved by the extractor and end up on the hierarchical net-list representing the circuit. The layout generator processes this net-list and flattens it until all the leaf-cells carry a Layout annotation. At this point, the general layout mechanism is invoked to obtain the layout of these leaf-cells, usually from a standard or user-defined library. This layout can also be obtained by composing other cells, or generated by program: since standard cells are nothing special to the system, adding a new cell is a benign operation. This illustrates the extensibility of the system and the uniformity of the layout generation. The last step is the usual placement and routing of those leaf-cells to obtain the complete layout for that block. Notice that the obtention of layout for such a design necessitates almost no overhead: a single annotation for a block of standard cells of any complexity. This situation is typical of high-level generators. 4. ANOTHER EXAMPLE: A PARAMETERIZED RAM The following example is taken from the register file of an experimental processor. The description illustrates the construction of a typical module generator using parameterized schematics. As expected in dense full-custom areas, the main layout operators are the low-level assembly functions of abutment, rotations and symmetries. 4.1 Leaf Cells Only two leaf cells are needed to describe the memory array, one of which is a very simple stitch cell, needed only to distribute power. The main cell is a triple-port RAM cell, shown in Figure 4.1.1. as a schematic at transistor-level with several annotations. The width of transistors is a typical annotation and is used by the schematics versus layout comparator, the static checker, and various simulators. An interesting annotation is Layout, whose value Get means that the layout is available as a user-defined cell. Computing the layout simply returns that cell, after checking that the schematics and layout cells have compatible interfaces. 4.2 Rows The next level of assembly describes a quad-word: the RAM cell, shown in Figure 4.2.1. in iconic form, is sequenced graphically and the resulting cell is composed with a RamStitch, forming a complete RamQuad cell. The graphical sequence is similar to the one of Section 3.2., except that the keyword SeqX specifies that the layout must proceed by abutting cells in the horizontal direction. Let's slow down here to examine closely the layout generation. When the layout generator processes the annotated net-list, it first encounters the AbutX annotation; this indicates that cells are to be abutted in the horizontal direction to compose the layout. Notice that the order of cells is derived from the schematic and does not have to be repeated explicitly. This is an extremely simple illustration of the use of schematics as a graphical language: since the layout generator has access to the graphical representation of the circuit in addition to its net-list, it can infer a lot of hints: these hints are exactly the ones a designer would use, which minimizes the redundancy and improves the legibility of the design. This graphical language is put to full use by high-level layout generators, such as data path or pad frame generators: the relative positions of cells and wires are used as floorplanning information to drive the layout generation. Back to layout generation. The Abut layout generator asks for the layout of its two components, the sequence and the stitch. The RamStitch cell carries a Get annotation and its layout is readily available; the sequence recursively calls the Array generator, which finally fetches the layout of the RAM cell. The layout of these two pieces are abutted, and an interface check is performed before returning the final layout for RamQuad. This RamQuad is then sequenced to form RamRow. Notice that the repetition factor is a parameter, making this a module generator rather than a fixed cell. 4.3 The Complete Array The layout of adjacent rows in the array must alternate in order to share power rails and wells. The schematic of Figure 4.3.1. shows a symmetric version of the row produced with the FlipY annotation; the row and its symmetric version are abutted, then sequenced vertically to form the entire array. The icon on the right side of Figure 4.3.1. simply abstracts this whole array. Since it is parameterized by the number of quads per words and the number of words, one must bind specific values to these parameters, as shown. The array can at this point be enhanced with I/O logic, and address decoders which are more naturally described by a page of code. The whole description for this parameterized RAM fits comfortably on two graphic pages (the schematics and layout of leaf-cells) and on one page of code. The design can easily be put together in a matter of hours, particularly if part of it can be borrowed from another design, like the code for making a decoder, or the schematic of a memory cell. 5. AN ADDITIONAL EXAMPLE Space is lacking here to illustrate how far we carried some of the concepts, so we will skim briefly over an additional example. Figure 5.1. shows on its left half an example of a finite-state-machine, described graphically with named states, outputs, and boolean equations conditioning the transitions. To the designer, it is simply a very readable picture which can be inserted into the circuit documentation; to the DA system, it is a portion of a schematic which can be extracted, just like a stack of gates would be. The schematic is extracted by an extractor specific to the FSM cell class. Depending on the option used, the result of the extraction can be an empty cell with a behavioral model generated directly from the boolean equations, or a complete net-list representing the FSM as standard cells or a PLA. An icon can be generated automatically from the schematic: it is shown in the right half of Figure 5.1. as part of a FIFO controller. 6. CONCLUSION We have presented a few examples which illustrate the major concepts behind our DA system, but these examples only give a weak idea of its power. Parameterized schematics mixed with code lead to very concise and natural descriptions of circuits: we have described circuits using representations bearing no resemblance to traditional schematics, i.e. finite-state-machines, boolean equations, data paths, and we have little doubt that the extensibility of the system will encourage new creative development. It is remarkable that the mechanism of annotating the source to drive the layout generation does not impose unreasonable restrictions on the style of layout: as a proof, a handful of designers have produced over the past couple of years a dozen chips ranging in complexity from small test chips, put together in a couple of hours, to full-custom circuits of over 300K transistors. The set of generators they used is quite large: in addition to the basic generators exhibited in this paper (Get, Abut, symmetries and rotations, arrays), one can place and route standard cell blocks, route blocks, assemble data path, semi-regular tilings, and pad frames. Specialized generators for logic arrays [5], and libraries of parameterized macros complete the panoply. Although work is proceeding to improve the system, the concepts of design capture as parameterized schematics mixed with code, and the use of annotations to drive layout generation already seem to be very powerful ones. As evidence, the variety of circuits developed with minimum man power using this system. 7. ACKNOWLEDGEMENTS The development of a state-of-the-art DA system cannot be dissociated from the development of state-of-the-art circuits: many designers at PARC, mainly in the Dragon project, have acted both as alpha-users and developers, providing ample feedback, challenging requests, new libraries, and generators. Among them, the author wants to acknowledge specially Rick Barth, Bertrand Serlet, and Pradeep Sindhu, who have co-authored the three papers [1, 2, 3] describing the system. Giordano Beretta, Don Curry, Jean-Marc Frailong, Christian Jacobi, Jim Gasbarro, Christian Le Cocq, Brian Preas and Mike Spreitzer have also left a paw-print on the DA system. Finally our Cedar programming environment [4] has to take some of the credit for enabling quick prototyping and development of the system. 8. REFERENCES 1. R. Barth, B. Serlet, "A Structural Representation For VLSI Design", 25th ACM/IEEE Design Automation Conference, June 1988. 2. R. Barth, B. Serlet, and P. Sindhu, "Parameterized Schematics", 25th ACM/IEEE Design Automation Conference, June 1988. 3. R. Barth, L. Monier, and B. Serlet, "PatchWork: Layout from Schematic Annotations", 25th ACM/IEEE Design Automation Conference, June 1988. 4. D. Swinehart, P. Zellweger, R. Beach, and R. Hagmann, "A Structural View of the Cedar Programming Environment", ACM Transactions on Programming Languages and Systems, Vol 8, No 4, pp. 419-490, October 1986. 5. B. Serlet, ``Fast, Small, and Static Combinatorial CMOS Circuits,'' proceedings of 24th DAC, Computer Society Press, pp. 451-458, June 1987. ([Artwork node; type 'ArtworkInterpress on' to command tool] Figure 3.2.1. The shift register and the parameterized schematic defining it [Artwork node; type 'ArtworkInterpress on' to command tool] Figure 3.2.2 A parameterized register, demonstrating a graphical sequence [Artwork node; type 'ArtworkInterpress on' to command tool] Figure 3.2.3 A parameterized buffer [Artwork node; type 'ArtworkInterpress on' to command tool] Figure 4.1.1. The leaf cells describing the memory array [Artwork node; type 'ArtworkInterpress on' to command tool] Figure 4.2.1. Assembly of a quad and a parameterized row [Artwork node; type 'ArtworkInterpress on' to command tool] Figure 4.3.1. The parameterized array [Artwork node; type 'ArtworkInterpress on' to command tool] Figure 5.1. A finite state machine @"aussie" styleIstandard9.5 cm bigger topIndentheadzIbodyMMsMMMMiMMkMM' nMMM M++MM {+^M##MM artworkFigureFitTRUE InterpressInterpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts HELVETICA-MIRXerox PressFonts Helvetica-MRRkj蠤?@#Р&xj(r(r(8((t((q(q(m(m(m(m(l(ࡹ(l(p(l(p(j,(j(f(f(f(f(b(b(X(`Z($Z(4("("( ( ( ( '(''( ( ( $( '('$'ҡ(d(h(d(h(b(b(T(h(L(T(L(hx(J(J(<(H(:(:(,(8z(,z(Hx(*(*($((("("(( (( (('(H','ڡJ'J'ء'(X''С'L''$'''''''''''''Z'pZ''p''Z'Z'(8'8'*'*'ء('L''8'''*'\*'J'\J'H'Z,'Z'T'Xr'Tr'Xp'R'R',''$','$'X'!'!'!'!z'z'P''''''''x'|'''''''''''''&'Xz&z'kxj &ԙ<( &ԏ 'CK (inLSB'dShiftx<'Loadp젢@(b_nb眠'ҙ'ҙ'ҙ''ҙ'H'™'ؠFĠ'enPh'b_nb((™"—x'doutMSB <'0 舠&栢nb 躠&栢nb躠'1/nb-1莠(vnb*(J0/nb-1V"(`nb-1@"(>nbb((InputH&젢OutputX贠&젢nOutput贠'inLSB"礠'outMSB"礠'̠Load!Ԡ'Shift! P'x("P'™"'shReg" P( "P'̠nb_8"ԠkkgArtwork InterpressBounds810.0 mm xmin 10.0 mm ymin 205.9 mm xmax 78.00673 mm ymax0.3471502 the lineLength .mul 2.811678 .add topLeading 0.3471502 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeadingn;;IartworkCaptionObiLLMMf! L)~"code k9P:EP)cEP%6P33PMMMTRUEInterpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts HELVETICA-MIRXerox PressFonts Helvetica-MRRXerox PressFonts Helvetica-MRRkj蠤;"Р#Xxj%2%2%1%1%0%0%/%/%.%.%-%-%,%%,%,%+%+%*%*%)%)%(%(%'%'%&%&%%%%%$%$%#%#%"%"%!%!% % %%'%%J$J$ܡ$$ʡ$$ȡ$$8$D$ڡ:$:$ء0$<$ҡ$%B$B$ء% %% % %%%%%$%$%$%$$ҡ@$$ҡB$B$С:$:$С8$D$ʡ2$2$С$$ࡹ$$¡2$2$0$$$$$$ȡ$$$$С$$J$J$䡹I$I$⡹H$H$ࡹG$G$ޡF$F$ܡE$E$ڡD$D$ءC$C$֡"$"% $P$ҡ@$@$С?$?$Ρ>$>$̡=$=$ʡ<$<$ȡ;$;$ơ:$:$ġ9$9$¡J$J$I$I$H$H$G$G$"$"$СF$F$E$E$ $,$D$D$C$C$*$*$($P$@$@$?$?$*$*$"$"$>$>$=$=$ $,$<$<$;$;$:$:$9$9$"$"$$$$$$$t$$t$$t$$r$r$L$$L$$J$J$D$H$D$H$B$BJ$8J$H $8 $@#$pkxj$x™"(T$ȠFT$|en" $# Register.icon"뤠#ԙT%#ԏ$젢d_b괠(%NENꄠ$nOutput$ܠOutputĠ%LInputT#젢CK봠8$|EN$$™ࠢ$L젢$Ġ™$Ġ$̠enԠ$ Register.sch넠$ %D$ 8$—ࠢ$™$en`$ࠢnEnp% —FĠ8$—$TSeq: b@Lkkg Interpress610.0 mm xmin 10.0 mm ymin 205.9 mm xmax 66.411 mm ymax0.2879581 the lineLength .mul 2.811678 .add topLeading 0.2879581 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeading;;ObitJJMM& M -+"! Vx :8GPJJP&&P&&)6P *P .AP66PP%6P44PM@eMTRUEInterpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts HELVETICA-MIRXerox PressFonts Helvetica-MRRkj蠤#D\!Dxj""ࡹ@""¡""""H"T"""R"R"8""P"("R"R"J"J"H"T""p" "j,"j""d""h"b$"b*"d*"h("bL"b*"\*"`""\""` "Z,"Z"X"`"T"p"""""H""""""""p""T"pr"Tr"p"R"R"R"R"D"H"BL"B"Z"Z""ʡ""ȡ""¡""""ȡ""""B"dB""d""b"bX"b"b"T"p"T""T"X"R"R"R("R"L"P"L"X"J"JX"Z"Z"T"X"RH"R"L"PZ"LZ"XX"J"J"@"`"0"P"0"P"0"Pkxj!,"ď!"\X D"nX "P™!P"T™!"T"™!"™!""I!"symDriver3.sch!휠T!#T!"TLL"d™"d"`™@"Ġ™"Ġ"™ࠢ"B젢"B젢"ܠd_n2Ġh"lI4`"̠nXԠp"lX4" symDriver.schh휠"d_d14!L"ď4!"P™P"T™"T"D2\T"symDriver6.sch L휠H"I X"nX0("\XD"™ "™ ""2 h"symDriver.icon#8휠"P™"P"DL"\"T™""Tkkg Interpress810.0 mm xmin 10.0 mm ymin 205.9 mm xmax 42.26588 mm ymax0.1647059 the lineLength .mul 2.811678 .add topLeading 0.1647059 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeading;;O$$MMM MMM''MLMM0.4626866 the lineLength .mul 2.811678 .add topLeading 0.4626866 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeading810.0 mm xmin 10.0 mm ymin 205.9 mm xmax 100.6403 mm ymax InterpressInterpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts Helvetica-MRRxerox pressfonts Helvetica-MRRxerox pressfonts HELVETICA-MIRxerox pressfonts GATES-MRR kj蠤𠤠#Ƞxxj H H 8 8 8 X X X H X 8 H 4 4 0P 0P 0p 0 0 8 8 8 0 8P ,p ,P (P 0P 0p 0p (p 0 ,P , ( 0 0P 0P (P 0P $h $8 $P $ $8 $      ( ( (    0 ( 0  (p ( (x  p p (p (p 0  0l l (p p (p p X h T T 8 P  8                               x  x  x x x    t t p x p p p p x x X p X p X X p p T T P X P P X X 8 P 8 P 8 8 P P  8  0 0 8   8 8                                                                       8  8 0 8  0                                                                      8 X 8 P 8 8 P X 8 P X X  xxx x   hh XxXX X X p x X p xx TT PXPP XX 8P8P88 8 P PP 44 0800 0 8 8 8 88 ((  0   0 00                                   衹졹衹졹衹䡹衹衹衹衹ࡹࡹࡹ衹ȡС衹衹衹̡ȡССȡȡȡȡȡȡȡ졹Xx졹XXXxxxpp衹``衹X`ءXX衹TTPXءPPPXXXXX衹DD8Pء888PPP,, 8ء  08 088衹   衹衹衹衹衹||xСxxءxxx`xԡ`xС``ءxxء\\ءX`СXXءX`ء``ءTTءPXСPPءPXءXXء8Pԡ8PС88ء8PءPPء8ԡ8Сء 8ء88ءԡСССءءDDС8P88С8PСPPС8ġ08С8С88С0000ССССССССССССȡ衹衹ءС8P888PPPrr H`tҡRRʡT С    ԡʡСxxxСxССhhСXxXXС`xСX`СxxСTTСPXPPPPPPСPXСXXСLLHPPP8H44080000088800000  衹衹衹ࡹСȡ         衹LLHPPP8H8P8@@P88PP440800088800000RRbbС`txxxxTTPXPPPPPPPXXXHH@P@@@PPP<<8@888@@@||xx||xx̡     H H 8 8 8 H H X X X 8 X 4 4 0 0 0 8 8 8 0 8 , , ( 0 0 0 ( 0 ( (  ( ( 0  0 ( ( $ $ ( ( ( ( 0 ( 0 (                                                         Hҡ""ʡ P      衹          ʡԡ    ""С H Hlllrlrjjhxlxhlhxhxhxhxdd```h`hdd```h`h`x`xxxhx`hh`hX`h`X`XXxx`xT`TP`X`P`PPXX`XH`H@`P`@`@@PP`P<`<8`@`8`88@@`@(`(`8``88`8````````````````````\8\X``8`8X8`4H4X8H8X(H(XHXHX@`@@@```X`HX@H@`@@@```@`@`@@@```@`@`@@@```@`@`@@@`@`@@@@`@`@@@@@@@@@@@@@@@(@(((@@@(@(@(((@@@(@(@(((@@@(@(@(((@@@(@$$ ((((( (   $$ ((((( (       (  ((( (   (((( (@`@@@```@`@`x@@x@x```@`p@p`h@x@h@h`x@x``@``X@h@X@X`X`h`h@h`T@T`P@X@P@P`P`X`X@X`H@H`@@P@@@@`@`P`P@P`<@<`8@@@8@8H8H8X8X8`8`@`@@@`( (H @@H8@8H8 8@44 88 ((    8 888RhRhLhLJJJJ<Hr<rhllXXXXPPHXHXHXHHHXXXHXPPHXHX@@@@HHXX@DD@@@HHH@H@@@@XHX@H<<H::p::@xxx@x@@@``@XhXX@X@h@hh@TT@PXPP@P@X@XX@HH@@P@@@@@P@PP@<<@8@888888 8 8@8@@@@@@88888@@@@ @ @@@@@@  ((@@@@졹衹衹衹ء衹ءTTPXࡹPPPXXXHH@Pࡹ@@@PPP<<8@ࡹ888@@@8衹8ࡹ888ࡹࡹࡹءx䡹xءxxxpphxءhhhxxx``XhءXXࡹXXXhhhTTࡹPXءPPࡹPXࡹXXࡹ@Pܡ@Pء@@ࡹ@PࡹPPࡹ<<ࡹ8@ء88ࡹ8@ࡹ@@ࡹ8ܡ8ءࡹ8ࡹ88ࡹࡹءࡹࡹࡹܡءࡹࡹࡹࡹءࡹࡹࡹءࡹءСءءԡССءءءءءءءءءءСȡССССȡССС̡ȡСССȡȡȡȡȡȡȡȡȡȡȡȡȡȡȡȡTTءPPءPXءXXء@Pԡ@PС@@ء@PءPPء<<ء88ء8@ء@@ءx̡xxxءxءء``ءXXСXXءXhءhhء8Xȡ8HHX88С@PСXXСءءءءءءءء8H888HHH(8(((888XxXhXXhxxxPPHXHHHHHXXXDDHHHH<<44,,((8H8H88HH(8(8((88$$ (   (((((((    ءȡءءءxxxxxxhxhxhhxxxxxxpphxhhhxxx``XhXXXhhh$ҡ꡹rr8pxxxxpphxhhhxxxPPHXHHHHHHHXXXXXXX@@8H888HHH00(8(((888hxhxhhhxxxXhXXXhhhHXHXHHHXXX8H8H888HHH(8(8(((888(((((ppppppxppxpxxxxpXxxxXpxpXpXhxxpxPpPHpXpHpHHXXpX@p@8pHp8p88HHpH0p0(p8p(p((88p8 p p p p(pp((p(pppppppppppppppppppppppppppppppppppppXpXXXpppXp0X0p(X8X(X(p(p8p8X8pPpP PPpp p X p P XPpPPPpppPp H pHHHpppPpHPHpHHHXXpppHpHpHHHpppXpHXHpHHHpppHppppP_ҡrr꡹RRС""С RtR"t"trTrllhhhphphhhhpphphphppphpTpRRHhHHHhhhPhHPHpxHHxHxpxpphpHhPHPpHHXHHHHpHpXpXHXp@H@p8HHH8H8P8P8X8X8p8pHpHHHpL0LHP P0PP P0H0P,8,H080H 8 H0H000HHH0H0H000HHH0H0Hx00x0xHxHH0HX<x<X0x0X0XHXHxHx0xHP0PHH0X0H0HHHHXHX0XH@0@H80H0808H8HHHH0HH404H00800008080H0H8H808H4040000800080P000HHPPPHP08 0 H000HHH0H0H000HHH0H<<000HHH0H0H000HHH0H0H000HHH0H0H000HHH0H0000000000衹衹衹衹衹ء衹衹衹衹衹衹000000000000衹衹衹衹衹ء衹衹衹衹衹衹PP0HXHH0H0X0XX0@@08H88080H0HH08X88HX8HXXTTXXHH<<888X8X88XX8X@P衹888XXXTT衹PP衹XX衹HH衹@Pء@@衹@P衹PP衹<<衹88衹@@衹000000xxx0x000"4"p4J0*p*@@@@,@(,(0pڡءܡ䡹ءء0pءءءءt8tppppxpx||ppppppppprrTpRRr4rJR4RpP2t22$2rr00Pxxxx||xxxxxx\\HHHPPpppHp0H000HHH0H<<000HHH0H0H000HHH0HPx衹xxxHH`HH`HH0H0HHHHHpHpHxHx`x``x0ࡹ0000衹衹衹ࡹ衹ء衹衹衹||衹xx衹衹xԡxСxxءءء8Xԡ8XС88ء@PءXXءԡСءءءԡСءءءkxj,t 0,xjpselCkxj 0+kxj(nkxjp4selAkxjp䠢selBkxjdT RamStitchkxjXBT/ Layout: $GetkxjnGndkxj VddkxjޠselAkxjvselBkxj6selCkxjP6selCkxjXvselBkxjXnGndkxjx栢bBitkxj8栢cBitkxj栢ncBitkxj栢naBitkxjpޠselAkxj VddkܙT L̎܏xj8+kxjnkxjnkxj8+kxj]dikxjdikxj@selBkxjselAkxjtselCkxj$Tp}StatekxjdT,}nStatekxjƠw_3kxjƠw_3kxjx&w_16kxj&w_16kxj T/ Layout: $GetkxjԠRamCellkxj ncBitkxj naBitkxj cBitkxj bBitkkkgTRUE;;O99LM 6q ^XMM_ U4~mMTRUE(Interpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts HELVETICA-MIRXerox PressFonts Helvetica-MRRkj蠤ؠ"Xlxj(ldbDbDjDjB,BhBxBbb@@jj@hxbbjjhx⡹jtjࡹ*t***@(<**(<⡹**ࡹ(<@btbࡹtࡹ**,rdr(rlr`ZbZ`YdYbXfXdWhWfVjVhUlUZZYYXXWWVVUUZZYYXXWWVVUUZZYYXXWWVVUUTpTTTpTTTpTTrTrpjTnTSSSSSSlStSRRRRRRnRtRQQQQQQpQtQPPPPPPpPvPOOOOOOpOxOvNzNxM|MzL~L|KK~JJIIHHNNMMLLKKJJIIHHNNMMLLKKJJIIHHN NM M LL KKJJIIHHbbaa``__^^]]bbaa``_ _^"^ ]$]HbJbHaLaJ`N`L_P_N^R^P]T]xbzbxa|az`~`|__~^^]]\\\Z\ZR\V\*\*"\&\\\\[[T[\[$[,[[[ZZVZ\Z&Z,ZZZYYXY\Y(Y,YYYXXXX^X(X.XXXWWXW`W(W0WWWVVUUTTSSR RQ Q P P.V2V0U4U2T6T4S8S6R:R8Q<Q:P<P^VbV`UdUbTfTdShSfRjRhQlQjPlPVVUUTTSSRRQQPP8WZ8ZW*8*W8W\\888XXppcac`a_`^_]^\][\Z[8Z $p$ p  H H J J K K L L M M N N O O P P Q Q X XpXp8pXpp8OOOrrOkxj|촎쏘,촎,H—FH—F䠢H—FF`젢naBit"@F蠢ncBit"FРcBit!ࠢFРbBit!8selA!selB!8ؠselC!hZ2RamCell"F@SeqX: 4"H—F턠Fr RamStitchr Π蠢selC XselB (HselA 0RamQuad!(Layout: $AbutX!x@4@HԎ4P—FlP—Fl<P—F< P—F selAl8ؠselBlhselClFPࠢcBit𠢠FࠢbBitFnaBitPF ncBit RamQuadX.H SeqX: NbQuads xRamRowȠkkg Interpress810.0 mm xmin 10.0 mm ymin 205.9 mm xmax 69.12992 mm ymax0.3018373 the lineLength .mul 2.811678 .add topLeading 0.3018373 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeading;;O99LMMTRUE"Interpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts HELVETICA-MIRXerox PressFonts Helvetica-MRRkj蠤#8@hxjrrBBTppxxpxp衹p衹x衹$@ޡ @֡RRP@ҡjjġii¡hhggffeeddcc22С$RRСP``__^^]]\\[[ZZYY22@$@$~@~ v@v t tRtRr@rPrrRLRprLrBLBLLLJTJrDrHBDBHDHDHBTBRR@Prdrjbjdi`ibh^h`g\g^fZf\eXeZdVdXcTcV2T2p$RR`N`P_L_N^J^L]H]J\F\H[D[FZBZDY@YB242P 4 p2@2$,@,$@ @  00p@RRP꡹jjiihhggffeeddcc22$``__^^졹]]꡹\\衹[[桹ZZ䡹YY⡹22  衹@ҡ$@̡  СRR衹P RRrr@BB@@@@Tpppppb,bp`*x*bb(`xbb`xʡb<bȡ<p:d:(8r(r8B(B8(8DpDpxxpxp8pxp(p8pp(rrBBkxjselC< selA< 𠢠selB<PRamArrayBFFnaBit8F8ncBitFhcBitؠFbBit NbWords~408 NbQuads~328llXࠢ—`X@—  SeqY: MAX[NbWords/2, 1]! l|Dl|Ƞ RamRowPair# xpLayout: $AbutY#06RamRow!j&selA 0ࠢselB `selC F naBit !FncBit!FH𠢠cBit!XFx𠢠bBit!(HselAXHHXselBX蠢HselCXpDhpD6BRamRow!jLselA |selB ĠselC F젢naBit!F젢ncBit!FH젢cBit!XFx젢bBit!(xLayout: $FlipY#(x RamRowFlipped#(@PRamArray `𠢠X—kkg Interpress810.0 mm xmin 10.0 mm ymin 205.9 mm xmax 73.40724 mm ymax0.3236715 the lineLength .mul 2.811678 .add topLeading 0.3236715 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeading;;O&&MMMTRUE.Interpress/Xerox/3.0 fjXeroxResearchCMYK?"}[-fIE5c /TEKD|1dR=Hxerox pressfonts HELVETICA-MIRXerox PressFonts Helvetica-MRRXerox PressFonts Helvetica-MRRkj蠤#@ `@,ġxjxJJ0H..8**""zzH |  (0  22(<::22**(<(l22zzjjh|꡹jj衹**(lҡH\꡹衹⡹ࡹzz衹xʡF*N2XBhZ>ZT<:|:zzdx2d20bb4`4j4j22h22  jj h0222 20 T @ʡ(<¡::**(<0ZZ"X0ȡBBȡ@"d"tdxb$b"P"`","<,`*$*""(H(FFH⡹ZZ衹\ʡȡh:p:p:d:pdp@2L2B B02 20 D jjhBB0DڡH,¡BBء**(D**JJH,B|B*|*(zDz*d*xJdJHb,bJ J0H \ ffJJHhڡJJءH\J|JHz\zJLJxBLBx@JLJkxj4D`4D \Pop4 䠢 $nInc4 P4NewRqstP z_4 TCin 젢$Bin Load LĠUp |Down TCout 젢$Bout 0x 0x up/down ™ 0ܠCK d(X+ 蠢IncH L Q 4 D 4xؠ™ hʡʡ ʡʡ FVrrꠢ( + ܠb_4` dlWTable ԠRequest ̠PopFifo tp LoadReply DHlClock ԠHReset H̠Free tH DataAvail D FSM4 4™F 40™ 4 ™ 4F0 ™ 𠢠R( PHCK R@ PlCKP ԠXdUsed ܠ ~Free 4ܙܗ! —Ž◘" t! s! —Ž◘! t! s —Ž◘ 䠢t! \䠢s! \ ܙܗ —Ž◘# t# s" $ܙܗ"|  ܙܗ —Ž◘ t  s PܙܗPܙܗxܙܗF <xܙܗܙܗP—Ž◘ 𠢠tt ̠ts! ̠ؠ DataAvail" h` out: PopFifo" ࠢl\ out: Request!4 䠢p` out: WTable 0 ࠢ84out: PopFifo, LoadReply!h xout: LoadReply"( ĠFree*~DataAvail |𠢠Init# P𠢠Pop! P𠢠Wait! Px𠢠Write ( PtPopRp!, 0Reply" x̠ ~DataAvail#( t0Free*DataAvail p kkg Interpress810.0 mm xmin 10.0 mm ymin 205.9 mm xmax 103.9759 mm ymax0.4797136 the lineLength .mul 2.811678 .add topLeading 0.4797136 the lineLength .mul 2.811678 .add topIndent 1.405839 mm bottomLeading;;O##MMM MMMMI reference~~QzzQQQQYu&