WO2002061577A2 - Application program interface for programmable architecture cores - Google Patents

Application program interface for programmable architecture cores Download PDF

Info

Publication number
WO2002061577A2
WO2002061577A2 PCT/GB2002/000390 GB0200390W WO02061577A2 WO 2002061577 A2 WO2002061577 A2 WO 2002061577A2 GB 0200390 W GB0200390 W GB 0200390W WO 02061577 A2 WO02061577 A2 WO 02061577A2
Authority
WO
WIPO (PCT)
Prior art keywords
platform
interface
independent
programmable
application
Prior art date
Application number
PCT/GB2002/000390
Other languages
French (fr)
Other versions
WO2002061577A3 (en
Inventor
John Gordon Lee Alexander
Hammad Hamid
Original Assignee
Celoxica Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/772,710 external-priority patent/US20030033588A1/en
Application filed by Celoxica Limited filed Critical Celoxica Limited
Priority to AU2002226583A priority Critical patent/AU2002226583A1/en
Publication of WO2002061577A2 publication Critical patent/WO2002061577A2/en
Publication of WO2002061577A3 publication Critical patent/WO2002061577A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/44Encoding
    • G06F8/447Target code generation

Definitions

  • the present invention relates to programmable platform architectures and more particularly to providing a methodology for coding for programmable platform architectures in a platform independent manner.
  • an application programming interface includes calling conventions by which an application program accesses an operating system and other services.
  • An API is defined at the source code level and provides a level of abstraction between the application and the kernel (or other privileged utilities) to ensure the portability of the code.
  • An API can also provide an interface between a high level language and lower level utilities and services that were written without consideration for the calling conventions supported by compiled languages.
  • the API's main task may include the translation of data from one format to another or one protocol to another.
  • FPGAs are gate arrays which can be repeatedly reprograrnmed while remaining in their environment of use (e.g., while mounted in the circuit board in which it is intended to be used).
  • FPGAs typically include programmable logic blocks (e.g., programmable Boolean logic gates), and may also include programmable memory blocks, programmable clocking blocks, and other specialized programmable blocks such as multiplier blocks and I/O ports. Examples of commercially available FPGAs include those manufactured and distributed by the XILINX, Inc., such as the Spartan II Series and Virtex Series FPGAs.
  • Verilog HDL Hardware Description Language
  • NHSIC HDL often referred to as VHDL
  • HDLs thus provide a method of generating code that is reasonably independent from the FPGA architecture.
  • HDLs cannot be "platform-independent" which requires support for the vast variety of peripheral components that might be found connected to the FPGA.
  • the compiler, or synthesis tool cannot be platform-independent. Therefore, the HDL must be compiled uniquely for differing FPGAs.
  • a change to any of the other platform components such as hardware resources or peripherals require that the application be rewritten to use the new peripheral(s).
  • FPGA Platform 1 may include a first generation of a product or reference board produced by a company.
  • FPGA Platform 2 may include a second generation of the board produced by the company.
  • To port the system produced for FPGA Platform 1. to FPGA Platform 2 requires a large amount of effort since a new interface must be written for each new peripheral.
  • FPGA Platform 3 represents a possible future platform. Again, much effort is required to port the system produced for FPGA Platform 2 to FPGA Platform 3.
  • there is a need for an interface framework including platform-independent code which may easily be utilized in the context of FPGA Platform 1, FPGA Platform 2, FPGA Platform 3 or any programmable platform.
  • a system and computer program product are provided for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms.
  • a platform-independent application and a platform-independent interface.
  • the platform-independent interface is capable of interfacing, at least in part, the platform-independent application with any one of the distinct types of programmable platform.
  • the programmable platform is further equipped with a platform-dependent interface. This platform-dependent interface serves in conjunction with the platform-independent interface in providing the interface between the platform-independent application and the programmable platform.
  • a versatile framework is provided that allows the reuse of the platform-independent application on numerous different types of programmable platforms.
  • the platform-dependent interface may include a library of platform-dependent resource interfaces which are wrapped with a standard interface capable of being accessed by the platform- independent interface. Further, the platform-independent application may be specifically written to use the platform-independent interface.
  • the interface between the platform-independent application and the programmable platform may be customized.
  • the specific port requirements of the platform- independent application may be accommodated in a customizable manner.
  • peripherals may be included and excluded based on the requirements of the platform-independent application. Still yet, the memory resources required by the platform-independent application may be dedicated.
  • the interface may be customized in accordance with user-specified criteria.
  • a graphical user interface may be provided for allowing a user to enter the user-specified criteria.
  • a plurality of the applications may be included.
  • Each application may thus be equipped with a unique platform-independent application, and a single platform-independent interface including a plurality of plugs.
  • the platform-dependent interface of the programmable platform may include a plurality of sockets allocated to the plugs.
  • the programmable platform may include a field programmable gate array (FPGA).
  • FPGA field programmable gate array
  • the platform-independent interface may be written in a C-based variant programming language.
  • Prior art Figure 1 illustrates the difficultly associated with the platform- dependence of applications executed on FPGAs.
  • Figure 2 illustrates a framework for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms, wherein the application is shown to be integrated with a first type of programmable platform.
  • Figure 2 A illustrates the framework of Figure 2, wherein the application is shown to be integrated with a second type of programmable platform.
  • Figure 2B illustrates the framework of Figure 2, wherein a plurality of applications are shown to be integrated with a programmable platform.
  • Figure 2C illustrates the framework of Figure 2, wherein a plurality of specific exemplary applications are shown to be integrated with a specific exemplary programmable platform.
  • Figure 3 shows a lower level view of a possible linkage between the platform-independent application and the platform-dependent interface.
  • Figure 4 illustrates a method to produce a bit-stream for a programmable platform.
  • Figure 5 illustrates the file relationships that may be used to generate the system of the present invention, in accordance with one exemplary embodiment.
  • Figure 6 illustrates an exemplary embodiment of the present invention.
  • One aspect of the present invention involves an application program interface that permits the generation of platform-independent code that may be used with different types of programmable platforms.
  • the present invention is capable of allowing code to be conveniently reused from one programmable platform to another.
  • FIG. 2 illustrates a framework 200 for allowing a platform-independent application 204 to be integrated with any one of a plurality of distinct types of programmable platforms.
  • the platform-independent application 204 is integrated with a first type of programmable platform 201 which includes a first type of memory 210, a bus I/O 212, and a first type of audio decoder 214.
  • the first type of programmable platform 201 is merely exemplary of one possible programmable platform. Of course, any type of programmable platform 201 may be employed per the desires of the user.
  • the manner in which the platform-independent application 204 is conveniently integrated with a second type of programmable platform will be set forth later during reference to Figure 2 A.
  • a programmable platform refers the programmable hardware including resources situated on the hardware.
  • Programmable hardware may refer to a field programmable gate array (FPGA), or any hardware that is programmable.
  • Resources situated on the hardware may include application resources such as memory or an audio codec as well as interfaces to peripheral devices such as an i/o bus.
  • different "types" of programmable platforms may differ by any variation in the programmable platform itself and/or in an associated environment.
  • the platform-independent application 204 may be integrated with the programmable platform by being implemented thereon, implemented on an associated device in a "co-development environment,” or integrated in any other desired manner.
  • FPGAs include the XC2000TM, XC3000TM, XC4000TM, and/or Virtex families of FPGA devices introduced by Xilinx, Inc. of San Jose, Calif.
  • the architectures of these devices are exemplified in U.S. Pat. Nos. 4,642,487; 4,706,216; 4,713,557; and 4,758,985; each of which is originally assigned to Xilinx, Inc. and which are herein incorporated by reference for all purposes. It should be noted, however, that FPGAs of any type may be employed in the context of the present invention.
  • platform- independent interface 206 By being “platform-independent,” the platform- independent application 204 and the platform-independent interface 206 are written/configured universally in a manner that is independent of any particular type of programmable platform.
  • the platform-independent application 204 may be specifically written to use the platform-independent interface 206. In one embodiment, this is accomplished by defining a set of macros and functions that may be used to form and access generic interfaces to platform resources (i.e. resources that are specific to particular programmable platform and possibly the peripheral components connected thereto, etc.).
  • the platform-independent interface 206 is designed based on a standard predetermined format. In use, the platform-independent interface 206 is capable of providing, at least in part, an interface between the platform-independent application 204 and any one of the distinct types of programmable platforms.
  • the programmable platform is further equipped with a platform-dependent interface 208.
  • platform-dependent interface 208 is specifically written for the programmable platform and further serves in conjunction with the platform-independent interface 206 in interfacing the platform-independent application 204 and the programmable platform.
  • platform-dependent interface 208 is written configured specifically based on a specific type of programmable platform including interfaces to the hardware resources and peripherals that will be used by the platform-independent application 204.
  • the platform-dependent interface 208 provides a collection of interfaces to platform resources wrapped with a common interface.
  • the interfaces may include a memory chip interface, a video DAC interface, an interface to a bus of some description, or any other desired interface.
  • a bus interface may be provided which is customized to facilitate co-processing. As such, a co-processor may be reduced to a component inside the platform-dependent interface 208.
  • the platform-dependent interface 208 further provides a method of collecting all of such interfaces, and storing them in a common library.
  • the common library is then given a standard interface for each type of platform resource for allowing communication with the standard format of the platform-independent interface 206.
  • the platform-independent interface 206 includes a standard set of functions/macros that provide access to one or more of the aforementioned interfaces of the platform-dependent interface 208.
  • the actual implementation of the connection formed can be of any format required providing that the platform-dependent interface 208 supports the connection method. As such, the flexibility of the present technique is extended. More information regarding the linkage between the platform-independent application 204 and the platform- dependent interface 208 will be set forth hereinafter in greater detail during reference to Figure 3.
  • the platform-independent interface 206 may be characterized as an Engineered Platform Independent Application (EPIA).
  • EPIA Engineered Platform Independent Application
  • the platform-independent interface 206 may be written in Handel-C programmable language.
  • the platform-independent interface 206 may be referred to as a Handel-C Platform Application Program Interface (HCP-API).
  • the platform-dependent interface 208 may be referred to as a Platform Resource Support Package (PRSP).
  • PRSP Platform Resource Support Package
  • C-based variant programming language refers to any programming language which generally follows the conventions of the C programming language with adaptations suitable for programming reprogrammable platforms.
  • Examples of a C-based variant programming language include Handel-C, Bach-C, and any other programming language meeting the above criteria.
  • Figure 2A illustrates the framework of Figure 2, wherein the application 204 is shown to be integrated with a second type of programmable platform 203.
  • the second type of programmable platform 203 may include a second type of memory 220, a bus I/O 222, and a second type of audio decoder 224.
  • a new platform-dependent interface 208 is first configured to reflect the resources of the programmable platform 203. This may require the development of new modules for the platform-dependent interface 208 designed specifically to interface with the new resources. However, since the interface between the platform-independent interface 206 and the platform-dependent interface 208 is standardized, an interface module previously developed for the same resource can be incorporated in the platform dependent interface 208 without modification. The process of configuring the platform dependent-interface 208 to use the correct resources may be facilitated by use of a graphical user interface described later.
  • the second type of programmable platform 203 includes components that generally correspond to those of the first type of programmable platform 201 of Figure 2.
  • measures may be taken to ensure that the application 204 is capable of operating using the available resources.
  • the platform-dependent interface 208 may dedicate memory resources required by the platform-independent application 204.
  • FIG 2B illustrates the framework of Figure 2, wherein a plurality of applications 240 are shown to be integrated with a single programmable platform.
  • Each platform-independent application 204 may thus be designed for a unique purpose.
  • each platform-independent application 204 may include a platform-independent interface 206 similar to the platform-independent interfaces 206 of the other applications 204.
  • the platform-dependent interface 208 associated with the programmable platform may include a plurality of ports 210 each associated with one of the applications 204.
  • FIG. 2C illustrates the framework of Figure 2, wherein a plurality of specific exemplary applications 240 are shown to be integrated with a specific exemplary programmable platform.
  • each platform-independent application 204 are designed for a unique purpose, i.e. an encrypting and rendering.
  • each platform-independent application 204 includes a platform-independent interface 206 including a plurality of "plugs" 270 that allow the platform- independent applications 204 to interface resources of the programmable platform in a generic manner.
  • such resources may include a memory controller, video DAC controller, and bus controller.
  • the platform-dependent interface 208 associated with the programmable platform may include a plurality of "sockets" 272 allocated to the plugs 270 of the platform-independent interface 206.
  • the aforementioned ports 210 may be viewed as having two portions, namely a plug portion and a socket portion. It should be noted that such allocation of the sockets 272 to the plugs 270 may be set forth in a top level file 274 used to instantiate the applications 240. When the programmable platform is to be changed, only this top level file 274 needs to be altered to accommodate this change.
  • FIG. 3 shows a lower level view 300 of a possible linkage between the platform-independent application 204 and the platform-dependent interface 208.
  • each port 210 identifies actual ports 302 based on the specific requirements of the platform-independent application 204.
  • Such ports 302 may include memory ports, data-stream ports, etc.
  • Table 1 illustrates the various ports that may be supported in one embodiment.
  • the hardware should have the required resources.
  • the platform-independent interface 206 may be configured to customize the interface by enabling/disabling a plurality of peripherals, i.e. external bus, video DAC, ZBT memory chip, async memory chip, video capture chip, etc.
  • peripherals i.e. external bus, video DAC, ZBT memory chip, async memory chip, video capture chip, etc.
  • the exact configuration may depend on the particular programmable platform being used. It should be noted that the foregoing feature is especially useful where I/O connectors are used to provide optional functionality. Other options may include dedication of memory resources or multi-porting of memory resources.
  • the platform-dependent interface 208 may be capable of customizing the interface in accordance with user-specified criteria.
  • a graphical user interface may be provided for allowing a user to enter the user- specified criteria.
  • Such criteria may involve any of the parameters, peripherals, ports, etc. set forth hereinabove.
  • the application associated with the graphical user interface further generates a code base for the platform-dependent interface 208 which is configured to the specific user requirements. Use of the graphical user interface thus enables the inclusion of future, more complex configuration features, thus expanding flexibility.
  • the platform-dependent interface 208 is thus both configurable and extendable. Such allows features to be implemented as required by the user. Data streaming and message sending may be provided to allow easy, compatible and efficient communication between the platform-independent application 204 and other resources, i.e. an external bus.
  • the implementation of the features of the platform-independent interface 206 is also flexible. This flexibility allows, for example, a video engine to be used on programmable platform with no video output hardware. This may be useful if the image is to be sent to other programmable platform to be displayed.
  • the platform-dependent interface 208 may include a Handel- C library and a header file that contains interfaces to the resources of the programmable platform.
  • the Handel-C library and header may be used to create a source file that forms a top-level for a system. It is this top-level source file that creates the instances of the platform-independent application 204.
  • the header file may further include macros for creating and customizing the interfaces to the platform-independent application 204. It is possible for the interface to the platform-independent application 204 to have different port requirements depending on functionality, thus warranting the use of such technique.
  • the platform-dependent interface 208 may also be at the top-level as it is possible for data streaming ports and messaging ports to be interconnected with the platform-independent application 204.
  • Figure 4 illustrates a method 400 to produce a bit-stream for the programmable platform. As shown, the method 400 includes writing the platform- independent application 204, wherein the platform-independent application 204 is further equipped with the platform-independent interface 206. See act 402.
  • the platform-independent application 204 is compiled into a predetermined format, i.e. EDIF, etc.
  • the platform-dependent interface 208 is then configured in act 406 for serving in conjunction with the platform-independent interface 206 in providing the interface between the platform-independent application 204 and programmable platform.
  • the platform-dependent interface 208 is compiled into the predetermined format.
  • Figure 5 illustrates the file relationships 500 that may be used to generate the system of the present invention, in accordance with one exemplary embodiment.
  • FPGA Platform 1 includes a first generation of a product or reference board produced by a company.
  • FPGA Platform 2 may include a second generation of the board produced by the company.
  • the platform-dependent interface 208 is not necessarily application-specific and thus only needs to be produced once for each platform. For the platform- independent application 204 to function with a particular platform-dependent interface 208 requires only that the platform-dependent interface 208 supports the requirements for performance and functionality that the platform-independent application 204 requires.
  • the port types may specify the functionality requirements of the platform-independent application 204.
  • Table 2 illustrates an exemplary interface for a split phase memory access controller which may be defined by the platform-independent interface 206.
  • address cycles 600 and data cycles 602 are treated separately. This allows efficient and low delay access to an external memory device. This technique also allows support for memory devices that do not return data within the same clock cycle that the address was issued. In use, the data cycles 602 lock until an address cycle 600 has been processed.
  • Address This is a value represents the address location to be accessed.
  • This value represents the direction of the memory transfer operation.
  • Table 3 illustrates exemplary code usage that may be utilized by the platform-independent application 204 to utilize the interface ofTable 2.
  • HCPAPISetAddress (BankHandle, AddressValue, MemoryTransferDirection) ; ⁇ else delay; ⁇ par ⁇ if (AddressValueValid &
  • platform-dependent interface 208 may be generated manually, it is more efficient if a code wizard is used. Such code generation wizard may be included with the platform-dependent interface 208 as an application included with libraries associated with the platform-dependent interface 208. Table 4 illustrates a usage example.
  • HCPAPI_EXECUTE_MODULE DemoModulel ) ( 0, LEDResourceO, 10000000 ) ;
  • HCPAPI_EXECUTE_MODULE DemoModulel ) ( 1, LEDResourcel, 20000000 );
  • LEDStatus HCPAPI_EXECUTE_FUNCTION ( DemoFunctionl, InstancelD ) ( LEDStatus ) ;
  • HCPAPISetLEDResourceStatus AnLEDResource, LEDStatus ) ;

Abstract

A system and computer program product are provided for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms. First included is a platform-independent application and a platform-independent interface. The platform-independent interface is capable of interfacing the platform-independent application with any one of the distinct types of programmable platform. The programmable platform is further equipped with a platform-dependent interface. This platform-dependent interface serves in conjunction with the platform-independent interface in providing the interface serves in conjunction with the platform-independent interface in providing the interface between the platform-independent application and the programmable platform. As such, a versatile framework is provided that allows the reuse of the platform-independent application on numerous different types of programmable platforms.

Description

APPLICATION PROGRAM INTERFACE FOR PROGRAMMABLE
ARCHITECTURE CORES
FIELD OF THE INVENTION
The present invention relates to programmable platform architectures and more particularly to providing a methodology for coding for programmable platform architectures in a platform independent manner.
BACKGROUND OF THE INVENTION
Traditionally, an application programming interface (API) includes calling conventions by which an application program accesses an operating system and other services. An API is defined at the source code level and provides a level of abstraction between the application and the kernel (or other privileged utilities) to ensure the portability of the code.
An API can also provide an interface between a high level language and lower level utilities and services that were written without consideration for the calling conventions supported by compiled languages. In this case, the API's main task may include the translation of data from one format to another or one protocol to another.
FPGAs are gate arrays which can be repeatedly reprograrnmed while remaining in their environment of use (e.g., while mounted in the circuit board in which it is intended to be used). FPGAs typically include programmable logic blocks (e.g., programmable Boolean logic gates), and may also include programmable memory blocks, programmable clocking blocks, and other specialized programmable blocks such as multiplier blocks and I/O ports. Examples of commercially available FPGAs include those manufactured and distributed by the XILINX, Inc., such as the Spartan II Series and Virtex Series FPGAs.
Typically, FPGAs are programmed using a programming language specific to hardware, such as the Verilog HDL (Hardware Description Language) or the NHSIC HDL (often referred to as VHDL). These programming languages are generally used to implement specific hardware logic which is desired in the FPGA. As an example, the VHDL statement "ADD <= Al + A2 + A3 + A4" could be used to add signals Al through A4. After the logic has been coded in HDL, it is synthesized to a bit stream. The FPGA can then be programmed by writing the bit stream to the FPGA.
HDLs thus provide a method of generating code that is reasonably independent from the FPGA architecture. However, it is well known that HDLs cannot be "platform-independent" which requires support for the vast variety of peripheral components that might be found connected to the FPGA. Further, the compiler, or synthesis tool, cannot be platform-independent. Therefore, the HDL must be compiled uniquely for differing FPGAs. Furthermore, even if the FPGA remains the same, a change to any of the other platform components such as hardware resources or peripherals require that the application be rewritten to use the new peripheral(s). These features inhibit the reuse of applications on different FPGA platforms. Since FPGAs are found in an increasingly wide variety of systems, a technique of generating platform-independent code is desirable. In traditional systems, platform-independence for applications is commonly provided by an operating system. Unfortunately, an FPGA has no operating system.
Prior art Figure 1 illustrates one difficultly associated with the platform- dependence of applications executed on FPGAs. As shown in Figure 1, FPGA Platform 1 may include a first generation of a product or reference board produced by a company. FPGA Platform 2 may include a second generation of the board produced by the company. To port the system produced for FPGA Platform 1. to FPGA Platform 2 requires a large amount of effort since a new interface must be written for each new peripheral. FPGA Platform 3 represents a possible future platform. Again, much effort is required to port the system produced for FPGA Platform 2 to FPGA Platform 3. In view of this difficulty, there is a need for an interface framework including platform-independent code which may easily be utilized in the context of FPGA Platform 1, FPGA Platform 2, FPGA Platform 3 or any programmable platform.
SUMMARY OF THE INVENTION
A system and computer program product are provided for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms. First included are a platform-independent application and a platform-independent interface. The platform-independent interface is capable of interfacing, at least in part, the platform-independent application with any one of the distinct types of programmable platform. The programmable platform is further equipped with a platform-dependent interface. This platform-dependent interface serves in conjunction with the platform-independent interface in providing the interface between the platform-independent application and the programmable platform. As such, a versatile framework is provided that allows the reuse of the platform-independent application on numerous different types of programmable platforms.
In one embodiment of the present invention, the platform-dependent interface may include a library of platform-dependent resource interfaces which are wrapped with a standard interface capable of being accessed by the platform- independent interface. Further, the platform-independent application may be specifically written to use the platform-independent interface.
In another embodiment of the present invention, the interface between the platform-independent application and the programmable platform may be customized. For example, the specific port requirements of the platform- independent application may be accommodated in a customizable manner.
Moreover, peripherals may be included and excluded based on the requirements of the platform-independent application. Still yet, the memory resources required by the platform-independent application may be dedicated.
In another aspect of the present embodiment, the interface may be customized in accordance with user-specified criteria. In such aspect, a graphical user interface may be provided for allowing a user to enter the user-specified criteria.
In another embodiment of the present invention, a plurality of the applications may be included. Each application may thus be equipped with a unique platform-independent application, and a single platform-independent interface including a plurality of plugs. Further, the platform-dependent interface of the programmable platform may include a plurality of sockets allocated to the plugs.
In still another embodiment of the present invention, the programmable platform may include a field programmable gate array (FPGA). Further, the platform-independent interface may be written in a C-based variant programming language.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be better understood when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein:
Prior art Figure 1 illustrates the difficultly associated with the platform- dependence of applications executed on FPGAs.
Figure 2 illustrates a framework for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms, wherein the application is shown to be integrated with a first type of programmable platform.
Figure 2 A illustrates the framework of Figure 2, wherein the application is shown to be integrated with a second type of programmable platform.
Figure 2B illustrates the framework of Figure 2, wherein a plurality of applications are shown to be integrated with a programmable platform.
Figure 2C illustrates the framework of Figure 2, wherein a plurality of specific exemplary applications are shown to be integrated with a specific exemplary programmable platform.
Figure 3 shows a lower level view of a possible linkage between the platform-independent application and the platform-dependent interface.
Figure 4 illustrates a method to produce a bit-stream for a programmable platform.
Figure 5 illustrates the file relationships that may be used to generate the system of the present invention, in accordance with one exemplary embodiment. Figure 6 illustrates an exemplary embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
One aspect of the present invention involves an application program interface that permits the generation of platform-independent code that may be used with different types of programmable platforms. By this design, the present invention is capable of allowing code to be conveniently reused from one programmable platform to another.
Figure 2 illustrates a framework 200 for allowing a platform-independent application 204 to be integrated with any one of a plurality of distinct types of programmable platforms. As shown, the platform-independent application 204 is integrated with a first type of programmable platform 201 which includes a first type of memory 210, a bus I/O 212, and a first type of audio decoder 214. It should be understood that the first type of programmable platform 201 is merely exemplary of one possible programmable platform. Of course, any type of programmable platform 201 may be employed per the desires of the user. The manner in which the platform-independent application 204 is conveniently integrated with a second type of programmable platform will be set forth later during reference to Figure 2 A.
In the present description, a programmable platform refers the programmable hardware including resources situated on the hardware. Programmable hardware may refer to a field programmable gate array (FPGA), or any hardware that is programmable. Resources situated on the hardware may include application resources such as memory or an audio codec as well as interfaces to peripheral devices such as an i/o bus. Further, different "types" of programmable platforms may differ by any variation in the programmable platform itself and/or in an associated environment. Further, the platform-independent application 204 may be integrated with the programmable platform by being implemented thereon, implemented on an associated device in a "co-development environment," or integrated in any other desired manner. Examples of FPGAs include the XC2000™, XC3000™, XC4000™, and/or Virtex families of FPGA devices introduced by Xilinx, Inc. of San Jose, Calif. The architectures of these devices are exemplified in U.S. Pat. Nos. 4,642,487; 4,706,216; 4,713,557; and 4,758,985; each of which is originally assigned to Xilinx, Inc. and which are herein incorporated by reference for all purposes. It should be noted, however, that FPGAs of any type may be employed in the context of the present invention.
With continuing reference to Figure 2, further included is a platform- independent interface 206. By being "platform-independent," the platform- independent application 204 and the platform-independent interface 206 are written/configured universally in a manner that is independent of any particular type of programmable platform.
The platform-independent application 204 may be specifically written to use the platform-independent interface 206. In one embodiment, this is accomplished by defining a set of macros and functions that may be used to form and access generic interfaces to platform resources (i.e. resources that are specific to particular programmable platform and possibly the peripheral components connected thereto, etc.).
The platform-independent interface 206 is designed based on a standard predetermined format. In use, the platform-independent interface 206 is capable of providing, at least in part, an interface between the platform-independent application 204 and any one of the distinct types of programmable platforms.
With reference again to Figure 2, it is shown that the programmable platform is further equipped with a platform-dependent interface 208. Such platform- dependent interface 208 is specifically written for the programmable platform and further serves in conjunction with the platform-independent interface 206 in interfacing the platform-independent application 204 and the programmable platform. By being "platform-dependent," the platform-dependent interface 208 is written configured specifically based on a specific type of programmable platform including interfaces to the hardware resources and peripherals that will be used by the platform-independent application 204.
In use, the platform-dependent interface 208 provides a collection of interfaces to platform resources wrapped with a common interface. The interfaces may include a memory chip interface, a video DAC interface, an interface to a bus of some description, or any other desired interface. In one embodiment, a bus interface may be provided which is customized to facilitate co-processing. As such, a co-processor may be reduced to a component inside the platform-dependent interface 208.
The platform-dependent interface 208 further provides a method of collecting all of such interfaces, and storing them in a common library. The common library is then given a standard interface for each type of platform resource for allowing communication with the standard format of the platform-independent interface 206.
As mentioned earlier, the platform-independent interface 206 includes a standard set of functions/macros that provide access to one or more of the aforementioned interfaces of the platform-dependent interface 208. The actual implementation of the connection formed can be of any format required providing that the platform-dependent interface 208 supports the connection method. As such, the flexibility of the present technique is extended. More information regarding the linkage between the platform-independent application 204 and the platform- dependent interface 208 will be set forth hereinafter in greater detail during reference to Figure 3.
By this design, a versatile framework is provided that allows the reuse of the platform-independent application 204 on numerous different types of programmable platforms. One exemplary reuse of the platform-independent application 204 will be set forth later during reference to Figure 2A.
In one embodiment, the platform-independent interface 206 may be characterized as an Engineered Platform Independent Application (EPIA). As an option, the platform-independent interface 206 may be written in Handel-C programmable language. In such embodiment, the platform-independent interface 206 may be referred to as a Handel-C Platform Application Program Interface (HCP-API). Still yet, the platform-dependent interface 208 may be referred to as a Platform Resource Support Package (PRSP).
More information regarding the Handel-C programming language may be found in " Celoxica Handel-C Language Reference Manual: Version 3," " Celoxica Handel-C User Manual: Version 3.0," " Celoxica Handel-C Interfacing to other language code blocks: Version 3.0," each authored by Rachel Ganz, and published by Celoxica Limited in the year of 2001; and "EMBEDDED SOLUTIONS Handel- C Preprocessor Reference Manual: Version 2.1," also authored by Rachel Ganz and published by Embedded Solutions Limited in the year of 2000; and which are each incorporated herein by reference in their entirety. Additional information may also be found in a co-pending application entitled "SYSTEM, METHOD AND
ARTICLE OF MANUFACTURE FOR USING A LIBRARY MAP TO CREATE AND MAINTAIN IP CORES EFFECTIVELY" which was filed 1/29/2001 under serial number 09/772,710, and which is incorporated herein by reference in its entirety.
It should be understood that other programming and hardware description languages may be utilized as well. In particular, in one embodiment it is preferred to utilize a "C-based variant programming language," which refers to any programming language which generally follows the conventions of the C programming language with adaptations suitable for programming reprogrammable platforms. Examples of a C-based variant programming language include Handel-C, Bach-C, and any other programming language meeting the above criteria.
Figure 2A illustrates the framework of Figure 2, wherein the application 204 is shown to be integrated with a second type of programmable platform 203. As shown, the second type of programmable platform 203 may include a second type of memory 220, a bus I/O 222, and a second type of audio decoder 224.
In order to integrate the application 204 with the new type of programmable platform 203, a new platform-dependent interface 208 is first configured to reflect the resources of the programmable platform 203. This may require the development of new modules for the platform-dependent interface 208 designed specifically to interface with the new resources. However, since the interface between the platform-independent interface 206 and the platform-dependent interface 208 is standardized, an interface module previously developed for the same resource can be incorporated in the platform dependent interface 208 without modification. The process of configuring the platform dependent-interface 208 to use the correct resources may be facilitated by use of a graphical user interface described later. It may also be facilitated by a method of using library maps set forth in the co-pending application entitled "SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR USING A LIBRARY MAP TO CREATE AND MAINTAIN IP CORES EFFECTIVELY" referenced above. Further, the application 204 is recompiled in the context of the new platform-dependent interface 208. More information regarding such process will be set forth hereinafter in greater detail during reference to Figure 4.
As can be noted above, the second type of programmable platform 203 includes components that generally correspond to those of the first type of programmable platform 201 of Figure 2. In cases where the programmable platforms include fewer or additional components, measures may be taken to ensure that the application 204 is capable of operating using the available resources. For example, the platform-dependent interface 208 may dedicate memory resources required by the platform-independent application 204.
By this design, the amount of effort required to port applications from one FPGA platform to another is reduced. This, in turn, enables easier construction of systems on a semiconductor platform.
Figure 2B illustrates the framework of Figure 2, wherein a plurality of applications 240 are shown to be integrated with a single programmable platform. Each platform-independent application 204 may thus be designed for a unique purpose. Further, each platform-independent application 204 may include a platform-independent interface 206 similar to the platform-independent interfaces 206 of the other applications 204. Further, the platform-dependent interface 208 associated with the programmable platform may include a plurality of ports 210 each associated with one of the applications 204.
Figure 2C illustrates the framework of Figure 2, wherein a plurality of specific exemplary applications 240 are shown to be integrated with a specific exemplary programmable platform. As shown, each platform-independent application 204 are designed for a unique purpose, i.e. an encrypting and rendering. Further, each platform-independent application 204 includes a platform-independent interface 206 including a plurality of "plugs" 270 that allow the platform- independent applications 204 to interface resources of the programmable platform in a generic manner. As shown in the specific example of Figure 2C, such resources may include a memory controller, video DAC controller, and bus controller.
The platform-dependent interface 208 associated with the programmable platform may include a plurality of "sockets" 272 allocated to the plugs 270 of the platform-independent interface 206. As such, the aforementioned ports 210 may be viewed as having two portions, namely a plug portion and a socket portion. It should be noted that such allocation of the sockets 272 to the plugs 270 may be set forth in a top level file 274 used to instantiate the applications 240. When the programmable platform is to be changed, only this top level file 274 needs to be altered to accommodate this change.
Figure 3 shows a lower level view 300 of a possible linkage between the platform-independent application 204 and the platform-dependent interface 208. As shown, each port 210 identifies actual ports 302 based on the specific requirements of the platform-independent application 204. Such ports 302 may include memory ports, data-stream ports, etc. Table 1 illustrates the various ports that may be supported in one embodiment.
Table 1
Data Streaming
Memory Access (On chip or Off chip )
Message Sending
Message Receiving
Basic Video DAC Interface Bus Interface
For a feature to be available (e.g. Memory access), the hardware should have the required resources.
In one embodiment, the platform-independent interface 206 may be configured to customize the interface by enabling/disabling a plurality of peripherals, i.e. external bus, video DAC, ZBT memory chip, async memory chip, video capture chip, etc. The exact configuration may depend on the particular programmable platform being used. It should be noted that the foregoing feature is especially useful where I/O connectors are used to provide optional functionality. Other options may include dedication of memory resources or multi-porting of memory resources.
As an option, the platform-dependent interface 208 may be capable of customizing the interface in accordance with user-specified criteria. In such aspect, a graphical user interface may be provided for allowing a user to enter the user- specified criteria. Such criteria may involve any of the parameters, peripherals, ports, etc. set forth hereinabove. The application associated with the graphical user interface further generates a code base for the platform-dependent interface 208 which is configured to the specific user requirements. Use of the graphical user interface thus enables the inclusion of future, more complex configuration features, thus expanding flexibility.
The platform-dependent interface 208 is thus both configurable and extendable. Such allows features to be implemented as required by the user. Data streaming and message sending may be provided to allow easy, compatible and efficient communication between the platform-independent application 204 and other resources, i.e. an external bus. The implementation of the features of the platform-independent interface 206 is also flexible. This flexibility allows, for example, a video engine to be used on programmable platform with no video output hardware. This may be useful if the image is to be sent to other programmable platform to be displayed.
In one embodiment within the context of the aforementioned Handel-C programming language, the platform-dependent interface 208 may include a Handel- C library and a header file that contains interfaces to the resources of the programmable platform. The Handel-C library and header may be used to create a source file that forms a top-level for a system. It is this top-level source file that creates the instances of the platform-independent application 204. The header file may further include macros for creating and customizing the interfaces to the platform-independent application 204. It is possible for the interface to the platform-independent application 204 to have different port requirements depending on functionality, thus warranting the use of such technique. The platform-dependent interface 208 may also be at the top-level as it is possible for data streaming ports and messaging ports to be interconnected with the platform-independent application 204. Figure 4 illustrates a method 400 to produce a bit-stream for the programmable platform. As shown, the method 400 includes writing the platform- independent application 204, wherein the platform-independent application 204 is further equipped with the platform-independent interface 206. See act 402.
Thereafter, in act 404, the platform-independent application 204 is compiled into a predetermined format, i.e. EDIF, etc.
The platform-dependent interface 208 is then configured in act 406 for serving in conjunction with the platform-independent interface 206 in providing the interface between the platform-independent application 204 and programmable platform. Next, in act 408, the platform-dependent interface 208 is compiled into the predetermined format.
It should be noted that acts 402-404 may be separated from acts 406-408 to form two different stages. Figure 5 illustrates the file relationships 500 that may be used to generate the system of the present invention, in accordance with one exemplary embodiment.
With reference again to Figure 1, a solution has thus been provided for a versatile framework that allows the reuse of the platform-independent application 204 on numerous different types of programmable platforms. A general example of use of such solution will now be set forth in the context of Figure 1. As mentioned earlier, FPGA Platform 1 includes a first generation of a product or reference board produced by a company. FPGA Platform 2 may include a second generation of the board produced by the company.
To port the system produced for FPGA Platform 1 to FPGA Platform 2 would normally require a large amount of effort. If, however, the system has been designed so that the application in the systems of Figure 1 constitute a platform- independent application 204 in accordance with the foregoing descriptions, the porting effort is much reduced. To port the platform-independent application 204 all that is required is the presence of the platform-dependent interface 208 for the target hardware.
The platform-dependent interface 208 is not necessarily application-specific and thus only needs to be produced once for each platform. For the platform- independent application 204 to function with a particular platform-dependent interface 208 requires only that the platform-dependent interface 208 supports the requirements for performance and functionality that the platform-independent application 204 requires. The port types may specify the functionality requirements of the platform-independent application 204.
A specific example of an implementation of the present invention will now be set forth in the context of the EPIA (platform-independent application 204), HCP-API (platform-independent interface 206) and PRSP (platform-dependent interface 208) set forth hereinabove. It should be noted that the present example is illustrative in nature, and should not be construed as limiting in any manner.
Table 2 illustrates an exemplary interface for a split phase memory access controller which may be defined by the platform-independent interface 206. As shown in Figure 6, address cycles 600 and data cycles 602 are treated separately. This allows efficient and low delay access to an external memory device. This technique also allows support for memory devices that do not return data within the same clock cycle that the address was issued. In use, the data cycles 602 lock until an address cycle 600 has been processed.
Table 2
macro proc HCPAPISetAddress (UniqueBankHandle, Address, ReadNot rite) ;
UniqueHandle:
This is the name of a port created prior to the use of this routine. Address : This is a value represents the address location to be accessed.
ReadNot rite:
This value represents the direction of the memory transfer operation.
1 = Read, 0 = Write. macro proc HCPAPIMemoryReadfUniqueBankHandle, DataValue); UniqueBankHandle : This is the name of a port created prior to the use of this routine. DataValue:
This is a pointer to a register that will be used to store the data read from the memory port. macro proc HCPAPIMemoryWrite (UniqueBankHandle, DataValue); UniqueBankHandle :
This is the name of a port created prior to the use of this routine. DataValue:
This is a pointer to a register that the data to be written will be taken from.
Table 3 illustrates exemplary code usage that may be utilized by the platform-independent application 204 to utilize the interface ofTable 2.
Table 3
while (1)
{ par { if (AddressValueValid == 1) {
// Use the HCP API routine to send a memory address...
HCPAPISetAddress (BankHandle, AddressValue, MemoryTransferDirection) ; } else delay; } par { if (AddressValueValid &
MemoryTransferDirection) {
// Use the HCP API routine to perform a memory read... HCPAPIReadMemory (BankHandle,
&MemoryReadBuffer) ; } else if (AddressValueValid & ( -MemoryTransferDirection) ) {
// Use the HCP API routine to perform a memory write...
HCPAPIWriteMemory ( BankHandle , SMemoryWriteBuf fer) ; } else delay; }
}
While the platform-dependent interface 208 may be generated manually, it is more efficient if a code wizard is used. Such code generation wizard may be included with the platform-dependent interface 208 as an application included with libraries associated with the platform-dependent interface 208. Table 4 illustrates a usage example.
Table 4
..include "TopLevellnclude.h" #include "prsp.h" tinclude "DemoEPIAl .h"
// Initialise this top-level module. It is possible to have more than one
// top-level module.
HCPAPI_INITIALISE_TOP_LEVEL( TemporaryClockSource )
// Create two instances of the LED flasher module (it is called DemoModulel) .
HCPAPI CREATE MODULE INSTANCES ( DemoModulel, 2 )
// Define the main function for this module... void main()
{ // The instances of the EPIA should be executed in parallel... par {
// Run instance 0 of DemoModulel, connect it to LEDResourceO...
// NOTE: the names of the resources a platform supports will be provided
// in documention provided with a PRSP.
// Set the flashing interval to 10000000...
HCPAPI_EXECUTE_MODULE ( DemoModulel ) ( 0, LEDResourceO, 10000000 ) ;
// Run instance 1 of DemoModulel, connect it to LEDResourcel...
// NOTE: the names of the resources a platform supports will be provided // in documention provided with a PRSP.
// Set the flashing interval to 20000000...
HCPAPI_EXECUTE_MODULE ( DemoModulel ) ( 1, LEDResourcel, 20000000 );
#include "DemoEPIAl .h" ..include "EPIAInclude .h"
// Initialise the EPIA module, you can put more than one EPIA in a source file or library if required...
HCPAPI INITIALISE MODULE ( DemoModulel )
// Declare a function that is used by an EPIA module. This allow the mechanism to keep track
// of multiple instances of the module and create multiple copies of functions used by an EPIA... HCPAPI_DECLARE_FUNCTION( DemoModulel, DemoFunctionl, unsigned int 1 ) ( unsigned int 1 Parameter ) ;
// Define the entry point for the EPIA... HCPAPI_ENTRY_POINT ( DemoModulel )( InstancelD, AnLEDResource, FlashDelay )
{
// Declare a couple of variables (registers) for the EPIA functionality... static unsigned int 1 LEDStatus = 0; static unsigned int 32 Timer = 0;
while (1) { if( Timer == FlashDelay )
{ par
{ // Calculate the new LED status using
LEDStatus = HCPAPI_EXECUTE_FUNCTION ( DemoFunctionl, InstancelD ) ( LEDStatus ) ;
// Use the LE resour.ce worker macro to updata the LED status...
HCPAPISetLEDResourceStatus ( AnLEDResource, LEDStatus ) ;
// Reset the timer... Timer = 0;
} else Timer++; }
// Define a function that is used by the EPIA, see declaration above ...
HCPAPI_DEFINE_FUNCTION( DemoModulel, DemoFunctionl, unsigned int 1 ) ( unsigned int 1 Parameter )
{
// This function inverts the input and returns it... return ( -Parameter ) ;
1
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

CLAIMSWhat is claimed is:
1. A system for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms, the system comprising: (a) a platform-independent application capable of being integrated with any one of a plurality of distinct types of programmable platform; (b) a platform-independent interface capable of interfacing, at least in part, the platform-independent application with any one of the distinct types of programmable platforms; and (c) a platform-dependent interface situated on a predetermined programmable platform and capable of serving in conjunction with the platform- independent interface in interfacing the platform-independent application with the predetermined programmable platform.
2. A system as recited in claim 1, wherein the platform-dependent interface is specifically written to interface with the predetermined programmable platform.
3. A system as recited in claim 2, wherein the platform-dependent interface includes a library of platform-dependent resource interfaces which are wrapped with a standard interface capable of being accessed by the platform-independent interface.
4. A system as recited in claim 1, wherein the platform-independent application is specifically written to interface with the platform-independent interface.
5. A system as recited in claim 1 , wherein the interface between the platform- independent application and the programmable platform is capable of being customized.
6. A system as recited in claim 5, wherein the interface is customized by accommodating the specific port requirements of the platform-independent application.
7. A system as recited in claim 5, wherein the interface is customized by including and excluding peripherals based on the requirements of the platform- independent application.
8. A system as recited in claim 5, wherein the interface is customized by dedicating memory resources required by the platform-independent application.
9. A system as recited in claim 5, wherein the interface is capable of being customized in accordance with user-specified criteria.
10. A system as recited in claim 9, wherein a graphical user interface is provided for allowing a user to enter the user-specified criteria.
11. A system as recited in claim 1 , wherein a plurality of the applications are included each with a unique platform-independent application utilizing a single platform-independent interface including a plurality of plugs.
12. A system as recited in claim 11 , wherein the platform-dependent interface of the programmable platform includes a plurality of sockets allocated to the plugs.
13. A system as recited in claim 11, wherein the platform-dependent interface of the programmable platform is capable of reserving resources for each of the applications.
14. A system as recited in claim 1, wherein the programmable platform includes a field programmable gate array (FPGA).
15. A system as recited in claim 1 , wherein the platform-independent interface is written in a C-based variant programming language.
16. A system comprising:
(a) a plurality of unique platform-independent applications;
(b) a platform-independent interface capable of interfacing, at least in part, the platform-independent applications with any one of a plurality of distinct types of programmable platforms; and
(c) a platform-dependent interface situated on a predetermined programmable platform and capable of serving in conjunction with the platform- independent interface in interfacing the platform-independent applications and the predetermined programmable platform.
17. A method for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms, the method comprising: (a) providing a platform-independent application capable of being integrated with any one of a plurality of distinct types of programmable platform; (b) interfacing the platform-independent application with any one of the distinct types of programmable platforms utilizing a platform-independent interface at least in part; and (c) interfacing the platform-independent application with a predetermined programmable platform utilizing a platform-dependent interface situated on the predetermined programmable platform at least in part.
18. A computer program product for allowing an application to be integrated with any one of a plurality of distinct types of programmable platforms, the computer program product comprising: (a) a platform-independent application capable of being integrated with any one of a plurality of distinct types of programmable platform; (b) platform-independent computer code for interfacing, at least in part, the platform-independent application with any one of the distinct types of programmable platforms; and (c) platform-dependent interface computer code situated on a predetermined programmable platform for interfacing, at least in part, the platform- independent application with the predetermined programmable platform.
19. A system comprising: (a) a platform-independent application capable of being integrated with any one of a plurality of distinct types of programmable platform; (b) a platform-independent interface capable of interfacing, at least in part, the platform-independent application with any one of the distinct types of programmable platforms; and (c) a platform-dependent interface situated on a predetermined programmable platform and capable of serving in conjunction with the platform- independent interface in interfacing the platform-independent application with the predetermined programmable platform; (d) wherein the interface between the platform-independent application and the predetermined programmable platform is capable of being customized in accordance with user-specified criteria utilizing a graphical user interface for allowing a user to enter the user-specified criteria.
PCT/GB2002/000390 2001-01-29 2002-01-29 Application program interface for programmable architecture cores WO2002061577A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002226583A AU2002226583A1 (en) 2001-01-29 2002-01-29 Application program interface for programmable architecture cores

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/772,710 US20030033588A1 (en) 2001-01-29 2001-01-29 System, method and article of manufacture for using a library map to create and maintain IP cores effectively
US09/772,710 2001-01-30
US09/872,167 US20040015502A1 (en) 2001-01-29 2001-05-31 Application program interface for programmable architecture cores
US09/872,167 2001-05-31

Publications (2)

Publication Number Publication Date
WO2002061577A2 true WO2002061577A2 (en) 2002-08-08
WO2002061577A3 WO2002061577A3 (en) 2003-11-27

Family

ID=27118641

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2002/000390 WO2002061577A2 (en) 2001-01-29 2002-01-29 Application program interface for programmable architecture cores

Country Status (2)

Country Link
AU (1) AU2002226583A1 (en)
WO (1) WO2002061577A2 (en)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5583983A (en) * 1994-11-17 1996-12-10 Objectware, Inc. Multi-platform object-oriented software development and deployment system
US5748980A (en) * 1994-05-27 1998-05-05 Microsoft Corporation System for configuring a computer system
EP0860773A1 (en) * 1997-02-21 1998-08-26 Alcatel Method of generating a software application
US6026238A (en) * 1997-08-18 2000-02-15 Microsoft Corporatrion Interface conversion modules based upon generalized templates for multiple platform computer systems
EP0994416A2 (en) * 1998-10-16 2000-04-19 Sun Microsystems, Inc. Techniques for implementing pluggable virtual machines
US6063128A (en) * 1996-03-06 2000-05-16 Bentley Systems, Incorporated Object-oriented computerized modeling system
US6131166A (en) * 1998-03-13 2000-10-10 Sun Microsystems, Inc. System and method for cross-platform application level power management
US6154836A (en) * 1998-08-17 2000-11-28 International Business Machines Corporation Method and system for configuring plug and play devices for a computer operating system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6772419B1 (en) * 1997-09-12 2004-08-03 Hitachi, Ltd. Multi OS configuration system having an interrupt process program executes independently of operation of the multi OS

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748980A (en) * 1994-05-27 1998-05-05 Microsoft Corporation System for configuring a computer system
US5583983A (en) * 1994-11-17 1996-12-10 Objectware, Inc. Multi-platform object-oriented software development and deployment system
US6063128A (en) * 1996-03-06 2000-05-16 Bentley Systems, Incorporated Object-oriented computerized modeling system
EP0860773A1 (en) * 1997-02-21 1998-08-26 Alcatel Method of generating a software application
US6026238A (en) * 1997-08-18 2000-02-15 Microsoft Corporatrion Interface conversion modules based upon generalized templates for multiple platform computer systems
US6131166A (en) * 1998-03-13 2000-10-10 Sun Microsystems, Inc. System and method for cross-platform application level power management
US6154836A (en) * 1998-08-17 2000-11-28 International Business Machines Corporation Method and system for configuring plug and play devices for a computer operating system
EP0994416A2 (en) * 1998-10-16 2000-04-19 Sun Microsystems, Inc. Techniques for implementing pluggable virtual machines

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN & JP 011 149385 A (HITACHI LTD), 2 June 1999 (1999-06-02) & US 2001/016879 A1 23 August 2001 (2001-08-23) *

Also Published As

Publication number Publication date
AU2002226583A1 (en) 2002-08-12
WO2002061577A3 (en) 2003-11-27

Similar Documents

Publication Publication Date Title
US20040015502A1 (en) Application program interface for programmable architecture cores
Vipin et al. FPGA dynamic and partial reconfiguration: A survey of architectures, methods, and applications
US7902866B1 (en) Wires on demand: run-time communication synthesis for reconfigurable computing
US8412918B1 (en) Booting mechanism for FPGA-based embedded system
Gokhale et al. Reconfigurable computing: Accelerating computation with field-programmable gate arrays
Coussy et al. GAUT: A High-Level Synthesis Tool for DSP Applications: From C Algorithm to RTL Architecture
US7418681B2 (en) Simulation system, simulation method and simulation program for verifying logic behavior of a semiconductor integrated circuit
US20070283311A1 (en) Method and system for dynamic reconfiguration of field programmable gate arrays
US9075624B2 (en) Compilation of system designs
WO2002061576A2 (en) System, method and article of manufacture for interface constructs in a programming language capable of programming hardware architectures
Sau et al. Reconfigurable coprocessors synthesis in the MPEG-RVC domain
US7062744B2 (en) Emulation solution for programmable instruction DSP
Gonzalez et al. Self-reconfigurable embedded systems on low-cost FPGAs
Quadri MARTE based model driven design methodology for targeting dynamically reconfigurable FPGA based SoCs
WO2002061577A2 (en) Application program interface for programmable architecture cores
Domer et al. Reuse and protection of intellectual property in the SpecC system
Patterson et al. Slotless module-based reconfiguration of embedded FPGAs
Tatas et al. A survey of existing fine-grain reconfigurable architectures and CAD tools
Russo Adaptation of High Performance and High Capacity Reconfigurable Systems to OpenCL Programming Environments
US20230052788A1 (en) Software-Defined Synthesizable Testbench
Ramanathan et al. Interfacing hardware and software using C++ class libraries
Wei A FPGA-based Soft Multiprocessor System for JPEG Compression
Bellows et al. Designing run-time reconfigurable systems with JHDL
Neuendorffer FPGA platforms for embedded systems
Spivey et al. A component architecture for FPGA-based, DSP system design

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP