|Publication number||USRE42444 E1|
|Application number||US 12/322,325|
|Publication date||7 Jun 2011|
|Filing date||30 Jan 2009|
|Priority date||20 Nov 1998|
|Also published as||DE69910826D1, DE69910826T2, EP1138001A2, EP1138001B1, EP1351153A2, EP1351153A3, EP1351154A2, US6658564, US7171548, US20040098569, WO2000031652A2, WO2000031652A3|
|Publication number||12322325, 322325, US RE42444 E1, US RE42444E1, US-E1-RE42444, USRE42444 E1, USRE42444E1|
|Inventors||Stephen J. Smith, Timothy J. Southgate|
|Original Assignee||Altera Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (57), Non-Patent Citations (27), Referenced by (2), Classifications (10), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of U.S. patent application Ser. No. 09/443,971, filed Nov. 19, 1999, now U.S. Pat. No. 6,658,564, which claims the benefit of U.S. provisional patent application No. 60/109,142, filed Nov. 20, 1998.
This invention relates to programmable logic device technology, and more particularly, to computer systems in which programmable logic is reconfigured to optimize the ability of the system to handle a given application.
The only programmable element in a conventional computer architecture is the microprocessor. The microprocessor is manufactured with a fixed instruction set that cannot be customized for specific applications. The microprocessor is flexible in that it can run virtually any software-implemented function of an application. The speed of execution of a given function, however, is generally substantially slower when implemented to execute on a microprocessor. This is because software-implemented functions must be fairly complex to accommodate the microprocessor's generic instruction set.
With conventional computer architectures, software will typically only run on a limited range of platforms. If an application engineer decides to write an application to be run on a given microprocessor, the instruction set the application engineer may use is limited to the one permanently resident on the microprocessor. The application engineer must therefore select whether an application is better suited for a hardware platform or a software platform. Although software platforms are often preferred due to the inflexibility and inefficiency of hardware-based systems, in many cases, the generic instruction set resident on a microprocessor results in inadequate performance for a particular type of software application. For example, graphics-intensive applications usually require hardware that is specifically suited for the particular graphical elements of the application, such as 3-D rendering. In order to circumvent the difficulties associated with programming for a hardware platform, engineers turn to software, which in many cases greatly reduces the application's speed.
Recently, the notion of a reconfigurable computer based on programmable logic devices has been proposed. The goal of a reconfigurable computer is to increase performance over a conventional computer by providing parallelism and rapid execution times through the use of customizable hardware. Increased flexibility can be achieved by using programmable logic devices, because the logic of such devices may be reconfigured by loading new configuration data into the devices. This allows the reconfigurable computer to provide a large number of instruction sets, rather than a single instruction set for a conventional computer. A greater number of functions may be provided using a fixed amount of hardware if the computer uses reconfigurable logic.
It is an object of the present invention to provide improved reconfigurable computers based on programmable logic devices that may be reprogrammed to optimize the ability of the computer to handle a given application.
This and other objects of the invention are accomplished in accordance with the principles of the present invention by providing a reconfigurable computer system based on programmable logic.
An application engineer developing an application for the reconfigurable computer need not be concerned with the details of which resources are available on that computer. A hardware abstraction is used that is based on the size of a single programmable logic device or a subset of a programmable logic device. When an application is compiled, the functions of the application that are implemented in hardware are partitioned into blocks containing configuration data that are the same size as a programmable logic device or smaller.
The reconfigurable computer system is modular and scalable. If more hardware resources are added, system performance increases. It is not necessary to recompile the application to obtain the benefit of the increased performance.
The reconfigurable computer system allows both hardware and software implementations of a function to exist simultaneously during run-time. A virtual computer operating system is used to select which implementation to run depending on the resources that are available at run-time. Software development tools may be provided that allow an application engineer to use a high-level language to develop both a hardware implementation and a software implementation for an application that may be executed on a reconfigurable computer system using programmable logic resources. These tools may include a partitioner that automatically partitions a specification written in a system design language made up of functions and constraints into software functions and hardware functions. The software functions and hardware functions may be compiled into threads and programmable logic resource configuration data, respectively. The threads and configuration data may be used by the virtual computer operating system at run-time to execute the application.
The reconfigurable computer system provides mechanisms for an application engineer to specify performance requirements for an application. For example, a graphics application may require a particular throughput in terms of the number of polygons that may drawn on a display screen per unit time. If it is required that a million polygons be drawn per second, for example, the application engineer may specify to the virtual computer operating system that the function that draws the polygon must complete its operation in one microsecond.
The virtual computer operating system has the capability to monitor the performance of applications (as well as their individual functions) running within the system and has the capability to reallocate more resources to a particular application or to an individual function to ensure that it meets its performance requirements. The virtual computer operating system may also determine whether to execute the software version or the hardware version of a particular function depending on the performance of the system at the time the function is to be executed. For example, if the polygon drawing function is scheduled to execute at the same time as another computationally intensive application is executing, the dynamic profiling being performed by the virtual computer operating system may take this into consideration when determining resource allocation and whether to use the software version of the polygon drawing function or the hardware version of the polygon drawing function.
A virtual computer operating system is provided that allocates the functions of the application among the programmable logic resources. The virtual computer operating system may include a virtual computer kernel services component. The virtual computer kernel services component may include various resource managers including a virtual logic resource manager.
During run-time, if a particular reconfigurable computer system has a virtual operating system with virtual logic capabilities, the virtual logic manager may control the swapping of programmable logic configuration data and application state information between programmable logic resources and a secondary storage device. This allows reconfigurable computer systems with limited resources to implement complex applications.
Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and the following detailed description of the preferred embodiments.
A schematic diagram showing a high-level view of an illustrative reconfigurable computer system in accordance with the present invention is shown in
A programmable logic device typically includes an array of programmable logic regions, a routing structure, input and output regions, memory regions and a configuration store (i.e., memory for storing the configuration data that is used to configure the logic components in the programmable logic regions). The logical functions performed by a programmable logic device are determined by the configuration data stored in the configuration store and the connection of the configuration store to the logic regions, the routing structure, the input and output regions, and the memory regions. The configuration store may be based, for example, on static random-access memory which may be written to, in-circuit, an essentially unlimited number of times. Alternatively, a device, such as an erasable programmable read-only memory device, external to the programmable logic device may be used as a configuration store in place of the internal static random access memory of the programmable logic device. Any other memory or storage device that is capable of being written to a substantial number of times may be used if desired. The logical function performed by a programmable logic device may therefore be modified in-circuit numerous times. An example of a suitable programmable logic device is the FLEX EPF10K50 device from Altera Corporation of San Jose, Calif. This type of programmable logic device is merely illustrative. Any other suitable type of programmable logic device may be used in system 5 if desired. If desired, programmable logic devices may support partial reconfiguration of the configuration store or multiple configuration stores.
Non-volatile random access memory 10 may be used to store initialization information. When power is first applied to a reconfigurable computer system, the initialization information may be used to initialize the computer. This process is known as “boot-strapping.”
The memory devices used for computation may be random-access memory devices 12. These may be formed from static or dynamic integrated circuit memory technology. The choice of static or dynamic memory technology may be made based on the desired computational function to be performed by the memory device. Static random-access memory devices have faster access times than dynamic random-access memory but use more transistors per storage cell, and are therefore more expensive to manufacture for an equivalent storage density. The combination of access time, density and cost are factors in determining the preferred memory technology for a given computational function.
The interconnect network 22 may be formed by wires (e.g., a bus) connecting each of the physical resources together. The interconnect network topology may also be formed using programmable logic devices or using programmable interconnect devices which may allow the topology to be dynamically reconfigured. The topology may then be optimized for a particular computational function. Examples of potential network topologies are mesh, full or partial crossbar, cliques, hyper-cubes, and distributed or shared memory hierarchies.
The I/O connections 20 may be formed by wires coupling the reconfigurable computing array to external devices such as a keyboard, a visual display, mass storage devices such as a hard disk drive, or to a computer network comprising other reconfigurable, or non-reconfigurable, computer systems.
If desired, programmable logic devices may be used to implement combinatorial or sequential logic functions for logic device 14, microprocessor functions for microprocessor 16, or I/O functions for I/O interface 18. Some of these functions, such as the microprocessor functions, may be implemented in fixed-hardware, if desired.
The expansion of such a system may involve the addition of more programmable logic devices. As programmable logic devices are added to the system, the processing power increases. Scalability and modularity allow an increase in the programmable logic device resources to result in an increase in the performance of the system.
Memory 12 may support a memory hierarchy for executing applications and system programs and data. Applications and system programs may include microprocessor code and programmable logic device configuration data.
A programmable logic device may be configured to form an application-specific I/O device 18 which may be required only for the duration of the application. These devices may use protocols such as Ethernet protocols, small computer systems interface (SCSI) protocols, peripheral component interconnect (PCI) protocols, video driver protocols, etc.
The interconnect network 22 may be used to provide the following functions: a programmable logic device configuration bus, an application memory bus and an I/O bus. Each bus may function independently. The programmable logic device configuration bus may be used to configure each programmable logic device in the system. Depending upon the programmable logic device configuration addressing mode, this data may be simultaneously broadcast to a group of programmable logic devices or to an individual programmable logic device. The application memory bus may allow the system to form a shared or distributed memory system with the array of programmable logic devices. The I/O bus may connect a programmable logic device to an external I/O device.
The information in the non-volatile memory device 10 may be used to boot-strap the system as shown in
The boot-strap instructions stored in the non-volatile memory 10 may be executed on a computational resource during step 36. This resource may be a dedicated microprocessor, a programmable logic device configured as a microprocessor, a combination of a microprocessor and a programmable logic device partially configured as a microprocessor, or a programmable logic device logic circuit. If the resource is a dedicated microprocessor, the non-volatile memory 10 will simply contain the microprocessor instructions required to complete the boot-strap process. If a programmable logic device needs to be configured as a microprocessor, then the non-volatile memory 10 may contain programmable logic device configuration data and microprocessor instructions. Otherwise, the non-volatile memory 10 may contain programmable logic device configuration data for a logic circuit which may or may not require additional program instructions to complete the boot-strap process.
The final boot-strap process is to load an operating system kernel. The loading process may involve loading instructions for a microprocessor implemented using a programmable logic device, or may involve loading the configuration data for a programmable logic device. Whichever arrangement used—microprocessor and instructions or logic circuit with or without instructions—the operating system may be referred to as the virtual computer operating system (VC-OS).
Illustrative components of the virtual computer operating system are shown in
The virtual computer operating system includes run-time management tools that ensure that the functions of a given application can be executed. For example, the run-time management functions ensure that functions and timing constraints specified at the system design level are satisfied.
Conventional operating systems such as Microsoft Windows NT schedule functions to be executed on the available resources in conventional computer systems at run-time. The resources in such a conventional computer system are allocated dynamically at run-time depending upon application program requirements and resource availability. Each resource has a resource manager, such as a virtual memory manager which is responsible for the allocation of physical memory. The most common resource managers in conventional operating systems are a file system manager, a graphics manager, an I/O manager (to handle mass storage access or simple I/O devices such as a keyboard or mouse), a network manager, and a virtual memory manager.
In accordance with the present invention, virtual computer operating system 40 includes an application program interface 44 that provides an interface between the virtual computer operating system 40 and applications written for the virtual computer operating system 40. Virtual computer operating system 40 also includes kernel services 42 that provide resource management functions. Each resource in the system may have a resource manager. For example, file resources may be handled by file system manager 46. Graphics resources may be handled by graphics manager 47, I/O resources may be handled by I/O manager 48, network resources may be handled by network manager 50, and virtual memory resources may be handled by virtual memory manager 52. A reconfigurable computer system may have virtual logic, which may be managed by a virtual logic manager 54 that handles requests that are made by applications to access the limited programmable logic resources in system 5.
Conventional operating systems rely on virtual memory to overcome limited random-access memory constraints. Virtual memory may use secondary storage devices (such as hard-drives) to temporarily handle run-time data that would otherwise typically be stored in a primary storage device (such as random-access memory). As functions and data are requested by an application, the operating system determines whether the requested data is currently stored in virtual memory, and if it is, replaces the data in the physical memory for other applications with the functions and data currently being requested from virtual memory.
The virtual logic manager of the present invention, however, is responsible for the run-time allocation of programmable logic devices. The virtual logic manager satisfies the run-time requirements of various applications' requests for functions that are to be implemented in programmable logic. An application may request that more functions be implemented using programmable logic devices than there are programmable logic devices to handle such requests. The virtual logic manager must therefore manage the run-time swapping of functions to be implemented in programmable logic.
Conventional virtual memory managers make a relatively small amount of physical memory appear to an application as a relative large amount of logical memory. This is achieved by the run-time swapping of memory pages in and out of physical memory to and from a secondary storage (usually a local hard disk drive). With virtual logic manager 54 of the present invention, a relatively small amount of physical programmable logic devices may be made to appear to an application as a relative large amount of logical programmable logic devices. This is achieved by using virtual logic manager 54 to perform run-time swapping of programmable logic device configuration data and state information in and out of programmable logic device configuration memory (i.e., the configuration store) to and from a secondary storage device (usually a local hard disk drive).
The process of loading a function for execution in the system is shown in
The available hardware processing bandwidth of the system and the available software processing bandwidth of the system is determined at step 150. The software processing bandwidth may be calculated from the amount of time all of the microprocessors in the system are idle and are not executing functions. The hardware processing bandwidth may be calculated on the basis of the number of unused programmable logic resources in the system along with the amount of time the used programmable logic resources are not processing data.
The required hardware processing bandwidth for the function and the required software processing bandwidth for the function are determined at step 152. These requirements may be specified by the application engineer as an absolute requirement or it may be specified based on the performance of the system when executing a small additional function supplied alongside the function to be executed. This small function may be executed at step 152 and the system's performance may be measured.
At step 154, it is determined whether the required software processing bandwidth is less than the bandwidth available in the system. If the required software processing bandwidth is less than the bandwidth available in the system, then the software implementation is loaded onto the system to be run on a microprocessor at step 160. This choice is made because the software implementation will use less system resources than the hardware implementation.
If the software processing bandwidth is not adequate then the hardware implementation is evaluated at step 156. If the available hardware bandwidth is acceptable, then the function is loaded onto the system to be executed directly on a programmable logic resource at step 162. If it was determined at step 156 that the available hardware bandwidth is not acceptable, and further determined at step 158 that the performance requirement was “hard,” meaning the performance requirement must be satisfied, then an error message is reported to the user and the loading of the function (and it's parent application) must be abandoned at step 164. If the requirement was not “hard,” then the function is loaded anyway at step 162 and runs at a reduced performance level.
After either implementation of a function has been loaded into the system (using normal means for determining which functions are of lower priority and unloading these lower priority functions if necessary), the performance of the function in the system is monitored at step 166. The priority given to the function for system processing bandwidth will be proportional to the differences between the required bandwidth and the actual bandwidth being realized.
Whenever a new function is scheduled for resource allocation by the priority management process, the first step taken by the resource allocation routine of the virtual computer operating system is to determine whether a resource exists that can satisfy the constraints of the function. If such a resource exists, then the resource is allocated to the function. If not, a suitable candidate must be found from the existing pool of physical resources using a suitable replacement policy. For example, if it is determined that there are insufficient programmable logic resources available to be reconfigured to perform a given function of an application, the virtual computer operating system may be used to ensure that the given function is implemented using hardware resources that do not need to be reconfigured (e.g., a dedicated microprocessor or a programmable logic device configured to perform as a CPU). The virtual computer operating system may ensure that a suitable software version of the function was provided by the application engineer before attempting to run the function on a microprocessor.
Subject to function constraints, suitable replacement policies which may be used include first-in-first-out, least-recently-used, or least-frequently-used. An extreme case might be an on-demand swap of the first suitable resource when the run-time management system detects a high priority function such as a real-time interrupt handling process.
With regard to resource allocation and scheduling, run-time resource management by operating systems for conventional computer architectures involves the use of various techniques for CPU scheduling. Having a computer system handle applications (as well as individual functions under the same application) on a one-by-one basis can be extremely inefficient. Depending on the task being processed at any given time, resources can become tied up while other resources are idle. The result is a very slow computer. In response, the concept of CPU scheduling was gradually adopted by most conventional operating systems.
CPU scheduling in conventional computer systems involves allocating resources and scheduling the order in which all functions are processed by the system. The goal of CPU scheduling is to create a stable multitasking environment. This environment is created by algorithmically allocating CPU resources based on a combination of factors such as prioritization, function idleness due to I/O delays, or any other factors that may be used in determining the order in which functions are processed. For example, if a microprocessor is handling a function that reaches a point at which it has to wait for a user input, a conventional operating system's CPU scheduling feature may provide another function with an opportunity to use the microprocessor's resources (as well as other available system resources) until the user input is available. When the user input is available, the first function may regain the resources it had relinquished when it caused an idleness in the system.
In accordance with the present invention, in a reconfigurable computer system where programmable logic devices are either fully or partially configured as one or more microprocessors, the function of a scheduling system takes on a somewhat different role than that of a conventional CPU scheduling system. Whereas conventional CPU scheduling allocates microprocessor resources to functions, programmable logic device scheduling allocates programmable logic resources (of which there may be several) to functions. The programmable logic resources do not necessarily have to be programmed to be a microprocessor, but may be programmed to perform any function desired, such as I/O functions, graphics functions, network functions, etc. The purpose of such a feature in a reconfigurable computer's operating system is to help manage the various tasks being processed simultaneously among a group of programmable logic resources. In a conventional computer's operating system, in contrast, the purpose of a CPU scheduling feature is primarily to reduce microprocessor idleness due to the high demand for processing power by the various tasks being active at any given time.
A typical scheduling system for a reconfigurable computer may use a time-multiplexing system in which programmable logic resources may be allocated to application functions. This may involve switching between different functions at predetermined time intervals. Notable exceptions include real-time interrupts and I/O functions.
If resources become idle in a reconfigurable computer system and no functions are scheduled for immediate allocation, then function prefetching can help to minimize the time cost associated with programmable logic resource configuration overhead as the programmable logic resource can be loaded with the configuration data before the function is required.
This time cost associated with loading a programmable logic device may be on the order of milliseconds with presently available programmable logic devices. If desired, the time required to configure a programmable logic device may be reduced (e.g., to the order of nanoseconds) by using increased pipelining and parallelism on the device.
A reconfigurable computer system based on a group of programmable logic resources therefore has the benefit of having relatively large processing capabilities, because the number of programmable logic resources used in the system may be relatively large. In a reconfigurable system, if more processing power is needed, one simply needs to add more programmable logic devices onto the interconnect network. An application need not necessarily be recompiled after adding more programmable logic devices to the system, because the run-time manager will automatically detect and incorporate the new hardware in the run-time performance specification. All of these devices may then be controlled and kept track of using the virtual computer operating system.
The minimum and maximum function performance goals set by the software designer may determine the next function to be scheduled for resource allocation. In addition, the priorities of the functions currently executing may also be used in the determination of the next function to be scheduled.
Another feature of the present invention is the ability to defragment the programmable logic devices. In conventional computers, storage devices such as hard drives may be defragmented to avoid the problems that occur as resources on the drive are continually allocated and deallocated. A region of deallocated space on a conventional hard drive may not be sufficiently large to be reallocated to a function that requires a larger contiguous space. In accordance with the present invention, programmable logic defragmentation may be used to defragment the partial configuration of a single programmable logic device. This allows many small preallocated areas of programmable logic to be relocated to make a larger working region of programmable logic available. This involves reallocating the configuration data for certain switches to different portions of the programmable logic to accommodate desired programmable logic device functions.
Another aspect of the present invention relates to software development. The software development process is a critical part of using any computing system. It is important to have capabilities for performing complex functions and creating intricate interfaces with which a user may interact with the computing system. Most conventional development tools include high level programming languages such as JAVA, C++, ADA, LISP, COBOL, VISUAL BASIC, as well as others. In order to maintain consistency during the software development process, high level languages for the reconfigurable computer system may be designed using the principles of conventional high-level programming languages.
An application typically includes multiple functions. For example, a graphics-intensive application may use certain functions for rendering surfaces and may use other functions for ray tracing. The virtual computer operating system allocates programmable logic device resources to the functions of the application.
A unit hardware abstraction may be used. That is, an application engineer need not worry about how many programmable logic device resources any particular system running the application has. Rather, an abstraction may be made that all of the resources are available, subject to a minimum resource requirement of at least one programmable logic device.
This is shown in
In the example of
The process of compiling a high-level design specification or algorithm and executing it on a reconfigurable hardware architecture is detailed in
The partitioning phase may have to take constraints 74 into account. There are two generic types of constraints 74. First, the functional boundaries of the system design language specification 70 may have timing relationships within functions and there may be a concurrent or sequential constraint between functions. Second, cost functions may be associated with using hardware resources in the resource library 76. The resource library 76 contains details about each available hardware resource (generally this includes microprocessors, memory, and programmable logic devices). These can include computation rate, latency, and response time of a resource or cost functions of time (usually for software implementations), area (usually for hardware implementations), or communication (overhead in both time and area).
Constraints may be defined as “hard” constraints that must be met. An example of a hard constraint is a constraint involving a real-time I/O or interrupt process. Constraints may also be defined as “soft” constraints. An example of a soft constraint is a constraint related to arithmetic functions in a spreadsheet. It is not critical that these arithmetic functions get performed within a particular time, but the faster these functions are executed, the more convenient it would be to use the application.
The resource library 76 describes properties for each type of resource. For example, a microprocessor may have properties such as a particular instruction set and a data-path width, a memory may have a particular data-path width, and a programmable logic device may have a particular logic capacity and an I/O count. The partitioning tool 72 takes properties from the resource library 76 and constraints 74 into account, but may not take into account how many resources there are of each resource within a given system. It is the responsibility of the run-time resource managers to map functional partitions into available hardware resources on-demand from an executing application.
Once the system design language specification 70 is partitioned into software functions 78 and hardware functions 80, interface functions 86 may be synthesized to allow parameters to be passed between these functions. These interface functions 86 may be software methods for writing parameters to hardware functions 80 that are memory-mapped, or this could involve instantiating a hard-disk interface circuit into a programmable logic device to enable the archive of a file system.
It is not necessary to have both software and hardware versions of all of the functions. An application engineer may write all functions for both software and hardware, some for both, or strictly for one or the other. It may be desirable, however, to have both versions in order to give the operating system flexibility in choosing an optimal set of functions and implementations.
After partitioning to functions, each component in software and hardware must be mapped into the physical implementation technology. This involves compiling software functions 78 into threads 88 using a high-level language compiler 82 and hardware functions 80 into configuration patterns 90 using a hardware description language compiler 84. Various optimization and reduction techniques may be applied at this stage, such as constant propagation (both arithmetic and geometric), strength reduction (e.g. a+a=2 * a—this would remove a potentially costly multiply stage), pipelining, or resource sharing.
The final executable code image (generated by a linker 92 which resolves software and hardware function and parameter addresses), includes a main function and dynamically-linked functions all of which may be executed in software or hardware or a combination of both. These functions and the constraints 74 generated by the system design language partitioner 72, are inputs to the virtual computer operating system 94.
Alternatively, a user may simplify the design flow by partitioning the specification manually into software components and hardware components as illustrated in
Algorithm functions, targeting either a microprocessor 130 or a programmable logic device 132, may be written in a high-level language 114 and translated to a hardware description language using a high-level language to hardware description language compiler 118 for the functions to be implemented in a programmable logic device 132. Interface functions 112 necessary to pass parameters between the software and hardware functions are also specified in the high-level language.
The high-level language compiler 116 compiles software functions 110 and creates threads 122 that are linked with the configuration data 126 from the hardware description language compiler 120 in the linker 124. These functions may then be used by the virtual computer operating system 128.
Depending on available resources, the application engineer's instructions, and constraints, the virtual computer operating system may determine (either during run-time or during software compilation) whether the software implementation, the hardware implementation, or a combination of both will be used to run a particular application. This allows for extremely efficient processing since functions that are better suited to run on software are run using software, whereas those functions that are better suited for programmable logic device hardware are run using programmable logic resources.
The foregoing is merely illustrative of the principles of this invention and various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5068823||11 Jul 1988||26 Nov 1991||Star Semiconductor Corporation||Programmable integrated circuit using topological and parametric data to selectively connect and configure different high level functional blocks thereof|
|US5128871 *||7 Mar 1990||7 Jul 1992||Advanced Micro Devices, Inc.||Apparatus and method for allocation of resoures in programmable logic devices|
|US5134884||7 Oct 1987||4 Aug 1992||Forrest Anderson||Single pulse imaging device|
|US5142625 *||13 Jan 1989||25 Aug 1992||Minolta Camera Kabushiki Kaisha||One-chip microcomputer including a programmable logic array for interrupt control|
|US5442792||10 Jun 1994||15 Aug 1995||Hughes Aircraft Company||Expert system compilation method|
|US5469003||5 Nov 1993||21 Nov 1995||Xilinx, Inc.||Hierarchically connectable configurable cellular array|
|US5535342||28 Sep 1993||9 Jul 1996||Giga Operations Corporation||Pld connector for module having configuration of either first PLD or second PLD and reconfigurable bus for communication of two different bus protocols|
|US5535406 *||29 Dec 1993||9 Jul 1996||Kolchinsky; Alexander||Virtual processor module including a reconfigurable programmable matrix|
|US5541849||14 Jun 1993||30 Jul 1996||Lsi Logic Corporation||Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of timing parameters|
|US5548228||28 Sep 1994||20 Aug 1996||Altera Corporation||Reconfigurable programmable logic device having static and non-volatile memory|
|US5579530 *||14 Feb 1995||26 Nov 1996||Intel Corporation||Method and apparatus for dynamically allocating access time to a resource shared between a peripheral bus and a host bus by dynamically controlling the size of burst data transfers on the peripheral bus|
|US5684980||23 Jul 1996||4 Nov 1997||Virtual Computer Corporation||FPGA virtual computer for executing a sequence of program instructions by successively reconfiguring a group of FPGA in response to those instructions|
|US5705938 *||5 Sep 1995||6 Jan 1998||Xilinx, Inc.||Programmable switch for FPGA input/output signals|
|US5761484 *||1 Apr 1994||2 Jun 1998||Massachusetts Institute Of Technology||Virtual interconnections for reconfigurable logic systems|
|US5819064||8 Nov 1995||6 Oct 1998||President And Fellows Of Harvard College||Hardware extraction technique for programmable reduced instruction set computers|
|US5822570||30 Oct 1996||13 Oct 1998||Microsoft Corporation||System and method for parsing and executing a single instruction stream using a plurality of tightly coupled parsing and execution units|
|US5835734||23 Sep 1997||10 Nov 1998||California Institute Of Technology||Electronic processing and control system with programmable hardware|
|US5859878 *||31 Aug 1995||12 Jan 1999||Northrop Grumman Corporation||Common receive module for a programmable digital radio|
|US5946219 *||30 Oct 1996||31 Aug 1999||Atmel Corporation||Method and system for configuring an array of logic devices|
|US5966534||27 Jun 1997||12 Oct 1999||Cooke; Laurence H.||Method for compiling high level programming languages into an integrated processor with reconfigurable logic|
|US5968161 *||7 Feb 1997||19 Oct 1999||Altera Corporation||FPGA based configurable CPU additionally including second programmable section for implementation of custom hardware support|
|US5999990 *||18 May 1998||7 Dec 1999||Motorola, Inc.||Communicator having reconfigurable resources|
|US6011740 *||4 Mar 1998||4 Jan 2000||Xilinx, Inc.||Structure and method for providing additional configuration memories on an FPGA|
|US6044211||14 Mar 1994||28 Mar 2000||C.A.E. Plus, Inc.||Method for graphically representing a digital device as a behavioral description with data and control flow elements, and for converting the behavioral description to a structural description|
|US6068823 *||15 Jan 1999||30 May 2000||The University Of Houston System||Process for the benign direct fixation and conversion of nitrogen oxides|
|US6085317 *||15 Aug 1997||4 Jul 2000||Altera Corporation||Reconfigurable computer architecture using programmable logic devices|
|US6219149||31 Mar 1998||17 Apr 2001||Fuji Xerox Co., Ltd.||Print processing apparatus|
|US6219628||18 Aug 1997||17 Apr 2001||National Instruments Corporation||System and method for configuring an instrument to perform measurement functions utilizing conversion of graphical programs into hardware implementations|
|US6219785 *||26 Apr 2000||17 Apr 2001||Altera Corporation||Reconfigurable computer architecture using programmable logic devices|
|US6226776||16 Sep 1997||1 May 2001||Synetry Corporation||System for converting hardware designs in high-level programming language to hardware implementations|
|US6282627 *||29 Jun 1998||28 Aug 2001||Chameleon Systems, Inc.||Integrated processor and programmable data path chip for reconfigurable computing|
|US6457173||20 Aug 1999||24 Sep 2002||Hewlett-Packard Company||Automatic design of VLIW instruction formats|
|US6477683||5 Feb 1999||5 Nov 2002||Tensilica, Inc.||Automated processor generation system for designing a configurable processor and method for the same|
|US6510546 *||13 Jul 2000||21 Jan 2003||Xilinx, Inc.||Method and apparatus for pre-routing dynamic run-time reconfigurable logic cores|
|US6608638||7 Feb 2000||19 Aug 2003||National Instruments Corporation||System and method for configuring a programmable hardware instrument to perform measurement functions utilizing estimation of the hardware implentation and management of hardware resources|
|US6625797||10 Feb 2000||23 Sep 2003||Xilinx, Inc.||Means and method for compiling high level software languages into algorithmically equivalent hardware representations|
|US6658564||19 Nov 1999||2 Dec 2003||Altera Corporation||Reconfigurable programmable logic device computer system|
|US6745160||8 Oct 1999||1 Jun 2004||Nec Corporation||Verification of scheduling in the presence of loops using uninterpreted symbolic simulation|
|US20020100032||7 Aug 2001||25 Jul 2002||Paul Metzgen||Software-to-hardware compiler|
|US20020124238||7 Aug 2001||5 Sep 2002||Paul Metzgen||Software-to-hardware compiler|
|*||EP419105A2||Title not available|
|EP0445913A2||31 Jan 1991||11 Sep 1991||Advanced Micro Devices, Inc.||An apparatus and method for allocation of resources in programmable logic devices|
|EP0759662A2||16 Aug 1996||26 Feb 1997||Xilinx, Inc.||Time multiplexed programmable logic device|
|*||EP801351A2||Title not available|
|EP0829812A2||12 Sep 1997||18 Mar 1998||Sharp Kabushiki Kaisha||Method of designing an integrated circuit and integrated circuit designed by such method|
|GB1444084A||Title not available|
|JPH03214370A||Title not available|
|JPH08305547A||Title not available|
|JPH09218781A||Title not available|
|JPH10171645A||Title not available|
|WO1994010627A1||5 Nov 1993||11 May 1994||Giga Operations Corporation||System for compiling algorithmic language source code into hardware|
|WO1997009930A1||11 Sep 1996||20 Mar 1997||Medison Co., Ltd.||Ultrasonic diagnostic apparatus for compressing and storing data in cine memory|
|WO1997013209A1||2 Oct 1996||10 Apr 1997||Telefonaktiebolaget L M Ericsson (Publ)||Method of producing a digital signal processor|
|WO1998031102A1||22 Dec 1997||16 Jul 1998||Pact Informationstechnologie Gmbh||Reconfiguration method for programmable components during running time|
|WO2000031652A2||19 Nov 1999||2 Jun 2000||Altera Corporation||Reconfigurable programmable logic device computer system|
|WO2000038087A1||21 Dec 1999||29 Jun 2000||Celoxica Limited||Hardware/software codesign system|
|WO2000063719A1||20 Apr 1999||26 Oct 2000||Synthes Ag Chur||Device for the percutaneous obtainment of 3d-coordinates on the surface of a human or animal organ|
|1||"List of FPGA-based Computing Machines," Steve Guccione, , Last updated Mar. 31, 1999.|
|2||"List of FPGA-based Computing Machines," Steve Guccione, <http://www.io.com/.about.guccione//HW.sub.--list.html>, Last updated Mar. 31, 1999.|
|3||Bernardo Kastrup et al., "ConCISe: A Complier-Driven CPLD-Based Instruction Set Accelerator," IEEE, 1999, pp. 92-101.|
|4||Christian Iseli et al., "A C++ compiler for FPFA custom execution units synthesis," IEEE, 1995, pp. 173-179.|
|5||David Wo et al., "Compiling to the gate Level for a Reconfigurable Co-Processor," IEEE, 1994, pp. 147-154.|
|6||Edwards et al. "Acceleration of Software Algorithms Using Hardware/Software Co-Design Techniques" Journal of Systems Architecture, Elsevier Science Publishers BV., Amsterdam, NL>, vol. 42, No. 9/10, pgs. 697-707, XP000643485.|
|7||Edwards et al. "Hardware/software partitioning for performance enhancement" pgs. 2-5, Jan. 1, 1995, XP006529055.|
|8||Electronik, De, Franzis Verlag GmbH-"MIT Programmierbarer Logik Verheirated," Mar. 31, 1998, vol. 47, No. 7, p. 38.|
|9||Electronik, De, Franzis Verlag GmbH—"MIT Programmierbarer Logik Verheirated," Mar. 31, 1998, vol. 47, No. 7, p. 38.|
|10||Ernst et al. "The Cosyma Environment for Hardware/Software Cosynthesis of Small Embedded Systems" Microprocessors and Microsystems, IPC Business Press Ltd. London, GB vol. 20, No. 3 May 1, 1996 pp. 159-166, XP000590927.|
|11||Ian Page, "Constructing Hardware-Software Systems from a Single Description," Journal of VLSI Signal Processing, vol. 12, No. 1, Jan. 1996, pp. 87-107.|
|12||IBM, "Programmable Manual Cable Assembly Board," IBM Technical Disclosure Bulletin, vol. 31, No. 12, May 1989, pp. 306-309.|
|13||João M.P. Cardoso et al., "Marco-Based Hardware Compilation of Java(TM) Bytecodes into a Dynamic Reconfigurable Computing System," IEEE, 1999, pp. 2-11.|
|14||João M.P. Cardoso et al., "Marco-Based Hardware Compilation of Java™ Bytecodes into a Dynamic Reconfigurable Computing System," IEEE, 1999, pp. 2-11.|
|15||Luc Séméria et al., "SpC; Synthesis of Pointers in C Application of Pointer Analysis to the Behavioral Synthesis from C," 1998, pp. 340-346.|
|16||M Wazlowski et al., "Prism-II Complier and Architecture," IEEE, 1993, pp. 9-16.|
|17||M.D. Edwards, J. Forrest-"Software acceleration using programmable hardware devices," Jan. 1996, p. 55-63.|
|18||M.D. Edwards, J. Forrest—"Software acceleration using programmable hardware devices," Jan. 1996, p. 55-63.|
|19||Michael J. Wirthlin and Brad L. Hutchings-"Improving Functional Density Using Run-Time Circuit Reconfiguration," Jun. 1998, p. 247-256.|
|20||Michael J. Wirthlin and Brad L. Hutchings—"Improving Functional Density Using Run-Time Circuit Reconfiguration," Jun. 1998, p. 247-256.|
|21||Nanya et al. "Scalable-Delay-Insensitive Design: a high-performance approach to dependable asynchronous systems," Proceedings of International Symposium on Future of Intellectual Integrated Electronics, Mar. 1999, pp. 1-10.|
|22||Nanya, "Asynchronous VLSI System Design," ASP-DAC '98 Tutorials, Feb. 10, 1998, Yokohama, Japan.|
|23||Parkinson et al. "Profiling in the ASP Codesign environment" Systems Synthesis, 1995, Proceedings of the Eighth International Symposium on Cannes, France Sep. 13-15, 1995, Los Alamitos, CA, USA, IEEE pp. 128-133, XP010192178.|
|24||Stroy et al. "Inter-Domain Movement of Functionality as a Repartitioning Strategy for Hardward/Software Co-Design" Journal of Systems Architecture, Elsevier Science Publishers BV., Amsterdam, NL, vol. 43, No. 1/05, pgs. 87-98 Mar. 1, 1997 X000679758.|
|25||Timothy J. Callahan et al., "The Garp Architecture and C Complier," IEEE, Apr. 2000 pp. 62-69.|
|26||Tsukasa Yamauchi et al., "SOP: A Reconfigurable Massively Parallel System and Its Control-Data-Flow based Compiling Method," NEC Laboratory, pp. 148-156, IEEE 1996.|
|27||Tsuyoshi Isshiki et al., "Bit-Serial Pipeline Synthesis aand Layout for Large-Scale Configurable Systems," IEEE, 1997, pp. 441-446.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8266416 *||11 Dec 2008||11 Sep 2012||Fujitsu Limited||Dynamic reconfiguration supporting method, dynamic reconfiguration supporting apparatus, and dynamic reconfiguration system|
|US20090164773 *||11 Dec 2008||25 Jun 2009||Fujitsu Microelectronics Limited||Dynamic reconfiguration supporting method, dynamic reconfiguration supporting apparatus, and dynamic reconfiguration system|
|U.S. Classification||713/1, 710/8, 713/100|
|International Classification||G06F3/00, G06F9/00, G06F17/50, G06F11/00, G06F15/78|