Computer-aided design and analysis of circuits and semiconductor – Nanotechnology related integrated circuit design
Reexamination Certificate
2002-06-20
2004-05-25
Smith, Matthew (Department: 2825)
Computer-aided design and analysis of circuits and semiconductor
Nanotechnology related integrated circuit design
C716S030000
Reexamination Certificate
active
06742173
ABSTRACT:
DESCRIPTION OF THE INVENTION
1. Field of the Invention
This invention is related in general to the field of interfacing with programmable logic devices (“PLDs”). In particular, the invention consists of a novel communication and control mechanism for querying the status of and controlling the behavior of field programmable gate array (“FPGA”) based systems.
BACKGROUND OF THE INVENTION
Highly demanding computer processing tasks have generally been performed by software applications on general-purpose computers. Often these general-purpose computers are not adequate for the processing requirements of the applications and designers have been forced to employ solutions involving special-purpose hardware. Special-purpose hardware often requires detailed programming and extended effort to take advantage of the unique processing elements they possess. This extra programming effort introduces significant development costs for special purpose processing.
Software applications written in various programming languages such as “C”, MATLAB, Python, Midas 2K, and the like can control PLDs. The software applications are run on general purpose processors, special purpose processors, or embedded processors. Some PLDs have inherent microprocessors which run software applications. For example, the VIRTEX II PRO CHIP® FPGA has an embedded POWER PC® processor for running software applications. PLDs are comprised of functional units, each providing a computational function. Some functional units employ large proprietary algorithms called “cores”. A core can be treated as a “black box” during a design process, wherein knowledge of a functional unit's behavior is known, but knowledge of the composition of the functional unit is not required. Typically, knowledge of a core's communication path, inputs and outputs, attributes and behavior are necessary to utilize the core.
One method of communicating with functional units and their cores is to use an Application Program Interface (“API”). APIs are software interface constructs that provide specifications of functions provided by hardware devices which can be requested by software applications. However, traditional APIs require software applications to have specific knowledge of detailed functional unit information, such as register addressing, control and status bit information, control access sequences, and functional unit timing diagrams to properly communicate with and control these hardware devices. For example, a software application that attempts to set a frequency attribute of a digital tuner core inside an FPGA would typically need a register address inside the functional unit associated with the frequency attribute. Additionally, the application might also need to access the functional unit via some control sequence that accesses specific bits in a specific control register. A programmer would explicitly indicate the register address in a software application that wishes to set the frequency attribute parameter and then perform the appropriate control sequence to transfer data to this register address. If the register address changes due to a modification of a functional unit or design implementation with a different FPGA design, or the control sequence is altered for similar reasons, the software application would not function properly, as the coded register address no longer points to the frequency attribute register and the control sequence and control information may be different. A programmer would need to modify the programming code for the software application to match these changes in the hardware design.
If a software application requests a function via an API, the function will partition the request into discrete steps that can be performed by the hardware. Only those hardware functions that are described by the API are available to the software application. If a hardware device has additional features or attributes not recognized by the API, they are typically not available for use by the software application.
There has been an attempt to establish an industry standard input/output (“I/O”) interface for software applications such that API calls may be uniform. An attempt has also been made to utilize these industry standard I/O interfaces by developing industry standard hardware interfaces. The result is a uniform set of API software calls producing uniform stimulation of hardware devices. This is useful for establishing a standard method of transferring data between software applications and functional units (in the cases above, the drivers will still be different, but encapsulated by these API calls). However, this standard does not provide a method of controlling the attributes of functional units. A change of hardware design would still require a corresponding change in application software.
One patent which discloses attempts to improve on methods of controlling FPGAs is Davis et al. U.S. Pat. No. 6,230,307, entitled SYSTEM AND METHOD FOR PROGRAMMING THE HARDWARE OF FIELD PROGRAMMABLE GATE ARRAYS (FPGAS) AND RELATED RECONFIGURATION RESOURCES AS IF THEY WERE SOFTWARE BY CREATING HARDWARE OBJECTS. Davis discloses a system that controls the behavior of FPGAs as if they are software by creating hardware objects that implement application level functions. Control and execution of hardware objects occurs via high level software constructs. However, a change in a function in an FPGA will necessitate that a new hardware object be created. Thus, every time a design adds or changes an FPGA core, a new hardware object must be written and the software applications must be re-compiled to integrate this new object. This eliminates the need to re-code software applications when designs change, but introduces a requirement of coding new hardware objects to reflect changes to functional units. This patent does not disclose run-time control of functional unit attributes nor does it provide a software object that represents the functional unit hierarchy with attribute control. Run-time reconfiguration is disclosed but not run-time control.
A second patent of interest is Athanas et al. U.S. Pat. No. 5,828,858, entitled WORM-HOLE RUN-TIME RECONFIGURABLE PROCESSOR FIELD PROGRAMMABLE GATE ARRAY (FPGA). Athanas discloses a methodology of using dynamically created operators and pathways to move data between functional units through configurable interconnections. This invention makes use of dynamically changeable variable length data ports. While Athanas discloses a novel approach to interconnecting functional units, it does not address a method of allowing software applications to query these functional units to ascertain their attributes. Nor does Athanas provide a method of controlling functional units without prior detailed knowledge of their attributes.
Another reference is Mohan et al. U.S. Pat. No. 6,216,258, entitled FPGA MODULES PARAMETERIZED BY EXPRESSIONS. Mohan discloses parameterizing functional modules of target specific FPGAs. This provides a standard method of representing FPGA attributes. While these parameters are visible to high level software applications, applications must still be hard-coded to access these parameters directly.
In the methods discussed, a system designer must have intimate knowledge of underlying hardware in order to effectively integrate the hardware into a given software environment. Therefore, it is desirable to have a method of allowing software applications to communicate with and control hardware functional units without specific and detailed knowledge of a device's parameters and attributes.
It is also desirable to have a method of changing hardware designs without necessitating that software applications be rewritten or re-compiled to integrate these hardware changes.
It is likewise desirable to allow software applications and hardware devices to be designed independently of each other, yet operate in a cohesive manner when integrated.
Previously, software applications controlling FPGA functional units have been designed for specific purposes and for specific software environments. Because s
Dinh Paul
Durando Birdwell & Janke PLC
Rincon Research Corporation
Smith Matthew
LandOfFree
Communication and control model for field programmable gate... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communication and control model for field programmable gate..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communication and control model for field programmable gate... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3263127