United States Patent [19]
`Grant et al.
`
`US005971595A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,971,595
`Oct. 26, 1999
`
`[54] METHOD FOR LINKING A HARDWARE
`DESCRIPTION TO AN IC LAYOUT
`
`Synopsys, Inc., DesignWare Technical Bulletin, Jan. 1996.
`no pg #s.
`
`[75] Inventors: Douglas M. Grant, Edinburgh; John P.
`Gray, East Lothian, both of United
`Kingdom
`
`[73] Assignee: XilinX, Inc., San Jose, Calif.
`
`[21] Appl. No.1 08/840,341
`[22] Filed:
`Apr. 28, 1997
`
`Int. Cl.6 .................................................... .. G06F 17/50
`[51]
`[52] US. Cl. ................ ..
`364/488; 364/489
`[58] Field of Search ................................... .. 364/488, 489,
`364/490, 491, 578
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,469,003 11/1995 Kean ....................................... .. 326/39
`5,724,250
`3/1998 KerZman et al.
`364/488
`5,726,903
`3/1998 KerZman et al.
`364/489
`5,805,861
`9/1998 Gilbert et a1.
`.. 395/500
`5,850,348 12/1998 Berman ..............................
`364/488
`
`OTHER PUBLICATIONS
`
`Xilinx, Inc., “The Programmable Logic Data Book,” 1996,
`available Xilinx, Inc., 2100 Logic Drive, San Jose, Califor
`nia 95124. no pg #s.
`
`Synopsys, Inc., DesignWare Technical Bulletin, Apr. 1996.
`no pg #s.
`
`Synopsys, Inc., DesignWare Technical Bulletin, Jul. 1996.
`no pg #s.
`
`Synopsys, Inc., DesignWare Technical Bulletin, Oct. 1996.
`no pg #s.
`
`Synopsys, Inc., DesignWare Technical Bulletin, Jan. 1997.
`no pg #s.
`
`Primary Examiner—Kevin J. Teska
`Assistant Examiner—Leigh Marie Garbowski
`Attorney, Agent, or Firm—Edel M. Young
`
`[57]
`
`ABSTRACT
`
`A method and system for converting a hardware description
`language ?le which includes parameteriZed attributes into a
`product speci?cation with hardware properties generated
`based on the parameters used to create/instantiate cells
`de?ned by the hardware description language ?le. The
`hardware properties are used by design tools to perform such
`functions as pre-place cells, route cells, and control the
`con?guration of cells.
`
`19 Claims, 11 Drawing Sheets
`
`405
`Hardware
`Description
`with
`Parameter-
`.
`Zedb
`
`ttri utes
`
`Parameters
`
`400
`
`415
`
`410
`
`425
`
`\ Hardware \ WEigIOit
`’ Compiler ’
`.
`Propertles
`\
`
`I
`
`EDIF
`\ with
`Post-
`Processor ’ Evaluated
`-
`Properties
`
`420
`
`Place
`Rand
`(Jute
`Tool
`
`430
`
`Other
`Tools
`
`405
`Hardware
`Description
`with
`Parameter-
`ized
`Attributes
`
`Parameters
`
`400'
`Hardware
`Compiler
`that uses
`Parameter-
`ized
`Attributes
`
`425
`
`EDIE
`with
`Evaluated
`Properties
`
`XILINX, EX. 1016
`Page 1 of 17
`
`

`
`U.S. Patent
`
`011.26, 1999
`
`Sheet 1 0f 11
`
`5,971,595
`
`o2
`
`XILINX, EX. 1016
`Page 2 of 17
`
`

`
`XILINX, EX. 1016
`Page 3 of 17
`
`

`
`XILINX, EX. 1016
`Page 4 of 17
`
`

`
`XILINX, EX. 1016
`Page 5 of 17
`
`

`
`XILINX, EX. 1016
`Page 6 of 17
`
`

`
`U.S. Patent
`
`Oct.26, 1999
`
`Sheet 6 0f 11
`
`5,971,595
`
`— — Amibutes for place and route control
`
`—— Ona6216,with64by64oe11s. ..
`—— Therecanbe3rowsof10tapsand0ne0f9ifn_bits<11
`——
`1 r0w0f10taps andoneof9ifn_bits<27
`——
`lrowof 9tapsifn_bits<58
`- —
`lstmw
`2ndr0w
`— —
`lstrow
`2ndr0w
`- —
`3rdrow
`4throw
`
`4thr0w
`3rd10w
`Watchoutforoontmller!
`J 1C!
`
`justincase!
`
`BEGIN
`snnl : snnll GENERIC MAP (n -> n, n_taps => n_taps, c0eff=> coe?)
`PORT MAP(din =>din,clk=> clk,
`clra => cha, chb => clxb, bufselbar => bufselbar,
`dout => dout, addin => addin, sumout -> sumout,
`bufse1bardel=> bufselbardel);
`
`END stluctural;
`
`CONFIGURATION cfg_s1ml 1p_s1I OF 31ml 1p I3
`FOR structural
`END FOR;
`END cfg_srmllp_str,
`
`1315
`
`FIG. 3D
`
`XILINX, EX. 1016
`Page 7 of 17
`
`

`
`XILINX, EX. 1016
`Page 8 of 17
`
`

`
`U.S. Patent
`
`Oct. 26, 1999
`
`Sheet 8 0f 11
`
`5,971,595
`
`— — — Common text in normal typeface.
`— — — Text speci?c to post-conversion in bold
`
`(cell snnll_n8_n_taps5_coe?33 (cellType GENERIC)
`(property RTMAX (string "X1Yl") (owner “XACT6000"))
`(property BBOX (string "W1DE") (owner "XACT6000"))
`(view Netlist_representation (viewType NETLIST)
`(interface (port din (direction INPUT)) (port clk (direction INPUT))
`(port clra (direction INPUT)) (port clrb (direction INPUT))
`(port bufselbar (direction INPUT)) (port dout (direction OUTPUT))
`(port addin (direction INPUT)) (port sumout (direction OUTPUT))
`(port bufselbardel (direction OUTPUT))
`
`(contents
`( instance add
`(viewRef Net1ist_representation (cellRef seradd))
`(property RLOC (string "X4Y9")
`(owner "XACT6000"))
`
`)
`
`( instance bdel
`(viewRef Netlist_representation (cellRef FDC (libraryRef xc6000)))
`(property RLOC (string "X5Y9") (owner "XACT6000"))
`
`( instance ff
`(viewRef Netlist_representation (cellRef fdcp_place0_n_bits0))
`(property FLATTEN (string "") (owner "XACT60()()"))
`
`— — — instances ff_1 through ff_l0
`( instance ff_11
`(viewRef Netlist__representation (cellRef fdcp_place11_n_bits8))
`(property FLATTEN (string "") (owner "XACT6000"))
`
`( instance mul
`(viewRef Net1ist_representation (cellRef mult_n_bits8_coeff33))
`(property RLOC (string "X1Y1") (owner "XACT6000"))
`
`— — - net connections for signals "addin", "clk", "sumout", "z_1_"
`- - — through "z_1 1_", "bufselbardel", "bufselbar", "feedbackl ",
`____ "bout", "Cl-ta", "din",
`"ell-b",
`
`{500
`
`FIG. 5A
`
`XILINX, EX. 1016
`Page 9 of 17
`
`

`
`U.S. Patent
`
`Oct. 26, 1999
`
`Sheet 9 0f 11
`
`5,971,595
`
`— — — Placement (p=3) for an instance of the generic S-tap, 33 coef?cient snnl,
`— — — disclosed above, now that attributes have been added
`
`(cell sm1ll_n8_n_taps5__coeff33_p3 (cellType GENERIC)
`(view Netlist_representation (viewType NETLIST)
`(interface (port din (direction INPUT)) (port clk (direction INPUT))
`(port clra (direction H\TPUT)) (port clrb (direction INPUT))
`(port bufselbar (direction INPUT)) (port dout (direction OUTPUT))
`(port addin (direction INPUT)) (port sumout (direction OUTPUT))
`(port bufselbardel (direction OUTPUT))
`
`)
`(contents
`( instance srml
`(vieWRef Netlist_representation (cellRef
`srml 1_n8_n_taps5_coeff33))
`(property RLOC (string "X12YO") (owner "XACT6000"))
`
`— — — net connections for signals "din", "clk", "bufselbardel"
`— — — "bufselbar", "feedbackl ", "sumout", "clra", "dout",
`— — — "addin" and "clrb"
`
`)
`
`)
`
`)
`
`‘505
`
`FIG. 5B
`
`XILINX, EX. 1016
`Page 10 of 17
`
`

`
`U.S. Patent
`
`Oct. 26, 1999
`
`Sheet 10 0f 11
`
`5,971,595
`
`— — — SRML - 5 taps, 44 coefficients, no tap placement infonnation
`(Cell snnll_n8_n_taps5_coeff44 (cellType GENERIC)
`(property RTMAX (string "X1Y1") (owner "XACT6000"))
`(property BBOX (string "WIDE") (owner "XACT6000"))
`(view Net1ist_representation (viewType NETLIST)
`(interface (port din (direction INPUT)) (port clk (direction INPUT))
`(port clra (direction INPU'D) (port clrb (direction INPUT))
`(port bufselbar (direction INPUT)) (port dout (direction OUTPUT»
`(port addin (direction INPUT)) (port sumout (direction OUTPUT))
`(port bufselbardel (direction OUTPU'D)
`
`)
`(contents
`( instance add
`(viewRef Netlist_representation (cellRef seradd))
`(property RLOC (string "X4Y9") (owner "XACT6000"))
`
`( instance bdel
`(viewRef Net1ist_representation (cellRef FDC (libraryRef xc6000)))
`(property RLOC (string "X5Y9") (owner "XACT6000"))
`
`( instance ff
`(viewRef Netlist_representation (cellRef fdcp_p1ace0_n_bits8))
`(property FLATI‘EN (string "") (owner "XACT6000"))
`
`— — - instances ff_1 through ff_10
`( instance ff_11
`(viewRef Netlist_representation (cellRef fdcp_p1acel1_n_bits8))
`(property FLATTEN (string "") (owner "XACT6000"))
`
`( instance mul
`(viewRef Netlist_representation (cellRef mult_n_bits8_coeff44))
`(property RLOC (string "X1Y1") (owner "XACT6000"))
`
`— — - net connections for signals "addin", "clk", "sumout", "z_l_"
`— — — through "z_1 1_", "bufselbardel", "bufselbar", "feedbackl ",
`__ _ "bout", HClra", "din",
`HclrbH,
`
`{51°
`
`FIG. 5c
`
`XILINX, EX. 1016
`Page 11 of 17
`
`

`
`U.S. Patent
`
`Oct. 26, 1999
`
`Sheet 11 0f 11
`
`5,971,595
`
`— - — SRML with a tap at position (p=4) for a generic S-tap,
`- - — 44 coef?cient snnl de?ned above
`
`(Cell snnllp_n8_n_taps5_coeff44_p4 (cellType GENERIC)
`(View Netlist_representation (viewType NETLIST)
`(interface (port din (direction INPUT)) (port clk (direction INPUT))
`(port clra (direction INPUT)) (port clrb (direction INPUT))
`(port bufselbar (direction INPUT)) (port dout (direction OUTPUT))
`(port addin (direction INPUT)) (port sumout (direction OUTPUT))
`(port bufselbardel (direction OUTPUT))
`
`)
`(contents
`( instance srml
`(viewRef Netlist_representation (cellRef srml 1_n8_n_taps5_coeff44))
`(property RLOC (string "X18Y0") (owner "XACT6000"))
`
`— — — net connections for signals: "din", "clk", "bufselbar"
`—— —"sunout", "bufselbardel", "clra", "dout", "addin" and
`
`_ _ _ llclrbll
`
`)
`
`)
`
`)
`
`‘515
`
`FIG. 5D
`
`XILINX, EX. 1016
`Page 12 of 17
`
`

`
`1
`METHOD FOR LINKING A HARDWARE
`DESCRIPTION TO AN IC LAYOUT
`
`TECHNICAL FIELD
`
`The present invention relates to the ?eld of hardware
`description programming languages and the conversion of
`designs from a hardWare description to an integrated circuit
`layout.
`
`BACKGROUND OF THE INVENTION
`
`10
`
`Xilinx, Inc. the assignee of the present application, manu
`factures logic devices. Although some devices are mask
`programmable, many devices manufactured by Xilinx are
`?eld programmable logic devices. A programmable logic
`device is an integrated circuit chip Which includes a plurality
`of programmable input/output pads, a plurality of con?g
`urable logic elements, and a programmable interconnect for
`interconnecting the plurality of logic elements. Further, each
`logic element includes a logic block Which implements a
`logic function of the n inputs to the logic block according to
`hoW the logic element has been con?gured. Logic functions
`may use all n inputs to the logic block or may use only a
`subset thereof. A feW of the possible logic functions that a
`logic element can be con?gured to implement are: AND,
`OR, XOR, NAND, NOR, NXOR and mixed combinations
`of these functions. The implementation and operation of
`logic devices made by Xilinx are described in “The Pro
`grammable Logic Data Book,” pages 4-1 to 4-372, copyright
`1996 by Xilinx, available from Xilinx, Inc., 2100 Logic
`Drive, San Jose, Calif. 95124. The contents of “The Pro
`grammable Logic Data Book” are incorporated herein by
`reference.
`As the density of logic devices increases, the complexity
`of possible designs that can be incorporated into a single
`device increases. By reusing existing designs from previous
`projects, designers are freed from having to “recreate the
`Wheel”, and are better able to concentrate on the neW aspects
`of their designs. Designers have created libraries of designs
`Which represent previously tested designs, but these knoWn
`libraries Were not automatically extendable to designs using
`a larger number of bits or designs With slightly different
`parameters. For example, knoWn libraries included designs
`for each bit siZe of a particular type of component, e.g.,
`adders from a single-bit adder to a thirty-tWo-bit adder. By
`including each of these designs separately, library siZes greW
`quickly. In static library con?gurations, despite the large
`library siZes, extending a library is aWkWard and involves
`using a library component along With design speci?c logic
`to create a custom piece, e.g., combining a single-bit adder
`With a thirty-tWo-bit adder to create a thirty-three-bit adder.
`This restrictive design methodology Which creates large
`libraries and semi-rigid designs is not easily adaptable to an
`increasingly dynamic design schedule Which requires faster
`turn-around times for designs. LikeWise, libraries Which
`include statically pre-routed components are not adaptable
`to changes in architecture or to a variation in shape of the
`unused components of an architecture.
`To help decrease design time, designers have turned to
`tWo important technologies: 1) programmable gate arrays
`and 2) hardWare description languages. Gone are the days of
`hardWired discrete components being used to implement
`circuits for printed circuit board-level designs. Designers
`noW use compact, highly integrated, VLSI chips to conserve
`board space and system poWer. HoWever, fabricating an
`ASIC also requires an increase in lead time to fabricate and
`test the ASIC to be used in a design. Xilinx sells a family of
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,971,595
`
`2
`?eld programmable gate arrays (FPGAs) that can be quickly
`programmed and reprogrammed by a designer to implement
`a particular logic function. Using FPGA-based boards,
`changes can be made to a design by simply reprogramming
`the appropriate FPGA, Without even removing the FPGA
`from its socket. This technique reduces design time.
`The use of hardWare description languages also reduces
`design time. Although schematic capture Was previously
`used to develop designs, hardWare description languages
`such as VHDL are noW capable of generating designs from
`logical descriptions of the functions Which are to be per
`formed by the circuit being built. It is believed that this more
`generaliZed and higher level approach alloWs designs to be
`created more compactly and to be analyZed more quickly. A
`hardWare description language is then compiled like a
`high-level programming language to produce a design ?le
`Which implements the speci?cs of the design. This design
`?le is either an intermediate design ?le Which is architecture
`independent, or it is a product speci?c design ?le, e.g., a
`design ?le speci?c to a gate array architecture or a FPGA
`architecture. When generating a product speci?c design ?le,
`the design compiler determines routes betWeen independent
`units in the design, and as the number of independently
`routed units increases, so does the time required to generate
`a neW or modi?ed design. Synopsys, Inc. of 700 East
`Middle?eld Rd. in Mountain VieW, Calif., provides a suite of
`tools Which support hardWare description languages. Tools
`produced by Synopsys, Inc. include DesignWare and FPGA
`Express. Details on DesignWare can be found in the January
`1996, April 1996, July 1996 and October 1996 editions of
`the DesignWare Technical Bulletin. The contents of each of
`these Technical bulletins is incorporated herein by reference.
`However, a signi?cant limitation of DesignWare is that it
`does not support user-speci?c, parameteriZed attributes
`Which can be converted to properties of instances of com
`ponents.
`
`SUMMARY OF THE INVENTION
`
`Accordingly, the present invention bene?cially over
`comes at least one of the above-identi?ed de?ciencies in
`knoWn systems. The present invention provides an improved
`method and system for linking a hardWare description to an
`integrated circuit layout.
`Brie?y, the preferred embodiment of the present invention
`is a method for operating a microprocessor, Where the
`method ultimately is embodied in code for controlling the
`microprocessor When the code is executed by the micropro
`cessor. The inventive method utiliZes parameteriZed
`attributes in a hardWare description language, a language
`compiler, and a post-processor for processing the output of
`the language compiler.
`According to the present invention, a hardWare design
`system is made more ef?cient and feature-rich by utiliZing
`parameteriZed attributes to augment high-level descriptions
`of logic functions. The parameteriZed attributes control
`pre-placement of inter-related logic components, an order of
`routing, aligning and grouping constraints, and the relative
`positions of components to each other. The attributes also
`include interconnection constraints such as a maximum
`length for Wires/buses Which interconnect components and
`Whether or not designs are to be compacted. When a
`component is generated from the library, parameters are
`speci?ed Which create a ?le representing an instance of the
`component, but the parameteriZed attributes are not added to
`the ?le. The ?le representing the instance is then post
`processed to add properties to the ?le based on the attributes
`
`XILINX, EX. 1016
`Page 13 of 17
`
`

`
`3
`stored in the original hardware description of the library. The
`post-processed ?le can then be used by back-end tools to
`pre-place or route the components based on their respective
`properties.
`Further, by implementing libraries of designs using the
`high-level, attribute-based descriptions used by the present
`invention, extendable libraries can be built Which accom
`modate variable parameters, e.g., Widths of adders.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`10
`
`The above and further aspects of the present invention
`Will become more clear to those skilled in the art in vieW of
`the best presently knoWn mode of carrying out the invention
`and the industrial applicability of the preferred embodiment
`as described herein and as illustrated in the several ?gures,
`Wherein:
`FIG. 1 is a schematic illustration of a computer system for
`performing the method of the present invention;
`FIG. 2 is a schematic illustration of an exemplary inte
`grated circuit architecture onto Which a hardWare description
`is mapped;
`FIGS. 3A to 3D are hardWare description listings of
`components Which are to be mapped onto the integrated
`circuit architecture of FIG. 2;
`FIGS. 4A and 4B are block diagrams of the interrelation
`ship betWeen tools used by the method of the invention;
`FIGS. 5A to 5D are portions of an EDIF generated from
`the hardWare description listings of FIGS. 3A to 3D after the
`listings have been processed according to the method of the
`present invention; and
`FIG. 6 is a schematic illustration of a mapping of high
`level components onto logic elements, Wherein the logic
`elements are assigned in a serpentine order.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`Referring noW to the draWings, Wherein like reference
`numerals designate identical or corresponding parts
`throughout the several vieWs, FIG. 1 is a schematic illus
`tration of a computer system for linking a hardWare descrip
`tion to an integrated circuit layout. A computer 100 imple
`ments the method of the present invention, Wherein the
`computer housing 102 houses a motherboard 104 Which
`contains a CPU 106, memory 108 (e.g., DRAM, ROM,
`EPROM, EEPROM, SRAM and Flash RAM), and other
`optional special purpose logic devices (e.g., ASICs) or
`con?gurable logic devices (e.g., GAL and reprogrammable
`FPGA). The computer 100 also includes plural input
`devices, (e.g., a keyboard 122 and mouse 124), and a display
`card 110 for controlling monitor 120. In addition, the
`computer system 100 further includes a ?oppy disk drive
`114; other removable media devices (e. g., compact disc 119,
`tape, and removable magneto-optical media (not shoWn));
`and a hard disk 112, or other ?xed, high density media
`drives, connected using an appropriate device bus (e.g., a
`SCSI bus or an Enhanced IDE bus). Also connected to the
`same device bus or another device bus, the computer 100
`may additionally include a compact disc reader 118, a
`compact disc reader/Writer unit (not shoWn) or a compact
`disc jukebox (not shoWn). Although compact disc 119 is
`shoWn in a CD caddy, the compact disc 119 can be inserted
`directly into CD-ROM drives Which do not require caddies.
`In addition, a printer (not shoWn) also provides printed
`listings of processed design ?les. The computer 100 may
`also control a programmer to program an external device
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,971,595
`
`4
`such as a programmable gate array. In some programmable
`gate array architectures, simply Writing to a con?guration
`memory in the programmable gate array is suf?cient to
`program it.
`As stated above, the system includes at least one computer
`readable medium. Examples of computer readable media are
`compact discs 119, hard disks 112, ?oppy disks, tape,
`magneto-optical disks, PROMs (EPROM, EEPROM, Flash
`EPROM), DRAM, SRAM, etc. Stored on any one or on a
`combination of the computer readable media, the present
`invention includes softWare for controlling both the hard
`Ware of the computer 100 and for enabling the computer 100
`to interact With a human user. Such softWare may include,
`but is not limited to, device drivers, operating systems and
`user applications, such as development tools. Such computer
`readable media further includes the computer program prod
`uct of the present invention for linking a hardWare descrip
`tion to an integrated circuit layout.
`FIG. 2 shoWs an exemplary integrated circuit architecture
`200 onto Which a hardWare description is to be mapped. For
`convenience and for illustrative purposes only, the descrip
`tion Will be given in terms of the XC6200 Family architec
`ture of FPGAs made by assignee, Xilinx, Inc. HoWever, the
`same design process is applicable to ASICs using standard
`iZed cells, to PALs, to GALs, etc. In the Xilinx XC6216
`device, there is a 64x64 hierarchical array of logic elements
`205. The loWest-level of the hierarchical array includes
`individual logic elements 205 With bidirectional connections
`210 to each neighboring logic unit. The bidirectional con
`nection 210 in the XC6216 is a pair of uni-direction Wires,
`but in an alternative embodiment, a single Wire With bidi
`rectional control is used. Groups of 4x4 logic element
`groups are arranged to form a second-level of the hierarchy,
`and 4 roWs and 4 columns of the 4x4 logic element groups
`de?ne the highest level of the hierarchy. The logic elements
`205 are coupled to external pins 215 through con?gurable
`I/O controllers 220. Such a structure is further discussed by
`Kean in US. Pat. No. 5,469,003, incorporated herein by
`reference.
`As an example of hoW a design can be mapped onto an
`architecture such as the architecture of FIG. 2, FIGS. 3A to
`3D shoW a series of VHDL statements 300, 305, 310 and
`315, respectively, from a library that describe part of an
`implementation of a ?nite impulse response (FIR) ?lter.
`Unlike knoWn libraries, the embodiment shoWn in FIG. 3A
`is not speci?c to a particular data siZe, number of taps or
`coef?cients. Rather, the implementation is described gener
`ally using variables to specify the data siZe, number of taps
`and coef?cients. To support this general parameteriZed
`approach, the de?nition includes a library entitled “XACT”
`and uses attributes.
`The de?nition of the “srmll” block of the FIR ?lter
`speci?es tWo constant attributes to be used by the present
`invention When creating each “srmll” block. These attributes
`are “bbox” and “rtmax” Which, respectively, control the
`aspect ratio (bounding box) and the maximum routing length
`used in the X and Y directions Within that block. Valid values
`for “bbox” are: WIDE, TALL, SQUARE or #Y#, e.g.,
`X12Y14. In FIG. 3A, the bounding box surrounding each
`instance of a “srmll” block is constrained to be “WIDE”. The
`general attribute “rtmax” is of the form X#Y#. HoWever, in
`FIG. 3A, the “srmll” blocks are constrained to use intercon
`nects Within the block Which are at most one unit long.
`Additional parameters used by the example are shoWn in
`FIG. 3B as part of the architectural de?nition of the “srmll”
`block de?ned in FIG. 3A. The ?rst attribute of FIG. 3B
`
`XILINX, EX. 1016
`Page 14 of 17
`
`

`
`5,971,595
`
`5
`indicates that the multiplier slice named “mul” is placed at
`a relative location compared to other elements in the block.
`The multiplier slice is placed at “X1Y1”, i.e., offset one unit
`in both the horiZontal and vertical directions from the origin
`of the block. The placement of the multiplier slice is
`independent of the parameters used to create the instance of
`the “srmll” block. On the contrary, although the adder is
`placed relatively to the other components (including the
`multiplier slice), the relative location of the adder in the
`vertical direction is dependent on the data siZe of the FIR
`?lter, i.e., based on the number of bits of data ?ltered by the
`FIR ?lter. Similarly, the “bdel” unit is offset by one unit
`horiZontally from the adder. It is also valid to specify a
`relative position based on a particular PORT by using the
`syntax “PORTJBTLRT’, Where one of B, T, L, and R is
`chosen to folloW “PORTi” depending on Whether the
`de?nition is based on the bottom, top, left or right,
`respectively, of the port. The last attribute of FIG. 3B is the
`“?atten” attribute associated With the ?ip-?ops generated in
`the gizGENERATE statement. This speci?es that the ?ip
`?ops are to be ?attened, i.e., grouped together by superim
`posing their layouts; to remove unused logic elements in a
`“srmll” block.
`FIGS. 3C and 3D shoW hoW the general de?nition of
`FIGS. 3A and 3B can be extended With further parameter
`iZed information using a tap placement parameter, p. Rather
`than having to build into the library the location of each
`possible tap for each FIR ?lter, the position of the taps can
`be expressed as a function of the desired tap position. It Was
`determined empirically that in the present design a “srmll”
`block is six logic elements Wide on a XC6216. Given that the
`XC6216 is 64 logic elements Wide, there can be at most 10
`“srmll” blocks across a band of the logic array. Depending
`on the number of data bits to be ?ltered by the FIR ?lter, a
`varying number of bands of “srmll” blocks can be placed in
`the array. According to the example of FIG. 3D, a designer
`has decided for his/her design that the FIR ?lter is not the
`only circuit to be placed in the XC6216, so the designer has
`chosen the “rloc” equation to avoid the corner corresponding
`to the highest numbered roW and the loWest numbered
`column. Also, in light of additional routing concerns, the
`“rloc” attribute of the tap of the FIR ?lter constrains the tap
`to be positioned only at roWs 0, 16, 32 and 48.
`FIG. 4A shoWs the relationship betWeen tools used at
`various stages in the design method of the present invention.
`A hardWare description ?le 405 that includes parameteriZed
`attributes, such as a VHDL ?le corresponding to FIG. 3A, is
`read by a hardWare compiler 400, such as DesignWare by
`Synopsys. The hardWare compiler 400 generates an EDIF
`415 from the hardWare description ?le 405, but the EDIF
`415 does not contain any properties corresponding to param
`eteriZed attributes. The EDIF 415 does, hoWever, include
`cell de?nitions for each of the cells generated by the
`hardWare compiler 400.
`The present invention then post-processes the cell
`instances generated by the hardWare compiler 400 Which are
`stored in the EDIF 415. The post-processor can be either a
`compiled or an interpreted program, but in the preferred
`embodiment the post-processor is implemented as a Perl
`script executed by a Perl interpreter. Perl is advantageous
`because of its compact but poWerful pattern matching func
`tions. To post-process the EDIF 415, the post-processor 410
`must also read the attributes from the original hardWare
`description ?le 405. The post-processor 410 parses and
`identi?es the attributes in the hardWare description ?le 405
`and maintains scope information on Which attributes affect
`Which types of cell instances. The post-processor 410 then
`
`5
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`reads the EDIF 415 and searches for cell instances Which
`have attributes to be converted into properties. To determine
`Which cell instances require attributes to be converted, the
`post-processor parses the grammar of the declarations in the
`hardWare description ?le 405 in the same Way that a C++
`compiler Would parse a C++ computer programming lan
`guage program. For ease of understanding, each ENTITY
`can be thought of as an object (e.g., a C++ object) With a set
`of interfaces. The simplest objects are de?ned ?rst and act as
`a basis for more complex objects. In FIG. 3A, the interface
`de?nition of a “srmll” block is given, including the attributes
`“bbox” and “rtmax”. Based on the interface, the implemen
`tation (i.e., architecture) of a “srmll” block is given. This
`implementation includes de?nitions for additional building
`blocks including “mult”, “seradd”, “fdc”, and “fdcp”, and
`further includes signals/connections betWeen the building
`blocks. The signals, shoWn in FIG. 3B, include “bout”, “Z”,
`“feedback1”, and “feedback2”. The post-processor reads in
`the “rloc” attributes for cells “mul”, “add”, and “bdel” and
`for cells generated using generator variable “gi”. As a
`C++compiler Would track class de?nitions and
`implementations, the post-processor 410 tracks the interface
`and implementation of each cell. Part of the information
`tracked is the scope of each variable so that the post
`processor 415 may determine the scope of an attribute When
`it is applied. From the de?nition of a “srmll” block, FIG. 3C
`de?nes an interface and an implementation of a “srmllp”
`block Which includes a “srmll” block de?ned in FIG. 3A, but
`also includes the “rloc” placement information de?ned in
`FIG. 3D.
`After the interface and implementation information has
`been analyZed by the post-processor 410, the post-processor
`then analyZes the EDIF 415 to determine Which cell
`instances need to have properties added based on the param
`eteriZed attributes of the hardWare description ?le 405. The
`post-processor 410 does this by looking for root names of
`cell instances for Which it has found attributes. The suf?x to
`the name indicates the parameters used When instantiating
`the cell instance. For example, in code 500 of FIG. 5A, the
`cell named “srmllin8initaps5icoeff33” is an instance of
`a “srmll” block that Was instantiated With n=8, nitaps=5
`and coeff=33. Generally this syntax can be described as:
`rooti?rstvar#isecondvar#, Where the number of variables
`is equal to the number of variables used to instantiate the
`instance. It should be noted that When using this syntax, to
`prevent interpreting part of the variable name as its invoca
`tion parameter, variable names cannot include numbers.
`Likewise, a hardWare compiler 400 may shorten a name to
`remove instantiation parameters When the ?rst instance of a
`cell is created. In cases such as these Where a cell is
`generated/instantiated inside a series of generate loops, the
`?rst instance Will be labeled “root”, and the subsequent
`instances have a label of the form “rooti#i#i#” Where
`there are as many numbers as there are loops in the series.
`In the example, if the post-processor 410 determines that
`attributes exist for “srmll” blocks—Which they do—then the
`properties are added, based on the scope of the attributes, as
`the cell instance is parsed. During the addition, the param
`eters used to instantiate the cell instance are also substituted
`into the parameteriZed attribute before Writing the attribute
`to an augmented EDIF. For example, in the case above of
`“srmllin8initaps5icoeff33”, variable “n” Would be
`replaced by 8, variable nitaps Would be replaced by 5, and
`variable coeff Would be replaced by 33. The entire resulting
`expression Would then be reduced to its simplest form. The
`result is an augmented EDIF or an EDIF With evaluated
`parameters 425. This EDIF With evaluated parameters 425
`
`XILINX, EX. 1016
`Page 15 of 17
`
`

`
`5,971,595
`
`15
`
`25
`
`7
`can then be used as an input to a place and route tool 420 or
`other tools 430. When the EDIF With evaluated parameters
`425 is applied to a place and route tool 420 before joining
`With other components of a design, routing time is reduced
`by limiting the initial routing to inter-related components.
`Although the above has been described in terms of a
`post-processing tool Which utiliZes an EDIF output 415 from
`a hardWare compiler 400 to generate an augmented EDIF
`425, the present invention also encompasses an integrated
`hardWare compiler tool 400‘ that converts a hardWare
`description ?le 405 directly into an augmented EDIF ?le
`With parameteriZed properties 425 as shoWn in FIG. 4B.
`As an eXample of the method of the present invention, it
`Will be described With reference to FIGS. 5A through 5D
`hoW tWo serial multiplier slices described by FIGS. 3A
`through 3D are created. A user chooses to have tWo serial
`multiplier slices created or instantiated. The ?rst serial
`multiplier slice is created using n=8, nitaps=5 and coeff=
`33, and the second serial multiplier slice is created using
`n=8, nitaps=5 and coeff=44. For the ?rst serial multiplier
`slice, a slice is also speci?ed at p=3, and for the second serial
`multiplier slice a slice is speci?ed at p=4. Together the
`parameters and the library With parameteriZed attributes are
`applied to the hardWare compiler 400. If the bold section of
`FIGS. 5A through 5D Were absent, then FIGS. 5A through
`5D Would shoW the EDIF 415. HoWever, Without the bold
`sections, FIGS. 5A through 5D Would not include any
`properties, only cell instances and netWork routing informa
`tion. (For clarity, the netWork information has been removed
`and