Frequency driven layout system and method for field programmable gate arrays

Abstract

A device independent, frequency driven layout system and method for field programmable gate arrays ("FPGA") which allow for a circuit designer to specify the desired operating frequencies of clock signals in a given design to the automatic layout system to generate, if possible, a physical FPGA layout which will allow the targeted FPGA device to operate at the specified frequencies. Actual net, path and skew requirements are automatically generated and fed to the place and route tools. The system and method of the present invention evaluates the frequency constraints, determines what delay ranges are acceptable for each electrical connection and targets those ranges throughout the layout.

Description

BACKGROUND OF THE INVENTION

The present invention relates, in general, to a device-independent, frequency-driven layout system and method for field programmable gate arrays ("FPGA"). More particularly, the present invention allows an FPGA circuit designer to specify the desired operating frequencies of clock signals in the FPGA design to the frequency-driven layout system of the present invention which will then, if possible, generate a physical layout for the device that will allow it to operate at the specified frequencies. Actual net, path and skew requirements are automatically generated and fed to the place and route tools. This is effectuated by evaluating the frequency constraints, determining what delay ranges are acceptable for each electrical connection and targeting those ranges throughout the layout synthesis.

Field programmable gate arrays ("FPGA") are a relatively new technology, first introduced by Xilinx, Inc. in 1985. An FPGA consists of cells which can be programmed to perform a variety of logical functions and programmable interconnects to connect the logic cells in a general way. The cells and interconnects are used to implement complex logical circuits. The use of FPGA's continues to grow at a rapid rate due to their relatively shorter design cycles, reduced cost through logic consolidation and the flexibility offered by their re-programmability. With an FPGA's inherent flexibility also comes additional timing problems not encountered, for example, in the use of gate arrays due to the fact that an FPGA uses programmable switches having inherently less predictable and greater delay characteristics, fixed interconnect resources and logic cells which are generally coarser than other types of programmable devices.

However, despite the advantages offered by FPGA's, one of the significant shortcomings of the devices is their limited speed. Utilizing the automatic map, place and route tools provided by the FPGA manufacturers themselves, designs implemented in today's technology typically can achieve maximum operating frequencies of only about 30 to 40 Mhz. Nevertheless, even though the devices continue to attain faster operating speeds due to improved process technology, many of today's board level designs require operating frequencies in the 50 to 100 Mhz range. Moreover, competing technologies such as programmable logic devices ("PLD") and gate arrays are likewise becoming faster.

Previously, designers have attempted to maximize chip performance by becoming so knowledgeable in a particular device's architecture and proficient at designing in that particular device, that through meticulous design capture and manual place and route, the designers were able to do a more effective job of programming than with the use of the automatic tools provided by the FPGA manufacturer. Nevertheless, as such devices become larger and inherently more complex, it is increasingly more difficult to do the design manually. Moreover, with the introduction of additional FPGA's from still other manufacturers, whole new architectures are presented, each with its own unique strengths and weaknesses. It is, therefore, becoming increasingly difficult for a designer to become expert in working with each of the many different available designs.

Typically, the process for implementing a design in an FPGA begins with the device selection. In this regard, the designer typically attempts to maximize the efficiency of his implementation by careful selection of the device, given its inherent limited size and speed. The second primary step is termed "design capture" and the vast majority of FPGA designs are "captured" utilizing schematics. Alternative design capture techniques include programmable array logic/programmable logic device ("PAL/PLD") behavioral languages such as Abel and Palasm and hardware description languages such as VHDL and Verilog. Functional simulation follows design capture. However, simulation of the actual timing cannot be done because the design exists only in terms of a logical representation and there is no physical information available on which to base the functional simulation.

The next step in the design process is the mapping of the design into the target device. Mapping, or "fitting" is that stage of the design in which the logical information is converted into the technology-specific components unique to the physical device targeted for implementation; that is, the logic blocks within a particular FPGA. Some device specific optimization can occur at this point and some designers wait until after mapping to do the above-described functional simulation thereby allowing them to do some preliminary timing simulation at the same time, even though, until place and route is complete, the only timing information available are the component delays.

Once the design has been converted into the logic blocks available within the specific targeted device, they must be placed and routed. This is typically a lengthy phase of the design process and, unlike gate arrays, FPGA's are fixed in size and if the design does not automatically place and route to completion, getting it to fit within the targeted device can prove to be very difficult. It is also important to understand that even a completely routed design can still be a long way from a working design. Getting the timing inside the targeted device to work properly, and at the desired operating frequency, is typically the most time consuming, and error prone, part of the design process.

Current design techniques include following the routing of all the connections with timing analysis or timing simulation (or a combination of both techniques) in order to find the problems that would keep the device from running at the desired operating frequency. This is an iterative process as the designer runs timing analysis (or simulation), finds and fixes a problem, runs timing analysis again to find the next problem and so on, until the design works. Other techniques which designers may implement include using static random access memory ("SRAM") based devices to build a prototype board to aid in identifying timing problems and then fixing them at lower operating speeds, raising the speed a notch, finding and fixing new problems and so on, until the desired operating frequency is obtained.

The inherent flexibility of FPGA's makes them more susceptible to timing problems than other technologies such as PAL's, PLD's, gate arrays and standard cells. For example, because of the more varied logic blocks used in FPGA's, (as compared to the relatively fine-grain elements utilized in gate arrays), without good device-specific optimization, logic functions may not be efficiently implemented to the particular architecture being used thereby resulting in extra delays through potentially critical paths. This problem is especially acute with relatively coarse-grain architectures such as AT&T's ORCA and Xilinx's 3,000/4000 Series devices. The number of permutations of logic elements within these devices is so great that current synthesis tools simply do not work, and in general, special mapping algorithms must be developed.

Another difficulty encountered in the programming of FPGA's is that the average interconnect delays within the typical device are greater than those on an associated printed circuit board ("PCB") or gate array, making it difficult to obtain perfectly synchronized timing while at the same time creating a higher penalty for poorly routed connections. The heterogeneous interconnect resources of the aforedescribed Xilinx devices, or the ability to route through logic blocks and architectures such as is found in Pilkington and Concurrent devices further complicates the situation. These unique FPGA characteristics make it particularly difficult to get all devices timing optimized, as the delay on any particular path can change significantly depending on which route is taken. This commonly results in skew and setup-and-hold violations.

Another problem encountered in programming FPGA's is that there may simply not be sufficient routing resources of the proper type to readily implement the design. Problems may be encountered in finding adequate routing resources such as dedicated clock lines or interconnects which can handle wide fanout circuitry with minimal delay variances. As has been previously described, interconnect resources within FPGA's are both fixed and relatively limited. In fact, the larger devices currently available are even more susceptible to these type of problems due to the increased demand placed upon them for global interconnect resources.

Further, the limited operating speeds of current FPGA's provide additional constraints forcing programmers to find alternative techniques for optimizing the devices for their maximum operating frequencies. As has been described, obtaining the maximum operating speed of a particular device is important, while at the same time, FPGA's are particularly susceptible to timing problems which affect the ability to obtain this desired performance. While the most important single step in implementing an FPGA design is choosing the proper device based upon its size, speed and architecture, most of the time spent in designing a working device is spent in getting the device timing to work.

Therefore, it can been seen that there are two primary ways to shorten FPGA design cycles. That is, one can either shorten the time it takes to get through the process of mapping, optimization, placement, routing, timing analysis and programming and/or reduce the number of times that one needs to go through that process to get working results. Typically, the design flow of a FPGA device comprises an iterative process of laying out the design, checking the timing using timing analysis and/or timing simulation, making changes to the layout and then rechecking the timing. Inherent in this iterative process is that changing the layout in one part of an FPGA in an attempt to fix a particular timing problem can easily cause a concomitant timing problem to appear somewhere else in the design.

Therefore, an optimal solution to these problems is the ability to set timing requirements up front and then have the design tools automatically meet them during implementation. Such a "timing-driven" approach shortens the design cycle by eliminating the need to run multiple iterations of place and route, or having to resort to manual "tweaking" of the design in an attempt to repair timing problems and maximize operating frequency. Moreover, having the ability to set timing requirements up front allows all critical nets of the device to be constrained by these timing requirements and, therefore, changes can be made to the design without causing concomitant timing problems elsewhere in the device. The ability to deal with timing issues dynamically, during placement and routing, allows the designer to shorten design cycles significantly.

In order for the design process of a FPGA to be truly timing-driven, two criteria must be met. First, the designer has to be able to specify the exact timing requirements up front, before the automatic design tools are engaged. Next, the automatic tools (mapping/placement/routing) have to be designed to complete their task while simultaneously adhering to the timing rules as input by the designer. Therefore, timing requirements, such as clock frequency, offset (the off-chip timing relationships between clock and data signals), and external setup/hold times should be considered along with physical constraints like package type and pinout assignments early in the design process. Because most of the timing requirements will be in terms of the logical design, such need first be converted into constraints that the physical implementation tools can relate to, such as specific paths, nets and maximum skew, before being handed off to the mapping, placement and routing routines. In general, FPGA programming can be broken down into four steps comprising technology mapping/optimization, placement, routing and programming.

With regard to the mapping/optimization step of FPGA programming, there are at least three different approaches. First, the optimization algorithms may be "fixed" and make pre-set tradeoffs between device area and speed. (Typically, optimizing for speed entails "flattening" the hierarchy of the circuitry, but this usually results in the circuitry taking up more space or area). Alternatively, the designer may be provided with control over whether the mapper optimizes more for area or more for speed. Finally, the mapper may be truly "timing-driven" although typically the only timing evaluation which may take place is component delays, since when there is no placement and routing information from which to determine interconnect delays, such cannot be considered.

The second step of FPGA programming is placement, and while speed enhancing mapping algorithms can provide incremental improvements over a solution which only provides timing-driven placement and timing-driven routing, a timing-driven mapping capability without timing-driven place and route will prove insufficient. Currently, the state of the art in FPGA design tools has relied on a process called "delay-based cleanup" to reduce overall interconnect delays. With delay-based cleanup, the designer is only allowed to enter net/signal priorities (that is, signal A has a higher priority than signal B). Such tools provide no capability to enter specific, detailed timing requirements and thus, such tools cannot possibly meet timing requirements because they have never been specified. Basically, a cleanup pass is run after the design has been routed to 100% completion with the tools attempting to reduce the average delay of all nets in the design. Among the disadvantages of such delay-based cleanup techniques is that the tools do the same thing each time, and as an example, high priority nets are always routed first, regardless of the results. Further, the tools don't necessarily balance the use of available resources, and some nets may be "faster" than they need to be only because they were routed first and, therefore, use up valuable routing resources that were not really needed, while others may not be fast enough. Finally, not enough information is provided for the tools to act intelligently, and there is no way for them to report back whether they have balanced the use of available resources or where potential problems may exist.

Utilizing truly timing-driven techniques, the designer may specify exact timing constraints for all paths, nets, skew and so forth (as an example, all points on signal A must be under 15 nanoseconds, and the clock skew for net X must be under 3 nanoseconds). Among the many advantages to utilizing a truly timing-driven technique is that the tools would then have the necessary information with which to attempt to balance the use of available resources and allow them to work on the problems until all input requirements are met. Further, potential timing problems are, therefore, addressed up front, as opposed to the numerous iterations required to find and fix problems after layout of the FPGA is complete. This significantly shortens the design cycle and aids in eliminating the possibility of creating a new problem somewhere else on the device while attempting to fix an existing one. Moreover, when properly implemented, true timing-driven capability would preclude the unnecessary ripping up of acceptably placed and routed circuitry as changes are made to the design, thereby also shortening the design cycle. While there are numerous advantages to timing-driven approaches, it is nevertheless incumbent upon the designer to know, up front, his exact timing requirements and to assign them specifically and correctly to the appropriate paths and nets. Depending on the design and size of the device, this could include anywhere from several dozen to several hundred signals.

Therefore, it would be highly desirable to provide an FPGA designer with the benefits of true timing-driven techniques while allowing him to specify his requirements in high-level terms such as frequency and offset. Such would then result in a "frequency-driven" design technique where actual net, path and skew requirements would then be automatically generated and passed to the place and route tools. Therefore, a frequency-driven design approach would provide all of the same benefits as a timing-driven approach, but would allow the input of merely a single preference (such as clock frequency) and the system would automatically generate and assign constraints to the literally thousands of signals on the device automatically, relieving the designer of the difficult task of manually identifying the paths and signals and the exact timing requirements himself. Moreover, since all potentially critical paths in the device are then automatically assigned constraints, the tools have the requisite information to analyze and optimize the design for best results. Balancing timing between multiple different paths at the same time requires the manipulation of large amounts of data while simultaneously solving equations.

In order to effectuate such a "frequency-driven" design, timing analysis must be integrated into the total timing/frequency-driven solution such that analysis can be run using the designer's original input constraints/preferences as the measurement criteria. Such timing analysis functionality, when combined with the detailed and accurate set of timing constraints needed to achieve a desired operating frequency, allows for a technique which can pinpoint exactly where an implemented design has failed to meet the designers specified timing requirements as well eliminating the problems inherent in the conventional approach of manually sorting through vast amounts of data to pinpoint such problems.

SUMMARY OF THE INVENTION

Disclosed herein is a frequency-driven layout system and method for an FPGA which allows for automatic conversion of operating frequency and offset information input by the designer or otherwise passed from high-level synthesis tools. The system and method of the present invention utilizes specially designed timing analysis techniques to analyze the circuit and identify circuit paths and associated maximum delays needed to operate at a target frequency. This information is then converted into a set of constraints and rules which are used by the placement and routing functions. Moreover, false path elimination may be performed in order to preclude the placement and routing tools from wasting resources and meeting timing constraints that are not actually required.

During the technology mapping stage of the FPGA programming process, the system and method of the present invention optimizes for device speed versus device area using a separate predetermined balance of these two offsetting attributes depending upon the unique device architecture incorporated into a given manufacturers FPGA. Importantly, the system and method of the present invention allows for delay prediction during the placement stage of the FPGA programming process. Before an FPGA is routed, there are no actual delays to calculate and the path delays resulting from a particular placement must be predicted. Unlike gate arrays in which all interconnect resources are homogeneous, FPGA's exhibit a wide variety of interconnect resources such as direct connects, general purpose local interconnects, long lines, pips, switch boxes, and tri-state busses or their equivalents in other nomenclature. Such non-homogeneous resources make it extremely difficult to predict the final routing delay for any particular placement.

The system and method of the present invention also provide for timing analysis during the routing stage of the FPGA programming process. Unlike the placement stage where estimates of timing implications associated with a particular action may be utilized, during routing, true timing analysis may be implemented. However, it is important to note that the execution time and memory requirements are critical issues in any solution as only a finite amount of time and memory are ever available. The timing analysis function of the system and method of the present invention is accurate and extremely fast and is automatically run on every connection that is considered during routing with the result that the timing analysis routine can be run literally thousands of times during a single auto-routing session.

Still further, the system and method of the present invention allows, through the availability of its particular functionality, to confirm that a designers timing requirements have either been met or the exact locations and types of timing problems encountered, such that the design may be modified or a faster target device selected.

Disclosed herein is a layout system and process for constructing an electronic circuit from a programmable logic device, the device including a plurality of programmable logic cells having programmable interconnects therebetween. The system includes means for mapping the circuit into logical elements capable of implementation by the device logic cells. Means are provided for specifying timing preferences for the device to determine path delay requirements, whereupon a path enumeration is performed for the circuit. Means are also provided for calculating an actual path delay for existing routing and an estimated path delay for proposed routing. Means are further provided for assigning a maximum route delay for each connection based upon the actual or estimated path delays in the enumerated path to provide an indication of whether the maximum route delay exceeds or falls short of the path delay targets. Further provided are means for dynamically, during the placement and routing process, transforming the enumerated path to increase or decrease the actual or estimated path delays to the maximum route delay and reestimating the transformed path delay.

Further disclosed is a system and process for constructing an electronic circuit having predetermined operational frequency constraints from a programmable logic device, wherein the logic device includes a plurality of programmable logic cells having programmable interconnects therebetween. The process comprises the steps of converting the operational frequency constraints to timing requirements of the logic device and identifying paths of the interconnects between selected logic cells of the logic device for implementing the electronic circuit. Maximum delays of the paths are computed for meeting the timing requirements and the computed maximum delays of the paths are converted to a set of timing constraints. Logic blocks of the electronic circuit are placed within specific logic cells of the logic device, within the set of timing constraints, and the interconnects between the specific logic cells are also selectively routed within the set of timing constraints. Adherence of the paths and specific logic cells to the set of timing constraints is then verified.

Utilizing the frequency-driven layout system and method of the present invention, timing requirements may be addressed during the placement and routing of an FPGA as opposed to attempting to fix timing problems after the chip is routed. This can result in very significant time savings in the design cycle of a large FPGA. In fact, the time savings increases with the complexity of the design and, with current industry trends toward larger, more complex chips, timing problems within such devices become increasingly more difficult to find and to fix rendering conventional methods more completely ineffectual and inefficient. Further, the frequency-driven layout system and method of the present invention allows for significant increase in the overall clock speed of a given FPGA despite the greater number of critical timing requirements and the increase in placement and routing options available in increasingly larger FPGA devices. Moreover, the frequency-driven layout system and method of the present invention allows FPGA designers to obtain maximum performance from a given device architecture without the necessity of becoming intimately familiar with the internal architecture, such that one would have to know the exact timing requirements of the design and assign them specifically and correctly to the appropriate paths and nets in the device.

BRIEF DESCRIPTION OF THE DRAWINGS

The above mentioned and other features and objects of the present invention and the manner of attaining them will become more apparent, and the invention itself will be best understood by reference to the following embodiment of the present invention taken in conjunction with the accompanying drawings wherein:

FIG. 1 is a conceptual, schematic diagram of a typical FPGA device illustrating the provision of a number of logic blocks and programmable interconnection resources thereof;

FIG. 2a is a simplified illustration of a portion of an FPGA device, as an example of one type of FPGA only, illustrating a number of logic blocks and switch matrices and the variety of programmable interconnects typically provided therein;

FIG. 2b is a representative illustration of a logic block of the FPGA of FIG. 2a showing the various available signal inputs and outputs thereof;

FIG. 2c is a simplified representation of a switch matrix of the FPGA of FIG. 2a illustrating a programmed function thereof and a tri-state buffer ("TBUF") for driving a global line;

FIG. 3a is a functional logic block diagram illustrative of the path classes supported by the system and method of the present invention;

FIG. 3b is a functional logic block diagram illustrative of the relationship between a clocked input path and a clocked output path;

FIGS. 4a-4c are a block diagram illustrative of the basic connection delay estimate logic flow of the system and method of the present invention;

FIGS. 5a-5b are a logic block diagram illustrative of the compute connection targets logic flow of the system and method of the present invention;

FIGS. 6a-6c are a logic block diagram illustrative of the relax connection targets logic flow of the system and method of the present invention; and

FIG. 7 is a functional block diagram illustrating the design flow for programming an FPGA utilizing the system and method of the present invention.

DESCRIPTION OF A PREFERRED EMBODIMENT

Referring now to FIG. 1, a conceptual field programmable gate array ("FPGA") 10 is shown. Conceptual FPGA 10 includes a number of logic blocks 14 and input/output ("I/O") cells 12. Logic blocks 14 and I/O cells 12 may be programmably interconnected to perform defined logic functions by means of programmable interconnection resources 16. Interconnection resources 16 may comprise direct connects, general purpose local interconnects, long lines, pips, switch boxes and/or tri-state busses as such may be described in a particular FPGA 10 manufacturer's nomenclature.

There are four primary steps in programming conceptual FPGA 10 with a specific circuit implementation. The first is technology mapping/optimization, which decomposes the circuit into smaller, logical elements then recombines the elements into blocks of logic which can be implemented by the logic blocks 14 on the conceptual FPGA 10. The second step is placement which assigns the mapped logic blocks 14 to specific cell locations on the conceptual FPGA 10. The third step is routing which chooses the interconnect points that must be enabled so that the cells containing logic blocks 14 may be connected to one another by means of interconnection resources 16. Ultimately, the cell and interconnect programming is encoded in a bit stream which is downloaded to the conceptual FPGA 10, turning "on", or "off" the appropriate interconnect switches, whereupon the device is ready to be operated as a physical implementation of the specified circuit.

Referring now to FIG. 2a, a portion of an FPGA 20 is shown. FPGA 20 which, as a representative example only, depicts a Xilinx XC3000 device, comprises, in pertinent part, a number of logic blocks 22 and switch matrices 24. Switch matrices 24 may also be commonly referred to as switch boxes.

FPGA 20 further includes various types of interconnection resources for programmably interconnecting the logic blocks 22, such as general purposes interconnects 26 which horizontally interconnect switch matrices 24. A number of general purpose interconnects 32 vertically interconnect switch matrices 24. General purpose interconnects 26, 32 are also commonly referred to as local lines.

FPGA further includes other interconnection resources for programmably interconnecting logic blocks 22. A number of global lines 28 extend vertically through FPGA 20 while a similar global line 34 extends horizontally. Global lines 28, 34 are also commonly referred to as long lines. In addition, FPGA 20 may comprise a number of direct interconnects 30 for connecting logic blocks 22 other than through general purpose interconnects 26, 32 or global lines 28, 34.

Referring additionally now to FIG. 2b, a logic block 22 of FPGA 20 of FIG. 2a is shown. Logic block 22 comprises a number of signal inputs and signal outputs which determine its functionality in the particular design to which it is mapped. In general, logic block 22 may include a plurality of inputs 40 (designated A-E), and outputs 42 (designated X-Y) depending on the programming thereof. Logic block 22 further includes a data input 44, clock input 46, reset input 48, and clock enable input 50. Logic block 22 may also include a global reset 52, circuit ground 54 and power input 56.

Referring additionally now to FIG. 2c, a switch matrix 24 as illustrated in FIG. 2a is shown. Switch matrix 24 is programmably switchable to interconnect any one or more of general purpose interconnects 26, 32 to others of general purpose interconnects 26, 32 as may be required in the programming of FPGA 20. Tri-state buffer ("TBUF") 36 connected to one of general purpose interconnects 32 is used to drive a global line 34 as shown.

FPGA 20 utilizes clock signals which have voltages which rise and fall regularly. The frequency of the clock signals is a measure of how fast FPGA 20 will operate. FPGA 20 will typically operate more slowly than other devices in the system into which it is incorporated and it tends to represent the lower bound of system operating frequency. It is, therefore, usually desirable to have FPGA 20 operate as fast as possible in a given specific circuit implementation. As has been previously described, FPGA 20 comprises a number of cells containing logic blocks 22 which can be programmed to perform a variety of logical functions, and a number of interconnection resources which can be programmed to connect the cells in a general way. The cells and interconnection resources are used to implement complex logical circuits.

The system and method of the present invention is implemented in a single executable computer timing module designed to be fully integrated with the NeoCAD.TM. FPGA Foundry.TM. device-independent modular toolset for FPGA design available from NeoCAD, Inc., 2585 Central Avenue, Boulder, Colo. 80301, assignee of the present invention. The Foundry operating environment, as with that of the timing module embodying the system and method of the present invention, includes a number of industry-standard digital computer platforms. Representative of the possible hardware operating environments are personal computer ("PC") based systems and workstations. Suggested hardware platforms include either a) an IBM-PC.RTM. or compatible 386/486SX (with coprocessor) or 486; MS DOS.RTM. 4.1 or higher; Microsoft.RTM. Windows 3.0 or higher in enhanced mode; a minimum of 16 MB of random access memory ("RAM"); 40 MB of disk space for the first family of FPGA's supported and 20 MB for each additional family; Swap: 10 MB permanent Microsoft Windows swap file; Color VGA monitor; 2/3 button Microsoft Windows compatible mouse; and one parallel port for transport security device or b) a Sun.RTM. SPARCstation.RTM. or compatible; SunOS.RTM. 4.1.1 or higher; X Windows.RTM. version X11R4 or higher and OSF.RTM. Motif 1.1; a minimum of 32 MB or RAM; 45 MB of disk space for the first family of FPGA's supported and 20 MB for each additional family; Swap space of 32 MB; color monitor; 3 button mouse and one serial port for a security device. Additionally, the timing module embodying the system and method of the present invention may be utilized in conjunction with the Prism.TM. device independent logic-partitioning system for FPGA design, EPIC.TM. editor for programmable IC's and TRACE.TM. FPGA specific timing analyzer also available from NeoCAD, Inc.

The module hereinafter described is backed by an interface library of timing functions which can be used by placement and routing programs to generate a timing database of absolute timing constraints on both system and user specified paths in a design, and to check adherence of these constraints, insuring that the design meets the timing constraints.

As utilized herein:

"Timing Preference" is a user-defined timing limit on a design. Timing preferences define the constraints for timing verification and analysis. A timing preference can generate one or more timing constraints on the design. "Timing Constraint" is an absolute time limit derived from a timing preference, limiting delay or skew on a circuit path or signal. "Timing Verification" is the process of verification of design adherence to timing constraints. "Delay Predictor" estimates wire delays for unrouted connections. "Delay Calculator" calculates wire delays for routed connections.

The process can be further described from the internal perspective, or its actual mechanics, as well as from the user perspective. The user simply provides a frequency "preference" in a "preference file," and tells the place and route application ("PAR") where to find the preference file. PAR then places and routes the design, and indicates whether all signals were completely routed, and if the timing preferences were met. If any preferences were not met, the user can run the timing analyzer, TRACE, which will report paths that exceed the maximum delay. Remedial actions include modifying (relaxing) the preferences, running PAR with a different cost function, and manual intervention.

Internally, PAR reads the timing preferences, then passes them on to the timing module which performs "path enumeration" for the design. This process builds connectivity graphs. Then, the timing module does "connection targeting," which assigns to each connection the maximum route delay which will not cause any maximum path delay specification to be exceeded. During this process, the module uses either actual delays from existing routing (via the delay calculator) or estimated delays (via the Delay Predictor) to determine whether each path has positive or negative "slack." Positive slack means that the path as routed (or estimated) has a total delay below the specified (or computed) maximum. Negative slack means that the path delay exceeds the maximum. Slack, whether positive or negative, is distributed among the connections which make up the path. If the slack is positive, this allows the placer or router to increase that connection's delay by the amount of the slack without causing an error. Such an increase may be necessary when reducing the delay of another connection. If the slack is negative, then the placer or router must try to reduce the delays in that path further.

During the placement process, when a transformation (component move or swap) is attempted, all of the connections relevant to the transformation (i.e. connected to the moving components(s)) must have their delays estimated. The new estimates are compared 424 with the connections' delay targets to produce a score 425, which is used to decide whether or not to accept the transformation.

Periodically, the placer will ask the timing module to perform "connection relaxation," which redistributes the slack among connections. The algorithm takes into account the fact that some connections belong to multiple paths, and attempts to maximize the positive slack (or minimize negative slack) for each connection.

After placement is complete, the router takes over. First, the connections to be routed are ordered, with particular attention to constrained connections. Then the router routes each connection in order. If it is unable to meet the target delay for a connection, the router will try again, allowing the connection to shove other routing out of the way. After all connections have been attempted, the timing module performs "relaxation," then the router reorders the connections and retries them. This continues until all connections are routed, and all target delays are achieved, or the router gives up.

The input to the software module is a mapped NeoCAD design database as will be more fully described hereinafter. Optional input includes an ASCII preference file containing user timing preferences, which define generalized or absolute timing limits on design delays.

Timing Preferences

Timing preferences will define the constraints used to perform timing verification. Preferences can apply to design paths or signals, and could indicate a clock frequency or period, the external timing relationship between two or more input signals, an absolute maximum delay requirement on a design path, an absolute maximum delay or skew limit on a design net, or a global timing requirement for a class of design pins.

The NeoCAD Preference Language (NPL) defines the actual language syntax for timing preferences. The following BNF language definition describes the timing preferences supported in the language:

__________________________________________________________________________<pref> : := <period> .vertline. <frequency> .vertline. <maxdelay> .vertline. <maxskew> .vertline. <block> .vertline. <offset> ;<period> : := PERIOD [NET <name>] <ns><frequency> : := FREQUENCY [NET <name>] <Hz><maxdelay> : := MAXDELAY<pathclass>.vertline.allnets.vertline.((NET.vertline.BUS.vertline.PATH)<name>) <ns><maxskew> : := MAXSKEW [(NET.vertline.BUS) <name>] <ns><block> : :=BLOCK <class>.vertline.((NET.vertline.BUS.vertline.PATH) <name>)<offset> : := OFFSET (IN.vertline.OUT) COMP <name> <ns>(BEFORE.vertline.AFTER) COMP <name><pathclass> : :=allpaths.vertline.asyncpaths.vertline.syncpaths.vertline.clockpaths.vertline.enablepaths.vertline.outputpaths<path> : := { [COMP <name>] NET <name>} [COMP <name>]<bus> : := {NET <name>}__________________________________________________________________________ where the terminal symbol <ns> represents a floating point value (in nanoseconds), and <Hz> represents a floating point value (in Hertz). Note that the NeoCAD preference language supports nanoseconds, milliseconds, and microseconds for time units, megahertz and kilohertz for frequency units.

The ASCII symbol <name> is context sensitive. If <name> is associated with a PATH terminal symbol, it must refer to a <path> specification. The <path> specification represents a delay path in the design. It can be specified with an optional component name indicating the start of the path (to designate a single driver in multiple drivel situations), any number of net name designators, and an optional component name indicating the end of the path (to designate a single load in multiple fanout situations).

If <name> is associated with a BUS terminal symbol, it must refer to a <bus> specification. If <name> is associated with a NET terminal symbol, it must be the name of a valid signal net in the design. If <name> is associated with a COMP terminal symbol, it must be the name of a valid component name in the design. The names can refer to either the logical (schematic) or physical (FPGA) signals and components.

Path Classes

There are six general path classes that can be used with the MAXDELAY and BLOCK preferences to check maximum delay or block checking on an entire class of design paths. FIG. 3a illustrates the path classes supported by the system and method of the present invention by use of an exemplary circuit 60:

The path class ASYNCPATHS is used to specify all asynchronous reset paths in the design, terminating at an asynchronous reset pin on a design component. In FIG. 3a, the path from component D0 68 to the component CLB1 62 pin R (D0 68.fwdarw.CBL1.R 62) is an asynchronous reset path.

The class SYNCPATHS is used to specify all synchronous data paths in the design, terminating at a synchronous data input pin on a design component. A synchronous data input pin is defined a data input to a design component that has a setup and/or hold requirement relative to a clock input pin on the component. In FIG. 3a, the paths (D1 70.fwdarw.CLB1.D 62) AND (CLB1.Q 62.fwdarw.CLB2.D 64) are synchronous paths.

The path class CLOCKPATHS is used to define all paths terminating at a clock input of a design component. In FIG. 3a, the paths (CLK 72.fwdarw.CLB1 62) AND (CLK 72.fwdarw.CLB2 64) are clock paths. ENABLEPATHS is used to define all paths terminating at a clock enable input of a design component. The path (EN 74.fwdarw.CLB2.EC 64) is an enable path.

Finally, OUTPUTPATHS is used to define all paths that terminate at a primary output ("IOB") component in the design. In the example above, the paths (D0 68.fwdarw.CLB0.A 66.fwdarw.CLB0.X 66.fwdarw.OUT0 76) and (CLB2.Q 64.fwdarw.OUT1 78) are output paths. OUTPUTPATHS do not proceed through sequential elements.

The superclass ALLPATHS is a union of the path classes listed above.

Timing Constraints

The ASCII user preference file specified for a particular design is used to generate the timing constraints for verification by the timing module. Each timing preference can generate many timing constraints in the design. For instance, a PERIOD or FREQUENCY preference will generate a timing constraint for every data path clocked by the specified net, and a MAXDELAY <pathclass> will generate a timing constraint on every path in the specified path class.

Note: if no timing preferences are specified in the user preference file, no timing constraints will be generated for the design.

PERIOD and FREQUENCY Preferences

The PERIOD and FREQUENCY preferences are used to specify a clock period for all sequential input pins clocked by the specified net. If no net name is specified, the preference applies to all sequential input pins that do not have a specific PERIOD or FREQUENCY preference.

All paths terminating at sequential input pins clocked by the specified net are enumerated (see Path Enumeration), and the specified clock period/frequency is used as the maximum delay limit to create a PATHDELAY constraint. Paths to clock pins of the specified net are also enumerated (for timing analysis), but they are not assigned a constraint.

MAXDELAY Preference

The MAXDELAY preference is used to specify a maximum delay value for a circuit path or net in the design. If a <path> is specified, the delay value is applied as the PATHDELAY constraint for the circuit path(s).

If the keyword ALLPATHS is specified, the delay value is applied as the constraint for all paths in the design that do not have a specific MAXDELAY, PERIOD, or FREQUENCY preference. Similarly, the keywords ASYNCPATHS, SYNCPATHS, CLOCKPATHS, ENABLEPATHS, and OUTPUTPATHS enumerate paths of the specified class and apply the maximum delay value as the PATHDELAY constraint for each of the paths that does not have a specific MAXDELAY, PERIOD, or FREQUENCY preference.

If a <net> is specified, the delay value is used as the maximum delay limit to create a NETDELAY constraint for all driver-to-load connections on the net. If the keyword ALLNETS is specified, the delay value is applied as the NETDELAY constraint for all nets in the design that do not have a specific MAXDELAY preference. If a <bus> is specified, the delay value is applied as the NETDELAY constraint for all driver-to-load connections on the nets that belong to the specified bus.

MAXSKEW Preference

The MAXSKEW preference is used to specify the signal skew between a driver and loads on a given signal. A NETSKEW constraint is created with the specified maximum skew value. If no signal is specified, the preference applies to all clock signals (signals with a clock pin as a load) that do not have a specific MAXSKEW preference.

OFFSET Preference

The OFFSET preference is used to specify the external timing relationship between a clock input and a data input/output of the FPGA that have a common sequential element within the FPGA. If a data input is specified, an OFFSET/IN constraint is generated to ensure adherence to internal setup requirements for all sequential elements within the FPGA for the data path relative to the specified clock input. If a data output is specified, a OFFSET/OUT constraint is generated to ensure the path delay from the clock input to the data output through common sequential elements do not exceed the specified external timing requirement.

With reference now to FIG. 3b, an exemplary circuit 80 is shown in which the path (DIN 84.fwdarw.CLB1.D 82) is a clocked input path, and the path (CLB1.Q 82.fwdarw.DOUT 88) is a clocked output path.

OFFSET IN/BEFORE

The "OFFSET IN . . . BEFORE" preference specifies that a data input arrives before the specified clock input. The setup offset is equal to the specified offset value. For instance, if the preference associated with the above example was "OFFSET IN DIN 5 ns BEFORE CLK", the minimum path delay from (CLK 86.fwdarw.CLB1 82) must be greater than the path delay from (DIN 84.fwdarw.CLB1.D 82) plus the appropriate setup time, less the specified offset value (since DIN 84 arrives BEFORE CLK 86). An error would occur if:

MIN(CLK 86.fwdarw.CLB1 82)<=MAX(DIN 84.fwdarw.CLB1.D 82)+setup-offset OFFSET IN/AFTER

The "OFFSET IN . . . AFTER" preference specifies that a data input arrives after the specified clock input (before the next clock edge). The setup offset is equal to the period for the clock path less the specified offset. For instance, if the preference associated with the above example was "OFFSET IN DIN 5 ns AFTER CLK", the minimum path delay from (CLK 86.fwdarw.CLB1 82) must be greater than the path delay from (DIN 84.fwdarw.CLB1.D 82) plus the appropriate setup time, less the difference between the clock period and the specified offset MIN(CLK 86.fwdarw.CLB1 82)<=MAX(DIN 84.fwdarw.CLB1.D 82)+setup-(period-offset)

OFFSET OUT/AFTER

The "OFFSET OUT . . . AFTER" preference specifies that a data output arrives at the specified offset after the clock input. For instance, if the preference associated with the above example was "OFFSET OUT DOUT 5 ns AFTER CLK", the specified offset value must be less than the sum of the maximum path delay from (CLK 86.fwdarw.CLB1 82) and the maximum path delay from (CLB1.Q 82.fwdarw.DOUT 88) (since DOUT 88 arrives AFTER CLK 86). An error would occur if:

offset>=MAX(CLK 86.fwdarw.CLB1 82 )+MAX(CLB1.Q 82.fwdarw.DOUT 88) OFFSET OUT/BEFORE

The "OFFSET OUT . . . BEFORE" preference specifies that a data output arrives before the next clock input. For instance, if the preference associated with the above example was "OFFSET OUT DOUT 5 ns BEFORE CLK", the clock period less the specified offset value must be less than the sum of the maximum path delay from (CLK 86.fwdarw.CLB1 82) and the maximum path delay from (CLB1.Q 82.fwdarw.DOUT 88) (since DOUT 88 arrives BEFORE next CLK 86). An error would occur if:

(period-offset )>=MAX(CLK 86.fwdarw.CLB1 82)+MAX(CLB1.Q 82.fwdarw.DOUT 88) BLOCK Preference

The BLOCK preference is used to block timing checks on irrelevant paths in a design. If a full <path> is specified, the path is blocked from consideration by the timing calculator and verifier. If a <net> is specified, all paths through the specified net are blocked.

If any of the path classes ASYNCPATHS, SYNCPATHS, CLOCKPATHS, ENABLEPATHS, or OUTPUTPATHS are specified, all paths of the specified class are blocked from timing analysis and verification.

Path Specification

The path specification is used to specify a particular delay path in the design. A typical path specification will contain a list of net names that uniquely identify a delay path in the design. However, the user may specify component names in the path to clarify ambiguous paths. All component and net delays between the first and last nets in the path are included in the path. If multiple drivers or loads exist at the end of a path specification, the path specification is expanded to include all possible paths between the multiple endpoints. Component names can be included at the endpoint of a path to reduce path expansion.

If an endpoint component of a user-defined path is a primary input or primary output, the pin-to-pad delay of the component is included in the path. Paths that originate at sequential output pins automatically have the clk-to-q component delay (if any) included in the path. Paths that terminate at sequential input pins automatically have the setup and hold requirements accounted for in any timing constraint analysis and verification.

Conflict Resolution

Conflicting preferences are resolved by hierarchical precedence, with global preferences being the weakest, followed by group preferences (i.e. BUS preferences), and finally individual preferences (i.e. NET or PATH preferences). Conflicting preferences of the same type are resolved with the more restrictive preference taking precedence.

Path Enumeration

A depth-first path enumeration technique [Hitchcock, R., "Timing Verification and the Timing Analysis Program," Proceedings 19th Design Automation Conference, 1982, pp.; Roth J. P., "Diagnosis of Automata Failures: A Calculus and a Methods," IBM Journal of Research and Development, July 1966, pp. 278-291] is used to fully enumerate all possible input paths to a design component pin. This is necessary to ensure that the routes of all paths meet the timing requirements.

Path enumeration starts at each pin, following component logic and fanin topology through successive fanin levels, until a primary input pin or clock input pin is found.

False Paths

False path detection involves the identification and elimination of unsensitized paths from the timing database. This is desirable, as elimination of false paths from the timing database would reduce the number of timing constraints on the NeoCAD partition, place and route tools.

Current research [Du, D., Yen, S., and Ghanta, S., "On the General False Path Problem in Timing Analysis," Proceedings 26th Design Automation Conference, 1989, pp. 555-560; Liu, L., Chen, H., and Du, D., "The Calculation of Signal Stable Ranges in Combinational Circuits," Proceedings ICCAD-91, 1991, pp. 312-315; McGeer, P., and Brayton, R., "Efficient Algorithms for Computing the Longest Viable Path in a Combinational Network," Proceedings 26th Design Automation Conference, 1989, pp. 561-567; Perremans, S., Classen, L., and De Man, H., "Static Timing Analysis of Dynamically Sensitizable Paths," Proceedings 26th Design Automation Conference, 1989, pp. 568-573; Stewart, R. and Benkoski, J., "Static Timing Analysis using Internal Constraints," Proceedings ICCAD-91, 1991, pp. 308-311] indicates that reliable false path detection depends on fixed and accurate circuit delay information. In the NeoCAD place and route environment (where routing operations routinely modify the circuit's delay characteristics), circuit delay information is hardly constant.

This could lead to inaccurate identification of false paths, leaving some valid paths unconstrained, and some invalid paths unnecessarily constrained. Furthermore, each routing pass could modify the accuracy of all previous false path identifications. Therefore false path detection and elimination will not be performed in the timing module.

Path Delay Calculation

Path delay calculation includes the component and wire delay along the path. It may also account for a setup time on constrained sequential input pins.

Component Delay

Component delay is the pin-to-pin delay values for the delay through the component. Both rise and fall delays are used to accurately calculate the path delay, when supplied by the FPGA vendor. Component logic sense, if available, is used to track both rising and falling edges through a path.

Only maximum delays are calculated for the component delay along a path. Minimum delay values are not calculated and verified due to a lack of vendor information on minimum component delays [Xilinx, Inc., "Programmable Gate Array Data Book," Xilinx, Inc., San Jose, Calif., 1989, page 6-18], and because vendors will often bin faster parts in a slower speed grade (making guaranteed minimum timing problematic).

I/O Delays

Additional delay is added to a path's component delay for device input and output delays (pin-to-pad delays).

Wire Delay

Wire delay is calculated using the Timing Estimator for unrouted connections and the Timing Calculator for routed connections.

For paths terminating at sequential input pins, the setup and hold requirements (relative to a clocking input pin) are accounted for in all timing analysis and verification of the path relative to a specified timing constraint.

Net Delay Calculation

Net delay is calculated using the Timing Estimator for unrouted net connections and the Timing Calculator for routed net connections.

Delay Predictor

Unrouted connection delay is estimated by the delay predictor. The estimate is device specific, and is affected by the likelihood that fast routing resources will be available for the connection. The delay predictor will be more fully described hereinafter.

Delay Calculator

Routed connection delay is calculated using a standard RC delay calculation [Rubenstein, J., Penfield, P., and Horowitz, M., "Signal Delay in RC Tree Networks," IEEE Transactions on Computer-Aided Design, Vol CAD-2, No. 3, July 1983, pp. 202-211].

Timing Verification

The timing module allows client applications to perform timing verification of an FPGA design, given the design and a preference file containing timing preferences. Once a timing database has been generated for a particular design, client applications can dynamically verify design compliance with the timing constraints. Timing verification checks the actual net and path delays of the design against the specified timing constraints, and determines compliance with the timing constraints.

NETDELAY Constraints

Signal delay is checked against the specified maximum delay for a driver-to-load connection on constrained signals. The following inequality is used to determine if the signal delay exceeds the specified constraint:

constraint>=MAX(conndelay) where constraint is the maximum delay constraint, and MAX(conndelay) is the maximum driver-to-load delay for all connections on the net. NETSKEW Constraints

Signal skew is checked against the specified maximum skew for constrained signals. The following inequality is used to determine if the signal skew exceeds the specified skew constraint:

constraint>=maxconndelay-minconndelay where constraint is the maximum skew constraint, minconndelay is the minimum connection delay between a driver and all loads on the signal, and maxconndelay is the maximum connection delay between a driver and all loads on the signal. If the signal skew exceeds the specified constraint, a skew error will be output to the timing report. PATHDELAY Constraints

For a PATHDELAY constraint, each path is checked with the following inequality:

constraint>=compdelay+conndelay+setuptime where compdelay represents the summation of component delay along the path, conndelay is the summation of connection delay along the path, and setuptime is the setup requirement (if any) for paths terminating at sequential input pins. Those paths with component and connection delays that exceed the constraint will be flagged as timing errors in the timing report. OFFSET/IN Constraints

For paths with OFFSET/IN constraints relative to a clock input path the inequality

minclkdelay>=maxdatadelay+setuptime-offset is used to check a primary input with an external arrival time BEFORE a clock input, and minclkdelay=<maxdatadelay+setuptime-(period offset) is used to check a primary input with an external arrival time AFTER a clock input. OFFSET/IN errors are also listed in the timing report.

Note that a clock period or frequency preference is required for OFFSET IN/AFTER preference.

OFFSET/OUT Constraints

For paths with OFFSET/OUT constraints relative to a clock input path, the inequality

offset>=maxclkdelay+maxdatadelay is used to check the path delay to the primary output AFTER the clock input, and (period-offset)>=maxclkdelay+maxdatadelay is used to check the path delay to the primary output BEFORE the next clock input. OFFSET/OUT errors are also listed in the timing report.

Note that a clock period or frequency preference is required for OFFSET OUT/BEFORE preference.

Connection Delay Targets

In order to reduce the amount of data necessary to verify design timing, the system and method of the present invention generates a database of connection target delays, which can be efficiently verified by client applications. This reduces the amount of work needed to verify timing constraints significantly.

Target Assignment

Target delay assignment for design connections restricted by timing preferences is automatic with generation of the timing database. These targets are used to perform timing-driven partition, place and route.

Connection delay targets for design connections restricted by timing constraints are established with the minimum/maximum possible connection delay values that will satisfy all net and path timing constraints that contain the connection [Bening, L. C. and Lane, T. A., "Developments in Logic Network Path Delay Analysis," Proceedings 19th Design Automation Conference, 1982, pp. 605-615; Jackson, M. A. B and Kuh, E. S., "Performance-Driven Placement of Cell Based lC's," Proceedings 26th Design Automation Conference, 1989, pp. 370-375; Youssef, H, and Shragowitz, E., "Timing Constraints for Correct Performance," Proceedings ICCAD-90, 1990, pp. 24-27]. For instance, the slack (available delay) along a path is:

slack=(constraint-setuptime)-(sumcompdelay+sumconndelay) where sumconndelay is the summation of connection delays for the path, sumcompdelay is the summation of component delays for a path, and the setuptime is the setup time (if any) for paths terminating at sequential input pins. If positive slack exists for the path, it can be equitably divided among the connections in the path. If negative slack exists for the path, each connection can equitably be reduced. In general, the target delay value for a connection (relative to a specific path constraint) is: conn.target=conn.delay+((conn.delay/sumconndelay)*slack) where conn.delay is the estimated or actual delay for the connection, and sumconndelay is the summation of connection delays for the path, and conn.target is the connection's maximum delay target relative to the path. Minimum delay targets can also be established for connections covered by a NETSKEW or OFFSET/IN constraint.

Note that each connection's target delay must be set relative to all net and path constraints on the connection. For instance, if a NETDELAY constraint imposes a lesser delay on a connection than all of it's path constraints, the lesser value will take precedence. In this way adherence to the connection target delays ensures that all timing constraints will be met [Youssef, H, and Shragowitz, E., "Timing Constraints for Correct Performance," Proceedings ICCAD-90, 1990, pp. 24-27].

With reference now to FIGS. 5a and 5b, the process flow for the computation of connection targets in the system and method of the present invention is shown. At step 150 the variable C is assigned the value of 0 and passed to connector 152 for transfer to operation 154 where conns[c]. mintarget is assigned the value of 0 and conns[c]. maxtarget is assigned the value .infin.. Following operation 154, at decision 156, C is tested to see if it is less than design.numconns and, if true, the variable C is assigned the value of C+1 at operation 158 and applied to connector 152. If C is not less than design.numconns, the result process continues to step 160 where the variable P is assigned the value of 0.

Following step 160, the process continues to connector 162 and operation 164 where minslack is assigned paths[p]. minslack and maxslack is assigned paths[p]. maxslack and the process proceeds to step 166 where C and delay are both assigned a value of 0. Following connector 168, delay is assigned the value of delay+conns[c]. delay at operation 170 and the result passed to decision 172 where, if C is determined to be less than paths.nummconns, C is assigned the value of C+1 at operation 174 and applied to connector 168. If C is not less than paths.numconns at decision 172, C is assigned the value of 0, mintarget is assigned the value of 0 and maxtarget is assigned the value of .infin. at step 176. Following connector 178, at decision 180, if delay equals 0, mintarget is assigned the value of minslack/path[p]. numconns and maxtarget is assigned the value of maxslack/path[p]. numconns at operation 182. Otherwise, if delay does not equal 0 at decision 180, mintarget is assigned the value of conns[c]. delay-((conns[c]. delay/delay) * minslack) and maxtarget is assigned the value of conns[c]. delay+((conns[c]. delay/delay) * maxslack). The results of operations 182 and 184 are applied to connector 186 for input to decision 188 where, if mintarget is greater than conns[c]. mintarget, conns[c]. mintarget is assigned the value of mintarget at operation 190. The results of operation 190 are applied to connector 192 along with a result of mintarget not being greater than conns[c]. mintarget at decision 188 and, at decision 194, if maxtarget is less than conns[c]. maxtarget, conns[c]. maxtarget is assigned the value of maxtarget at operation 196. If maxtarget is not less than conns[c]. maxtarget, the process proceeds with the results of operation 196 through connector 198 to decision 200. At decision 200, if C is less than paths.numconns, C is assigned the value of C+1 at operation 202 and the results passed to connector 178. If C is not less than paths.numconns at decision 200, at decision 204, if P is less than design.numpaths, P is assigned the value of P+1 at operation 206 and the results applied to connector 162. If P is not less than design.numpaths at decision 204, the process proceeds to the end step 208 and is completed.

The above described process may also be understood with respect to the following pseudocode representation.

______________________________________Pseudocode: Compute Connection Targets______________________________________for each conn in the designconn.mintarget := 0conn.maxtarget := maximum possible delayendfor each path in the designminslack := path slack above minimummaxslack := path slack below maximumsumdelay := total conn delay in pathfor each conn in pathmintarget := 0maxtarget := maximun possible delayif (sumdelay=0) / / Divide slack equally for paths / / that are totally unplaced mintarget := minslack / path.numconns maxtarget := maxslack / path.numconnselse / / Distribute slack pro rata mintarget := conn.delay - (conn.delay/sumdelay) * minslack maxtarget := conn.delay + (conn.delay/sumdelay) * maxslack / / Check the new targets against existing targets for the conn if (mintarget > conn.mintarget) conn.mintarget := mintarget if (maxtarget < conn.maxtarget) conn.maxtarget := maxtargetendend______________________________________ Target Relaxation

If a connection appears in more than one path, its target delays will be the most restrictive of the targets computed by the formula listed above. As a consequence, other connections in the same path may have their target delays adjusted to compensate for the additional slack available. The process of reallocating this "unused" slack is called connection relaxation, and is described in [Youssef, H, and Shragowitz, E., "Timing Constraints for Correct Performance," Proceedings ICCAD-90, 1990, pp. 24-27].

With reference now to FIGS. 6a-6c, the process flow for the relaxation of connection targets in accordance with the system and method of the present invention is shown. The process flow begins at connector 220 and proceeds to step 222 where C is assigned the value of 0. Following step 222 and connector 224, conns[c]. mindelta and conns[c]. maxdelta are both assigned a value of .infin. at operation 226. If C is less than design.numconns at decision 228, C is assigned the value of C+1 at operation 230 and the results passed to connector 224. If C is not less than design.numconns at decision 228, P is assigned the value of 0 at step 232. The process continues through connector 234 to operation 236 where C, mintargets, maxtargets, and delays are each assigned the value of 0.

Following operation 236 and connector 238, mintargets is assigned the value of mintargets+paths[p].conns[c].mintarget; maxtargets is assigned the value of maxtargets=paths[p].conns[c].maxtarget; and delays is assigned the value of delays=paths[p].conns[c].delay at operation 240. At decision 242, if C is less than paths[p].numconns, C is assigned the value of C+1 at operation 244 and the result applied to connector 238. If C is not less than paths[p].numconns, the process proceeds to operation 246 where minslack is assigned the value of paths[p].minslack and maxslack is assigned the value of paths[p].maxslack. At operation 248, minslack is assigned the value of minslack-delays+mintargets and Maxslack is assigned the value of maxslack+delays-maxtargets. Following operation 248, C is assigned the value of 0 at step 250 and the process proceeds through connector 252 to operation 254 where mindelta is assigned the value of minslack * (paths[p].conns[c].mintarget/mintargets) and maxdelta is assigned the value of maxslack * (paths[p].conns[c].maxtarget/maxtargets).

At decision 256, if mindelta is less than paths[p].conns[c].mindelta, paths[p].conns[c].mindelta is assigned the value of mindelta at operation 258. If mindelta is not less than paths[p].conns[c].mindelta at decision 256, the process continues through connector 260 with the results of operation 258 to decision 262 where, if maxdelta is less than paths[p].conns[c].maxdelta, paths[p].conns[c].maxdelta is assigned the value of maxdelta at operation 264. A false indication at decision 262 and the results of operation 264 are applied to connector 266 to decision 268 where, if C is less than paths[p].numconns, C is assigned the value of C+1 at operation 270 and the results applied to connector 252. If C is not less than paths[p].numconns at decision 268, the process proceeds to decision 272.

At decision 272, if P is less than design.numpaths, P is assigned the value of P+1 and the process returns to connector 234. If P is not less than design.numpaths, the process continues to step 276 where C is assigned the value of 0. Following connector 278, conns[c].mintarget is assigned the value of conns[c].mintarget-conns[c].mindelta and conns[c].maxtarget is assigned the value of conns[c].maxtarget+conns[c].maxdelta at operation 280. At decision 282, if C is less than design.numconns, C is assigned the value of C+1 at operation 284 and the process returns to connector 278. Otherwise, if C is not less than design.numconns at decision 282, the process proceeds to decision 286 where, if all conns.mindelta are equal to 0 and all conns.maxdelta are also equal to 0, the process is completed at step 288. Otherwise, the process returns to connector 220 and the relax connection targets process is repeated.

The above-described process may also be understood with respect to the following pseudocode representation.

______________________________________Pseudocode: Relax Connection Targets______________________________________while not done/ / Initialize an array of connection delta values for all/ / design connections to the largest practical delay valuefor each conn in designconn.mindelta := infinityconn.maxdelta := infinityfor each design path/ / Get the summation of connection targets for the pathmintargets := .SIGMA. conn[i].mintarget, i=1,path.numconnsmaxtargets := .SIGMA. conn[i].maxtarget, i=1,path.numconns/ / Get the summation of actual connection delays for the pathdelays := .SIGMA. conn[i].delay, i=1,path.numconns/ Get the slack for the path relative to max delay constraintsminslack := path slack above minimum constraintmaxslack := path slack below maximum constraint/ / Determine the amount of connection delay that is really/ / available for this path by adding the actual connection/ / delay to the slack values. If other paths caused a/ / connection along this path to be reduced further than/ / this path's original connection targets, additional slack/ / will be available to other connections in this path, relative/ / to the existing connection targets.minslack' := minslack - delays + mintargetsmaxslack' := maxslack + delays - maxtargets/ / Re-distribute the available slack to all connections on the/ / path by assigning a portion of the slack (proportioned by/ / the connection's target delay relative to the summation/ / of target delays) to each connection.for each conn in pathmindelta := minslack' * ( conn.mintarget / mintargets )maxdelta := maxslack' * ( conn.maxtarget / maxtargets )/ / Assign the new delta slack if it is less than any previous/ / delta established for this connection in this iterationif (mindelta < conn.mindelta) conn.mindelta = mindeltaif (maxdelta < conn.maxdelta) conn.maxdelta = maxdeltaendend/ / Now add the connection delta values to each connection/ / target. Note that the delta values will be zero for those/ / connections which lie along paths with zero slack, and/ / the delta values will be greater than zero for connections/ / that can be relaxed.for each conn in designconn.mintarget -= conn.mindeltaconn.maxtarget += conn.maxdelta/ / If all conn.delta values are zero, we're done!end______________________________________

Delay Predictor

The Delay Predictor takes a driver/load pair for a net, and estimates the best-case wire delay based on a set of heuristics. These heuristics determine which type of routing resource will be used by the router for the connection. In some cases, such as direct connect and certain clock resources, the determination is not subject to guess. In other cases, not only the resource type but how many of each resource are open to question.

Because the Predictor is based on heuristics which may be unique to a specific architecture, the following example will describe the Delay Predictor for the Xilinx XC3000 family of FPGA's. Routing and other resources specific to this architecture will be used to illustrate the heuristic technique, which can be used for any architecture.

The basic connection delay estimate is made without regard to net fanout or topology, both of which have an effect on the connection's delay, and are factored in after the initial estimate is made. (An exception to this is the direct connect.) In the general case, four delay estimates are made, using combinations of local and global routing resources in the horizontal and vertical axes. Special cases considered include clock nets, direct connect routing, special pin locations, input/output synchronization clocks, special pin relationships, and any other case where the four basic estimates are inapplicable.

With reference again to FIG. 2a, the global lines 28, 34 (also know as "longlines") and the general purpose interconnects 26, 32 (also known as local lines) are connected in each channel by "switch matrices 24" (also known as "switch boxes") as previously described. The four standard estimates assume a) switch matrices 24 for both horizontal and vertical traversal; b) switch matrices 24 for vertical, global lines 34 for horizontal; c) global lines 28 for vertical, switch matrices 24 for horizontal; and d) global lines 28,34 for both vertical and horizontal. The minimum delay of these four estimates is used, which is in keeping with the goal of an accurate estimate of the best-case route delay.

With reference to FIG. 4a, a portion of the process flow for basic connection delay estimates in the system and method of the present invention is shown. The process starts at step 100 and proceeds to decision 102 where, if the driver type is the oscillator, a fixed estimate of 1000 is assumed at operation 104. If the driver type is not the oscillator at decision 102, at decision 108, if the driver type is the global clock buffer, a fixed estimate of 2000 is assumed at operation 110. If the driver type is neither the oscillator or the global clock buffer, at decision 112, if the driver and load pins are connected by a single arc, the process proceeds to the subroutine 114 illustrated in more detail in FIG. 4b.

With reference additionally to FIG. 4b, the process flow of subroutine 114 is shown. Subroutine 114 begins at start step 141 and proceeds to decision 140 where, if the driver is of the type clockin, an estimate of clock direct delay is assumed at operation 142 and the subroutine 114 proceeds to return step 149. If the driver is not of the type clockin at decision 140, the subroutine 114 proceeds to decision 144, where, if the driver is an I/O to a clock buffer, an estimate of I/O to clock delay is assumed at operation 146 and the subroutine 114 proceeds to return step 149. If the driver is not of the type I/O to clock buffer, an estimate of direct delay on the number of loads is assumed at operation 148 and the subroutine 114 proceeds to return step 149.

Referring again to FIG. 4a, if following decision 112, the driver and load pins are not connected by a single arc, the process proceeds to decision 116 where, if the driver type is an alternate clock buffer, a fixed estimate of an alternate clock delay is assumed at operation 118 and the process proceeds to end step 106. Otherwise, the process proceeds to subroutine 120 further illustrated in FIG. 4c.

With reference additionally to FIG. 4c, the subroutine 120 is shown in more detail. Subroutine 120 begins at start step 122 and proceeds to operation 124 where the delay is computed for a horizontal longline with a vertical switchbox; a vertical longline with a horizontal switchbox; both horizontal and vertical longlines; and all switch box connection delays. At decision 126, if the driver is a TBUF or an I/O on the top or bottom, than the delay is assumed to be a horizontal longline and vertical switchbox delay at operation 128 and the process proceeds to end step 106. Otherwise, if the driver is not a TBUF or an I/O on the top or bottom, the process continues to decision 130. At decision 130, if the load is an I/O buffer ("IOB") or a left or right load clock pin, the delay is assumed to be a longline plus a horizontal distance at operation 132 and the process proceeds to end step 106. Otherwise, following decision 130, at decision 134, if the distance is 0, the minimum delay is assumed at operation 136 and the process proceeds to end step 106. If the distance at decision 134 is not zero, then the smallest of the four delays computed in operation 124 is assumed at operation 138 and the process is completed at end step 106.

The above-described process flow may also be understood with respect to the following pseudocode representation.

______________________________________Pseudocode: Basic Connection Delay Estimate______________________________________count the horizontal and vertical switch boxesif driver comp is the oscillatorestimate := 1000else if driver comp is the global clock bufferestimate := 2000else if driver and load pins are connected by asingle arcif driver comp is of type clockinestimate := clock.sub.-- direct.sub.-- delayelse if driver comp is an I/O and the loadcomp is a clock bufferestimate := io.sub.-- to.sub.-- clock.sub.-- delayelseestimate := direct delay +direct.sub.-- fanout.sub.-- penalty * max(numloads, 20)else if driver comp is alternate clock bufferandload pin is a logic block clock pinestimate := alt.sub.-- clock.sub.-- delayelseforcelongvert := falseforcelonghoriz := falseadjust numswitchboxes // see pseudocode belowif load comp is a logic block and load pinis a clock pinif numswitchboxes is 0estimate := minimum.sub.-- delayelseestimate := numswitchboxes * switchbox.sub.-- delay/ / special case: route the driver to the alt clock/ / longline if that longline isn't used by the alt clock// buffer. note that this longline must connect at the// top or bottom of the deviceallowvertlongline := this signal not the alt clock and this load pin doesn't share a longline with any alt clock load (i.e. reserve longline for alt clock)if allowvertlongline disttotoporbot := number of switch boxes from driver to top or bottom of device llestimate := clock.sub.-- longline.sub.-- delay + (disttotoporbot + numhorizswitchboxes) * switchbox.sub.-- delay if (llestimate < estimate) estimate := llestimateelse/ / not a logic block clock pin, so compute the four basic/ / delays for vertical/horizontal longline/switchboxvll.sub.-- hll := 2 * longline.sub.-- delayvll.sub.-- hsw := longline.sub.-- delay + (numhorizswitchboxes *switchbox.sub.-- delay)vsw.sub.-- hll := longline.sub.-- delay + (numvertswitchboxes *switchbox.sub.-- delay)vsw.sub.-- hsw := numswitchboxes * switchbox.sub.-- delay/ / see which to useif forcelongvert and forcelonghorizestimate := vll.sub.-- hllelse if forcelonghorizestimate := vsw.sub.-- hllelse if forcelongvertestimate := vll.sub.-- hswelse if numswitchboxes is 0estimate := minimum.sub.-- delayelse if numloadsonsig < 5estimate := vsw.sub.-- hswelseestimate := min (vll.sub.-- hll, vll.sub.-- hsw, vsw.sub.-- hll, vsw.sub.-- hsw)end______________________________________

The number of switch matrices 24 is computed based on the distances in cell rows and columns between the driver site and the load site. However, this number must be adjusted if certain conditions exist, such as locations near the perimeter of the FPGA 20 or connections which are in the same column but must loop back to connect.

______________________________________Pseudocode: Adjust Number of Switch Matrices______________________________________if load comp is the driver compincrement numhorizswitchboxeselse if driver comp is a logic cellif load comp is a logic celllvc := load pin vertical channellhc := load pin horizontal channeldvc := driver vertical channeldhc := driver horizontal channelif lvc > dvcif lhc = dhcif lvc - dvc = 1 decrement numvertswboxes if driverpin is X and load pin is K or EC increment numvertswboxes if driver pin is Y and load pin is RD increment numvertsboxeselse if driver pin is X and load pin is B, C, D, E, RD, or K decrement numvertswboxes if driver pin is Y and load pin is A, B, C, Dl or EC decrement numvertswboxeselse if lhc > dvc if lvc - dvc = 1 if driver pin is Y and lhc - dhc == 1 and load pin is D or K decrement numvertswboxes by 2 else decrement numvertswboxes by 1else decrement numvertswboxes if driver pin is Y and loan pin is B, C, D, E, RD, or K decrement numvertswboxeselse if lhc < dhc if lvc - dvc = 1 if driver pin is X and dhc-lhc==1 and load pin is A, B, Dl or E decrement numvertswboxes by 2 else decrement numvertswboxes by 1 else decrement numvertswboxes if driver pin is X and load pin is A, B, C, Dl, or EC decrement numvertswboxeselse/ / these pins can only be reached from the left, so/ / they require either a longline or an extra swboxif load pin is B or C increment numvertswboxeselse if lhc < dhc if load pin is B, C, D, E, RD or K increment numvertswboxelse if load pin is A, B, C, Dl or EC increment numvertswboxeselse if driver comp is an I/O cellif driver comp is on left or rightedgeif load pin vertical channel not same as driver decrement numhorizswitchboxeselse / / must be on top or bottom edge if load pin horizontal channel not same as driver decrement numvertboxeselse if driver comp is a pullup ortristate buffernumhorizswitchboxes := 0forcelonghoriz := trueif load comp is an I/O cellif load pin is a clock pin if load pin is on left or right edge forcelongvert := true else // must be on top or bottom forcelonghoriz := trueend______________________________________

The Predictor knows about the FPGA 20 architecture and about the router; it does not know to what extent the delay will deviate due to congestion. It compensates for not knowing by adding a penalty, based on the type of device and the density of the design. Also, the delay for a single connection is affected (through additional capacitance) by the other connections on the same net. This penalty is based on the fanout and the extrema of the net. The penalties involve constants which are derived from comparison of the estimates to the delay values obtained by actually routing the connection during development.

______________________________________Pseudocode: Adjust Connection Delay for Fanoutand Extrema______________________________________Estimate := connection delay estimateif not direct connect and not alternate clock get net extrema dist := (xmax -xmin) + (ymax -ymin) dist := dist * distfactor load := loadfactor * min (17, numload) estimate := estimate + dist + (dist * load) estimate := estimate * congestionfactorend______________________________________ where "distfactor" and "loadfactor" are coefficients which vary with the FPGA 20 device's speed grade, and "congestionfactor" reflects an application-specific pessimism regarding the router's ability to make the best-case route given factors such as design density.

Placement Algorithm

The placement algorithm used may be, as an example only, a standard optimization algorithm called "simulated annealing." This is a generic method, but it utilizes a qualitative metric (called the "objective function") which evaluates the "goodness" of a given placement.

The implementation of annealing is as follows: All components are placed randomly, in legal positions, with the exception of user-specified component locations, which are simply adhered to. A series of "transformations" is applied to the initial placement, with the goal of improving the placement to a global near-optimum state. In the placer forming part of the NeoCAD Foundry software, these transformations consist of "moving" or "swapping" components or component groups. Transformations are selected, evaluated, and either accepted or rejected based on the objective function and the current "temperature" of the annealing process. The temperature allows transformations which result in a lower quality placement to be accepted. This behavior, which is the primary characteristic of the annealing algorithm, enables the optimization to avoid local minima in the costed search space.

As an example only, the objective function may be composed of two elements which have competing goals. The "completion score" is based on various conditions in the placement at hand which relate to routeability. The "timing score" is based on the degree to which the current placement conforms to the connection targets defined by the timing module. The reason these scores compete is that the completion score is tuned to balance all relevant factors so that the entire design is routeable, and the timing score is concerned only with connections which are constrained by timing preferences such as frequency. Too much emphasis on the latter score results in poor overall routeability, which in turn invalidates to some degree the delay estimates provided by the Delay Predictor, upon which the timing score is based. Therefore, these two scores must be carefully balanced.

The timing score is calculated as follows: If the connection is routed, ignore it, since there is nothing the placer can do about it. Otherwise, obtain the connection score from the timing module for that connection. This score is the number of picoseconds by which the estimated delay exceeds the target maximum (or is exceeded by the target minimum). If the connection score is zero, then the timing score for that connection is zero. Otherwise, the timing score is the sum of a failure penalty (100), and the product of an excess factor (4) and the square of the excess delay in nanoseconds:

______________________________________Pseudocode: Compute Placement Connection TimingScore______________________________________excess := 0If maxdelay > maxtarget excess := maxdelay - maxtargetelse if maxdelay < mintarget excess := mintarget - maxdelayif excess > 0 nanoover := (excess + 999)/1000 / / convert to nanoseconds score := 100 + (4 * nanoover * nanoover)else score := 0end______________________________________

The failure penalty and excess factor represent the mechanism by which the completion score is balanced with the timing score. Since this mechanism exists here, the total completion score is simply added to the total timing score to obtain the overall objective function for a given placement.

Routing Algorithm

The router may be based, for example, on the standard "costed maze" algorithm. The timing-driven aspects of the router's behavior derive from the costs used, and the ripup-and-reroute strategy employed to achieve a given connection's target without violating another connection's target.

As with the placer, there is a fundamental conflict between the goals of completion and timing constraint satisfaction. Unlike the placer, which applies and weighs these goals in parallel, the router attempts to satisfy them in sequence. First and foremost is completion, for without a completely routed design, the frequency is 0.

The costed maze algorithm routes a single connection at a time, although which connection on a net is not typically predetermined, so it is sometimes a valuable simplifying assumption to route all of the connections on one signal before proceeding to the next.

The costs used during the maze search can be anything. Normally, they are costs associated with particular types of routing resources, plus other penalties for such things as making a turn. When the router searches in delay-driven mode, the cost of getting from the net driver to the current point is simply the delay in picoseconds, provided by the Delay Calculator. The delay-driven costing will be referred to as delay-driven, and all other cost sets will be referred to as cost-driven, or simply as costed.

The router is "iterative," which in this context indicates that the router makes repeated passes through the signals in the design, ripping up and re-routing each signal in an order determined by such factors as routeability, topology, and conformance to connection targets. The router stops when all signals are completely routed and all connection targets are met, or when the router meets some user-specified iteration limit, or when the router decides of its own accord that no further progress can be made in reasonable time.

The concept of "crossover" allows the router to identify what other routes are blocking the current connection by allowing the search to go through blocked passages at some costs. Routing with crossover serves two purposes: it enables the router to shove the blocking signals out of the way; and it provides a record of congested areas to be avoided during subsequent iterations. Both shoving and area avoidance are techniques which contribute heavily to achieving completion and meeting the connection targets.

______________________________________Pseudocode: Router Iterations______________________________________repeat sort signals for each signal rip up signal route signal using costs if rejected route signal delay-based if rejected route signal with crossover, delay-based add area-avoidance codes along route path else accept route else accept route until (all routed and met constraints) orgiving up end______________________________________

Whether a signal has been re-routed in an acceptable way is based on three factors: a) the number of unrouted connections (fewer is always better, more is always worse; b) the overall timing score for the design; and c) whether the signal has met the timing constraints. If the re-route is rejected, the previous state of the routing is restored.

______________________________________Pseudocode: Reject/Accept Signal Route______________________________________rejected := falseif there are fewer unrouted connections thanbefore rejected :=falseelse if there are more unrouted connectionsthan before rejected := trueelse if new score better than old score rejected := false else if new score worse than old score rejected := true else if signal constraints are now met rejected := false else if signal constraints were previously met rejected := trueend______________________________________

Since the router performs "shoving," which allows one signal to move another out of the way, and since this process is reasonably transparent to the timing algorithm, the timing scores include the entire design, rather than simply the score of the signal being routed. The timing score in the router is weighted in favor of connections which are members of multiple paths. It is computed as follows:

______________________________________Pseudocode: Compute Router Timing Score______________________________________score := 0for each connectionif excess > 0 score := score + excess * numpathsend______________________________________ where "numpaths" is the number of paths containing that connection, and "excess" is the number of picoseconds by which the connection delay exceeds the target maximum delay, as described in the placement pseudocode above.

With reference now to FIG. 7, an FPGA design flow 300 in accordance with the system and method of the present invention is shown. Design flow 300 is intended for use with the NeoCAD FPGA Foundry device-independent modular toolset for FPGA design on the industry-standard digital computer platforms previously described. The FPGA architecture description step 302 and NeoCAD technology modelling system step 314 produce the physical device description of step 318. From the physical device description step 318, the design flow 300 proceeds to a technology mapper 320, the EPIC.TM. editor for programmable IC's 322, place and route 324 and the Prism .TM. device-independent logic partitioning system.

The design flow begins with the design capture step 304, which comprises a number of possible behavioral or hardware description languages such as Abel or VHDL as well as state machine, Boolean equation or schematic representations. Most FPGA designs are "captured" using schematics. Electronic Design Interchange Format ("EDIF") 308, Xilinx Net list File ("XNF"), QuickLogic Data Interchange Format ("QDIF") 310 result in a net list 316 comprising a logic description of the design. The constraint files 312, which interact with the design capture step 304, include design preferences and, with the net list 316, they provide input to a NeoCAD Generic Database ("NGD") for subsequent input to the technology mapper 320 to generate an annotated net list 332 to the design capture step 304. The technology mapper 320 in conjunction with the editor for programmable IC's 322, place and route 324 and logic-partitioning system 326 develop a NeoCAD Circuit Description ("NCD") 330. By use of the logic-partitioning system 326, a number of NCD's 336 may be developed partitioning the design across multiple FPGA's. The NCD's 330, 336 are supplied as input to the timing module 338 comprising the system and method of the present invention which supplies inputs to the back annotation step of the NGD 328. The NCD's 330, 336 furnish the necessary binary output to programming step 340 to be applied to the target FPGA to program the device to function in accordance with the circuit design.

While there have been described above, the principles of the present invention in conjunction with specific apparatus and methods, it is to be clearly understood that the foregoing description is made only by way of example and not as a limitation to the scope of the invention.

Claims

1. A system for establishing a predicted routing delay in an electronic circuit connection between a driver and a load element to be constructed from a programmable logic device having a plurality of programmable logic cells and a number of heterogeneous routing resources including at least a first and a second type of interconnect having respective predetermined delays thereof, said system comprising:

means for firstly estimating a first routing delay based upon a possible routing of said electronic circuit connection utilizing a horizontally disposed one of said first interconnects and a calculated number of vertically disposed ones of said second interconnects;

means for secondly estimating a second routing delay based upon a possible routing of said electronic circuit connection utilizing a vertically disposed one of said first interconnects and a calculated number of horizontally disposed ones of said second interconnects;

means for thirdly estimating a third routing delay based upon a possible routing of said electronic circuit connection utilizing a horizontally and a vertically disposed ones of said first interconnects;

means for fourthly estimating a fourth routing delay based upon a possible routing of said electronic circuit connection utilizing a calculated number of horizontally and vertically disposed ones of said second interconnects; and

means for determining a least routing delay of said first, second, third and fourth routing delays; and

means for utilizing said least routing delay as said predicted routing delay between said driver and load elements.

2. The system of claim 1 further comprising:

means for determining a type of said driver element of said electronic circuit connection; and

means for alternatively utilizing a fixed estimate of said routing delay as said predicted routing delay instead of said least routing delay if said driver element is of a predetermined type.

3. The system of claim 1 further comprising:

means for determining a location on said logic device of said driver element of said electronic circuit connection with respect to a vertically disposed input/output pin of said programmable logic device; and

means for alternatively utilizing a horizontally disposed first interconnect delay and a predetermined number of vertically disposed second interconnect delays of said driver element from said load element of said electronic circuit connection as said predicted routing delay instead of said least routing delay.

4. The system of claim 1 further comprising:

means for determining a location on said logic device of said load element of said electronic circuit connection with respect to a horizontally disposed input/output pin of said programmable logic device; and

means for alternatively utilizing a vertically disposed first interconnect delay and a predetermined number of horizontally disposed second interconnect delays of said load element from said driver element of said electronic circuit connection as said predicted routing delay instead of said least routing delay.

5. The system of claim 4 further comprising:

means for establishing if said driver element and said load element of said electronic circuit connection are connected by a single arc;

means for determining a type of said driver element of said electronic circuit connection if said driver element and said load element are connected by a single arc; and

means for alternatively utilizing a fixed estimate of said routing delay associated with said single arc plus a fanout delay of said electronic circuit connection as said predicted routing delay instead of said least routing delay if said driver element is of a predetermined type.

6. A system as defined in claim 5 wherein said predicted routing delay between a driver and a load element is established in conjunction with the establishment of predicted routing delays between other drivers and load elements; and

means wherein said utilizing means includes considering the availability of said routing resources and the requirements of routing delays of predicted routing delays between other drivers and load elements and utilizing one of the estimated routing delays other than the least routing delay when necessary to satisfy said requirements.

7. A system as defined in claim 5 wherein said first type of interconnect is a global interconnect and said second type of interconnect is a local interconnect.

8. A method for establishing a predicted routing delay of an electronic circuit connection between a driver and a load element to be constructed from a programmable logic device having a plurality of programmable logic cells and a number of heterogeneous routing resources including at least a first and a second type of interconnect having respective predetermined delays thereof, said method comprising the steps of:

estimating a first routing delay based upon a possible routing of said electronic circuit connection utilizing a calculated number of horizontally disposed ones of said first interconnects and a calculated number of vertically disposed ones of said second interconnects;

estimating a second routing delay based upon a possible routing of said electronic circuit connection utilizing a calculated number of vertically disposed ones of said first interconnects and a calculated number of horizontally disposed ones of said second interconnects;

estimating a third routing delay based upon a possible routing of said electronic circuit connection utilizing a calculated number of horizontally and vertically disposed ones of said first interconnects;

estimating a fourth routing delay based upon a possible routing of said electronic circuit connection utilizing a calculated number of horizontally and vertically disposed ones of said second interconnects; and

determining a least routing delay of said first, second, third and fourth routing delays; and

utilizing said least routing delay as said predicted routing delay between said driver and load elements.

9. A method as defined in claim 8, further including the steps of:

determining a location on said logic device of said driver element of said electronic circuit connection with respect to a vertically disposed input/output pin of said programmable logic device; and

alternatively utilizing a horizontally disposed first interconnect delay and a predetermined number of vertically disposed second interconnect delays of said driver element from said load element of said electronic circuit connection as said predicted routing delay instead of said least routing delay.

10. A method as defined in claim 8, further including the steps of:

determining a location on said logic device of said load element of said electronic circuit connection with respect to a horizontally disposed input/output pin of said programmable logic device; and

alternatively utilizing a vertically disposed first interconnect delay and a predetermined number of horizontally disposed second interconnect delays of said load element from said driver element of said electronic circuit connection as said predicted routing delay instead of said least routing delay.

11. A method as defined in claim 10, further including the steps of:

establishing if said driver element and said load element of said electronic circuit connection are connected by a single arc;

determining a type of said driver element of said electronic circuit connection if said driver element and said load element are connected by a single arc; and

alternatively utilizing a fixed estimate of said routing delay associated with said single arc plus a fanout delay of said electronic circuit connection as said predicted routing delay instead of said least routing delay if said driver element is of a predetermined type.

12. A method as defined in claim 8 wherein said predicted routing delay between a driver and a load element is established in conjunction with the establishment of predicted routing delays between other drivers and load elements; and

wherein said utilizing step includes considering the availability of said routing resources and the requirements of routing delays of predicted routing delays between other drivers and load elements and utilizing one of the estimated routing delays other than the least routing delay when necessary to satisfy said requirements.

13. A method as defined in claim 8 wherein said first type of interconnect is a global interconnect and said second type of interconnect is a local interconnect.

14. A method as defined in claim 8, further including the steps of:

determining a type of said driver element of said electronic circuit connection; and

alternatively utilizing a fixed estimate of said routing delay as said predicted routing delay instead of said least routing delay if said driver element is of a predetermined type.