Method and apparatus for assembling array and datapath macros

[0002] The present invention relates to a method and apparatus for assembling array and datapath macros for very large scale integrated (VLSI) semiconductor integrated circuits.

[0003] VLSI devices are typically formed as circuit chips having a chip image including multiple logic and memory circuits integrally formed on a single semiconductor substrate. The VLSI devices may be formed, for example, by a field effect transistor (FET) technique with conventional complementary metal oxide semiconductor (CMOS) technology. Advancement in VLSI technology allows system architects to pack more and more functions into a chip.

[0004] Predesigned functional macros or leaf cells may include many different integrated circuits of varying complexity. Leaf cells are comprised of hand generated schematics, symbols, and physicals or layouts. As used in the following description and claims, physicals and layouts are equivalent terms. For example leaf cells include simple inverter circuits, multiplexor (MUX) circuits, and empty pad or spacing circuits. Custom arrays are typically designed individually and may include thousands of leaf cells. This design approach creates serious problems in the layout and design of the overall chip image because the conventional design approach does not effectively facilitate placement and wiring of multiple leaf cells on the chip to provide a desired system.

[0005] Assembly of array and datapath macros is a tedious and error prone procedure, especially when attributes and/or properties for Layout Versus Schematic (LVS) are required. These macros typically have thousands of leaf cells that need to be assembled. Standard assembly procedures such a Place and Route programs are too random and complicated for the structured assembly required for some problems, such as memory array and datapath macros. Known array generation or grow programs are too constrained and rigid for general application.

[0006] A principal object of the present invention is to provide an improved method and apparatus for assembling array and datapath macros for very large scale integrated (VLSI) semiconductor integrated circuits. Other important objects of the present invention are to provide such method and apparatus for assembling array and datapath macros for very large scale integrated (VLSI) semiconductor integrated circuits substantially without negative effects and that overcome some disadvantages of prior art arrangements.

[0007] In brief, a method, computer program product and apparatus for assembling array and datapath macros are provided for very large scale integrated (VLSI) semiconductor integrated circuits. User selections are received for a hierarchical macro to be created. The user selections include a command list of multiple leaf cell build commands. X and Y placer pointers are initialized. A next build command is obtained from the command list and a command type is identified. Responsive to identifying a next leaf cell build command in a leaf cell group, a user selected schematic or physical view is identified. A corresponding leaf cell view is read for the user selected schematic or physical view. X and Y sizes are obtained for the leaf cell view. Then the leaf cell is oriented and placed. Next X and Y placer pointers are calculated and the sequential steps are repeated until a last leaf cell build command in the leaf cell group is found. Then the sequential steps return to obtain a next build command from the command list.

[0008] Connections to adjacent leaf cells are provided by abutting cells together. Port and pin connections from the periphery of the array of placed leaf cells are propagated to a next hierarchical level of the hierarchical macro being created.

[0009] The present invention together with the above and other objects and advantages may best be understood from the following detailed description of the preferred embodiments of the invention illustrated in the drawings, wherein:

[0010] FIG. 1 is a block diagram representation illustrating a computer system for implementing methods for creating a hierarchical macro in accordance with the preferred embodiment;

[0011] FIGS. 2, 3A, 3B, 3C, 3D, 3E, 3F, and 3G are flow charts illustrating exemplary sequential steps for creating a hierarchical macro in accordance with the preferred embodiment;

[0012] FIGS. 4A and 4B are respective schematic and physical exemplary flat tile representations created in accordance with the preferred embodiment;

[0013] FIGS. 5A and 5B are exemplary third level representations created in accordance with the preferred embodiment;

[0014] FIGS. 6A, 6B and 6C are exemplary second level representations created in accordance with the preferred embodiment;

[0015] FIGS. 7A, 7B and 7C are exemplary first level representations created in accordance with the preferred embodiment;

[0016] FIGS. 8A and 8B are respective schematic and physical exemplary zero level representations created in accordance with the preferred embodiment;

[0017] FIGS. 9, 10, 11, 12, 13, 14, 15 and 16 are exemplary demonstration representations created in accordance with the preferred embodiment; and

[0018] FIG. 17 is a block diagram illustrating a computer program product in accordance with the preferred embodiment.

[0019] Having reference now to the drawings, in FIG. 1, there is shown a computer or data processing system of the preferred embodiment generally designated by the reference character 100. As shown in FIG. 1, computer system 100 includes a central processor unit (CPU) 102, a read only memory 103, a random access memory or main memory 104, and a display adapter 106 coupled to a display 108. CPU 102 is connected to a user interface (UI) adapter 110 connected to a pointer device and keyboard 112. CPU 102 is connected to an input/output (IO) adapter 114 connected to a direct access storage device (DASD) 116 and a tape unit 118. CPU 102 is connected to a communications adapter 120 providing a communications function.

[0020] Various commercially available processors could be used for computer system 100, for example, an IBM personal computer or similar workstation can be used. An example of a specific computer system on which the invention may be implemented is the International Business Machines Corp. RS/6000 computer system. Central processor unit(s) 102 is suitably programmed to execute the flowcharts of FIGS. 2, 3A, 3B, 3C, 3D, 3E, 3F, and 3G for creating a hierarchical macro and for assembling array and datapath macros for very large scale integrated (VLSI) semiconductor integrated circuits in accordance with the preferred embodiment.

[0021] In accordance with features of the preferred embodiment, a hierarchical tiler (buildArray) is provided for assembling leaf cells in such a way so as to create bigger leaf cells for the next level of assembly. Leaf cells are tiled together with connections to adjacent cells being made by abutting cells together. Schematic and layout are specified by the same code. Ports and pins from the periphery of the matrix of leaf cells placed are propagated to the next level of the hierarchy in a manner compatible with conventional Layout Versus Schematic (LVS) processes. Tiler routines of the preferred embodiment are used to create a user selected architecture of the macro. A user enters selections or writes a configuration file for the class of macros to be tiled. The tiler routines illustrated and described with respect to FIGS. 2, 3A, 3B, 3C, 3D, 3E, 3F, and 3G, support the creation of schematics, layouts and symbols. All necessary properties and attributes for LVS checking are automatically added to the cell or hierarchical macro to be created. The tiler routine supports adding power and ground busing, and has provisions for altering pin/port placement.

[0022] Referring to FIG. 2, there are shown sequential steps for hierarchical tiler usage to create a hierarchical macro as indicated at a block 200. A popup form or menu is provided to query the user for a predefined library to build in, a top level cellname, and a cell or macro size to build as indicated at a block 202. Information from the user selections are passed to multiple calls to the tiler routine to build a hierarchical macro of the preferred embodiment as indicated at a block 204. Physical, schematic, and symbol representations of a leaf cell from the given library are passed to the tiler routine as indicated at a block 206. A finished macro is created as indicated at a block 208.

[0023] Referring to now FIGS. 3A, 3B, 3C, 3D, 3E, 3F, and 3G, exemplary sequential steps for creating a hierarchical macro in accordance with the preferred embodiment are shown starting at a block 300. As indicated at a block 302, a call to the buildArray routine of the preferred embodiment is made to pass a library name, a cell name, a view type, an edge to build from, a list of leaf cell build commands, and build directives as indicated at a block 302. Referring also to TABLE 1: BUILDARRAY below, arguments for the buildArray tiler routine are defined. As illustrated in TABLE 1, the buildArray hierarchical macro generator or grow tiler was written in the Cadence SKILL language. It should be understood that other languages could be used to implement methods of the preferred embodiment.

[0024] As illustrated in TABLE 1, build directives are used to override default values or behavior. The following TABLE 1 is included to show the necessary functionality required to solve the generalized problem of implementing a hierarchical tiler. Given a set of correctly composed leaf cells the invention will yield identically constructed physical and schematic views. Directives either apply to the building of schematic or physical views or to both.

[0025] Some directives are needed to solve the generalized problem of tiling non-uniform cell sizes with local, bussed and global pin structures and creating a valid leaf cell for the next level of hierarchy.

[0026] Additional directives are specialized for building the physical so LVS can run cleanly or so the macro will conform to a given set of chip requirements.

[0027] The hierarchical tiler creates a new cell in library t_libName, named t_cellName of view type, t_viewName as specified by the t_edgeToBuildFrom and 1_Specification. The methodology is the same for all view types. Leaf cells are “tiled” together to create an array of cells, with connectively to adjacent cells by abutment. Pins or ports that end up on the edge of the array are propagated up to the next level. Cells built with the hierarchical tiler meet the requirements for leaf cells at the next level.

[0028] All leaf cells must have symbols and physicals. The physical needs to have a rectangular box on level GROWBOX that defines the boundary that will abut to adjacent cells. Symbols also have a bounding box and have pins aligned to the bounding box that connect to adjacent cells by abutment.

[0029] buildArray(

[0030] t_libName

[0031] t_cellName

[0032] t_viewName

[0033] t_edgeToBuildFrom

[0034] l_Specification

[0035] [?am 4 lt_topm4opt]

[0036] [?apt l_portNames]

[0037] [?bx n_bump]

[0038] [?by n_bump]

[0039] [?do l_boxCoords]

[0040] [?fps l_pinAndSides2]

[0041] [?in l_pinNames]

[0042] [?io l_pinNames]

[0043] [?mg l_pinNames]

[0044] [?note l_noteSpec]

[0045] [?nps t_sides]

[0046] [?out l_pinNames]

[0047] [?pm l_mapList]

[0048] [?pvg t_powerEdges]

[0049] [?sb l_busSignals]

[0050] [?sp l_pinNames]

[0051] )

[0052] →l_boxCoords

[0053] The arguments of the build array macro are defined as follows:

[0054] t_libName specifies the Cadence library name for the new cell. Any cell referenced must also come from this library.

[0055] t_cellName specifies the name of the cell to be created.

[0056] t_viewName specifies the type of view to be created. Currently only “physical” and “schematic” are allowed.

[0057] t_edgeToBuildFrom specifies the first letter of the edge from which new cell will be built. The edge can be any of “t”, “b”, “l” or “r”, where “t” specifies top, “b” specifies bottom, “l” specifies left and “r” specifies right. When set to “b” than the second group of cells will be placed above the first group placed (being built from the bottom).

[0058] l_Specification specifies the number of rows and columns for a set of leaf cells, followed by the cell name and an optional orientation. The list should have the following format where each line is a “group” referenced above:

[0059] list(x_rows x_cols t_lCellName [t_orient][x_rows x_cols t_lCellName [t_orient]][x_dirReset][x_rows x_cols t_lCellName [t_orient]]. . . )

[0060] x_rows specifies the number of rows of cell t_lCellName to place. Rows run horizontally.

[0061] x_cols specifies the number of columns of cell t_lCellName to place. Columns run vertically.

[0062] t_lCellName specifies the name of the leaf cell to be placed.

[0063] t_orient specifies an orientation for a leaf cell. The orientation is one of the Cadence orientations (“R0” “R90” “R180” “R270” “MX” “MY” “MXR90” “MYR90”) or one of “YD” “XD” “XY”. The orientation “YD” flips every other cell in a column about its X axis. The orientation “XD” flips every other cell in a row about its Y axis. And the orientation “XY” does both, to give four orientations. If no orientation is given the default is “RO”.

[0064] x_dirReset is a negative integer that will reset the placer based on the value of t_edgeToBuildFrom. If t_edgeToBuildFrom is “b” than the placer will start placing the next set of cells from the bottom to the right of all the previous placements. If t_edgeToBuildFrom is “l” than the placer will start placing the next group of cells from the left above all the previous placements. Currently it can be any value less than zero.

[0065] l_portNames is a list of ports to have text added to the physical in the cell being grown. Any existing text on specified ports is discarded. This puts text on metal levels of metal one or above. Text will be placed over the first port shape encountered in the cell. To add text to all ports replace the list with a double quoted asterisk “*”.

[0066] lt_topm4opt is either a list or string specifying how to place top level metalization and to put in top level macro elements for use by the place and route tools. The allowable options are:

[0067] nil is a default value, does nothing.

[0068] t adds metal four metalization power and ground buses and adds vias to connect to metal three metalization rectangles. Snaps “CLK” and “clk” pins from M3PIN or M3PST to a 2×2 pin on level M4PIN. This rounds the size to fit a predefined 10 channel by 1 channel grid and adds the OUTLINE box and OUT_TEXT shapes as required.

[0069] list(a b c) is a list of floats denoting how to place the power bussing and vias. “a” is the offset from where the M4 bus would normally start (−0.45). “b” is the point at which power vias should start being added. “c” is the point at which power vias should stop being added. If any part of the bus is blocked by “b” or “c” then no vias are placed on that bus.

[0070] “nv” is the same as “t”, except vias between power and ground M4 and M3 are omitted.

[0071] float is a floating point number indicating how much to offset the M4 grid from the default value. Omits snapping “CLK” and “clk” pins, rounding size and adding OUTLINE and OUT_TEXT shapes.

[0072] t_pinName is a name of pin.

[0073] n_bump specifies how much the new symbol should be grown in the direction specified. The new symbols top or right side is stretched by n_bump times 0.125. n_bump can be positive or negative.

[0074] l_boxCorrds is a list specifying alternative “GROWBOX” coordinates for the physical view. The first pair is optional and designates the corner by the first cell placed. The second pair is the corner by the last cell placed. These are absolute coordinates, not offsets. The list should have the following form:

[0075] list([f_phyXcd f_phyYcd] f_phyXcd f_phyYcd)

[0076] f_phyXcd: Physical X-axis coordinate in microns.

[0077] f_phyYcd: Physical Y-axis coordinate in microns.

[0078] l_pinNames is a list of pin names. Has the following format:

[0079] list(t_pinName [t_pinName] . . . )

[0080] l_noteSpec is a list of specifications for a note on the new cells symbol. It has the following format:

[0081] list(t_nTxt [f_xCd [f_yCd [t_orient2 [f_height]]]])

[0082] t_nTxt is text of the note to be placed. May use “\n” to get more than one line.

[0083] f_xCd is the X-axis coordinate. Defaults to 0.375. (typically small, like 0.625)

[0084] f_yCd is the Y-axis coordinate. Defaults to 0.375. (typically small, like 0.875)

[0085] t_orient2 specifies an orientation for the text. The orientation must be one of the Cadence orientations (“RO” “R90” “R180” “R270” “MX” “MY” “MXR90” “MYR90”).

[0086] f_height specifies the height for the text. Defaults to 0.0625.

[0087] l_mapList is a list containing pairs of pin names to be mapped. List should be in the following form:

[0088] list(t_pinName t_newName [x_sides][t_pinName t_newName [x_sides]] . . . )

[0089] Alternatively, all pins can be mapped to upper or lower case by the following formats respectively:

[0090] list(“upper*”) or list(“lower*”)

[0091] t_newName is a new name for the pin. Same format as t_PinName.

[0092] t_powerEdges is a string (enclosed in double quotes) specifying the leaf cells in a grown cell from which to propagate the power pins. Leaf cells are specified by the edges they fall on. Power pins cannot be propagated from leaf cells not on an edge. Edges are specified the same as in t_sides where “t” specifies top, “b” specifies bottom, “l” specifies left and “r” specifies right. Spaces within the side specifier string mean OR and no space between side specifiers means AND. Only relevant to the physical view. To take power pins from the corner leaf cells “tl tr bl br”, would be specified. Defaults to “l t” which specifies power pins from leaf cells on the left or top edges will become power pins in the grown cell.

[0093] l_pinAndSides2 is a list specifying symbol pins and what side they should go on in the new symbol. The list should have the following format:

[0094] list(t_pinName t_sides [n_space] [t_pinName t_sides [n_space]] . . . )

[0095] t_sides is a string consisting of the first letter of the sides on a symbol. To specify all sides, t_sides would be “tblr”, where “t” specifies top, “b” specifies bottom, “l” specifies left and “r” specifies right. Has also been used to put a pin on one side multiple times such as “ttt”.

[0096] n_space specifies the number of pin spaces to leave between the pin t_pinName and the previous pin on the symbol. Defaults to 1.

[0097] l_busSignals specifies the names of buses that should be split across the schematic. Optionally, allows for buses to not be consecutive on the sides of the array of cells placed. This can be used to interleave a bus on alternate sides of a cell. The list should be in the following format:

[0098] list(t_pinName [x_1Index] [t_pinName [x_1Index]] . . . )

[0099] x_1Index specifies the first index on the first side encountered for signal t_pinName. The next t_pinName found on this side will be indexed 2 greater than the previous. Only “0” or “1” currently supported.

[0100] Options invoked by keyed arguments descriptions:

[0101] ?am4, add metal 4, specifics to add fourth level metal power and ground buses. Also adds top level macro requirements and snaps “CLK” pins. More details listed under lt_topm4opt above. Defaults to nil.

[0102] ?apt, add port text, specifies to add text to physical ports listed. Defaults to nil.

[0103] ?bx, bump x-direction, specifies to bump out the right side of the new symbol by n_bump amount.

[0104] ?by, bump y-direction, specifies to bump out the top side of the new symbol by n_bump amount.

[0105] ?do, l_boxCoords, defines physical outline box. Overrides upper right or both upper left coordinates for the “GROWBOX” shape that is put into the physical.

[0106] ?fps, forced pin sides, forces pins to be on specified sides of the new symbol as directed by l_pinAndSides2. Can also be used to accommodate custom pin spacings.

[0107] ?in, make input pin, forces pins listed by l_pinNames to become input pins in the cell being created.

[0108] ?io, make inputOutput pin, forces pins listed by l_pinNames to become inputOutput pins in the cell being created.

[0109] ?mg, make global pin, forces pins listed by l_pinNames to be global pins.

[0110] ?note, note, creates a note on the symbol of the cell being grown. Specified by the list l_noteSpec.

[0111] ?nps, no alphabetical pin sort, specifies to place the symbol pins, on sides specified by t_sides, by their location in the schematic, rather than by alphabetically sorting each side.

[0112] ?out, make output pin, forces pins listed by l_pinNames to become output pins in the cell being created.

[0113] ?pm, pin map, specifies to map pins from one name to another as specified in l_mapList. Do not map pins to names that are already on that side. The bits in the resultant bus may differ between the physical and the schematic. Swapping pin names on a given side is allowed.

[0114] ?pvg, port vdd and gnd sides, specifies to propagate vdd and gnd ports from cells on the edges specified.

[0115] ?sb, separate bus, specifies that pins listed in l_busSignals that appear on opposite sides of a cell will not be shorted. Instead the pin width will be expanded to create a bigger bus.

[0116] ?sp, snap port to grid, will snap rectangular shapes in physical ports listed in l_pinNames to the routing grid.

[0117] The value returned:

[0118] l_boxCoords returns a listing of the grown cells GROWBOX coordinates. This is only useful when growing physicals, but is still reported for schematics. If the grow is unsuccessful the culprit error will be reported.

[0119] Referring to FIG. 3A, the cell view, physical or schematic, is created and opened for writing as indicated at a block 304. X and Y placer pointers are initialized as indicated at a block 306. A next build command from the command list is obtained as indicated at a block 308. A command type is identified as indicated at a decision block 310. Responsive to an identified placer reset command (x_dirReset) at decision block 310, the X pointer is reset to the initial place and the Y pointer is adjusted as indicated at a block 312. This assumes that X is the major axis and Y is the minor axis; however, it should be understood that the methods of the preferred embodiment are not limited to this assumption. Then a next build command from the command list is obtained at block 308.

[0120] Responsive to an identified place leaf cell group command at decision block 310, a view type is identified as indicated at a decision block 314 in FIG. 3B. Responsive to an identified schematic view type, the leaf cell symbol view is read as indicated at a block 316. If the leaf cell view is not found as indicated at a decision block 318, then an error is returned and buildArray is exited as indicated at blocks 320 and 322. This ends the buildArray sequence as indicated at a block 322. If the leaf cell view is found, checking for an edge cell is performed as indicated at a decision block 324. When an edge cell is found, an edge marker is added to the edge cell instance as indicated at a block 326. The X and Y sizes of the bounding box in the symbol for the leaf or edge leaf cell are obtained as indicated at a block 328. Then the leaf cell is oriented and placed as indicated at a block 330.

[0121] Referring to FIG. 3C, when a physical cell view is identified at decision block 314, then following entry point E, the leaf cell physical view is read as indicated at a block 332. If the cell view is not found at a decision block 334, then the sequential operations return to block 320 in FIG. 3B following entry point F to end the buildArray routine. Checking for an edge leaf cell is performed as indicated at a decision block 336. Responsive to an identified edge leaf cell, the appropriate pins to propagate into the new cell are obtained, and pin names are mapped if required, as indicated at a block 338. The X and Y sizes of the “GROWBOX” shape are obtained as indicated at a block 340 and then the leaf cell is oriented and placed as indicated at a block 342.

[0122] Referring to FIG. 3D, the power and ground pins that need to be copied to the next level for LVS are tagged as indicated at a block 344. Pin locations are snapped to the router grid if necessary and the pins are saved for later processing as indicated at a block 346. The new X and Y pointers are calculated as indicated at a block 348. Checking whether this is the last leaf in this group is performed as indicated at a decision block 350. If not, then the sequential operations return to block 314 following entry point A in FIG. 3B. Otherwise when this is the last leaf in this group, then the sequential operations return to block 308 following entry point B in FIG. 3A.

[0123] Referring to FIG. 3E, when no more groups are identified at decision block 310 in FIG. 3A, then a view type is identified at decision block 352. Responsive to an identified physical view type, global power and ground busing are added as specified as indicated at a block 354. Then final numbering of bits in bussed pins and adjusting pin types as specified is provided as indicated at a block 356. The “GROWBOX” shape is added to define the size of the new leaf cell, and the physical view is saved and closed as indicated at a block 358. This completes the physical buildArray processing as indicated at a block 360.

[0124] Referring to FIG. 3F, responsive to an identified schematic view type at decision block 352 in FIG. 3E, then the unconnected pins are obtained from the symbols along the perimeter of the placed leaf cell instances as marked in block 326 in FIG. 3B by edge as indicated at a block 362. Assuming that all pins will get bussed, the bit position counters are reset to zero for all pins as indicated at a block 364. All the pins on an edge are obtained and the bits of a given name are renamed incrementally based on the counter value as indicated at a block 366. Checking whether all edges are done is provided as indicated at a decision block 368. If not, for pin names found on multiple sides, it is determined if the names should be equated or incremented from side to side as specified as indicated at a block 370. If determined that the names should be equated as indicated at a decision block 372, then the sequential operations return to block 364. Otherwise, if the names should not be equated, then for names to be incremented the bit position counter is not reset as indicated at a block 374. Then all the pins on an edge are obtained and the bits of a given name are renamed incrementally based on the counter value at block 366. When determined that all edges are done at decision block 368, then the sequential operations continue in FIG. 3G following entry point I.

[0125] Referring to FIG. 3G, pin types are adjusted as required as indicated at a block 376. The pins are condensed by removing bussing from single bit busses and combining bussed single pins into multiple bit buss pins as indicated at a block 378. The symbol view is created and opened as indicated at a block 380. Pins are moved to different sides and spacings are adjusted if required as indicated at a block 382. The bounding box for the new symbol is created and the size is adjusted if required as indicated at a block 384. A note is added to the symbol if specified as indicated at a block 386. An instance label, cell name label and library name label are added as indicated at a block 388. Then the symbol view is saved and closed as indicated at a block 390. This ends the buildArray sequence as indicated at a block 392.

[0126] The following TABLE 2 provides an exemplary general procedure for calling buildArray of the preferred embodiment, as shown in FIG. 2.

[0127] procedure (tutGen (@optional libN aName a Words aBits)

[0128] prog((archDef adBits argList mkSch mkLay gwN fName)

[0129] ;

[0130] archDef=“tutSpec”; name of file describing architecture

[0131] gwN=“Tutorial”; name at top of calling form

[0132] ;

[0133] ; load stuff

[0134] load(“/˜grow/skill/

[0135] tutSpec.il”)

[0136] ; define program name, get info and quit if form cancelled

[0137] fName=strcat9gwN “Grow System”)

[0138] if(genGetInputForm(fName)==nil then return ())

[0139] ; print time

[0140] printf(“++++++started at % s +++++++\n”

[0141] getCurrentTime())

[0142] ; do scematics?

[0143] if(mkSch then

[0144] argList=list(libN aName “schematic” aBits aWords adBits)

[0145] apply(getd(concat(archDef)) argList)

[0146] )

[0147] ; do layout?

[0148] if(mkLay then

[0149] argList=list(libN aName “physical” aBits aWords adBits)

[0150] apply(getd(concat(archDef)) argList)

[0151] )

[0152] ; print time

[0153] printf(“++++++finished at % s +++++++\n”

[0154] getCurrentTime())

[0155] return(t)

[0156] )

[0157] )

[0158] Having reference to TABLE 3 below and FIGS. 4-16, the operation of the hierarchical tiler (buildAarray) of the preferred embodiment may be understood.

[0159] procedure(tutSpec(1N aName vt bts wls adBt)

[0160] let((qW1 bt2)

[0161] ; quarter the word lines and twice the number of bits

[0162] qWl=wls/4

[0163] bt2=bts*2

[0164] ; build flat one here (Note the schematic flatTile in FIG. 4A and physical flatTile in FIG. 4B, which are simplified views for readability.)

[0165] buildArray(1N “flatTile” vt “1”

[0166] ; third level (Note the corresponding third level illustrations, level_3a and level_3b of FIGS. 5A and 5B, where multiple instances of a leaf cell, “leaf_A” are placed.)

[0167] buildArray(lN “level_—3a” vt “b” list(4 1 “leaf_A” “YD”)

[0168] ?pm list(“c” “bc0” “t” “bt0”))

[0169] buildArray(lN “level_—3b” vt “b” list(4 1 “leaf_A” “YD”)

[0170] ?pm list(“c” “bcl” “t” “btl”))

[0171] ; second levels (Note the corresponding second level illustrations, level_2a, level_2b and level_2c of FIGS. 6A, 6B and 6C.)

[0172] buildArray(lN “level_—2a” vt “1” list(1 1 “leaf_C” 4 1 “leaf_B” “YD”)

[0173] ?bx −3 ?fps list(“clk” “tb” 9 “dwl” “r” 4))

[0174] buildArray(lN “level_—2B” vt “1”

[0175] list(qwl 1 “level_—3a” qWl 1 “level_—3b” “MY”)

[0176] ?fps list(“bc0” “tb” −2 “wl” “lr” 3 “btl” “tb”7)

[0177] ?nps “tb” ?bx −3)

[0178] buildArray(lN “level_—2c” vt “1” list(wls 1 “leaf_E” “YD”))

[0179] ; first levels (Note the corresponding first level illustrations, level_1a, level_1b and level_1c of FIGS. 7A, 7B and 7C.)

[0180] buildArray(lN “level_—1a” vt “r”

[0181] list(1 1 “leaf_J” 1 1 “leaf_G” −1 qWl 1 “level_—2a”−1 1 1 “leaf_H” −1 1 2 “leaf_G”) ?pm list(“dwl” “wl”))

[0182] buildArray(lN “level_lb” vt “b”

[0183] list(1 1 “leaf_S” 1 1 “level_—2b” 1 1 “leaf_D” 1 1“leaf_F”)

[0184] ?sp list(“data”) ?apt list(“data”))

[0185] buildArray(lN “level_—1c” vt “b” list(1 1 “leaf_G” 1 1“level_—2c”

[0186] 2 1 “leaf_G”))

[0187] ; top (zero) level (Note the corresponding first level illustrations, schematic level_0 in FIG. 8A and physical level_0 in FIG. 8B.)

[0188] buildArray(lN “level_—0” vt “1”

[0189] list(1 1 “level_—1a” 1 bts “level_—1b” 1 1 “level_—1c”))

[0190] ; placer reset demo and pin mapping (Note the corresponding demol of FIG. 9; demo2 of FIG. 10; demo3 at C in FIGS. 3A & 3E of FIG. 11; demo3 at I in FIGS. 3F & 3G of FIG. 12; demo3 of FIG. 13; demo4 of FIG. 14; and demo5 of FIG. 15.)

[0191] demol shows the pin mapping directive. Note how on the right side of the schematic the pin “kl” coming out of leaf_X is renamed or mapped to the name “wl”.

[0192] buildArray(lN “demol” vt “1” list(2 3 “leaf_A” 2 3 “leaf_X”) ?pm list(“kl” “wl”))

[0193] demo2 shows the effects of a placer reset command. After the matrix of leaf_A's is finished placing, the placer pointer is reset back to the left side of the schematic. So in comparison to demol the matrix of leaf_X cells get placed above the matrix of leaf_A cells as opposed to the right of them. Note also the pin mappings on the bottom of pins “c” to “b” and “t” to “a”.

[0194] buildArray(lN “demo2” vt “1” list(2 3 “leaf_A” −1 2 3 “leaf_X”)

[0195] ?pm list(“c” “b” “t” “a”))

[0196] FIG. 11 shows the building of demo3 and corresponds to the state of the schematic at point C in FIGS. 3A and 3E. FIG. 12 shows the building of demo3 and corresponds to the state of the schematic at point I in FIGS. 3F and 3G. FIG. 13 shows the finished demo3 schematic.

[0197] buildArray(lN “demo3” vt “b” list(1 2 “leaf_S” 2 3 “leaf_A”))

[0198] ; adjusting pin type (Note demo4 in FIG. 14.)

[0199] Note how pins “c” and “t” on leaf_A are bi-directional but have been changed to input and output respectively in schematic demo4. (FIG. 14)

[0200] buildArray(lN “demo4” vt “1” list(3 2 “leaf_A” 3 2“leaf_A” “MX”)

[0201] ?in list(“c”) ?out list(“t”))

[0202] ; showing non-equated bus on multiple sides (bus “wl”) (Note demo5 in FIG. 15.)

[0203] Notice on the right side how pin “wl” is label wl<3>, wl<4>, wl<5> instead of wl<0>, wl<l>, wl<2> as it would be normally.

[0204] buildArray(lN “demo5” vt “1” list(3 2 “leaf_A” 3 2“leaf_A” “MX”

[0205] ?sb list(“wl”))

[0206] ; change symbol size (schematic is same as demo1) Note FIG. 16.

[0207] buildArray(lN “demo1A” vt “1” list(2 3 “leaf_A” 2 3“leaf_X”)

[0208] ?pm list(“wl” “kl”) ?bx −2 ?by 3)

[0209] ; do different sort on top side, move “kl” pin to top and bottom sides

[0210] buildArray(lN “demo1B” vt “1” list(2 3 “leaf_A” 2 3“leaf_X”)

[0211] ?pm list(“wl” “kl”) ?nps “t” ?fps list(“k” “tb”))

[0212] ; put space between pins “a” “b” and add note to symbol

[0213] buildArray(lN “demo1C” vt “1” list(2 3 “leaf_A” 2 3“leaf_X”)

[0214] ?pm list(“wl” “kl”) ?fps list(“b” “tb” 2)

[0215] ?note list(“sym Note”))

[0216] ; finish up

[0217] printf(“>> Generator done creating % ss for % s\n” vt aName)

[0218] )

[0219] )

[0220] Referring now to FIG. 17, an article of manufacture or a computer program product 1700 of the invention is illustrated. The computer program product 1700 includes a recording medium 1702, such as, a floppy disk, a high capacity read only memory in the form of an optically read compact disk or CD-ROM, a tape, a transmission type media such as a digital or analog communications link, or a similar computer program product. Recording medium 1702 stores program means 1704, 1706, 1708, 1710 on the medium 1702 for carrying out the methods for assembling array and datapath macros of the preferred embodiment in the system 100 of FIG. 1.

[0221] A sequence of program instructions or a logical assembly of one or more interrelated modules defined by the recorded program means 1704, 1706, 1708, 1710, direct the computer system 100 for assembling array and datapath macros of the preferred embodiment.

[0222] While the present invention has been described with reference to the details of the embodiments of the invention shown in the drawing, these details are not intended to limit the scope of the invention as claimed in the appended claims.