Automatic generation of programmable logic device architectures

Details Automatic generation of programmable logic device architectures Automatic generation of programmable logic device architectures

1999-10-29

2003-10-07

Siek, Vuthe (Department: 2825)

Computer-aided design and analysis of circuits and semiconductor

Nanotechnology related integrated circuit design

C326S039000, C326S041000, C716S030000, C716S030000, C716S030000, C716S030000, C716S030000

Reexamination Certificate

active

06631510

ABSTRACT:

This invention relates generally to Programmable Logic Devices (PLDs), and more particularly to a method and system for generation and evaluation of architectures for such devices.
BACKGROUND OF THE INVENTION
Programmable Logic Devices (PLDs) are a widely used form of integrated circuit due to the flexibility provided by their customizable nature. In general PLDs include field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), simple programmable logic devices and laser programmable devices. Architecturally, a PLD includes logic blocks and input/output (I/O) blocks which are connectable through a programmable interconnect structure.
A typical PLD is an integrated circuit chip that, wholly or in part, consists of an array of one or more logic blocks, I/O blocks, and a programmable routing or interconnect network. The interconnect network can be programmed by a user to provide a connection between the logic and I/O blocks to achieve a desired logic function. A PLD can be a standalone device or be embedded in a larger integrated circuit such as ASICs or the like. Exemplary forms of such embedded PLDs are disclosed in U.S. Pat. No. 5,825,202 and U.S. Pat. No. 5,687,325.
The logic blocks may be comprised of a fixed logic function or may in turn also have programmable interconnect networks and programmable functionality. The logic blocks may be firer broken down into sub-blocks or grouped together as a cluster of logic blocks. These blocks may also include I/O circuits that enable connection to external circuits or to other parts of the chip as in the case of an embedded PLD. The I/O blocks are typically arranged at the periphery of a chip.
A PLD is typically arranged as a regular array of logic blocks, each of which may be identical or may be one of several different types (such as memory blocks, look-up table based blocks, p-term based blocks etc.). The conductors of the programmable interconnect network are typically arranged along rows and columns defied by the array of logic blocks, as shown schematically in FIG.
1
.
The architecture of a PLD specifies the structure of its logic blocks, I/O blocks and programmable interconnect network. In order to develop a high-quality PLD architecture, the PLD designer must evaluate the impact and utility of a wide range of architectural decisions and trade-offs. The performance of a PLD is typically judged on the basis of operational parameters of circuits implemented in the PLD. These operational parameters include speed of circuits implemented in the PLD, semiconductor or silicon area required to implement a given circuit in the PLD, power dissipation of the PLD after it has been programmed, reliability and routing flexibility.
The typical procedure for evaluating different architectures is shown in
FIG. 2. A
set of benchmark circuits is implemented in each PLD architecture (or architecture variant) of interest, and the operational parameters of the circuits are analyzed. Generally, PLD designers wish to experiment with as wide a variety of PLD architectures as possible in order to determine the architecture or class of architectures that best meets the operational parameters of interest.
However, in order to implement circuits in a PLD architecture of interest, the PLD designer requires a method of describing the PLD architecture to the CAD tool set. There are two basic components of a PLD architecture: the routing architecture which describes the routing resources or the programmable interconnect network; and the logic (or function) block architecture. Consider first the problem of describing the PLD routing architecture.
To specify a PLD architecture in its entirety, one must specify where every switch, routing wire and logic and IO block pin is located One must also specify which routing wires and logic and I/O blocks can be interconnected by programmable switches, and the delay of every programmable switch, routing wire and circuit path through a logic block in the entire PLD. This is an enormous amount of data—typically tens to hundreds of MB in size. Accordingly, it is not practical for a PLD architect to specify this data directly for every PLD architecture in which he or she is interested.
The most straightforward way of describing a PLD routing architecture is to create a directed graph (also called a routing-resource graph) that fully specifies all the connections that may be made in the routing of a circuit in the PLD. In essence, this requires the PLD designer to describe where every switch, interconnect wire, logic and I/O block connection pin is located. This description must specify which routing wires, logic blocks and I/O blocks can be interconnected by programmable switches. The description must also specify the delay of every programmable switch, interconnect wire and circuit path through a logic block, in the entire PLD. This is a very general representation of a PLD and is typically the data structure used internally by the routing tool. However, it is not very practical to specify this routing-resource graph manually because the routing-resource graph for a typical PLD requires an enormous amount of data—typically in the tens to hundreds of megabytes of memory in size. Essentially, this is too low-level a description for a PLD architect to use conveniently.
A more practical approach is to design a basic tile (consisting of a single logic block and its associated routing) manually, and create a program to automatically replicate and stitch together this tile into a routing-resource graph describing the entire PLD routing architecture. However, even the manual creation of a basic tile can be too time-consuming for most PLD architectures. A typical tile contains several hundred programmable switches and wires, so it can take hours or days to describe a single tile. Furthermore, the hand-crafted tile is severely limited in the PLD interconnect or logic block resources that may be varied—for example, a hand-crafted tile is generally designed for one value of the routing channel width, W (the number of routing tracks in a channel). In many architecture experiments, one must vary W in order to see how routable a given PLD architecture is, or to determine the minimum value of W that allows some desired faction of application circuits (say 95%) to route successfully. With a tile based approach, the PLD designer must hand-craft different tiles for each different value of W required to be tested. A PLD designer will often wish to investigate hundreds of different PLD architectures and tens of W values for each of these architectures. The net result is that the PLD designer is required to create thousands or tens of tho of different basic tiles.
There has been some prior work in describing PLD routing at a higher level of abstraction. In [1], Brown et al developed an FPGA router for use with island-style FPGAs. In order to quickly investigate FPGAs with different numbers of routing switches, they localized all the code that interacted with switch patterns to two routines, F
c
() and F
s
(). By rewriting these two routines, the FPGA designer can target their router (called CGE) to an FPGA with different switch pattern. The later SEGA router [2], used the same method to allow re-targetting to different FPGAs.
In the Emerald CAD system [3], an FPGA's routing is described by means of WireC schematics—essentially schematics annotated with C-language like code that describes switch patters. The Emerald system can convert these WireC schematics into routing-resource graphs for use by its FPGA router.
While CGE, SEGA and Emerald all reduce the labour required to specify a PLD architecture, they still require considerable hand-crafting effort. Instead of specifying every switch in a basic tile of an FPGA, these systems allow PLD designers to write software code (in either C or WireC) to generate all the switches in a basic tile. If the PLD designer writes sufficiently general code, it may be possible to change some interconnect and logic resources, such as the channel widt

Affiliated with

Also associated with

Rating

Automatic generation of programmable logic device architectures does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Automatic generation of programmable logic device architectures, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Automatic generation of programmable logic device architectures will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3172354