U.S. patent application number 09/741315 was filed with the patent office on 2001-05-24 for methods and media for utilizing symbolic expressions in circuit modules.
Invention is credited to Dellinger, Eric F., Hwang, L. James, Mitra, Sujoy, Mohan, Sundararajarao, Wittig, Ralph D..
Application Number | 20010001881 09/741315 |
Document ID | / |
Family ID | 21960253 |
Filed Date | 2001-05-24 |
United States Patent
Application |
20010001881 |
Kind Code |
A1 |
Mohan, Sundararajarao ; et
al. |
May 24, 2001 |
Methods and media for utilizing symbolic expressions in circuit
modules
Abstract
The invention provides parametric modules called Self
Implementing Modules (SIMs) for use in programmable logic devices
such as FPGAs. The invention further provides tools and methods for
generating and using SIMs. SIMs implement themselves at the time
the design is elaborated, targeting a specified FPGA according to
specified parameters that may, for example, include the required
timing, data width, number of taps for a FIR filter, and so forth.
In one embodiment, the SIM parameters may be symbolic expressions,
which may comprise strings or string expressions, logical (Boolean)
expressions, or a combination of these data types. The variables in
these expressions are either parameters of the SIM or parameters of
the "parent" of the SIM. Parametric expressions are parsed and
evaluated at the time the SIM is elaborated; i.e., at run-time,
usually when the design is mapped, placed, and routed in a specific
FPGA. The use of parametric expressions interpreted at elaboration
time allows dynamic inheritance and synthesis of actual parameter
values, rather than the static value inheritance commonly found in
programming languages such as C++ and Java.
Inventors: |
Mohan, Sundararajarao;
(Cupertino, CA) ; Dellinger, Eric F.; (San Jose,
CA) ; Hwang, L. James; (Menlo Park, CA) ;
Mitra, Sujoy; (Cupertino, CA) ; Wittig, Ralph D.;
(Menlo Park, CA) |
Correspondence
Address: |
XILINX, INC
ATTN: LEGAL DEPARTMENT
2100 LOGIC DR
SAN JOSE
CA
95124
US
|
Family ID: |
21960253 |
Appl. No.: |
09/741315 |
Filed: |
December 19, 2000 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09741315 |
Dec 19, 2000 |
|
|
|
09049518 |
Mar 27, 1998 |
|
|
|
Current U.S.
Class: |
716/102 ;
716/105; 716/117 |
Current CPC
Class: |
G06F 30/34 20200101 |
Class at
Publication: |
716/1 ; 716/12;
716/13; 716/14 |
International
Class: |
G06F 017/50 |
Claims
What is claimed is:
1. A data storage medium comprising a first self-implementing
module for an integrated circuit (IC), the first module comprising:
means for accepting one or more symbolic expressions from at least
one other module as parameters; and means for self-implementing a
circuit represented by the first module and targeting the IC, based
on the symbolic expressions.
2. The data storage medium of claim 1, further comprising means for
parsing and evaluating the symbolic expressions at execution
time.
3. The data storage medium of claim 1, wherein the first module is
a parent of a child module.
4. The data storage medium of claim 3, wherein the child module is
the at least one other module.
5. The data storage medium of claim 1, wherein the first module is
a child of a parent module.
6. The data storage medium of claim 5, wherein the parent module is
the at least one other module.
7. The data storage medium of claim 1, wherein the IC comprises a
programmable logic device.
8. The data storage medium of claim 1, wherein the symbolic
expressions specify a logical function for the first module.
9. A data storage medium comprising a first self-implementing
module for an integrated circuit (IC), the first module comprising:
means for accepting one or more symbolic expressions as parameters;
means for parsing and evaluating the symbolic expressions at
execution time; and means for self-implementing a circuit
represented by the first module and targeting the IC, based on the
symbolic expressions.
10. The data storage medium of claim 9, wherein the first module is
a parent of a child module.
11. The data storage medium of claim 10, wherein the child module
is the at least one other module.
12. The data storage medium of claim 9, wherein the first module is
a child of a parent module.
13. The data storage medium of claim 12, wherein the parent module
is the at least one other module.
14. The data storage medium of claim 9, wherein the symbolic
expressions specify a logical function for the first module.
15. A method for specifying a circuit, the method comprising:
instantiating a parametric module; receiving a first symbolic
expression from a first module; and specifying a parameter value
for the parametric module by using the first symbolic
expression.
16. The method of claim 15, wherein the circuit is to be
implemented in a programmable logic device, and the parameter value
includes information relating to an area of the programmable logic
device available for the parametric module.
17. The method of claim 15, wherein the parameter value specifies a
logical function for the parametric module.
18. The method of claim 15, further comprising receiving a second
symbolic expression from a second module, wherein specifying a
parameter value includes using the second symbolic expression.
19. A method for specifying a circuit, the method comprising:
instantiating a parametric module; receiving a first symbolic
expression; and specifying a parameter value for the parametric
module by using the first symbolic expression, wherein the symbolic
expression is parsed and evaluated at a time the parametric module
is executed.
20. The method of claim 19, wherein the circuit is to be
implemented in a programmable logic device, and the parameter value
includes information relating to an area of the programmable logic
device available for the parametric module.
21. The method of claim 19, wherein the parameter value specifies a
logical function for the parametric module.
22. The method of claim 19, further comprising receiving a second
symbolic expression, wherein specifying a parameter value includes
using the second symbolic expression.
23. A data storage medium comprising a first module for an
integrated circuit (IC), the first module comprising means for
transmitting one or more symbolic expressions as parameters
directly to a second module, the first and second modules each
implementing a sub-circuit for the IC.
24. The data storage medium of claim 23, wherein the IC comprises a
programmable logic device.
25. The data storage medium of claim 23, further including means
for accepting one or more symbolic expressions as parameters from
at least one other module.
26. The data storage medium of claim 23, further including means
for accepting one or more symbolic expressions as parameters from
the second module.
27. The data storage medium of claim 23, wherein the second module
is a parent module of the first module.
28. The data storage medium of claim 23, wherein the second module
is a child module of the first module.
29. A method for specifying a circuit, the method comprising:
instantiating a first parametric module including means for
receiving a symbolic expression from another module; instantiating
a second parametric module including means for transmitting the
symbolic expression to another module; and transmitting the
symbolic expression from the second parametric module directly to
the first parametric module.
30. The method of claim 29, further comprising parsing and
evaluating the symbolic expression at the time the first parametric
module is executed.
31. A method for specifying a logic circuit, the method comprising:
instantiating a first parametric module specifying a first
sub-circuit of the logic circuit; and transmitting a symbolic
expression from the first parametric module directly to a second
parametric module specifying a second sub-circuit of the logic
circuit.
32. The method of claim 31, further comprising parsing and
evaluating the symbolic expression at a time the first parametric
module is executed.
33. The method of claim 31, further comprising parsing and
evaluating the symbolic expression at a time the second parametric
module is executed.
34. The method of claim 31, further comprising specifying a
parameter value for the first parametric module by using the
symbolic expression.
35. The method of claim 31, further comprising specifying a
parameter value for the second parametric module by using the
symbolic expression.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation application of commonly
assigned, co-pending U.S. patent application Ser. No. 09/049,518,
entitled "FPGA MODULES PARAMETERIZED BY EXPRESSIONS", invented by
Sundararajarao Mohan et al. and filed Mar. 27, 1998, which is
incorporated herein by reference.
[0002] This application further relates to commonly assigned,
copending U.S. patent application Ser. No. 09/049,598, entitled
"METHOD FOR CONSTRAINING CIRCUIT ELEMENT POSITIONS IN STRUCTURED
LAYOUTS", invented by Cameron D. Patterson et al. and filed Mar.
27, 1998, which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
[0003] 1. Field of the Invention
[0004] The invention relates to programmable integrated circuits
(ICs). More particularly, the invention relates to parametric logic
modules for implementing designs in programmable ICs, and software
tools and methods for creating such modules.
[0005] 2. Description of the Background Art
[0006] Programmable ICs are a well-known type of digital integrated
circuit that may be programmed by a user to perform specified logic
functions. One type of programmable IC, the field programmable gate
array (FPGA), typically includes an array of configurable logic
blocks (CLBs) surrounded by a ring of programmable input/output
blocks (IOBs). The CLBs and IOBs are interconnected by a
programmable interconnect structure. The CLBs, IOBs, and
interconnect structure are typically programmed by loading a stream
of configuration data (bitstream) into internal configuration
memory cells that define how the CLBs, IOBs, and interconnect
structure are configured. The configuration data may be read from
memory (e.g., an external PROM) or written into the FPGA by an
external device. The collective states of the individual memory
cells then determine the function of the FPGA.
[0007] One such FPGA, the Xilinx XC4000 Series FPGA, is described
in detail in pages 4-5 through 4-78 of the Xilinx 1996 Data Book
entitled "The Programmable Logic Data Book" (hereinafter referred
to as "the Xilinx Data Book"), published September, 1996, available
from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which
pages are incorporated herein by reference. (Xilinx, Inc., owner of
the copyright, has no objection to copying these and other pages
referenced herein but otherwise reserves all copyright rights
whatsoever.)
[0008] As FPGA designs increase in complexity, they reach a point
at which the designer cannot deal with the entire design at the
gate level. Where once a typical FPGA design comprised perhaps
5,000 gates, FPGA designs with 20,000 gates are now common, and
FPGAs supporting over 100,000 gates will soon be available. To deal
with this complexity, circuits are typically partitioned into
smaller circuits that are more easily handled. Often, these smaller
circuits are divided into yet smaller circuits, imposing on the
design a multi-level hierarchy of logical blocks. The imposition of
hierarchy makes it possible to implement designs of a size and
complexity that would otherwise be unmanageable.
[0009] True hierarchical design is difficult to achieve for FPGAs
using currently-available software. Designs can be entered
hierarchically (e.g., via schematic entry or Hardware Description
Languages (HDLs)), but mapping, placement and routing software
typically "flattens" the design. It is desirable to retain the
hierarchy as long as possible through the mapping, placement, and
routing stages of implementing the design. The advantages of
maintaining a hierarchy include faster software (because fewer
objects at a time require manipulation), ease of changing the
design (because only a discrete portion of the total logic has to
be changed), and ease of doing incremental design (retaining a
portion of a design while remapping, replacing, and rerouting only
the part of the design that has been changed).
[0010] One result of the "hierarchical advantage" is the
development of "module libraries", libraries of predeveloped blocks
of logic that can be included in a hierarchy of logical blocks. A
higher-level block incorporating (instantiating) a second module is
called a "parent" of the instantiated module. The instantiated
module is called a sub-module or "child" of the parent. Such
library modules include, for example, adders, multipliers, filters,
and other arithmetic and DSP functions from which complex designs
can be readily constructed. The use of predeveloped logic blocks
permits faster design cycles by eliminating the redesign of
duplicated circuits. Further, such blocks are typically well
tested, thereby making it easier to develop a reliable complex
design.
[0011] To offer the best possible performance, some library modules
have a fixed size and shape with relative location restrictions on
each element. One such module type (now obsolete) was the "hard
macro" from Xilinx, Inc. Hard macros are described in the "XC4000
Family Hard Macro Style Guide", published Sep. 3, 1991 and
available from Xilinx, Inc., which is incorporated herein by
reference in its entirety. A hard macro did not require schematics;
instead, it included a schematic symbol that was used to include
the macro in a customer design, and a netlist referenced by the
schematic symbol and representing the macro circuitry. The netlist
was encrypted and sent to customers in binary format, which made it
difficult to edit or reverse-engineer the netlist. (A "netlist" is
a description of a circuit comprising a list of lower-level circuit
elements or gates and the connections (nets) between the outputs
and inputs thereof.)
[0012] One disadvantage of the hard macro format was that the area
of the FPGA encompassed by the hard macro was totally dedicated to
the contents of the macro. A customer could not place additional
logic in a CLB within the area, or access any signal inside the
area unless the signal had an output port defined as part of the
hard macro. Further, the area of the FPGA encompassed by the hard
macro had to be rectangular. If the logic fit best, or resulted in
the fastest performance, in a non-rectangular area, the extra CLBs
required to make the area rectangular were wasted. Hard macros did
not include routing information.
[0013] Another type of module having a fixed size and shape is the
Relationally Placed Macro (RPM) from Xilinx, Inc. RPMs are
described in pages 4-96 and 4-97 of the "Libraries Guide"
(hereinafter referred to as the "Xilinx Libraries Guide"),
published October 1995 and available from Xilinx, Inc., which pages
are incorporated herein by reference. An RPM is a schematic that
includes constraints defining the order and structure of the
underlying circuits. The location of each element within the RPM is
defined relative to other elements in the RPM, regardless of the
eventual placement of the RPM in the overall design. For example,
an RPM might contain 8 flip-flops constrained to be placed into
four CLBs in a vertical column. The column of four CLBs can then be
placed anywhere in the FPGA.
[0014] Relative CLB locations within an RPM are specified using a
Relative Location Constraint called "RLOC". RLOC constraints are
described in detail in pages 4-71 through 4-95 of the Xilinx
Libraries Guide, which pages are incorporated herein by reference.
Elements having an RLOC value of R0C0 are located in a given CLB
corresponding to the (0,0) coordinate location. The next CLB
"below" the (0,0) CLB is designated as R1C0, corresponding to the
(0,1) coordinate location. Although the RPM has a rigid size and
shape, other logic can be placed within the borders of the RPM.
RPMs, like hard macros, do not include routing information.
[0015] A hard macro or RPM implementation of a logic module
represents a single fixed circuit targeting a specific FPGA
architecture. To accommodate even a slight difference in logic or a
different FPGA architecture, a new RPM must be created. Therefore,
libraries of RPMs are typically large and limited in scope.
[0016] Some flexibility has been provided by creating a different
type of library module called a parametric module (i.e., a module
having one or more associated variable values). One such type of
parametric module is described in pages 1-1 to 2-14 of the "X-BLOX
User Guide", published April, 1994 and available from Xilinx, Inc.,
(hereinafter the "X-BLOX User Guide"), which pages are incorporated
herein by reference. The X-BLOX.TM. software tool includes a
collection of library modules from Xilinx, Inc. X-BLOX modules
comprise schematic symbols that can be added to a schematic
representation of an FPGA design, and then parameterized to specify
such variables as bit width, initial values, and so forth. The
schematic including one or more X-BLOX modules is then translated
into a netlist, and the netlist includes instantiations of the
X-BLOX modules. Translation software then implements the X-BLOX
module as lower-level circuit elements targeted for the Xilinx
XC4000 Series FPGA, and includes these elements in the netlist. The
netlist is then implemented in the FPGA by standard mapping,
placement, and routing software which generates a configuration
bitstream.
[0017] X-BLOX modules, although customizable, have a predefined
shape and size based on the user-defined parameter values. For
example, a counter module (called "COUNTER") is typically
implemented as a column of CLBs, wherein the number of CLBs
involved is dependent on the value of the parameter "COUNT_TO"
(which defines the maximum value of the counter). The COUNTER
module is described on pages 4-36 to 4-46 of the X-BLOX User Guide,
which pages are incorporated herein by reference. While the size of
the counter varies according to the value of the parameter
COUNT_TO, for a given parameter value the X-BLOX module has a fixed
size and shape.
[0018] A newer generation of the X-BLOX product is the LogiBLOX.TM.
tool, also from Xilinx, Inc. A LogiBLOX module has similar
capabilities to an X-BLOX module with some accompanying advantages,
such as the availability of different logical implementations for a
single module. For example, by setting a parameter in a graphical
user interface, a user can specify that a multiplexer be
implemented using tristate buffers driving horizontal interconnect
lines, rather than using the default CLB implementation. The
LogiBLOX product is described on pages 4-3 and 4-4 of the "CORE
Solutions Data Book", copyright 1997, and available from Xilinx,
Inc., (hereinafter the "CORE Solutions Data Book"), which pages are
incorporated herein by reference.
[0019] Another product comprising parametric modules is the
LogiCORE.TM. library and software tool from Xilinx, Inc., which is
described on pages 2-3 to 2-4 of the CORE Solutions Data Book,
which pages are incorporated herein by reference. One LogiCORE
product is the LogiCORE PCI interface module, described on pages
2-5 to 2-20 of the CORE Solutions Data Book, which pages are
incorporated herein by reference. The LogiCORE PCI interface
product includes a graphical user interface which allows the user
to customize a "header" portion of the PCI design. The data entered
by the user comprises memory initialization data that is stored in
a predefined register portion of the PCI interface design. The data
does not otherwise alter the logic of the PCI interface circuit
implemented by the module, other than to adapt the module to the
target application.
[0020] Another LogiCORE product is a set of DSP CORE modules,
described on pages 2-21 through 2-91 of the CORE Solutions Data
Book, which pages are incorporated herein by reference. The DSP
CORE modules are parameterizable VHDL modules. (VHDL is one
well-known type of HDL.)
[0021] Another parameterizable logic block is described by Karchmer
et al in UK Patent Publication GB 2306728 A, published May 7, 1997,
entitled "Programmable Logic Array Design Using Parameterized Logic
Modules" (hereinafter "Karchmer"), which is incorporated herein by
reference. Karchmer describes a programmable logic module in which
parameter values are passed down through a module hierarchy from a
parent module to child modules placed within the parent.
[0022] It is clear that X-BLOX, LogiBLOX, and LogiCORE modules are
optimized as independent blocks of logic, not in the context of the
entire design. It would be desirable for library modules to be
implemented in a manner leading to the optimal complete design,
rather than to a conglomeration of separately optimized
circuits.
[0023] Morphologic, Inc., of Bedford, N.H., reports that they have
devised a type of library module which is implemented based on both
user-supplied parameters (including bit widths, setup time, clock
to Q time, known sizes, shapes, and latencies) and dynamically
generated parameters. These dynamically generated parameters
include the target FPGA architecture and the type of tile (e.g.,
CLB or IOB) present in the portion of the FPGA to be occupied by
the logic in the module. For example, when a Morphologic register
module is targeted, using the Morphologic Floorplanner tool, to a
Xilinx XC4000 Series FPGA, the module may be implemented in either
a CLB or an IOB. When the Morphologic module is moved within the
interactive floorplanner from a CLB area to an IOB area, the
register is implemented using IOB input flip-flops rather than CLB
memory elements. When moved from one FPGA to another, and the FPGAs
have different architectures (for example, the module is moved from
a Lucent Technologies ORCA FPGA to a Xilinx XC4000 Series FPGA) the
Morphologic module reportedly changes from an implementation
directed to the first FPGA architecture to another implementation
directed to the second FPGA architecture. When moved from place to
place on a single FPGA within the Morphologic floorplanner, the
Morphologic module can reportedly change its shape by rearranging
sub-modules within the module, if in the new location it would
overlap with a previously placed module. Although a Morphologic
module can reportedly adapt to the location in which it is placed
during an interactive (i.e., manual) floorplanning step, it would
also be desirable to have the ability to optimize a module not only
in the context of the shapes of neighboring modules, but also based
on the logical interconnections that must be formed between
modules. It would be further desirable to have the ability to adapt
the shape of a module at the time the design is mapped, placed, and
routed, rather than adapting the shape at an earlier time (e.g., in
the Morphologic interactive floorplanner or using other prior art
methods) and then "freezing" the module so that it is unable to
respond to later changes. It would further be desirable to be able
to adapt not just the physical structure (the shape), or the target
FPGA architecture, but also the logical structure (the way the
circuit is logically implemented) in response to the requirements
of other modules.
[0024] When hierarchy is imposed using hard macros or RPMs, locally
optimized solutions are created, because placement of elements
within modules is without reference to spatial or timing
requirements of neighboring modules. Therefore, it would be
desirable to have the ability to alter a module at the time the
design is mapped, placed, and routed, based on the various
requirements of the complete design.
SUMMARY OF THE INVENTION
Self Implementing Modules
[0025] The invention provides parametric modules called Self
Implementing Modules (SIMs) for use in programmable logic devices
such as FPGAS. The invention further provides tools and methods for
generating and using SIMS. SIMs implement themselves at the time
the design is elaborated, i.e., when the SIM code (now in the form
of compiled code) is executed, usually when the design is mapped,
placed, and routed in a specific FPGA. (Modules implemented in a
programming language are first compiled into executable code, then,
in a second step, executed or elaborated to produce a netlist and,
optionally, placement and/or routing information.)
[0026] SIMs target a specified FPGA according to specified
parameters that may, for example, include the required timing, data
width, number of taps for a FIR filter, and so forth. SIMs are
called "self implementing" because they encapsulate much of their
own implementation information, including mapping, placement, and
(optionally) routing information. Therefore, implementing a
SIM-based design is significantly faster than with traditional
modules, because much of the implementation is already complete and
incorporated in the SIM. SIMs are relocatable anywhere in an FPGA
CLB array. They are also well-suited for use in reconfigurable
computing systems, wherein most of a programmed IC remains
operational while a portion of the IC is reconfigured. One or more
SIMs can be regenerated with new parameter values and downloaded to
such a reconfigurable IC. In one embodiment, the SIMs are not
parameterizable.
[0027] SIMs can be hierarchical, i.e., they can include other SIMs,
thereby forming a logical hierarchy. In addition, SIMs can include
a separate physical hierarchy which is imposed in addition to the
logical hierarchy. SIMs therefore offer the advantages of
hierarchical design. In some embodiments, SIM parameters are passed
down through the hierarchy from a given "parent" SIM to its
sub-SIMs, or "children".
[0028] In addition to storing logical and physical structural
information (e.g., hierarchical groupings) a SIM has an embedded
object (or a reference to such an object) called a "Planner". A
Planner object is a floorplanner that algorithmically computes the
physical locations of the SIM's constituent sub-SIMs. A
floorplanner's algorithm can range from the simple algorithm
"assign locations according to a single pre-defined footprint", to
complex algorithms such as "perform simulated annealing on the
constituent SIMs". A SIM with a context-sensitive floorplanner
algorithm is able to adapt its placement to its environment by way
of mutable shape and/or I/O port locations.
[0029] In addition to optimizing the physical structure, the
logical structure of the SIM can also be optimized. SIMs within a
design can interact with each other to change either or both of the
physical and the logical structures of each SIM to reach the
optimal result for the design comprising the entire group of SIMs.
For example, in a SIM representing a multiplier, a chosen
algorithmic implementation of the multiplier can depend on the size
of the area available for the SIM (based on feedback from other
SIMS) and the permissible delay through the SIM (based on the
amount of time allotted to the SIM from the total available time
for the complete design). When timing considerations are paramount,
a pipelined multiplier implementation can be chosen. When area is
the primary consideration, a non-pipelined implementation results
due to the area savings of not using register elements. The shape
of the implemented SIM is in each case tailored to the shape of the
available space, taking into account the needs of the other SIMs in
the design.
[0030] Because SIMs are preferably implemented using
object-oriented software, they are easy both to use and to design.
The computer code devices in a SIM may, however, be any interpreted
or executable code mechanism, such as scripts, interpreters,
dynamic link libraries, Java.TM. classes, and complete executable
programs. (Java is a trademark of Sun Microsystems, Inc.) In one
embodiment, all information for the SIM is included in a single
Java object, which may reference other Java objects.
[0031] SIMs can be transferred from the SIM designer (the person
who writes the code) to a SIM user (the person designing the
circuit using the SIM) in various ways, such as over a data
communications link or stored on a data storage medium. (The term
"data communications link" as used herein includes but is not
limited to the internet, intranets, Wide Area Networks (WANs),
Local Area Networks (LANs), and transducer links such as those
using Modulator-Demodulators (modems). The term "internet" as used
herein refers to a wide area data communications network, typically
accessible by any user having appropriate software. The term
"intranet" as used herein refers to a data communications network
similar to an internet but typically having access restricted to a
specific group of individuals, organizations, or computers. The
term "data storage medium" as used herein denotes all
computer-readable media such as compact disks, hard disks, floppy
disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, Flash
EPROM, etc.), DRAMs, SRAMs, and so forth.
[0032] SIMS are easily delivered over a data communications link
such as the internet. Therefore, in one embodiment a SIM is
protected from duplication or alteration by providing an encrypted
SIM that requires a key to decrypt the SIM, using well-known
techniques.
Modules Parameterized by Expressions
[0033] SIMs are also advantageously adaptable to parametric inputs.
In one embodiment, the SIM parameters may be symbolic expressions,
which may comprise strings or string expressions, logical (Boolean)
expressions (e.g., x AND y, x OR y, x>1), or arithmetic
expressions (e.g., x+y), or a combination of these data types
(e.g., modulename=basename+"."+((x&g- t;1) AND (y+1>5x)),
where "modulename" is a string resulting from a combination of
string, arithmetic and logical expressions). (The term "string
expressions" as used herein means any expression including a
character string; therefore every string is also a simple string
expression.)
[0034] SIMs may have symbolic expressions as parameters; the
variables in the expressions parameterizing a SIM are also
parameters of the SIM. The variables may also be parameters of the
"parent" of the SIM, passed down through the hierarchy to the child
SIM.
[0035] Parametric expressions are interpreted (parsed and
evaluated) at the time the SIM is elaborated. The use of parametric
expressions interpreted at elaboration time allows dynamic
inheritance (i.e., parameter values specified at elaboration time
are passed downward through the SIM hierarchy) and synthesis of
actual parameter values, rather than the static value inheritance
(i.e., parameter values must be specified at compile time to pass
downward through a hierarchy) described by Karchmer and commonly
found in programming languages such as C++ and Java.
Including Placement Information in SIMs
[0036] Each SIM may include or reference its own implementation
information, including physical layout information in the form of a
floorplanner. If a SIM does not include or reference a
floorplanner, its physical layout is computed by the floorplanner
of one of its ancestors in the physical hierarchy (i.e., the SIM's
parent or a parent of its parent, etc.). In one embodiment, each
floorplanner is implemented as a Java object.
[0037] Floorplanners can vary widely in complexity. One simple type
of floorplanner chooses from among a plurality of available
precomputed placements, depending on the area or timing constraints
imposed on the floorplanner. Precomputed placements for this
floorplanner could be implemented as a list of RLOC constraints
corresponding to the elements in the SIM and designating the
relative positions of the elements. Precomputed placements for a
given SIM may include, for example, one columnar organization
(implemented as a column of elements), one row organization
(implemented as a row of elements), one or more rectangular shapes,
and so forth. The precomputed placements may all apply to the same
logical implementation, or a SIM may include two or more logical
implementations for the circuit, and different precomputed
placements may apply to different logical implementations.
[0038] More sophisticated floorplanners implement more versatile
placement algorithms. Such placement algorithms might include, for
example: a linear ordering algorithm that places datapath logic
bitwise in a regular linear pattern; a rectangular mesh algorithm
that implements memory in a grid pattern in distributed RAM; a
columnar algorithm for counters and other arithmetic logic; or a
simulated annealing algorithm for random logic such as control
logic. Therefore, in a design including more than one SIM, the
design can include two or more SIMs (at the same or different
levels of hierarchy) using different placement algorithms. The
design as a whole can therefore utilize a non-uniform global
placement strategy, a technique that is not practical using prior
art methods.
[0039] In one embodiment, the user can specify a particular
floorplanner to be used for each SIM. The floorplanner can, for
example, be specified by attaching a floorplanner object or a
parameter to the SIM. In another embodiment, the user specifies a
physical area of the target device (e.g., in an interactive
floorplanner) where a given floorplanner is to be used, and
identifies SIMs to be placed within that area. SIMs placed within
that area then automatically use the floorplanner assigned to that
area. In another embodiment, a SIM has a default floorplanner that
is used if no other floorplanner is specified for the SIM.
[0040] In one embodiment, the user can specify a plurality of
floorplanners to be applied to different portions of a single FPGA.
Where more than one floorplanner is present in a design, the
floorplanners may be active simultaneously, and may communicate
with each other to implement the SIMs in a fashion that leads to
the most desirable overall solution. The most desirable solution is
determined by the user, who specifies timing and spatial
requirements using known methods such as attaching parameters to a
module or setting software options. The ability to run multiple
floorplanners simultaneously speeds up the implementation process,
due to the parallel processing of the placement task. In other
words, this embodiment applies the well-known "divide-and-conquer"
strategy to physical layout of an FPGA design.
[0041] This aspect of the invention is also useful in that a user
has the option of writing his or her own floorplanner, thereby
implementing his or her own placement algorithm, instead of (or in
addition to) specifying one of an existing set of
floorplanners.
[0042] In one embodiment, the floorplanner can also receive
placement information (e.g., from a constraints file or an
interactive floorplanner) specifying areas of the target device
that are "off limits" to the floorplanner. This ability is useful,
for example, when certain portions of a programmable device have
been tested and found defective. By specifying and avoiding these
defective areas of the device, the rest of the device can still be
utilized. The same methods can be used to reserve areas of the
target device to be occupied by other modules or elements. Non-SIM
elements are easily integrated into a SIM environment using a
"black box" interface.
Routing by Abutment
[0043] The invention also provides a method that can be used to
include routing information in SIMS. According to this method,
routing information is specified in such a manner that the routing
between modules, however parameterized and elaborated, occurs by
abutment of the modules.
[0044] In one embodiment, a SIM automatically places and
interconnects child SIMs in a mesh pattern. The mesh is a 2-5
dimensional object corresponding, for example, to an array of CLBs
on an FPGA. In essence, this embodiment allows a SIM to reserve
routing resources on a target device (e.g., an FPGA), and allocate
these resources to its child SIMs. Using a defined protocol, each
child SIM can request and reserve routing resources, as well as
placement resources (e.g., flip-flops and function generators),
through the parent SIM. The routing resources are not limited to
local or nearest neighbor routing.
BRIEF DESCRIPTION OF THE DRAWINGS
[0045] The present invention is illustrated by way of example, and
not by way of limitation, in the following figures, in which like
reference numerals refer to similar elements.
[0046] FIG. 1 is a block diagram of a SIM comprising two ports,
three nets, and two child SIMs.
[0047] FIG. 2 shows an exemplary partial listing of a SIM called
X4keAdderxWReg.
[0048] FIG. 3 shows the basic SIM class, the five extended classes,
and their inter-relationships.
[0049] FIG. 4 shows exemplary code for a SIM-related method called
addAllParams.
[0050] FIG. 5 shows exemplary code for a SIM-related method called
checkParams.
[0051] FIG. 6 shows exemplary code for a SIM-related method called
updateImplementation.
[0052] FIG. 7 shows a constructor for a SIM that is specific to the
XC4000E.TM. family of FPGAs from Xilinx, Inc.
[0053] FIG. 8 shows an exemplary constructor for a user-defined SIM
that extends the Java class ImplementedSim.
[0054] FIG. 9 shows an exemplary method body for SIM-related method
addAllParams.
[0055] FIG. 10 shows an exemplary class constructor that invokes
the addAllParams method and creates all the ports of a SIM.
[0056] FIG. 11 shows exemplary code for a SIM-related method called
setPortWidths.
[0057] FIG. 12 provides an exemplary implement method that
illustrates the use of the addHDLSim method.
[0058] FIG. 13 shows exemplary code for the Java class Output.
[0059] FIG. 14 shows exemplary code for the PlaceInfo class.
[0060] FIG. 15 shows exemplary code for the Implementation
class.
[0061] FIG. 16 shows exemplary code for the Constraint class.
[0062] FIG. 17 shows exemplary code for the Planner abstract
class.
[0063] FIG. 18 shows a Planner that cycles through a series of
precomputed shapes.
[0064] FIGS. 19 and 20 together show a special-purpose linear
Planner called "RowPlanner".
[0065] FIG. 21 shows a Planner using a simulated annealing
algorithm.
[0066] FIG. 22 shows a MetaPlanner" that calls several other
Planners such as those shown in FIGS. 18-21.
[0067] FIG. 23 shows the SIM hierarchy for an exemplary SIM
implementing a RISC processor.
[0068] FIG. 24 is a high-level drawing of the RISC microprocessor
of FIG. 23 mapped into an FPGA.
[0069] FIG. 25 shows a Planner for the RISC microprocessor SIM of
FIGS. 23 and 24.
[0070] FIG. 26 shows an exemplary Java class that implements the
Mesh2DSimInterface.
[0071] FIG. 27 shows a SIM comprising two child SIMs having a
common port, the two child SIMs forming two elements of a mesh
structure.
DETAILED DESCRIPTION OF THE DRAWINGS
[0072] Parametric modules, and tools and methods for generating and
using such modules, according to the invention are described. In
the following description, numerous specific details are set forth
in order to provide a more thorough understanding of the present
invention. However, it will be apparent to one skilled in the art
that the present invention may be practiced without these specific
details.
Self Implementing Modules (SIMs)
[0073] A SIM is a logical entity that can implement itself on a
device (e.g., an FPGA) under the restrictions imposed by the
context in which it is used. In the described embodiment, the word
"context" refers to the target FPGA device and to other modules
(e.g., other SIMs) or other elements that may already be placed on
the device. The SIM can incorporate all the knowledge necessary to
implement itself within a target device. Moreover, the SIM can
interact with other SIMs to achieve an optimal allocation of scarce
resources such that the global performance targets are met. These
steps occur with minimal user intervention and minimal run-time. In
one embodiment, when the self-implementing process has terminated,
a bitstream is available to program the targeted device.
[0074] SIMs may be parametric in that they implement themselves
based on a set of parameters supplied by the user. For example, the
user specifies a 32-bit multiplier by setting the appropriate
parameter of the multiplier to the desired word length. In one
embodiment, SIMs also have the ability to model the behavior,
functionality and timing of the logic. Like an HDL representation,
a SIM can provide a simulation model that allows the designer to
validate functional correctness early in the design cycle.
[0075] SIMs are hierarchical, i.e., each SIM can optionally include
one or more child SIMs and can be instantiated in a parent SIM. A
SIM at the lowest level of hierarchy, i.e., a SIM that cannot be
decomposed into constituent sub-SIMs, is called a "primitive SIM".
The hierarchy level just above the primitive SIM typically includes
all the mapping and placement information (and, optionally, routing
information) for the child primitive SIMS.
[0076] SIMs speed up the placement process in three ways: 1)
placement at the lowest level (the level just above primitive SIMS)
is already done; 2) hierarchical placement is used, i.e., a few
larger blocks are placed at each of two or more levels instead of
placing potentially thousands of small cells at a single level; and
3) a "divide and conquer" strategy is applied at each level, i.e.,
the placement problem is approached as a series of smaller and
faster placement problems.
[0077] SIMs can implement large blocks of functionality such as
adders, multipliers and FIR filters. Such blocks can be specified
as parametric logical entities, and the physical implementation can
also be constructively specified in terms of function generators
and flip-flops with relative location (e.g., RLOC) constraints. The
invention takes advantage of the fact that many sets of such
relative location constraints (i.e., many such shapes) are possible
for the same logical functionality, thereby increasing the
probability that a shape can be chosen to best match the physical
implementation context in which the SIM is used. Similarly, many
different logical implementations can be used to implement the same
circuit. A SIM for which all parameters are specified and a logical
implementation has been selected is referred to as an "Implemented
SIM". Generally, an Implemented SIM is rendered more usable in the
larger context if it provides a plurality of shapes for every
logical implementation. Given the logical implementation, the shape
most appropriate to the context can be selected.
[0078] In one embodiment, all elements in an Implemented SIM are
spatially mapped through relational constraints general enough to
allow the SIM to be located in most areas of the FPGA to which it
is targeted. In another embodiment, rather than specifying specific
relational constraints, a floorplanner is referenced that
implements the SIM according to a selected floorplanning algorithm.
A SIM is said to be "fully implemented" when both a logical and a
spatial implementation have been selected, i.e., a logical
implementation has been selected and all the elements within the
SIM have been placed. A fully implemented SIM may also include some
or all of the routing for the SIM.
[0079] While an Implemented SIM may optionally include routing
information, the Implemented SIM may require that some additional
routing be done before the bitstream is generated. The routing
depends on the context in which the SIM is placed, thus not all
possible routings can always be enumerated in the SIM. While the
interconnect fabric of any large FPGA is homogeneous in that it
follows a predefined pattern, the interconnect structure typically
cannot be segmented into large minimally interacting areas. For
example, in an XC4000EX.TM. device from Xilinx, Inc., long lines
span an entire quadrant, and quad lines span four CLB rows or
columns but are staggered such that a new line begins at every row
or column. However, the local direct interconnect can be used to
implement some of the routing local to an Implemented SIM. In some
embodiments, for SIMs large enough to require non-local routing, a
final post-placement routing phase is necessary to complete the
routing. Another embodiment, described below under "Pre-Routed
SIMS", includes both local and non-local routing within the
SIM.
Detailed Description of a SIM Embodiment
[0080] In one embodiment, SIMs are implemented in the Java
programming language. However, they can be implemented in any
sufficiently powerful programming language.
[0081] A SIM includes zero or more ports, nets, and child SIMs. In
addition to these elements, in the presently described embodiment
every SIM has a reference to a "PlaceInfo" object that holds
physical design information. A SIM can also include various
optional elements such as parameters or attributes, behavioral
models, and implementation methods (e.g., floorplanners) that
specify how the SIM is to be constructed. FIG. 1 shows a SIM (SIM0)
that comprises two ports (Port1, Port2), three nets (Net1, Net2,
Net3), and two child SIMs (Child1, Child2).
[0082] In this embodiment, each SIM is defined as a Java class
(defined below), and is derived from the class Sim. The base SIM
class provides several useful methods for adding or deleting ports,
nets, and child SIMs. In Java and other object-oriented languages,
a function or procedure is commonly called a "method". The word
"method" is also used herein in its traditional sense of a series
of steps to perform a task. A Java "class" is a collection of data
and methods that operate on that data. A class may also be referred
to as a "type". The base class also defines a few abstract methods
that have to be made concrete by the final derived SIM. (An
abstract method in Java is a method that has no body, just a return
type and parameter definition.) Each SIM includes one or more
constructors (i.e., Java methods that allocate memory for and
typically initialize the variables of a newly created object) which
create the ports of the SIM and define the parameters of the
SIM.
[0083] The class Net allows SIMs to be connected logically. Each
net has a width N greater than or equal to one, and is composed of
N strands. The SIM user does not create or deal with strands
directly; strands are used internally to implement certain net
usage semantics. Nets can be ripped to create smaller nets, and
bundled to make wider nets. Nets can also be logically merged with
other nets. A net connects to one or more SIMs through the ports. A
net can be assigned a logical value for simulation (N logical
values if the net is defined to be N-wide). In FIG. 1, net Net1
connects the two child SIMs (Child1, Child2) with each other and
with port Port1; net Net2 connects the two child SIMs (Child1,
Child2) with each other; and net Net3 connects child SIM Child2
with port Port2.
[0084] The class Port provides a mechanism to connect a SIM to a
net. Each port has place-holders for two nets: the internal net
that connects to the child SIMs; and the external net that connects
the SIM containing the port to its parent and siblings, if any. In
FIG. 1, port Port1 has an internal connection 101 to net Net1 and
an external connection 102. Port Port2 has an internal connection
103 to net Net3 and an external connection 104. The port mechanism
ensures that a SIM can be quickly and efficiently connected to or
disconnected from other SIMs, without altering the internal data
structures of the SIM. All the nets included in a SIM (i.e., the
port internal nets and the nets connecting child SIMs) are
completely contained in the SIM and are not visible outside. The
only way to connect an external net to a SIM is through the port
mechanism.
[0085] The class Sim defines several methods to help construct
SIMs. The methods can be broadly categorized as methods for adding
and deleting components (e.g., SIMs, nets, and ports), methods for
specifying interconnections between components, methods for
obtaining information about a SIM, and action methods that cause
the SIM to change its state or structure. Based on the disclosure
herein, these methods can be generated without undue
experimentation by those of ordinary skill in the art.
Methods for Adding and Deleting Components
[0086] The following methods are used to add and delete child SIMs,
nets, and ports.
[0087] Net addNet (String netName, int netWidth): Creates a new net
of width "netWidth" and adds it to the invoking SIM. This method
returns a reference (i.e., a pointer) to the newly created net.
[0088] Port addPort(String portName, int portWidth, int portType):
Adds a new port to the invoking SIM. The parameter "portType" is a
statically defined constant in the class Port.
[0089] Sim addChildSim (Sim childSim): Adds a child SIM "childSim"
to the invoking SIM. The child SIM must be created using its own
constructor before it is added to the invoking SIM.
[0090] deleteNet (Net someNet): Deletes the net "someNet" from the
invoking SIM.
[0091] deletePort (Port somePort): Deletes the port "somePort" from
the invoking SIM.
[0092] deleteSim (Sim someSim): Deletes the SIM "someSim" from the
invoking SIM.
Methods for Specifying Interconnections Between Components
[0093] The following methods are used to specify interconnections
between child SIMs, nets, and ports, and to manipulate internal
nets.
[0094] boolean connectNet (String portName, Net extNet): Connects
external net "extNet" to port "portName"; if port "portName" does
not exist, returns false, else returns true. This method is invoked
on the child SIMs of the invoking SIM, to connect nets in the
invoking SIM to the child SIM ports.
[0095] boolean connectPortInternal (Port somePort, Net someNet):
Connects a net "someNet" of the invoking SIM to a port "somePort"
of the invoking SIM. Both port and net should be non-null and have
the same width, else the method returns false.
[0096] Net getRipNet (Net net1, int index1): Creates a new net of
width=1 which contains the strand at index "index1" in net "net1".
This method does not modify net "net1" or the strand at index
"index1". Both net "net1" and the new net reference the same
strand. The new net is returned to the caller.
[0097] Net getRipNet (Net net1, int minIndex, int maxIndex):
Creates a new net of width=(maxIndex-minIndex+1) which references
the strands at indices "minIndex" to "maxIndex" (inclusive) in net
"net1". The new net is returned to the caller.
[0098] boolean equateNets (Net net1, Net net2) : Makes nets "net1"
and "net2" logically equivalent. Both nets should be non-null and
have the same width, else the method returns false. The semantics
of equateNets is that of creating an equivalence class of nets. For
example, the following code fragment first makes nets a and b
equivalent, then makes them both equivalent to net c, and then
makes a, b, and c all equivalent to net d. equateNets (a,b);
[0099] // makes nets a and b equivalent.
[0100] equateNets (b,c);
[0101] // makes b and c equivalent, and consequently, a, b, c
[0102] // are equivalent.
[0103] equateNets (c,d);
[0104] // makes c and d equivalent, and consequently, a, b, c,
d
[0105] // are equivalent.
[0106] Smaller nets can be bundled into a large bus/net using
equateNets, by first creating the large bus and then equating
portions of the large net to the smaller nets. For example:
[0107] Net smallNet1=addNet ("small1", 5);
[0108] // creates net of width 5
[0109] Net smallNet2 =addNet ("small2", 5);
[0110] // creates net of width 5
[0111] Net largeNet=addNet ("largeNet", 10);
[0112] // creates net of width 10
[0113] equateNets (getRipNet (largeNet,0,4), smallNet1);
[0114] equateNets (getRipNet (largeNet,5,9), smallNet2);
[0115] // largeNet is now equivalent to a bundle containing the
[0116] // two small nets
Methods for Obtaining Information about a SIM
[0117] The following methods can be invoked on a SIM to return
selected information about the SIM to the caller. The caller could
be a SIM that needs information about its child SIMs, or some other
tool such as a floorplanner or netlist formatter that needs
information about the SIM.
[0118] String getName(): Returns the name of the subject SIM
instance.
[0119] String getHierName(): Returns the hierarchical name of the
subject SIM instance. If the subject SIM has a parent SIM, the
hierarchical name of the subject SIM is the name of the subject SIM
instance, prefixed by the hierarchical name of the parent SIM and
"/". Otherwise, the hierarchical name of the subject SIM is the
same as its instance name.
[0120] int getNumNets() Returns the number of Nets that are part of
the subject SIM. The number returned does not include the nets of
the child SIMs, or the external nets connected to the ports of the
subject SIM.
[0121] int getNumPorts(): Returns the number of ports in the
subject SIM. The number returned does not include the ports of the
child SIMs.
[0122] int getNumSims(): Returns the number of child SIMs in the
subject SIM.
[0123] Sim getParentSim(): Returns the parent of the subject SIM if
a parent is defined, null otherwise.
[0124] boolean isPlaced(): Returns true if the subject SIM is fully
implemented (i.e., has fixed parameters, logical implementation,
and shape) and is placed at some location on a device, otherwise
returns false.
[0125] boolean isPrimitive(): Returns true if the subject SIM is a
primitive SIM. In this embodiment, a primitive SIM represents a
basic element that can be placed on an FPGA, such as a function
generator or a flip-flop.
[0126] Hashtable getAttribs(): Attributes are key-value pairs,
stored in a hashtable. This method returns the hashtable of
attributes to the caller.
[0127] Netlist getNetlist(): Returns a Netlist object containing a
flattened netlist representing the subject SIM. Every SIM in the
flattened netlist is a primitive SIM. Every net in the flattened
netlist has a width of 1. Netlist objects are used by various
computer aided design (CAD) tools.
[0128] PlaceInfo getPlaceInfo(): Returns a PlaceInfo object
associated with the subject SIM, describing the physical location
of the SIM within a particular FPGA.
[0129] An "enumeration" is a Java language construct that provides
a uniform interface for iterating (stepping one by one through) all
the elements in a collection of objects. The following three
methods return enumerations of nets, ports and child SIMs of the
subject SIM.
[0130] Enumeration netElements(): Returns an enumeration of the
nets of the subject SIM.
[0131] Enumeration portElements(): Returns an enumeration of the
ports of the subject SIM.
[0132] Enumeration simElements(): Returns an enumeration of the
child SIMs of the subject SIM.
Action Methods
[0133] The following methods cause the SIM to change its state or
structure.
[0134] abstract void implement (String deviceFamily, int row, int
col, String extraSite): Causes the SIM to create or modify its
structure, as necessary, to suit the context defined by the
parameters. The implement method is abstract in the base SIM class,
so each SIM defines a concrete implement method that does the
following:
[0135] 1) defines the structural netlist for the subject SIM in
terms of other SIMs;
[0136] 2) optionally defines the relative placement of one or more
of the SIMs within the subject SIM;
[0137] 3) optionally defines the placement of the subject SIM
either relative to its parent, or in absolute coordinates; and
[0138] 4) optionally sets a "placed" flag for the subject SIM. The
concrete implement method may be called repeatedly, as when a
floorplanner tries to place the SIM in various locations.
[0139] void setName(String instanceName): Sets the instance name of
the SIM to "instanceName".
[0140] void setPrimitive(boolean value): Marks the SIM as Primitive
if "value" is true, not Primitive if "value" is false.
Parameters and Expressions
[0141] SIMs can be defined in terms of parameters provided by the
SIM user. For example, the entire structure of an adder can be
described in terms of a parameter "width", representing the widths
of the inputs and outputs of the adder; therefore all bus widths,
loop counters, etc. in the code are parametric. These parameters
are similar to the function/subroutine parameters in programming
languages such as C or Java. Such programming languages allow the
user to define a function header such as "adder(int width)", with
the formal parameter "width". The function body uses the symbolic
variable "width" in various computations. The actual value of
"width" is known only when the user invokes the adder function
(e.g., "adder((widthA+widthB-widthC)*2+1)"), causing the algebraic
expression to be evaluated and the value to be placed in the
parameter "width" before executing the function body.
[0142] While SIMs can be completely defined and used in the form of
Java programs, classes, and methods, SIMs may also be specified,
created, and used through schematics or HDL-style languages. When a
SIM is used in a schematic editor, it is first instantiated, its
parameters are assigned values, and its ports are then
interconnected to other ports of other SIMs. The instantiated SIM
is considered to be a child SIM of the SIM represented by the
schematic drawing. The parameters of the child SIM can be defined
either as constants or as expressions involving the parameters of
the parent SIM. The user can attach new parameters to a SIM. The
class ParametricSim extends the basic SIM class to provide the
ability to add and evaluate parameters. The following parameter
types and methods are supported: Integer, Float, Double, Boolean,
String, Choice, FileName, and Vector. Each parameter type has
associated add, get, and set methods of the form:
[0143] void addParam (String name, <type> value);
[0144] For example: void addParam (String name, int value);
[0145] <type> getParam<type>(String name);
[0146] For example: int getParamInt (String name);
[0147] void setParam (String name, <type> value);
[0148] For example: void setParam (String name, int value);
[0149] The Integer, Boolean and String parameters have an
additional "add" method that takes a string expression instead of a
value, and their setParam method has a third argument, as in the
following examples. void addParam(String name,
<type>defaultValue, String expression);
[0150] void setParam(String name, <type>defaultValue, String
expression);
[0151] The expression string for Integers is any valid Java integer
expression comprising constants and/or variables, with the
variables being the names of other parameters of the SIM or its
parent (if a parent is defined). Similarly, the expression string
for Booleans is any boolean-valued Java expression with the same
restrictions as the Integer expression. String expressions have the
syntax of Java String expressions. All of these expressions are
stored in symbolic form, and are interpreted as late as possible in
the elaboration process.
[0152] The Choice parameter contains a Java Vector (i.e., an
indexed dynamic array) of arbitrary objects, and an index to
indicate which one of the objects in the vector is selected. Choice
parameters are similar to enumerated types in programming
languages.
[0153] The Vector parameter contains a Vector of objects, and
allows SIM designers or users to specify a coefficient list or an
array of memory initialization values as parameters.
[0154] The FileName parameter is an extension of the string
parameter, where the string represents a file name. Schematic tools
can take special action on a FileName parameter, such as presenting
a file browser to enable the user to select the appropriate file
name.
[0155] All the variable names used in parameter expressions are
either the names of other parameters of the same SIM, or the names
of parameters of the parent SIM, if a parent SIM exists. In this
embodiment, variable names should not contain the special character
"$", as this character is prefixed to a variable to indicate that
it is a parameter of the parent SIM.
Example SIM
[0156] FIG. 2 shows a partial listing 200 of a SIM called
X4keAdderxWReg, which illustrates some of the concepts discussed
above. In particular, in the example of FIG. 2 it is seen that the
width of the adder is established only when an instance of class
X4keAdderxWReg is actually instantiated, by calling the constructor
of this class. Therefore, the adder implementation is independent
of the adder width. The listing shows three ports, "a", "b", and
"sum". The listing also shows two internal nets, "cy" and "clsum".
One or more instantiations of SIM "CY4" are then added, the number
of child SIMs incorporated depending on the "sampleWidth" width
parameter set when the adder SIM is instantiated. In this example,
CY4 is a carry logic module for Xilinx XC4000 Series FPGAs and is
set to functional mode "ADD-FG-CI". Partial listing 200 illustrates
static parameter passing as implemented in programming languages
such as Java or C. For example, in FIG. 2, the "sampleWidth"
parameter is passed from parent SIM x4keAdderxWReg to child SIM CY4
through an expression (e.g., sampleWidth-2*i-1) that is parsed when
SIM x4keAdderxWReg is compiled, at which time the expression must
be fixed. Dynamic parameter evaluation is described later with
respect to class ParametricSim.
SIM Interfaces
[0157] An "interface" is a Java language construct comprising a
collection of methods with specific signatures. Any class can
implement these methods (with the same signatures) in some way that
is appropriate for the class. A class that implements all the
methods of an interface definition is said to implement that
interface. SIMs can choose to implement a variety of interfaces to
make themselves more useful in different contexts. For example, a
SIM can implement both a CustomizerInterface to allow a schematic
editor or some other tool to query and set the parameters of the
SIM, and a SimulatorInterface to provide a behavioral or structural
simulation model. The following are some of the more useful
interfaces for a SIM designer or tool builder.
[0158] CustomizerInterface: Allows tools to query and set the
parameters of a SIM. The CustomizerInterface includes three
methods:
[0159] 1) Vector getParams(): Allows an external agent (for
example, an external tool or another SIM) to get a Vector of all
the parameters of the subject SIM.
[0160] 2) void setParams(Vector): Allows an external agent to set
the values of all the parameters of the subject SIM.
[0161] 3) Panel getCustomizerPanel(): Allows an external agent to
display a graphical panel produced by the subject SIM to obtain
user input. If this method returns null, the external agent uses
the first two methods to create a default graphical user interface,
and set the values of the parameters.
[0162] A standard extension of the SIM class provides a default
implementation of the CustomizerInterface.
[0163] CustomizerPanelInterface: Allows tools to use a special
graphical dialog to query and set the parameters of a SIM.
[0164] DRCInterface: Allows a SIM to perform its own design rule
checks in addition to or in the place of certain standard checks
performed by a DRC tool.
[0165] SimulatorInterface: Allows a SIM to implement its own
behavioral/structural simulation model for use in a compiled code
or event driven simulator.
Standard Extensions to SIMs
[0166] The SIM package defines five classes that extend the basic
Sim class with default implementations of abstract methods, default
implementations of certain interfaces, and/or additional
methods/variables for extra functionality. The five extended SIM
classes described below simplify the work of the SIM designer in
commonly encountered usage models for SIMs.
[0167] FIG. 3 shows the basic Sim class 300, the five extended
classes 301, and their inter-relationships. In FIG. 3, a class
drawn with a dotted line is an abstract class 301A. A class drawn
with a solid line is a concrete class 301C. An arrow between two
classes means that the class at the base of the arrow extends the
class at the head of the arrow.
[0168] 1) The class ParametricSim extends the basic SIM class by
providing methods for storing and accessing parameters of various
types. Class ParametricSim provides default methods to implement
CustomizerInterface, and adds two new abstract methods that have to
be made concrete by the user.
[0169] 2) The class SchematicSim extends ParametricSim to interface
to a schematic editor.
[0170] 3) The class DesignSim extends SchematicSim by providing
trivial implementations of all its abstract methods, and adding
some extra fields. This class is designed to be used as a generic
or work-space SIM in the schematic editor and other tools.
[0171] 4) The class ImplementedSim extends the basic SIM class with
a default "implement" method. This class serves as the base class
for all SIMs whose context and structure (logical structure, not
physical structure or placement information) are completely
determined at creation time, so a separate "implement" method is
redundant. A SIM that extends the ImplementedSim class comprises
source code that closely resembles a Java (or any other high level
language) program.
[0172] 5) The class HDLSim extends ParametricSim to provide an
interface that is similar to the netlist-building constructs found
in hardware description languages such as VHDL or Verilog. In
particular, it allows SIM constructors to have no parameters, and
allows the user to set individual parameters after instantiating a
SIM. After setting all parameters of interest (other parameters
take default values) the user invokes a single addHDLSim method
that does all the required work.
Class ParametricSim
[0173] A parametric SIM has two manifestations, depending on the
context in which it is used. When a SIM is used in a schematic
editor, the usage model is as follows:
[0174] 1) The user selects a SIM from the library;
[0175] 2) A dialog (preferably graphical) is presented to the user
to set the parameters of the SIM;
[0176] 3) The user instantiates the SIM in the drawing;
[0177] 4) The user connects the SIM to other SIMs in the
drawing;
[0178] 5) Parameter values of the SIM are updated;
[0179] 6) Connections to the SIM are modified.
[0180] Hardware description languages such as VHDL allow a user to
instantiate a module as follows:
[0181] module1: modulename
[0182] generic map ( param1.thrfore.value1,
param2.fwdarw.value2)
[0183] port map ( port1.fwdarw.signal1,
[0184] port2.fwdarw.signal2);
[0185] The basic sequence of operations when using a SIM in the HDL
environment is:
[0186] 1) The user selects and instantiates a module;
[0187] 2) The user sets the parameters of the module;
[0188] 3) The user connects the module to other modules (through
signals).
[0189] The first four steps in the schematic usage model are
similar to the three steps in the HDL usage model, and any SIM that
can be used in either environment has to support these operations.
The designer of such a SIM has to implement the
CustomizerInterface, and provide a constructor that does not
require as parameters any of the external nets connected to the
SIM. The CustomizerInterface specifies a vector of parameters in
the getParams and setParams methods. These parameters are instances
of predefined parameter classes such as StringParam or ChoiceParam
or DoubleParam. The parameter values are either constants, or
expressions involving other parameters of the subject SIM or
parameters of the parent SIM of the subject SIM. While each SIM has
its own set of parameters, the task of maintaining a set of
parameters, presenting them to the user, and updating the values
received from the user via the CustomizerInterface is common to all
SIMS. The class ParametricSim provides code for performing all
these common tasks, leaving the SIM designer with only the task of
specifying things that are unique to that SIM.
[0190] Class ParametricSim maintains a hashtable of parameters for
the SIM, and provides default getParams and setParams methods that
get and set values from the hashtable. The ParametricSim class also
provides methods for creating and adding new parameter objects to
the hashtable, and evaluating parameter expressions to obtain
actual parameter values. The SIM designer can therefore create a
new SIM by extending ParametricSim, and writing the required
constructor and the other methods declared abstract in
ParametricSim. These methods include addAllParams and
checkParams.
[0191] void addAllParams(): Should be invoked in the SIM
constructor; should specify all the parameters to be added to the
hashtable. FIG. 4 shows example code 400 for the addAllParams
method. In example code 400, String, Integer, and Boolean
parameters are defined and added using the addParam method. Then, a
Vector of choices "Area" and "Speed" is created. The Choice
parameter is then added to the invoking SIM by passing the vector
to the addParam method.
[0192] String checkParams(): Invoked from the setParams method.
This method allows the designer to specify any consistency or error
checks on the parameters provided by the user, and to update class
variables from parameter values. FIG. 5 shows example code 500 for
the checkParams method. In example code 500, the parameter value
widthA is checked for compliance with its range conditions (between
2 and 128, inclusive). If widthA is not within its designated
range, an error message is generated. Otherwise, the widthA and
widthB parameter values are used to define the widths of three
predefined ports "inputA", "inputB", and "output". The last few
lines of example code 500 set an internal flag "updateImplem" if
certain conditions are met.
[0193] As earlier mentioned, parameter expressions may be provided
to the parametric SIM, instead of fixed parameter values. These
expressions are supplied to the running (i.e., executing) instance
of the parametric SIM and are not part of the Java code for the
parametric SIM. So these expressions are not "static" expressions,
as in VHDL or as in the example of FIG. 2. These expressions are
parsed and evaluated by the SIM at elaboration time. Since the
expressions may reference parameters of the parent SIM, which may
also be evaluated at elaboration time, the entire parameter
evaluation scoping and inheritance mechanism is dynamic.
Class SchematicSim
[0194] The usage model for a SIM used in the context of a schematic
editor was described above with regard to the ParametricSim class.
Class ParametricSim supports the first four of the six operations
of the schematic usage model.
[0195] Class SchematicSim extends Class ParametricSim by adding
another abstract method, updateImplementation, to support the last
two steps of the schematic usage model.
[0196] boolean updateImplementation(): Invoked by the schematic
editor of one embodiment after setting the parameters of the
subject SIM. Allows the SIM to indicate whether the external
connections to its ports need to be modified (e.g., if the number
of ports has changed, or if the width of some port has changed).
FIG. 6 shows example code 600 for the updateImplementation method.
In example code 600, the "updateImplem" flag from FIG. 5 is
checked. If true, then the existing logical structure of the SIM
containing the method is removed and a new logical structure is
created.
Class DesignSim
[0197] Every user-defined SIM is represented by a unique Java
class, but it is sometimes useful to create temporary, generic SIM
classes. For example, suppose a schematic editor creates an unnamed
SIM to which the user adds structure in the form of child SIMs,
interconnecting nets, and various parameters or attributes. A
floorplanner or layout editor could group together various SIMs
into a larger SIM for defining their placement. The class DesignSim
extends Class SchematicSim, and provides default implementations of
all the methods declared abstract in its parent class. When the
user creates a new schematic drawing, it is stored as a DesignSim
object until the user decides to give it a unique class name.
Class ImplementedSim
[0198] Class ImplementedSim extends the base SIM class in such a
way that the task of the programmer is simplified. In this context,
the programmer is a person who creates a new SIM by writing code,
instead of using a graphical tool such as a schematic editor. The
main difference between the usage model of ParametricSims and
ImplementedSims is that the context and the parameters of the
ParametricSim are not known at the time the SIM is created, but the
context and parameters of the ImplementedSim are known at creation
time. The "context" includes the external nets connected to the SIM
and the physical device location where the SIM is implemented.
Therefore, the ImplementedSim can have a constructor that takes as
arguments all the SIM parameters and all nets connecting to the
SIM. This approach is similar to the manner in which a VHDL Entity
is declared. VHDL separates the generic parameters and the ports,
but the ImplementedSim constructor has a single list of parameters
containing both the SIM parameters and the nets.
[0199] For example, the constructor 700 shown in FIG. 7 is for a
SIM that is specific to the XC4000E family of FPGAs from Xilinx,
Inc. The example shown in FIG. 7 includes parameters that specify
all the connecting nets, as well as the size of the SIM and the
connecting nets.
[0200] The base SIM class has an abstract method called "implement"
that provides parameters such as the device on which the SIM is to
be implemented and the location of the SIM on the device. The
ImplementedSim constructor already contains all this information so
the SIM user does not have to call the implement method separately
to create an actual implementation of the SIM. The ImplementedSim
class extends the base SIM class by providing a default "implement"
method, which can be overridden if necessary to provide special
capabilities for the SIM.
[0201] FIG. 8 shows an example of a constructor 800 for a
user-defined SIM that extends ImplementedSim. The constructor in
FIG. 8 first creates all the ports of the SIM using the addPort
method, and then creates all the child SIMs using the addSim
method, along with the child SIMs' own constructors. The addPort
method creates a port that is connected to both the external net
passed in through the SIM constructor, and a newly created internal
net with the same name as the port. This internal net is returned
to the constructor, so all the child SIMs are connected to the
internal nets of the subject SIM.
Class HDLSim
[0202] Although hardware design languages (HDLs) are similar to
high level programming languages (HLLs), there are certain
fundamental differences between commonly used HDLs such as VHDL or
Verilog, and commonly used HLLS such as C++ or Java. When HDLs are
used to build up structural netlists, the biggest of these
differences is the ability to use keyword parameters. HDLs allow
modules to have a set of generic parameters and ports that can be
assigned by name (i.e., by keyword) when the module is
instantiated. The order in which the port connections are specified
at instantiation time is independent of the order in which the
ports were created within the module. In Java or C++, a module
constructor has a list of generic, port, and net parameters. These
are positional parameters, and the actual parameter list must match
the formal parameter list exactly in terms of both "type" and
number. The only exception is that trailing parameters can be
assigned default values, and can be omitted from the actual
parameter list if the resulting signature is still unique. The
HDLSim class overcomes this limitation of Java by breaking up
module instantiation into multiple steps, each corresponding to
setting a single keyword parameter, or a single invocation of the
default constructor. As a result, the HDLSim class provides the
following HDL features:
[0203] 1) Name-based connection to ports of a component (similar to
VHDL: port map( a.fwdarw.a1) );
[0204] 2) Name-based parameter setting;
[0205] 3) Default assignment of constants to port/generic
parameters;
[0206] 4) Use of generic parameters to define port widths; and
[0207] 5) Extension of library modules with new functionality
and/or pins without affecting the calling modules.
[0208] Class HDLSim extends ParametricSim, and adds certain generic
methods to allow a user-defined SIM to resemble HDL code in gross
syntax and semantics. In this embodiment, every HDLSim contains the
following methods.
[0209] public void addAllParams() {}: Defines all the generic
parameters of the SIM. This method is abstract in class HDLSim, and
each SIM that extends HDLSim must provide a body for this method.
The method body consists of zero or more calls to the "addParam"
method provided by ParametricSim. An example addAllParams method
900 is shown in FIG. 9. Three SIM parameters, "inwidth",
"num_bits", and "outwidth", are defined.
[0210] public <class_name> {}: Class constructor. Invokes the
addAllParams method and creates all the ports of the SIM. If port
widths are determined by the generic parameters when the module is
instantiated, the port widths are set to 0 in the constructor.
Example code 1000 for the public class constructor is shown in FIG.
10. The constructor in example code 1000 has no arguments. The
constructor creates all the parameters of the SIM in which it is
defined. It also creates all the ports of the SIM. However, it does
not create the logical or physical structure of the SIM.
[0211] public void setPortWidths() {}: Sets port widths at module
instantiation time. This method is an abstract method in class
HDLSim, and any SIM extending HDLSim must provide a body where
generic parameters are evaluated and port widths are set. An
example setPortWidths method 1100 is shown in FIG. 11. The
setPortWidths method 1100 in FIG. 11 sets the width of the SIM
ports "inbits" and "sum" to the values of the SIM parameters
"num_bits" and "outwidth", respectively.
[0212] public void implement (Family, row, col, site) {}: Builds
the logical and (optionally) the physical structure of the SIM.
This method is declared abstract in class Sim. The four parameters
to this method are the device family on which the SIM is
implemented, the row and column on the device where the SIM's
reference point is placed, and an extra "site" parameter that can
provide a more precise location than just the row and column (e.g.,
can designate into which function generator in a CLB the element is
to be placed).
[0213] addHDLSim (HDLSim childSim): Generic method to build the SIM
structure. Invokes the setPortWidths method and the implement
method on the child SIM, and performs certain other actions to
place the child SIM at a particular location on the chip, before
adding the child SIM to the parent SIM's list of children. When any
SIM instantiates an HDLSim, it first sets all the parameters of the
HDLSim, and then invokes this single method to build the structure
of the HDLSim.
[0214] FIG. 12 provides an exemplary implement method 1200 that
illustrates the use of the addHDLSim method. Implement method 1200
first creates an adder SIM called "small_adder", then sets the
values of the adder SIM parameters based on input arguments
specified for the implement method. The addHDLSim method is then
invoked to build the logical and physical structure of the adder.
The ports of the adder are then connected to the ports of the
invoking SIM.
Helper Classes and Methods
[0215] The described embodiment of the invention includes
additional classes and methods to support SIM functions. These
classes and methods include:
[0216] 1) netlister classes that support reading a netlist or
generating a SIM output in the form of a netlist (e.g., XNF, EDIF,
structural VHDL);
[0217] 2) a placement object that holds information related to the
actual physical implementation of the SIM; and
[0218] 3) design rule and error-checking methods.
[0219] SIM designers, SIM users, and others can create any other
helper classes as required, to support the use of various external
tools or for other reasons. Netlister, placement, and design rule
classes and methods are described in the following three
sections.
Netlister Classes and Methods
[0220] The SIM data structure models nets as objects with a certain
width that are referenced by all the ports that connect to the net.
This model provides a compact and efficient representation of the
SIM in memory, and simplifies the creation of SIMs. CAD tools such
as simulators, placers, and routers sometimes require a netlist
that contains only single-width nets, and provides efficient
methods to access all the ports and modules connected to a net.
Given a SIM, the netlister classes build up additional data
structures and provide a convenient interface for the CAD tools.
The netlister classes also provide a convenient way to read and
write netlist files in various standard formats such as XNF or
EDIF. (XNF is the Xilinx Netlist Format from Xilinx, Inc. EDIF is a
well-known standard netlist format.)
[0221] For example, a SIM can be output in flattened XNF format by
writing code that looks like the following:
[0222] // code to construct a SIM called ad3
[0223] // the output code below:
[0224] Output output =new Output(); // create a new Output object
output.doXNF(ad3, true);
[0225] // tell the output class to print out the SIM in XNF
[0226] // format, preserving user defined net names
[0227] The Output class 1300 shown in FIG. 13 first creates a
netlist using the Netlist class, and then outputs the netlist in
the required format. The Netlist class is aware of special
requirements of different output formats, such as net-naming
conventions.
Placement Information Classes and Methods
[0228] Every SIM has an associated PlaceInfo object that is created
along with the SIM. The PlaceInfo object holds information related
to the actual physical implementation of the SIM. This information
includes the type of device on which the SIM is implemented, the
tile location (row, column) within the device, and, if applicable,
a location within this tile. Tile location information in this
embodiment can be specified in either of two forms: absolute tile
coordinates on the device, or relative tile coordinates with
respect to a designated ancestor of the SIM in the SIM instance
hierarchy.
[0229] Each PlaceInfo object has an attribute called "hsetType"
that determines the coordinate system of the associated SIM (the
"peer SIM"). If the hsetType is NONE, the tile location corresponds
to absolute device coordinates. If the hsetType is PARENT or OWN,
the tile location information is understood to be an offset from
the tile location of the nearest ancestor of the SIM whose hsetType
is OWN or NONE, if such an ancestor exists. If a SIM has no parent
SIM, its hsetType is interpreted as NONE, regardless of the actual
hsetType information stored in the PlaceInfo object.
[0230] The PlaceInfo class provides methods to query and set the
hsetType attributes. Changing the hsetType attribute from PARENT to
OWN or from OWN to PARENT can cause the locations of descendant
SIMs to be recomputed.
[0231] In certain situations, the SIM designer may not be able to
provide any placement information for a SIM. In such cases, a flag
is set in the PlaceInfo object to indicate that the placement
information is not valid. The SIM designer can also mark the
location of the SIM as unchangeable, or changeable only under
special circumstances. In one embodiment, these capabilities are
implemented through a variable called lockval that can take on
integer values ranging from "FREE" to "LOCKED", where "FREE" is an
integer corresponding to "placement not valid and the SIM is free
to move to any location on the device", and "LOCKED" is an integer
corresponding to "the SIM has a valid placement and is not free to
move on the device", and all values between FREE and LOCKED
indicate that the SIM has a valid placement, and can be moved to a
different location on the device. This form of indicator is well
known in the art of FPGA software engineering.
[0232] The PlaceInfo object includes a vector of "implementations"
and a vector of "constraints", where "Implementation" and
"Constraint" are defined below. A SIM implementation specifies the
location of every constituent in the SIM's subtree. (A "subtree" is
a hierarchy of child SIMs.) For example, an implementation might
comprise a list of RLOC-specified placements for each flip-flop or
function generator in a SIM. Alternatively, the implementation
might simply comprise a listing of sub-SIMs and their locations.
One method for constraining the placement of elements within a SIM
is described by Patterson et al in commonly assigned, co-pending
U.S. patent application Ser. No. 09/049,598 entitled "Method For
Constraining Circuit Element Positions in Structured Layouts",
which is referenced above and incorporated herein by reference.
Patterson describes a vector-based form of layout in which key
words or phrases such as "COLUMN" or "ROW" indicate the manner in
which the elements of the module are to be placed.
[0233] Example code 1400 for the PlaceInfo class is shown in FIG.
14. Example code 1400 illustrates a PlaceInfo class including a
vector of implementations and methods to enumerate and add these
implementations. The PlaceInfo class of FIG. 14 also illustrates
including a vector of constraints and methods to enumerate and add
these constraints.
[0234] FIG. 15 shows exemplary pseudo-code for the Implementation
class. (An implementation is represented as an object of the
Implementation class.) In an actual Implementation class, the curly
braces "{}" would enclose actual Java code implementing the
constructor and the "restore" method. (The comments delimited by
the character strings "/**" and "*/" provide information for the
JavaDoc utility, which provides on-line documentation for Java
code.)
[0235] Constraints on a SIM's layout are stored in objects of the
Constraint class 1600 shown in FIG. 16. In the example of FIG. 16,
a "RegionConstraint" constraint restricts a SIM's layout to be
contained in a rectangular device region, then defines resources
within the region that are unavailable to the SIM.
[0236] Other related information that can be obtained from a
PlaceInfo object includes a list of tiles occupied by the SIM, and
the bounding box of the tiles occupied by the SIM.
Design Rule Checking
[0237] The class SimDRC provides support for generic design rule
checks. Examples of such checks are checks for nets with no
drivers, nets with no loads, or SIMs with unconnected pins. In one
embodiment, each SIM can override the generic check for unconnected
pins to perform a more specific check. For example, a function
generator SIM with four inputs does not require any connections on
the pins that are not used in the equation implemented by the SIM.
In this case the generic connection check would flag an error, but
a specific check implemented by the SIM itself can eliminate these
spurious error messages. A SIM can implement the DRCInterface to
let the SimDRC object invoke the SIM's own DRC method.
[0238] Another kind of design rule checking, checking the validity
of parameters (both individually and with reference to other
parameters), is provided in the checkParams method of the
ParametricSim class.
SIM-Based Floorplanning and Placement
[0239] The term "floorplanning" is used herein to describe the
operation of computing or modifying both a SIM's location and its
"shape", i.e., the relative locations of all its descendants.
[0240] Traditionally, a design is floorplanned in a sequence of
"phases" using distinct algorithms such as min-cut, simulated
annealing, or by manual control. According to traditional methods,
only one algorithm is invoked at a time, and the algorithm is
invoked on the entire design. These methods and algorithms are
described by Sangiovanni-Vincentelli in "Automated Layout of
Integrated Circuits", pp. 113-195 of "Design Systems for VLSI
Circuits", edited by G. De Micheli, A. Sangiovanni-Vincentelli, and
P. Antognetti, (hereinafter Sangiovanni-Vincentelli) published 1987
by Martinus Nijhoff Publishers, which pages are incorporated herein
by reference.
[0241] SIM-based floorplanning is organizationally different from
prior methods. Instead of a sequence of algorithms that operate on
the design data, the SIM representation itself includes or
references algorithms to compute layout. Every SIM in the hierarchy
can optionally include one or more methods that floorplan the SIM
in context. If a SIM does not include at least one such method, one
of its ancestors must include at least one method that lays out the
SIM in the context of the ancestor's subtree.
[0242] Distributing these layout algorithms throughout the design
hierarchy has the benefit of localizing algorithms according to
local structure in the design. Because a design hierarchy is often
structurally heterogeneous, the most efficient layout approach
should be similarly heterogeneous. The approach described herein is
especially well-suited for constructive methods when the local
structure is well-understood by the designer. Further, this type of
distributed layout can speed implementation (compile-time) and
improve the final layout. For example, a general algorithm such as
simulated annealing is not a particularly efficient way to order
the constituents of a complex datapath. (The simulated annealing
algorithm is essentially optimization via random search. New
placements are chosen at random, then compared to the current
placement and either accepted to replace the current placement, or
rejected. This random search continues until the placement has
converged to a final state that is acceptable based on a specified
cost function.) A SIM designer who knows the best layout strategy
for a given SIM can embed a special-purpose algorithm within the
SIM that utilizes this optimal strategy.
Planner-Based Floorplanning
[0243] A Planner is an object that can be attached to a SIM's
PlaceInfo object to compute the SIM's floorplan. The floorplan is
computed by invoking the Planner's execute method. Because SIMs
form a hierarchy and each descendant SIM (i.e., each SIM lower in
the hierarchy) may itself have an associated Planner object,
planner-based floorplanning distributes SIM layout operations
through the hierarchy, as previously described.
[0244] Although the application to floorplanning is novel, defining
Planners that compute layouts is similar in function to defining
methods for geometry management in modern windowing systems such as
the "X" windowing system and Java AWT. However, floorplanning
constraints and objective functions are far more complex than those
associated with windowing systems, hence floorplanning has much
greater computational complexity than geometry management.
[0245] The Planner approach to floorplanning is extremely flexible,
since the SIM designer and user are free to write their own
Planners. The public interfaces for SIMs, PlaceInfo objects, and
Planner objects allow dynamic reassociation of Planners to SIMs and
vice versa, and it is possible for a Planner to traverse a SIM
hierarchy however it wishes (top-down, bottom-up, or a combination
thereof). A Planner can, in fact, re-associate and invoke different
Planners at different hierarchical levels.
[0246] In one embodiment, Planner is an abstract class, so Planner
objects must be instances of a class that extends the Planner class
to implement the abstract execute method. FIG. 17 shows an
exemplary Planner abstract class 1700.
[0247] A SIM can be associated with a Planner by invoking the
setSim(Sim s) method, which also updates the SIM's PlaceInfo object
to refer to the Planner. The setPlanner method can be multiply
invoked to associate different Planners with a SIM. A planner can
call itself recursively. A Planner can also replace itself with
another Planner.
Planner Examples
[0248] FIGS. 18-25 show several examples of Planners using a
variety of algorithms.
[0249] FIG. 18 shows a Planner 1800 that cycles through a series of
precomputed shapes. The SIM designer or user may have created
several implementations and stored them in the SIM's PlaceInfo
object. The simple Planner in FIG. 18 cycles through all available
implementations, scores each implementation according to a
predetermined scoring scheme, and selects the implementation with
the best score.
[0250] FIGS. 19 and 20 show a Planner called "RowPlanner" that is a
special-purpose linear Planner. (The Planner comprises the code
1900 of FIG. 19 followed by the code 2000 of FIG. 20.) For a SIM
that implements a data path, the constituents are often laid out in
a simple linear arrangement. The Planner in FIGS. 19 and 20
performs the layout of such a structure, placing the constituent
SIMs in a row. Note that the constituent SIMs need not be
identical, nor of the same size. The analogous column Planner
("ColumnPlanner") is very similar to the row Planner. Further,
since sub-SIMs can also have row or column Planners, a SIM can
easily be laid out in a slicing floorplan. (Slicing floorplans are
described by Sangiovanni-Vincentelli, referenced above.) A system
architect may decompose a design into large functional blocks that
will be developed in parallel by different engineering teams. The
system architect partitions the design into SIMs, and the device
into disjoint regions. A Planner can use simulated annealing to
place constituents within one such subregion, as shown in the
Planner 2100 of FIG. 21.
[0251] Planners such as those shown in FIGS. 18-21 can be invoked
sequentially so that the overall context is built incrementally.
However, for some designs, by appropriately defining the interface
between SIMs and regions, the individual floorplanning problems can
be decoupled. In these designs, the different Planners can be run
concurrently.
[0252] Rather than caching multiple implementations, the user (or
code) may instead invoke several algorithms on a SIM as shown in
the "MetaPlanner" class 2200 of FIG. 22. Using a Planner such as
the one in FIG. 22, one could, for example, combine the Planners of
FIGS. 18-21 to compute a number of implementations, then cycle
through the implementations, keeping the implementation with the
best score.
Heterogeneous Planners
[0253] FIG. 23 shows the SIM structure for a simple exemplary RISC
processor that comprises three main functional blocks: a register
file, a datapath, and control circuitry. In this example, the
datapath is highly structured and can be described by a slicing
floorplan, and the control logic is structurally random (i.e., has
no particular structure).
[0254] Each functional block in the RISC processor is represented
as a SIM. The top-level SIM 230 corresponds to the complete RISC
processor, and has two child SIMs, SIM A (231) and a Control SIM
(232). SIM A (231) also has two child SIMs, a register file SIM
(233) and a datapath SIM (234). The register file SIM (233)
incorporates sixteen register SIMs (R0-R15). Each register SIM
includes 32 D flip-flops (DFF0-DFF31). The register file and
datapath SIMs are grouped together in SIM A partly because they can
efficiently use the same layout algorithm.
[0255] FIG. 24 is a high-level drawing of the RISC microprocessor
of FIG. 23 mapped into an FPGA. Each register in the register file
(SIMs R0-R15) includes or references a ColumnPlanner that stacks
the constituent D flip-flops (DFF0-DFF31) in a column 245 as
indicated in FIG. 24. The register file SIM includes or references
a RowPlanner that places the registers (R0-R15) in a row (not
shown). In this manner, register file SIM 233 generates an array
structure 243. The datapath SIM's (234) slicing floorplan is
computed by a user-specified SlicingPlanner and mapped into a
region 244 of the FPGA.
[0256] SIM A (231) includes or references a RowPlanner that places
the register file sub-SIM to the left of the datapath sub-SIM to
create region 241.
[0257] Because the control logic is assumed to be structurally
random, the Control SIM (232) includes or references an
AnnealingPlanner that computes the SIM's layout using a simulated
annealing algorithm. (The simulated annealing algorithm is
particularly suited to the placement of random logic.) By setting
the Control SIM's region constraint to be the entire chip (region
242 in FIG. 24), the annealer can intersperse the control logic
with the logic in SIM A if doing so lowers the placement cost.
[0258] FIG. 25 shows a Planner 2500 for the top-level SIM (230) of
FIGS. 23 and 24. The sequence of calls initiated by the execute
method in top level Planner 2500 is as follows:
[0259] I) Top-level invokes SIM A's RowPlanner
[0260] A) Sim A Planner invokes Register file's RowPlanner
[0261] 1) Register file invokes R0's ColumnPlanner
[0262] 2) Register file invokes R1's ColumnPlanner . . .
[0263] 16) Register file invokes R15's ColumnPlanner
[0264] 17) Register file lays out R0-R15 in a row
[0265] B) Sim A Planner invokes SlicingPlanner
[0266] 1) SlicingPlanner lays out the datapath.
[0267] C) Sim A RowPlanner lays out datapath to the right of
register file.
[0268] II) Top-level Planner invokes Control SIM's
AnnealPlanner
[0269] A) Control Sim's AnnealPlanner lays out the Control
logic
Pre-Routed SIMS
[0270] In one embodiment, all routing is performed by well-known
routing tools such as those currently available from Xilinx, Inc.
However, another embodiment of the invention allows SIMs to be
pre-routed, as is now described.
[0271] An FPGA includes a uniform array of tiles, plus global
resources that are not part of any tile in the array. Examples of
such global resources are clock buffers, configuration logic, or
macro blocks such as RAMs and PLLs. Several other resources such as
clock lines or long lines are shared by (and can be accessed by)
more than one tile. If a SIM at tile location (x,y1) wants to drive
a long line passing over that tile, then some other SIM at location
(x,y2) might see the same long line, but should not be able to
drive it. SIMs can preferably describe their shared-resource
requirements using a simple method such as Vector
getSharedResourceReq(). A tool that places SIMs together on a
device can invoke the getSharedResourceReq method to avoid resource
conflicts. For example, when SIMs without routing are used in the
context of a shared-resource manager, a SIM requests the manager to
give it exclusive use of a shared routing resource, waits for the
request to be granted, and (if granted) uses the resource. This
concept extends to dynamically reconfigurable systems where the
shared-resource manager is the "operating system", which monitors
the requirements of the SIMs and swaps them in and out of the
device as necessary. In the case of reconfigurable systems,
available resources may include not just global routing, but also
function generators, registers, I/O ports, and so forth.
[0272] The MeshSim concept allows a SIM to automatically place and
interconnect child SIMs in a mesh pattern. In one embodiment, the
mesh is a 2-dimensional object corresponding to an array of CLBs on
an FPGA. In essence, this embodiment allows a SIM to reserve
routing resources on a target device (e.g., an FPGA), and allocate
these resources to its child SIMs. Using a defined protocol, each
child SIM can request and reserve routing resources, as well as
placement resources (such as flip-flops and function generators in
the CLBs) through the parent SIM. The routing resources are not
necessarily limited to local or nearest neighbor routing, but may
include interconnect lines spanning several CLBs and/or several
mesh rows or columns.
[0273] This embodiment includes four important elements:
[0274] MeshSim: A SIM having placement and routing resources with a
grid-like structure.
[0275] MeshElement: A SIM having defined locations for the Ports,
and methods for enumerating all the ports on each side of the
SIM.
[0276] MeshSimInterface: A set of rules (i.e., a "protocol") for a
SIM that allows child SIMs to be placed in the MeshSim and
automatically connected to resources on the grid.
[0277] MeshElementInterface: A set of rules for SIMs that want to
obtain resources from the grid.
MeshSimInterface
[0278] The following example illustrates a MeshSimInterface in two
dimensions, the Mesh2DSimInterface. The Mesh2DSimInterface allow sa
SIM to automatically interconnect & place child SIMs in a two
dimensional mesh pattern. This interface includes five basic types
of methods:
[0279] 1) methods for creating and initializing the mesh;
[0280] 2) methods for placing a SIM at a mesh location;
[0281] 3) methods for removing a SIM from a mesh location;
[0282] 4) methods for updating all the interconnections in the
mesh;
[0283] and
[0284] 5) methods for selectively updating the interconnections at
a particular location.
[0285] A SIM either implements all these methods by itself, or
simply inherits these methods by extending a Mesh2DSim.
("Extending" is a Java language concept that means inheriting
several methods and variables from a "super" or "parent" class, and
possibly adding more methods and variables, to form a new class.
Mesh2DSim is a 2-dimensional version of a MeshSim. 3-Dimensional
and higher versions have applications in the realm of
reconfigurable logic.) Once these methods are defined, the
elaboration phase of the SIM automatically creates the placement as
well as the routing for the subject SIM, as shown in FIG. 26. The
exemplary Java code 2600 in FIG. 26 is a partial listing for a
class SystolicArraySim that implements the Mesh2DSimInterface. Note
the use of methods defined in the Mesh2DSimInterface (initMesh,
setElementAt, updateConnections). Within code 2600 is a constructor
for the class SystolicArraySim that creates a mesh by invoking an
initMesh method also defined in the class (not shown in FIG. 26).
Then, the code creates a number of new SIMs ("SomeSim") that are
placed within the mesh. The resulting mesh is an array "numRows"
high and "numCols" wide. Because the SystolicArraySim class
implements the Mesh2DSimInterface, when the "SomeSim" SIMs are
added to the mesh they have the ability to reserve global routing
resources and to connect to their neighbors by abutment. Finally,
all the routing is generated by invoking an updateConnections
method also defined in the class (not shown). In example code 2600,
the same SIM is placed at each location in the mesh; however, in
other embodiments different SIMs are placed at different mesh
locations.
MeshElementInterface
[0286] In order for a MeshSim SIM to perform the routing for a
child SIM, the child SIM must implement the MeshElementInterface.
One version of the MeshElementInterface is the
Mesh2DElementInterface. This interface allows the SIM to present a
logical and physical view that includes an array of Ports on each
of the four sides, optionally including an array of global Ports.
For example, FIG. 27 shows two child SIMs (SIMC, SIMD) having a
common Port (SC is coupled to ND). (The physical view in FIG. 27 is
at a high level of abstraction, and does not correspond to any
specific device coordinates.) The Mesh2DSimInterface automatically
connects the "Southern" Port SC of child SIM SIMC to the adjacent
"Northern" Port ND of the neighboring child SIM SIMD.
[0287] The following example illustrates how the
Mesh2DElementInterface performs this automatic connection:
[0288] 1) Mesh2DSim implements the Mesh2DInterface, and has
elements SIMC and SIMD at adjacent rows of a single column within
the mesh.
[0289] 2) SIMC and SIMD implement the Mesh2DElementInterface, so
the ports on the South side of SIMC get connected to the ports on
the north side of SIMD.
[0290] 3) The clock nets of SIMC and SIMD are connected internally
to their global ports so the parent SIM can connect a single clock
net to all the child SIMs, irrespective of their physical location
in the mesh.
[0291] The above text describes the invention in the context of
SRAM-based FPGAs. However, the invention can also be applied to
other programmable ICs, including antifuse-based FPGAs, mask
programmable devices such as Application Specific ICs (ASICs),
Programmable Logic Devices (PLDs), and devices in which only a
portion of the logic is programmable. Some aspects of the invention
are further applicable to non-programmable ICs.
[0292] The above text further describes the invention in the
context of self implementing modules. However, after reading the
present application, it will be clear that many of the structures
and methods of the invention can also be applied to logic modules
that are not self implementing.
[0293] Those having skill in the relevant arts of the invention
will now perceive various modifications and additions which may be
made as a result of the disclosure herein. Accordingly, all such
modifications and additions are deemed to be within the scope of
the invention, which is to be limited only by the appended claims
and their equivalents.
* * * * *