Context-sensitive self implementing modules

Details Context-sensitive self implementing modules Context-sensitive self implementing modules

1998-03-27

2001-09-18

Smith, Matthew (Department: 2825)

Computer-aided design and analysis of circuits and semiconductor

Nanotechnology related integrated circuit design

C716S030000, C716S030000, C716S030000, C716S030000, C716S030000, C709S241000

Reexamination Certificate

active

06292925

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
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.
2. Description of the Background Art
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.
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.)
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.
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).
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.
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 “netlisto is a description of a circuit comprising a list of lower-level circuit elements or gates and the connections (nets) between the to outputs and inputs thereof.)
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.
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.
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 MEi 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,O) CLB is designated as R1C0, corresponding to the (0,1) coordinate location. Although the iA 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.
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.
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 UX-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™ 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-BLO

Affiliated with

Also associated with

Rating

Context-sensitive self implementing modules does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Context-sensitive self implementing modules, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Context-sensitive self implementing modules will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2533006