US20030163298A1 - Reconfigurable measurement system utilizing a programmable hardware element and fixed hardware resources - Google Patents

Abstract

A system and method for configuring a device to perform a function, where the device includes a programmable hardware element and one or more fixed hardware resources. A program is stored which represents the function. A hardware configuration program is generated based on the program, specifying a configuration for the programmable hardware element that implements the function, and usage of the fixed hardware resources by the programmable hardware element in performing the function. A deployment program deploys the hardware configuration program onto the programmable hardware element, where, after deployment, the device is operable to perform the function, where the programmable hardware element directly performs a first portion of the function, and the programmable hardware element invokes the fixed hardware resources to perform a second portion of the function. An optional measurement module couples to the device and performs signal conditioning and/or conversion logic on an acquired signal for the device.

Description

FIELD OF THE INVENTION
• The present invention relates to measurement and control, and particularly to measurement devices with programmable logic for performing interface, measurement, and control functions.[0001]
DESCRIPTION OF THE RELATED ART
• Scientists and engineers often use measurement or instrumentation systems to perform a variety of functions, including laboratory research, process monitoring and control, data logging, analytical chemistry, test and analysis of physical phenomena, and control of mechanical or electrical machinery, to name a few examples. An instrumentation system typically includes transducers and other detecting means for providing “field” electrical signals representing a process, physical phenomena, equipment being monitored or measured, etc. Exemplary transducers include thermocouples, strain gauges, pressure sensors, microphones and cameras. As one example, detectors and/or sensors are used to sense the on/off state of power circuits, proximity switches, pushbutton switches, thermostats, relays or even the presence of positive or negative digital logic-level signals. The instrumentation system typically also includes interface hardware for receiving the measured field signals and providing them to a processing system, such as a personal computer. The processing system typically performs data analysis and presentation for appropriately analyzing and displaying the measured data.[0002]
• Often, the field signals may comprise high common-mode voltages, ground loops, or voltage spikes that often occur in industrial or research environments which could damage the computer system. In that case, the instrumentation system typically includes signal conditioning circuitry, such as isolation circuitry, e.g., opto-couplers, for eliminating ground-loop problems and isolating the computer from potentially damaging voltages. Signal conditioning modules are typically provided for conditioning the raw field voltage signals by amplifying, isolating, filtering or otherwise converting the signals to appropriate signals for the computer system. In one embodiment, the analog signals are then provided to a plug-in data acquisition (DAQ) input/output (I/O) board, which is plugged into one of the I/O slots of a computer system. The DAQ board may include analog-to-digital (A/D) converters for converting the analog signals to corresponding digital signals. The computer system may have an I/O bus and connectors or slots for receiving I/O boards. Of course, other types of computer systems and I/O buses may be used to implement a processing system.[0003]
• In general, measurement and control cards or devices have a particular set of resources on-board for use in measurement or control tasks, such as counters, analog to digital converters (ADC), I/O ports, filters, etc. This is especially true with respect to mass produced cards or devices, such as National Instruments MIO (Multifunction I/O) DAQ (Data Acquisition) series. These devices typically include a set of resources which meets the needs of a large majority of users. For example, a typical card may include a 16 channel multiplexed AI (analog input) in front of an A/D (analog to digital) converter, 2 analog outputs (AO), 8 digital lines, −10 timing/triggering lines, 2 general purpose counters, plus one or more timing/triggering engines.[0004]
• However, in many cases the set of provided resources is a superset of those required for a particular application. In other words, for a given application there are likely to be components on the card or device which are not used. Conversely, for some applications the resources provided on the card or device may not be quite what is needed, and so either additional components may be added to the device, or a different product or device may be selected for the task. For example, a particular sensor, such as a quadrature encoder, may require extra digital logic between the sensor and a supplied counter to count not only the samples or hits of a signal, but also the direction of the signal at each hit, i.e., up or down, in order to correctly receive the signals from the sensor. In other words, there are many cases where the standard card or device provides more or less resources than required for an application or task.[0005]
• In addition, in many instances it would be desirable for the user to be able to program and reprogram a measurement device to perform different functions. This[0006]
SUMMARY
• Various embodiments of a system and method for measurement (including data acquisition) and/or control (including automation) operations are described. The system includes a measurement device, which may be referred to as a reconfigurable I/O (RIO) device, RIO unit, or a RIO. The RIO device may include at least one programmable hardware element which is configurable to perform a measurement and/or control function. The RIO device may also include one or more fixed hardware resources coupled to the programmable hardware element.[0007]
• A typical RIO measurement system includes a computer system coupled to a RIO measurement device or unit. In one embodiment, the RIO device is a standalone device, and the RIO device may be coupled to a computer system or network solely for programming purposes. A computer system may also be coupled to the RIO device for programming and supervisory control, logging, or other types of co-processing. The RIO device may have various form factors such as a computer board or card, a PXI card, a VXI card, a standalone device, a smart sensor, a smart camera, etc.[0008]
• As mentioned above, the RIO unit includes a programmable hardware element, such as a field programmable gate array (FPGA). The RIO device may also include one or more fixed hardware resources, such as counters, timers, A/D converters, signal conditioning logic, computer interface logic, etc. The RIO device may also include connectors for communicating with external components or systems, such as the computer system.[0009]
• As used herein, the term “measurement device” is intended to include any of various types of devices that are operable to acquire and/or store data, and which may optionally be further operable to analyze or process the acquired or stored data. Examples of measurement devices include various types of instruments, such as oscilloscopes, multimeters, etc., as well as data acquisition devices or cards, devices external to a computer that operate similarly to data acquisition cards, smart sensors, one or more measurement modules in a chassis, and other similar types of devices.[0010]
• The computer system may couple to the RIO measurement device through a serial bus, such as a USB (Universal Serial Bus) or IEEE 1394; a parallel bus such as PCI, PXI, VME, or VXI; or any other medium including a sensor bus; a network medium, such as Ethernet, a Control Area Network (CAN) or the Internet; wireless media such as IEEE 802.11 (Wireless Ethernet), Bluetooth, etc.; other serial or parallel buses, or any other transmission means. In one embodiment, the RIO measurement device may optionally also include one or more measurement modules, as well as one or more sensors or actuators which may be operable to couple to the modules and/or the RIO device and provide signals to the RIO measurement device for processing.[0011]
• The host computer may comprise a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard. The host computer may operate with the RIO measurement device to analyze or measure data from the sensor/measurement device or to control the sensor and/or device. Alternatively, the computer may be used only to configure or program the RIO measurement device, i.e., the RIO unit, as described below.[0012]
• In one embodiment, the computer system may store an application development environment used for creating programs. The computer system may also store a program implementing one or more measurement and/or control functions, i.e., a measurement program. The measurement program may be a graphical program implementing the one or more measurement functions. The measurement functions may perform one or more of signal acquisition, signal conditioning and conversion, control, signal analysis, signal display, and logging among others.[0013]
• The computer system may be operable to execute the measurement program to perform the one or more measurement and/or control functions in conjunction with operation of the RIO and optionally one or more measurement modules and/or sensors. The measurement and control functions may include analysis of data or signals received from the RIO unit, control of RIO unit and/or measurement module operations, and user interface functions, among others.[0014]
• In one embodiment, the computer system may be operable to deploy a portion or all of the measurement program (as a hardware configuration program) onto the programmable hardware element of the RIO unit. In one embodiment, the computer system may store and execute a deployment program for deploying a hardware configuration program onto a RIO unit. The RIO may then be operable to execute the hardware configuration program (corresponding to the measurement program) to perform the one or more measurement and/or control functions, possibly in conjunction with an optional measurement module and/or the computer system. During execution of the hardware configuration program by the FPGA, the FPGA may invoke or use one or more of the fixed hardware resources. The configured RIO may thus be operable to perform measurement and/or control operations. In one embodiment, the RIO may process and/or analyze the received signals, and may optionally send the results of the processing or analysis to the computer system for storage and/or further analysis. In another embodiment, the RIO may generate a control signal in response to the analysis, such as to an automation system.[0015]
• In one embodiment, a RIO system may be configured to perform a function defined in a program or application, preferably a graphical program. In this embodiment, the application may first be designed e.g., in a graphical development environment, such as LabVIEW, LabVIEW FPGA, Simulink, etc., and then may be debugged in a simulation environment, described below. In the preferred embodiment, the graphical program may be developed in the G graphical programming language in the form of a graphical block diagram.[0016]
• Then, the program (e.g., the graphical program) may be compiled to an FPGA hardware configuration program. In one embodiment, because of long compile times, the compiling may be performed on a client computer which is coupled to the host computer system[0017]102 (functioning as a server) to avoid having to share the CPU resources of the host computer system. Compiling the program preferably produces an FPGA hardware configuration program which is operable to be deployed on the targeted FPGA on the RIO device.
• Then, the hardware configuration program may be downloaded or deployed onto the FPGA. In one embodiment, downloading the hardware configuration program onto the FPGA may also include storing the hardware configuration program in a non-volatile memory coupled to the FPGA. The hardware configuration program may include the capability of invoking the various fixed hardware resources on the RIO device.[0018]
• Finally, the deployed hardware configuration program may be executed on the FPGA to perform the functionality of the application. It is noted that in various embodiments, the FPGA may perform the functionality of the application in conjunction with the one or more fixed hardware resources comprised on the RIO with the FPGA. In other words, during execution of the hardware configuration program on the FPGA, the hardware configuration program may direct the FPGA to invoke various of the fixed hardware resources to perform particular functions. The RIO device may also operate with one or more of the host computer system, and/or one or more sensors and/or one or more measurement modules.[0019]
• In one embodiment, the RIO measurement system may be configured to perform a measurement function. Performing the measurement function may include first acquiring a signal such as from a sensor or actuator, or from an external system. Then one or more of signal conditioning and signal conversion may be performed on the acquired signal, thereby generating data, e.g., results data. The signal conditioning and/or signal conversion may be performed by the RIO device, e.g., by the RIO FPGA, by the fixed hardware resources on the RIO device, or by a separate measurement module. The result data may include one or more of the original signal, the conditioned and/or converted signal, and information derived from or generated in response to the signal.[0020]
• The programmable hardware element and/or the fixed hardware resource on the RIO may then perform the measurement function, e.g., on the signal or data. In other words, the RIO may perform a measurement function which was programmed into the programmable hardware element, such as filtering, pattern recognition, or other analysis. For another example, the RIO may generate control signals in response to an analysis of the data, such as to control one or more plant operations.[0021]
• In another embodiment, in which the computer system comprises measurement software for performing a measurement function, the RIO unit may provide the data to the computer system. Then, the computer system may perform additional measurement functions, e.g., on the signal, where the measurement functions may include, measurement (including data acquisition) and/or control functions, as described above.[0022]
• In one embodiment, a variety of digital interfaces, such as SPIbus and interfaces not known a priori, may be adapted to the resources of the RIO device.[0023]
• Creation of the Graphical Program[0024]
• In one embodiment, the host computer or server may store and execute a program (development program) which receives user input indicating a RIO configuration and/or task specification and generates a program, such as a graphical program, implementing the configuration and/or task. In a preferred embodiment, the development program may be a configuration wizard which is operable to lead the user through the configuration process, and to generate the graphical program, i.e., the measurement program. The wizard may utilize any of various graphical user interface (GUI) techniques to create the user-defined configuration, including drag and drop capabilities, menus, data fields, buttons, etc. For example, the wizard may provide (through the wizard GUI) a list or description of available resources such as I/O primitives, filters, counters, etc., and/or default or current values or suggested ranges for operating parameters for these resources. The user may select various of the resources and set their respective parameter values as desired.[0025]
• In one embodiment, the wizard may present the available resources graphically (i.e., via icons), and may also graphically display the current configuration per the user's input. The user may drag and drop resources or components from the available resources to the current configuration diagram, and may remove resources from the configuration in the same manner. In one embodiment, the user may select, either graphically or through other means, one or more of the components in the configuration, and set timing, triggering, and/or synchronization parameters for the selected components. In another embodiment, the user may select two or more configured components and group them together, optionally giving the group a name and/or an associated icon. In this way, configured components may be organized and manipulated in a hierarchical manner. The wizard may further allow the user to add control structures such as loops and conditionals to the configuration, thereby providing higher level control functionality.[0026]
• In one embodiment, the user may engage the configuration wizard on a server via a client computer system over a network, such as the Internet, i.e., using a client/server model. Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request. Although the client/server idea can be used by programs within a single computer, it is a more important idea in a network. In a network, the client/server model provides a convenient way to interconnect programs that are distributed efficiently across different locations.[0027]
• In the usual client/server model, one server, sometimes called a daemon, is activated and awaits client requests. Typically, multiple client programs share the services of a common server program. Both client programs and server programs are often part of a larger program or application. In one embodiment, the client program may be a Web browser that requests services (the sending of Web pages or files) from a Web server (which technically is called a Hypertext Transport Protocol or HTTP server) in another computer somewhere on the Internet. Similarly, a computer with TCP/IP installed allows users to make client requests for files from File Transfer Protocol (FTP) servers in other computers on the Internet. The client program may provide various client functionality, such as browsing, requests for specific services (e.g., compilation), determining current configurations available, etc.[0028]
• For example, in one embodiment, the client computer system may execute a client program (e.g., a browser) to connect to the host computer or server. The host computer or server may then display the wizard GUI on the client computer system display, thereby providing a mechanism for communication between the user and the wizard.[0029]
• In response to the received user input, the wizard may generate the graphical program corresponding to the configuration, e.g., a LabVIEW diagram. The generated graphical program may itself be modified or edited by the user. Once the user is satisfied with the graphical program, conversion software may convert the graphical program into a hardware configuration program, as described below.[0030]
• In addition, in one embodiment, the wizard may directly create a hardware configuration program through a variety of user input. The user input may include, but is not limited to, conventional hardware synthesis, selection from a library of pre-generated files, or direct implementation in an FPGA, or combinations thereof, etc.[0031]
• Conversion of the Graphical Program to a Hardware Configuration Program[0032]
• In one embodiment, the method may include the conversion of a graphical program, such as a graphical image processing or machine vision program, into hardware and/or software descriptions. The graphical program may comprise graphical code, such as interconnected function nodes or icons, and may use graphical data flow, graphical control flow and/or graphical execution flow constructs.[0033]
• In one embodiment, programs of the present invention may create a VDiagram tree from the data structures of the graphical program. The VDiagram tree is an abstract hardware graph which represents at least a portion of the graphical program. The graph may be organized in a way that facilitates the generation of specific types of descriptions by back end programs of the present invention.[0034]
• A hardware description may be generated from the abstract hardware graph by a back end program, and may be in any of various hardware description languages such as VHDL, EDIF, and Verilog. In the preferred embodiment, the hardware description comprises one or more VHDL files. A hardware netlist (preferably an FPGA-specific netlist) may be generated from the hardware description using various synthesis tools. As noted above, the term “netlist” comprises various intermediate hardware-specific description formats comprising information regarding the particular hardware elements required to implement a hardware design and the relationship among those elements. The hardware netlist is used to create or configure one or more functional hardware devices or hardware elements which are configured to execute the portion of the graphical program that is represented by the abstract hardware graph. As used herein, the term “hardware configuration program” refers to the program, bitfile, etc., which is loaded onto the programmable hardware element.[0035]
• In one embodiment, the back end programs that convert the VDiagram tree to a hardware description may implement the functionality of components in the VDiagram component lists using constructs of their respective description languages. For example, a VHDL back end may create VHDL code to implement a component that performs a particular mathematical algorithm such as an exponential calculation. However, in one embodiment, such functional components are simply referenced as library components.[0036]
• Thus, one embodiment of the present invention may comprise pre-compiled function blocks which implement these library components for particular hardware devices such as FPGAs. The various FPGA netlist synthesis tools used to generate an FPGA netlist from the hardware description may incorporate the pre-compiled function blocks into the FPGA netlist, and may also utilize hardware target-specific information in creating the netlist. For example, the exact form that the FPGA netlist takes may depend on the particular type of FPGA that will use the netlist, since FPGAs differ in their available resources.[0037]
• An FPGA bit stream (hardware configuration program) may be generated from the FPGA netlist using readily available synthesis tools and uploaded to an FPGA. The FPGA may be comprised in a hardware device such as an interface board. After being programmed with the hardware configuration program, the FPGA is able to execute the portion of the graphical program that is exported to the hardware description. If the entire graphical program is not exported to the hardware description, then a portion of the program may execute on either a CPU implemented in the FPGA or on the general purpose CPU of the computer system. In either case, this portion of the graphical program may executed natively on the CPU, the graphical program may be converted to a text-based programming language (e.g., C) and then compiled for the CPU, or the graphical program may be compiled directly to machine language for execution on the CPU.[0038]
• Where a portion of the graphical program is implemented on a CPU, the CPU may execute a real time operating system (e.g., LabVIEW RT), e.g., for performing supervisory control. In one embodiment, where the CPU couples to a display device (e.g., where the portion of the graphical program is implemented on the host CPU implemented in the host computer), then the portion that executes on the host may comprise the display portion of the program.[0039]
• Simulation Environment[0040]
• In one embodiment, a simulation environment, also referred to as a “Ghost” environment, may be used to test, analyze, and/or debug a hardware configuration program targeting the programmable hardware element (and one or more fixed hardware resources) comprised in a RIO system. In general, compile times for generating a hardware configuration program for an FPGA may take a lengthy time, e.g., many hours. In order to allow faster design and debugging, the “Ghost” simulation environment allows realistic simulation of a hardware configuration program in software, while still invoking the fixed hardware resources on the RIO device.[0041]
• In one embodiment, as described above, the RIO system includes a programmable hardware element and one or more fixed hardware resources. The hardware configuration program may be designed to execute on the programmable hardware element and during execution the programmable hardware element may invoke various ones of the fixed hardware resources. During simulation, the programmable hardware element may be configured with a test feed-through configuration that may be optionally precompiled for the hardware target, and which may provide low level access to the fixed hardware resources on the reconfigurable board. In other words, when deployed on the programmable hardware element, the test feed-through configuration may provide for communication between the program executing on the host computer and the fixed hardware resources on the RIO device. This allows the host computer system to simulate execution of the hardware configuration program on the FPGA in software, while allowing the simulation software to invoke the actual fixed hardware resources on the RIO device, just as the FPGA would do.[0042]
• In one embodiment, a set of I/O primitives, such as a set of standard LabVIEW I/O primitives, for the fixed hardware resources may be used to mediate data flow between the simulation program and the fixed hardware resources. When targeting the hardware (i.e., the programmable hardware element) these I/O primitives (possibly including standard LabVIEW primitives) may be converted into a hardware representation, such as an FPGA program file, as described above, and may take considerable time to compile. When targeting the test or simulation environment, i.e., the Ghost environment, the standard LabVIEW primitives may remain in software and run on the host computer, and thus compile very quickly. The I/O primitives may also remain in software, but redirect their functionality to the precompiled test feed-through configuration in hardware. Thus the I/O primitives executing on the host computer system can access the fixed hardware resources on the RIO device.[0043]
• For example, consider a typical PID loop using an analog input and an analog output. This is commonly constructed as a while loop containing an I/O primitive for reading the analog input, the PID algorithm itself, and an I/O primitive for writing the analog output. When targeting hardware, all of these constructs may be converted to a hardware configuration program and downloaded to the FPGA on the RIO device. When targeting the Ghost environment, the precompiled test feed-through configuration may be quickly downloaded to the FPGA on the RIO device, and the while loop and PID algorithm may remain in software. As the diagram or program executes on the host, whenever an I/O primitive is called it communicates with the FPGA on the RIO device to interface to the actual hardware I/O. The test feedthrough configuration on the FPGA allows the I/O primitive to communicate through the FPGA to the fixed hardware resources.[0044]
• A key advantage to this solution is that software based debugging methodologies may be used for debugging the diagram (program) while retaining connectivity to real world signals that the hardware targeted application would provide. This functionality may be provided without any changes to the user's application and may be completely transparent. Therefore, the user may debug most functional issues related to the application or system, and so may concentrate primarily on timing issues after performing a full compilation.[0045]
• In one embodiment, the test feed-through configuration may be extended to utilize a micro-controller implemented or configured in the FPGA. In other words, a processor (e.g., a micro-controller) may be implemented on the FPGA, then the program may be compiled for the FPGA-implemented processor. The program may then be executed on the FPGA-implemented processor (while maintaining the original I/O capabilities of the Ghost environment). Thus any timing issues arising from sharing the processor of the host computer system may be avoided.[0046]
• As indicated above, the programmable hardware element may be configured or programmed with the test feed-through configuration, which provides connectivity between the fixed hardware resources and the program executing on the computer system.[0047]
• In summary, a program may be stored on a memory of the computer system. The program preferably specifies a function, e.g., a measurement function, where the program is operable to be converted into a hardware configuration program and deployed on the programmable hardware element to perform the function. In other words, as in the systems described above, the program is meant to be deployed on the programmable hardware element, after which the programmable hardware element may be operable to perform the function in conjunction with one or more fixed hardware resources, as described above. As mentioned above, deploying the program may comprise converting the program into a hardware configuration program. It is again noted that the hardware configuration program specifies usage of the one or more fixed hardware resources by the programmable hardware element (in performing the function).[0048]
• In order to test the program without waiting for a lengthy compilation of the program into a hardware configuration program, the simulation environment is provided. The programmable hardware element may be configured with a test feed-through[0049]
• In one embodiment, the RIO unit may comprise or be coupled to at least one measurement module which may be operable to provide connectivity to a sensor or actuator, and may be further operable to provide signal conditioning and/or signal conversion on the signal before sending the signal to the RIO unit. The RIO unit may be operable to receive interface protocol information from the measurement module specifying how to operate or interface with the measurement module. The RIO unit may then communicate the interface protocol information to the computer system. Alternatively, the measurement module may communicate the interface protocol information directly to the computer system. Based on the interface protocol information, the computer system may program or configure the programmable hardware element on the RIO unit to implement the interface as specified by the measurement module. In other words, the measurement module may tell the RIO how to “talk” with it, and the RIO may then tell the computer system how to program the RIO to communicate with the measurement module accordingly, or the measurement module may tell the computer system directly how to program the RIO. The computer system may then program the RIO unit (i.e., the programmable hardware element on the RIO unit), thereby implementing the interface specified in the interface protocol information communicated by the measurement module. This process may be referred to as initialization of the RIO/ measurement module. The configured RIO and the measurement module may then be operable to perform measurement and control operations in conjunction with the sensor and/or the computer system.[0050]
• In one embodiment, the measurement module may be in the form of a measurement cartridge and the RIO unit in the form of a RIO cartridge chassis or carrier which is operable to receive one or more of the measurement cartridges. Thus, the RIO may host a plurality of measurement cartridges, each of which may provide measurement and/or control functionality for a measurement or control operation or task. The RIO may be operable to communicate with each measurement cartridge (i.e., module) and be programmed or configured (e.g., by the computer system) to implement the respective interface of each measurement cartridge. In this manner a suite of sensors may be fielded, each of which feeds signals to a respective measurement cartridge which in turn communicates through a respective interface (protocol) with the RIO cartridge carrier. The RIO cartridge carrier (i.e., the RIO) may in turn couple to a computer system. Thus, the RIO device may support a heterogeneous plurality of interfaces without having to include a heterogeneous set of interface hardware components.[0051]
• Other Example Embodiments[0052]
• In one embodiment, the RIO unit may be designed to couple to a host computer system, wherein the host computer system may be used for programming or configuring the RIO unit. The host computer system may also be used to operate in conjunction with the RIO unit as a co-processor during RIO execution. In another embodiment, the host computer system may be used solely for programming or configuring the RIO unit. After configuration, the RIO unit may be disconnected from the host computer system and operated as a stand-alone device. As a stand-alone device, the RIO unit may couple to various sensors, actuators, measurement modules, etc., to perform a desired measurement function. A stand-alone RIO device may also be coupled to a network to communicate with other devices, including other RIO devices. In one embodiment, a RIO device is reconfigurable to operate either as a device controlled by a computer system and as a stand-alone device with network connectivity.[0053]
• In one embodiment, the RIO unit may comprise a PXI card, i.e., may be implemented on a PXI card. The PXI card may be operable to plug into a PXI chassis or a suitably equipped computer system, and may implement the RIO functionality described above. It should be noted that other card based implementations besides the PXI card implementation are also contemplated, for example, PCI, VXI, Infiniband, or other protocols or platforms may be used to implement a carrier, the PXI card embodiment being but one example.[0054]
• In one embodiment, the RIO unit may comprise or be coupled to a Personal Digital Assistant (PDA). Thus the PDA may comprise the RIO unit and may include one or more slots for measurement modules. Alternatively, the RIO may be in the form of an optionally detachable RIO module, which may in turn couple to a measurement module. The measurement module may in turn be operable to couple to a sensor or actuator, as described above. In one embodiment, the PDA may be operable to program the RIO (i.e., the RIO's programmable hardware element) with the interface protocol information provided by the measurement module, as described in detail above, and may be further operable to provide functionality related to a measurement and/or control task or operation. In another embodiment, the PDA may be used as an interface to another computer system. For example, a suitably equipped PDA may provide wireless communication for the RIO/measurement module.[0055]
• In one embodiment, RIO based systems may be extended with external I/O expansion, i.e., with additional I/O connections for coupling to a plurality of measurement modules. A RIO cartridge or card may provide connectors for analog I/O and/or digital I/O. The digital I/O may be coupled to an I/O expansion device, such as a breakout backplane, which may provide connectivity for a plurality of measurement module cards or cartridges, and may thereby be operable to facilitate external, synchronized, and conditioned I/O for the measurement system.[0056]
• In another embodiment, the RIO card or device may couple to an addressable backplane, for example, through an SPI with slot select capabilities, and which may provide a plurality of individually addressable slots for a plurality of measurement modules or cartridges, which may each be individually targeted for communication by the carrier. Additionally, the addressable backplane may be expandable, i.e., additional addressable backplanes may be coupled to the addressable backplane to provide additional slots for additional measurement modules.[0057]
• In yet another embodiment, the RIO card or device may couple to a “DAQ in the cable”, where a measurement module may be comprised in a cable connector. In other words, the features of a measurement module, as described above, may be included in one or both connectors of a cable which may be coupled to the RIO device or to a sensor/actuator, as desired.[0058]
• Configuration Wizard[0059]
• In one embodiment of the present invention, a configuration tool may be used to configure the RIO system. For example, the configuration tool may comprise one or more programs implementing a configuration wizard. The wizard may be operable to lead a user through the configuration process, receiving user input specifying the user requirements for the system, and generating a hardware configuration program for deployment on the RIO device. In one embodiment, the configuration tool (e.g., the wizard) may also be operable to deploy the hardware configuration program onto the RIO device.[0060]
• In one embodiment, operations for creation and deployment of the hardware configuration program may occur on the customer or client computer system. The client computer system may be coupled to the RIO device and may store and execute a configuration wizard program to receive user input specifying or characterizing the system configuration. The wizard may then generate the hardware configuration program and deploy the hardware configuration program onto the RIO device (i.e., the[0061]FPGA106 in the RIO device). The advantage to this approach is that the customer does not need to be connected to a vendor server. However, if software updates are required, for example, for backend tools or third party tools used in the process, it may be necessary to request the customer to perform the updates.
• In another embodiment, a vendor may operate or host the configuration wizard on a server computer system, such as an e-commerce server, which may be accessible to users (i.e., customers) over a network, e.g., the Internet. The client computer system may be coupled to a server computer system over a network, such as the Internet. The configuration wizard program may be stored and executed on the server computer. Software executing on the client computer system (e.g., a browser program) may be used to access the server (i.e., the configuration wizard). The user may thereby engage the configuration wizard remotely to specify a configuration of the RIO system, and to download or deploy the resulting hardware configuration program generated by the configuration wizard onto the RIO device. In one embodiment, the vendor server may provide sales and purchasing services to the customer in addition to system configuration.[0062]
• In one embodiment, the server program (configuration wizard) may present a graphical user interface (GUI) to the user on the[0063]client computer system102 and receive input therefrom specifying user requirements for the system to be configured.
• As described above, the RIO architecture provides a reconfigurable solution for adapting or customizing a measurement product to application requirements. There are several different approaches or support levels for performing the customization, each targeting a different class of users. For example, a basic support level may include providing precompiled hardware configurations from which the user may select a solution. This approach offers the least flexibility, but simplifies the choices that the user may consider. This approach may in many ways be considered a parameterized solution, in that the pre-defined nature of the hardware resources is very structured, with well defined acquisition modes and functionality.[0064]
• In contrast, another embodiment of the invention offers very little pre-defined structure. This embodiment mixes program primitives (e.g., LabVIEW primitives) with is low level I/O, and allows for the construction of timing, triggering, inline processing, and more. These building blocks can be pieced together to create the same functionality as the existing solutions, as well as much more capable operations. These blocks can often be combined in different ways to provide similar solutions, but one may be preferable to the other in terms of extensibility, resource utilization, etc. This approach offers the greatest flexibility, but requires a more sophisticated user.[0065]
• In one embodiment, as mentioned above, a configuration wizard may bridge the gap between flexibility and ease of use. In one embodiment, the wizard may provide a drag and drop interface for creating the user defined RIO configuration. In another embodiment, the wizard may provide a menu and/or button based graphical interface for creating the user defined RIO configuration. In another embodiment, the wizard may provide a list of available resources, e.g., low level interface primitives such as AI, AO, and DIO, as well as a list of higher level functions that can be applied to these low-level primitives, including higher level interface functions such as counters built on top of DIO lines, or inline processing such as linearization or filtering for AI lines.[0066]
• The user may select the resources required by an application, and configure any resources as necessary (for example, setting gain parameters on an analog input resource) using the configuration wizard. In one embodiment, the selections may be hierarchical, and may allow the user to add the higher level interface or inline processing in the same window. The user may then identify the timing and triggering requirements of the application, selecting from the resources identified/created in the previous step.[0067]
• In each of these approaches a description file is preferably generated which uniquely identifies resources and features the user has selected. From this description file, G code (graphical code, i.e., National Instruments G graphical programming language) may be generated. HDL code may then be generated from the G code, and eventually a program binary file, i.e., a hardware configuration program, for the FPGA generated from the HDL code. In these approaches, caching schemes are preferably used so that the number of compilations may be minimized.[0068]
• In one embodiment, specific features (as opposed to complete configurations) may be pre-compiled in such a way that they may be assembled or composed quickly into an appropriate configuration at the customer site. The advantage of this approach is that most of the relative placement and routing has been done up front, and so only a “quick” replacement and rerouting is needed to put the configuration together. In another embodiment of this approach, a set or library of complete configurations may be maintained and made available to the customer for a wide variety of applications. The user may select a best solution (i.e., configuration), then make modifications as needed.[0069]
• Thus, in a preferred embodiment, one or more configuration wizards may generate graphical programs, e.g., LabVIEW diagrams based on customer entered requirements that are architecturally more scaleable to allow for changing customer requirements.[0070]
• In one embodiment, typical applications may be grouped into a small number of classes. A wizard for each of these classes may be provided which queries the user about the application, then builds an appropriate LabVIEW diagram for the application. In one embodiment, there may be two aspects to this solution. The first is the definition of the classes and corresponding data structures. The second is the collection of wizards. In one embodiment, the wizards may use scripting, such as LabVIEW scripting, to generate the graphical programs or diagrams for each class of application.[0071]
• Thus, representative diagrams of user applications, including timing, triggering, and data transfer to the host may be developed and grouped into classes. The different diagrams in a given class preferably have very similar structure. For example, a diagram for timed acquisition of analog input channels may look nearly identical to a diagram for timed acquisition of analog and digital input channels, even though it is possible to draw the diagrams very differently. A configuration wizard for each class may then be provided which may generate the appropriate graphical program in response to user input specifying a particular application or function.[0072]
• In one embodiment, wizards may only include support for rudimentary functionality. In other words, wizards for basic acquisition, control loops, hardware in the loop testing, etc., may be provided. In another embodiment, the wizards may provide broad functionality in their respective areas of application. For example, in one embodiment, an acquisition wizard may only support pre- and post-triggering. In another embodiment, the acquisition wizard may also support external conversion, hardware gating, and other more advanced functionality.[0073]
• Thus, the use of one or more configuration wizards may provide an easy to use interface which allows the user or customer to configure or construct custom configurations for a reconfigurable system (i.e., the programmable hardware element in a RIO system). More specifically, a wizard may provide the user access to configurable RIO functionality without the user having to be familiar with a particular development environment, such as LabVIEW.[0074]
• Thus, the use of RIO devices in combination with a variety of platforms and computer systems provides a broad range of approaches for efficient and flexible measurement systems, including established platforms such as PCI/PXI and FieldPoint, USB/Ethernet devices, and small networked measurement nodes (e.g., smart sensors) for highly distributed measurement systems. Additionally, the adaptive (i.e., programmable) aspect of RIO systems in conjunction with measurement modules provides measurement and control solutions which may more accurately and efficiently match the measurement and control requirements of users. Finally, the use of graphical programs to configure the RIO hardware may greatly simply the configuration process.[0075]
BRIEF DESCRIPTION OF THE DRAWINGS
• A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:[0076]
• FIG. 1 is a block diagram of a networked RIO measurement system, according to one embodiment of the invention;[0077]
• FIGS.[0078]1A-1E illustrate various embodiments of a RIO system;
• FIGS. 2A and 2B are block diagrams representative of the computer systems of FIGS. 1A, 1B, and[0079]1C;
• FIG. 3A is a block diagram illustrating a RIO card or device configured with a programmable hardware element, according to one embodiment of the present invention;[0080]
• FIG. 3B is a block diagram illustrating a RIO card or device configured with a programmable hardware element and a processor and memory, according to one embodiment of the present invention;[0081]
• FIG. 3C illustrates example functionality of a programmable hardware element, according to one embodiment.[0082]
• FIG. 4 illustrates a RIO card, according to one embodiment of the invention;[0083]
• FIG. 5A illustrates a cartridge RIO with measurement cartridges, according to one embodiment of the invention;[0084]
• FIG. 5B is a block diagram of a RIO with multiple measurement modules, according to one embodiment of the invention;[0085]
• FIG. 6 is a block diagram of a RIO measurement system with a measurement module, according to one embodiment of the invention;[0086]
• FIG. 7 illustrates various embodiments of a RIO system with I/O expansion;[0087]
• FIG. 8 illustrates RIO in the context of current measurement systems;[0088]
• FIG. 9 illustrates design flow of a RIO system, according to one embodiment;[0089]
• FIG. 10 is a flowchart of a method for performing a measurement function, according to one embodiment;[0090]
• FIG. 11A is a flowchart of a method for configuring a measurement system, according to one embodiment;[0091]
• FIG. 11B is a flowchart of embodiments of a method for performing a measurement function, according to one embodiment;[0092]
• FIG. 12 illustrates the conversion of a graphical program to a hardware implementation;[0093]
• FIG. 13 illustrates the conversion of a graphical program into a hardware description and the use of the hardware description to program an FPGA;[0094]
• FIG. 14 is a block diagram of a RIO FPGA layout, according to one embodiment;[0095]
• FIG. 15 is a block diagram of a system for debugging a reconfigurable system, according to one embodiment;[0096]
• FIG. 16 is a flowchart of a method for debugging a reconfigurable system, according to one embodiment;[0097]
• FIG. 17 illustrates a client/server system, according to one embodiment;[0098]
• FIG. 18 is a flowchart of a method for configuring a RIO device using a configuration tool, according to one embodiment;[0099]
• FIGS.[0100]19A-19F illustrate a configuration wizard and its use, according to one embodiment;
• FIG. 20 illustrates one embodiment of a block module generator;[0101]
• FIG. 21 is a graphical program diagram generated by a block module generator, according to one embodiment;[0102]
• FIG. 22 illustrates a resource arbitration scheme for shared resource use, according to one embodiment of the invention;[0103]
• FIGS. 23A and 23B illustrate two embodiments of RIO system component responsibilities; and[0104]
• FIG. 24 illustrates example application domains for the present invention with characteristic times.[0105]
• While the invention is susceptible to various modifications and alternative forms specific embodiments are shown by way of example in the drawings and will herein be described in detail. It should be understood however, that drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed. But on the contrary the invention is to cover all modifications, equivalents and alternative following within the spirit and scope of the present invention as defined by the appended claims.[0106]
DETAILED DESCRIPTION OF THE EMBODIMENTS
• Incorporation by Reference[0107]
• The following U.S. Patents and patent applications are hereby incorporated by reference in their entirety as though fully and completely set forth herein.[0108]
• U.S. Provisional Patent Application Serial No. 60/312,252 titled “A Reconfigurable I/O Measurement System” filed Aug. 14, 2001, whose inventors were Brian Keith Odom, Joseph Peck, Hugo Andrade, Cary Paul Butler, James J. Truchard, Matt Novacek and Newton Petersen[0109]
• U.S. Provisional Patent Application Serial No. 60/313,136 titled “Reconfigurable Measurement System Utilizing a Programmable Hardware Element” filed Aug. 17, 2001, whose inventors were Brian Keith Odom, Joseph Peck, Hugo Andrade, Cary Paul Butler, James J. Truchard, Matt Novacek and Newton Petersen[0110]
• U.S. patent application Ser. No. 09/229,695 titled “Reconfigurable Test System” filed on Jan. 13, 1999, whose inventors are Arthur Ryan, Hugo Andrade, and Brian Keith Odom, which is now U.S. Pat. No. ______.[0111]
• U.S. patent application Ser. No. ______ titled “Measurement System with Modular Measurement Modules That Convey Interface Information” filed on Aug. 14, 2001, whose inventors are Perry Steger, Garritt Foote, David Potter, and James J. Truchard.[0112]
• U.S. patent application Ser. No. 06/312,242 titled “System and Method for Graphically Creating, Deploying and Executing Programs in a Distributed System” filed on Aug. 14, 2001, whose inventors are Jeffrey L. Kodosky, Darshan Shah, and Steven W. Rogers.[0113]
• U.S. patent application Ser. No. ______ titled “System and Method for Online Configuration of a Measurement System” filed on Aug. 15, 2001, whose inventors are Brian Sierer, Ganesh Ranganathan, Joseph Peck and Hugo Andrade.[0114]
• U.S. patent application Ser. No. 09/891,571 titled “System and Method for Configuring an Instrument to Perform Measurement Functions Utilizing Conversion of Graphical Programs into Hardware Implementations” filed on Jun. 25, 2001, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom, Cary Paul Butler, and Kevin L. Schultz.[0115]
• U.S. patent application Ser. No. 09/745,023 titled “System and Method for Programmatically Generating a Graphical Program in Response to Program Information,” filed Dec. 20, 2000, whose inventors are Ram Kudukoli, Robert Dye, Paul F. Austin, Lothar Wenzel and Jeffrey L. Kodosky.[0116]
• U.S. patent application Ser. No. 09/595,003 titled “System and Method for Automatically Generating a Graphical Program to Implement a Prototype”, filed Jun. 13, 2000, whose inventors are Nicolas Vazquez, Jeffrey L. Kodosky, Ram Kudukoli, Kevin L. Schultz, Dinesh Nair, and Christophe Caltagirone.[0117]
• U.S. patent application Ser. No. 09/886,455 titled “System and Method for Programmatically Generating a Graphical Program in Response to User Input”, filed Jun. 20, 2001, whose inventors are Jeffrey D. Washington, Ram Kudukoli, Robert E. Dye and Paul F. Austin.[0118]
• U.S. Pat. No. 4,914,568 titled “Graphical System for Modeling a Process and Associated Method,” which issued on Apr. 3, 1990, whose inventors are Jeffrey L. Kodosky, James J. Truchard, and John E. MacCrisken.[0119]
• U.S. Pat. No. 6,138,270 titled “System, Method and Memory Medium for Detecting Differences Between Graphical Programs,” which issued on Oct. 24, 2000, and whose inventor is Ray Hsu.[0120]
• U.S. Pat. No. 6,219,628 titled “System and Method for Converting Graphical Programs Into Hardware Implementations”, which issued on Apr. 17, 2001, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom and Cary Paul Butler.[0121]
• U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System” filed Aug. 18, 1997, whose inventors are Jeffrey L. Kodosky, Darshan Shah, Samson DeKey, and Steve Rogers.[0122]
• As used herein, the term “measurement device” is intended to include instruments, smart sensors, data acquisition devices or boards, and any of various types of devices that are operable to acquire and/or store data A measurement device may also optionally be further operable to analyze or process the acquired or stored data. Examples of a measurement device include an instrument, such as a computer-based instrument (instrument on a card) or external instrument, a data acquisition card, a device external to a computer that operates similarly to a data acquisition card, a smart sensor, one or more DAQ or measurement cards or modules in a chassis, an image acquisition device, such as an image acquisition (or machine vision) card (also called a video capture board) or smart camera, a motion control device, a robot having machine vision, and other similar types of devices. It is also contemplated that RIO technology as described herein may be used in control/automation and simulation systems.[0123]
• Exemplary instruments include oscilloscopes, multimeters, spectroscopes, and any measurement, test, or automation instrument. A measurement device may be further operable to perform control functions, e.g., in response to analysis of the acquired or stored data. For example, the measurement device may send a control signal to an external system, such as a motion control system or to a sensor, in response to particular data A measurement device may also be operable to perform automation functions, i.e., may receive and analyze data, and issue automation control signals in response.[0124]
• As used herein, the term “programmable hardware element” is intended to include various types of programmable hardware, reconfigurable hardware, programmable logic, or field-programmable devices (FPDs), such as one or more FPGAs (Field Programmable Gate Arrays), or one or more PLDs (Programmable Logic Devices), such as one or more Simple PLDs (SPLDs) or one or more Complex PLDs (CPLDs), or other types of programmable hardware. The programmable hardware element may also be referred to as a “reconfigurable core”.[0125]
• As used herein, the term “hardware configuration program” refers to any type of program, e.g., a netlist or bit file, that can be used to program or configure a programmable hardware element.[0126]
• As used herein, the term “fixed hardware resources” includes hardware resources that have pre-defined functionality. Fixed hardware resources may have some programmable parameters. Examples of fixed hardware include physical I/O resources such as analog to digital converters (ADCs), digital to analog converters (DACs), and digital lines, among others. For example, in the case of a analog input comprising an ADC and a programmable gain stage, the gain parameter of the gain stage may be adjustable or configurable programmatically by the FPGA.[0127]
• As used herein, the terms “data processing” and “data analysis” are used to refer to the processing of data to extract useful information from the data (such as an image) or determine characteristics of the data (or to determine characteristics of one or more objects represented by the data). The term “data processing function” may also include an operation or decision that is performed in response to the information extracted or characteristics determined from the data, i.e., a control function. The term “data processing function” is also intended to include a data processing (or control) algorithm that combines a sequence of two or more data processing functions or tools and/or decision operations that process a data in a desired way or which implement a data processing, control, or machine vision application, such as part inspection, automated assembly, data analysis, pattern matching, edge detection, alarm, logging, etc.[0128]
• The term “measurement function” may include measurement and/or control functions, such as acquiring data, conditioning data, logging data, displaying data, analyzing and/or processing received data to generate a result, performing signal processing on received data, or otherwise analyzing and/or processing received data to perform a measurement. More specifically, a measurement function may include one or more of signal acquisition, signal conditioning, signal conversion, and measurement analysis. Examples of measurement functions include various instrumentation functions or control functions, including machine vision, image processing and motion control, among others.[0129]
• The term “machine vision function” or “image processing function” includes tools such as edge detection, blob analysis, pattern matching, filtering, pixel transformations, and other image processing functions. The term “image processing” is used herein to refer to both “image processing” and “machine vision”, to the extent these terms have different meanings.[0130]
• In the present application, the term “graphical program” or “block diagram” is intended to include a program comprising graphical code, e.g., two or more nodes or icons interconnected in one or more of a data flow, control flow, or execution flow format, (and/or a “signal flow” format, which is considered a subset of data flow), where the interconnected nodes or icons may visually indicate the functionality of the program. Thus the terms “graphical program” or “block diagram” are each intended to include a program comprising a plurality of interconnected nodes or icons which visually indicate the functionality of the program. A graphical program may comprise a block diagram and may also include a user interface portion or front panel portion. The user interface portion may be contained in the block diagram or may be contained in one or more separate panels or windows. A graphical program may be created using any of various types of systems which are used to develop or create graphical code or graphical programs, including LabVIEW, DASYLab, and DiaDem from National Instruments, Agilent VEE (Visual Engineering Environment), Snap-Master by HEM Data Corporation, SoftWIRE from Measurement Computing, ObjectBench by SES (Scientific and Engineering Software), Simulink from The MathWorks, WiT from Coreco, Vision Program Manager from PPT Vision, Hypersignal, VisiDAQ, VisSim, and Khoros, among others. In the preferred embodiment, the system uses the LabVIEW graphical programming system available from National Instruments. Thus, in one embodiment, development tools typically used for software development may be used to configure hardware, i.e., the programmable hardware element.[0131]
• In the present application, the term “program” may include a graphical program as described herein, a program developed in a textual-based programming language, such as C, C++, Basic, Fortran, Pascal, Java, etc., and programs developed in hardware description languages, such as VHDL, Verilog, or system description languages, such as SystemC.[0132]
• In the present application, the term “measurement program” may include a program that performs a measurement function as described herein.[0133]
• As used herein, the term “memory medium” includes a non-volatile medium, e.g., a magnetic media or hard disk, or optical storage; a volatile medium, such as computer system memory, e.g., random access memory (RAM) such as DRAM, SRAM, EDO RAM, RAMBUS RAM, DR DRAM, etc.; or an installation medium, such as a CD-ROM or[0134]floppy disks104, on which the computer programs according to the present invention may be stored for loading into the computer system. The term “memory medium” may also include other types of memory or combinations thereof
• As used herein, the term “processor” includes a CPU (microprocessor or microcontroller), DSP, reconfigurable processor, or a hardcore or softcore inside an FPGA.[0135]
• RIO Overview[0136]
• The Reconfigurable Input/Output (RIO) architecture may be considered a template or pattern/platform for a reconfigurable measurement (including data acquisition), control (including automation) and/or simulation system, in which software and hardware components, as well as configuration and runtime behaviors, are defined. As used herein, the term “reconfigurable I/O” or “RIO” refers to a device, (e.g., a card) which includes at least one programmable hardware element. In simple terms, a RIO card or unit contains at least one programmable hardware element, i.e., a reconfigurable core, such as a field programmable gate array (FPGA), which may be surrounded by fixed hardware resources (e.g., I/O resources) (both on-board and off-board, e.g. measurement modules). The behavior of the reconfigurable core can be configured to better match the requirements of the measurement and/or control system. In an exemplary embodiment, the system may be implemented as an FPGA that is targeted by a development system, such as National Instruments LabVIEW or LabVIEW FPGA. Other embodiments are also contemplated, e.g., an embodiment which includes an addition of a microprocessor to the FPGA core.[0137]
• Thus, the reconfigurable core (programmable hardware element) is the basis for RIO. This scaleable resource may include such functions as I/O interfacing, timing and triggering, inline processing, and embedded decision-making. Fixed hardware resources may be connected at the boundary of the reconfigurable core, and may typically provide one of four types of functionality:[0138]
• 1) a control and data path to a host computer;[0139]
• 2) an I/O interface to external systems;[0140]
• 3) optimized hardware elements; and[0141]
• 4) basic operating services.[0142]
• These resources by themselves may not define the measurement and/or control system, but rather are the low-level building blocks for the creation of the system. The configuration or program (the hardware configuration program) in the reconfigurable core (e.g., the FPGA) builds on these blocks to define the system.[0143]
• The interface at the boundary of the reconfigurable core provides RIO with a very flexible mechanism for connecting to the fixed resources. The fundamental interface at this boundary may comprise digital and/or analog pins, and the ability of RIO to organize and build on these pins in a hierarchical method is an important capability. RIO allows pins to be grouped into ports that perform specific interfacing functionality. For example,[0144]4 digital pins may be associated with a fixed serial ADC, and together may be considered an interface port. A simpler example is a single digital pin defined as a1-bit DIO port. The grouping at this level defines the most basic interface to each of the fixed resources.
• These low-level ports can be further grouped to provide more advanced functionality. This functionality may include the creation of higher capability interfacing logic, such as counters built on top of several individual DIO ports, or the addition of logic to an interface, such as a digital filter placed inline with an ADC interface. This hierarchy of groups is not limited to one level, and may be arbitrarily deep.[0145]
• It is important to note that RIO is not limited to digital only solutions. Other embodiments include reconfigurable digital and analog circuitry. The grouping and connecting of “logic” in the FPGA may also include reconfigurable analog building blocks that can be configured to perform user defined analog functionality, such as, for example, an uncommon ADC with 11 bits of resolution with an integrated analog low pass filter.[0146]
• The concept of grouping pins also applies to communication mechanisms for RIO, such as for communicating with a host computer. The low-level grouping defines a physical interface which may connect to buses or interface chips implementing PC, USB, IEEE-1394, Ethernet, etc. The creation of read and write registers on top of the physical interface may implement the actual communication. The use of these registers is application dependent, but their method of access may be generic.[0147]
• Control and data paths (1) and the I/O interface (2) above are very similar in concept, but specific to the type of interface they are implementing and communicating with. As described in 3) above, communication paths may take advantage of optimized hardware elements. For example, to communicate with the host a hardwired PCI interface (e.g., National Instruments minMITE) may be utilized. If extraordinary FFT performance is desired or required, application specific integrated circuits (ASICs), specialized DSPs, or other FPGAs implementing Fast Fourier Transforms (FFT) may be used.[0148]
• The operating services of 4) above may refer to external (or internal) blocks that provide basic services to the reconfigurable core, e.g., a basic clock reference (internal and external (system)), a reconfiguration path (from host or persistent store), and a persistent store. It can also include basic standard debugging interfaces, and connectivity to RAM, among other services.[0149]
• In addition to the creation of user specific I/O interfaces, RIO may provide for the timing and triggering of these interfaces, allowing for very flexible relationships between resources. For example, the user may configure one group of I/O to be sampled at one rate, and another group at a completely independent rate. This same flexibility may apply to starting, stopping, pausing, etc. of I/O operations.[0150]
• Another possible use of the reconfigurable core is to provide processing. The inclusion of decision making capabilities in the hardware may be useful at all levels of the measurement and/or control system. For example, decision logic on the programmable hardware element may be used to transform signals, such as converting quadrature signals into count and up/down controls for a counter, for inline processing, such as adding linearization to an analog input data stream, for creating complicated trigger sequences, such as state based triggering for bus analyzers, and for high-speed control loops, such as PID. This decision-making capability may provide wide flexibility to many applications, and in some cases may allow the application to run autonomously in the FPGA without any host computer interaction.[0151]
• Yet another possible use of the programmable hardware element is to implement any of a variety of interfaces for communicating with a measurement module. In other words, the RIO device may be operable to be programmed with an interface protocol which is specific to a given measurement module. In addition, this programming may occur dynamically and/or automatically, such as upon connection to the module. These and other embodiments of the invention are described in detail below.[0152]
• A RIO device as described herein may be capable of being configured or programmed (in hardware) to perform any of a variety of measurement, control, and/or simulation tasks, i.e., to assume the properties in hardware of various devices or configurations of devices, as well as measurement and/or control functions. A RIO device may be used to perform any of various types of hardware operations in any of various applications.[0153]
• Exemplary applications targeted by RIO include, but are not limited to, measurement and data acquisition, embedded I/O and machine control, high-speed analog control loops, high density discrete control, hardware in the loop simulation, and applications requiring custom hardware triggering and/or digital logic, among others. In general, RIO may be particularly suitable for developing simple hardware functionality which is difficult to express in fixed hardware resources, including complex triggering, quadrature encoding, simple bit transfers, and the like, as well as hardware based interlocks, simple control algorithms, e.g., PID (proportional integral derivative), and simple measurements, DSP, rise time, fall time, RMS (root mean square), FIR (finite impulse response) filters, and period measurement, among others, although it is noted that RIO may be used for any other hardware development as well.[0154]
• FIG. 1—Block Diagram of a RIO Measurement System[0155]
• FIG. 1 is a block diagram of a RIO measurement system, according to an embodiment of the invention. As FIG. 1 shows,[0156]sensor112 may optionally be coupled to ameasurement module108, described above, which may in turn be coupled to a RIO unit or RIO device, also referred to as aRIO110. TheRIO110 may be coupled tocomputer system102 viatransmission medium104, e.g., the Internet. Alternatively, thesensor112 may couple directly to theRIO device110, andmeasurement module108 may not be included.
• In the embodiment where the[0157]sensor112 couples directly to the RIO device110 (i.e., where there is no measurement module), theRIO device110 may be operable to perform any necessary signal conditioning and/or signal conversion on the signals sent by thesensor112. Alternatively, signal conditioning and/or signal conversion may not be necessary. TheRIO device110 may then perform analysis or other data processing on the signals, and send results of the analysis to thecomputer system102 or another device. TheRIO device110 may also perform analysis and generate real time control signals to a process or system being controlled.
• The[0158]measurement module108 and the RIO unit (carrier)110 together may provide the functionality of theRIO measurement device110 of FIG. 1. For example, in one embodiment, themeasurement module108 may be operable to perform signal conditioning and/or signal conversion on the signals sent by thesensor112, and to transmit results of such processing on to theRIO110. In this embodiment, themeasurement module108 may include one or more fixed hardware resources used by the programmable hardware element on theRIO110. In one embodiment, theRIO110 may be operable to receive data from themeasurement module108, perform a function on the data, and communicate the data (possibly in a different format or form) to thecomputer system102, e.g., over thetransmission medium104. For example, theRIO110 may receive signal data in a proprietary format from themeasurement module108 and format the data for transmission over wireless Ethernet to thecomputer system102.
• The[0159]host computer102 may comprise a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. Thecomputer102 may be used to configure or program theRIO measurement device110, as described below.
• Additionally, the[0160]computer102 may operate with themeasurement device110 to analyze or measure data from thesensor112 and/ormeasurement device110 or to control thesensor112 and/ormeasurement device110.
• In one embodiment, the[0161]computer system102 may store an application development environment (ADE) for creating programs. The ADE may include specific functionality for creating programs that are to be deployed on aRIO device110. The ADE may also include specific functionality for a certain type of application, such as measurement, control, or automation, among others.
• The computer system may also store a program implementing a function. For example, the computer system may store a program implementing one or more measurement functions, i.e., a measurement program, e.g., a program, such as a graphical program, implementing the one or more measurement functions.[0162]
• The[0163]computer system102 may be operable to execute the measurement program to perform the one or more measurement functions, preferably in conjunction with operation of theRIO110 and/ormeasurement module108. For example, the measurement program may be executable to perform one or more measurement and/or control functions, including analysis of data or signals received from theRIO110, control of RIO and/or measurement module operations, user interface functions, and pattern recognition and/or characterization, among others.
• The[0164]computer system102 may store a deployment program which is executable to generate a hardware configuration program based on a program generated by the ADE. The deployment program may be part of the ADE. The deployment program may also be executable to transfer or deploy the hardware configuration program onto a programmable hardware element (or multiple programmable hardware elements) of aRIO device110.
• In the preferred embodiment, the[0165]RIO110 includes at least oneprogrammable hardware element106, which may be programmed bycomputer system102. In one embodiment, theRIO110 may include a plurality ofprogrammable hardware elements106. Thecomputer system102 may also couple tomultiple RIO units110, wherein eachRIO unit110 includes one or moreprogrammable hardware elements106. For example, thecomputer system102 may couple tomultiple RIO units110, wherein theRIO units110 may be distributed in various locations on a network (such as the Internet).
• Where the[0166]RIO unit110 includes a plurality ofprogrammable hardware elements106, thecomputer system102 may be operable to transfer or deploy a hardware configuration program onto one or more (or all) of the plurality of programmable hardware elements of theRIO device110. Thus the hardware configuration program may be generated and/or deployed in a manner to distribute the hardware configuration program across multipleprogrammable hardware elements106. The hardware configuration program may also be generated and/or deployed in a manner to distribute the hardware configuration program acrossmultiple RIO devices110, wherein each RIO device may include one or moreprogrammable hardware elements106.
• In one embodiment, the[0167]RIO device110 may include one or morefixed hardware resources204.Fixed hardware resources204 may also be located external to theRIO device110, such as themeasurement module108, or on thesensor112. A deployed hardware configuration program on theRIO device110 may be operable to invoke functionality of one or more of thehardware resources204. A user may specify use of fixedhardware resources204 when creating the program using the ADE. Alternatively, or in addition, the deployment program may automatically specify use of fixed hardware resources.
• Thus, the RIO unit(s)[0168]110 may be reconfigurable, i.e., programmable by an external computer system, such ascomputer system102. More specifically, the computer system may be operable to deploy the measurement program onto the programmable hardware element(s) of the RIO unit(s)110. In other words thecomputer system102 may download the measurement program onto the programmable hardware element of theRIO110, after which theRIO110 may be operable to execute the measurement program to perform the one or more measurement and/or control functions.
• After a measurement program has been deployed as a hardware configuration program onto the programmable hardware element of the[0169]RIO110, the RIO may operate in a stand-alone fashion to perform the measurement function. For example, the RIO unit may be disconnected from thecomputer system102 or from the network to which it is attached, and theRIO110 may be used to perform the measurement function as a stand-alone device. Alternatively, theRIO device110 may optionally operate in conjunction with operation of themeasurement module108, and possibly thecomputer system102, as well as other devices, such asother RIOs110, smart sensors, networked devices, etc. The configuredRIO110 and themeasurement module108 may thus be operable to perform measurement (i.e., data acquisition and/or control) operations using thesensor112 and/or thecomputer system102. More generally, a measurement function may be distributed across multiple devices, such as one ormore RIO units110, one or more sensors (such as smart sensors), one or more measurement modules, one or more computer systems, and/or one or more instruments or other devices.
• In one embodiment, the[0170]RIO unit110 may be operable to receive interface protocol information from themeasurement module108 specifying how to operate or interface with themeasurement module108. TheRIO unit110 may then communicate the interface protocol information to thecomputer system102. Alternatively, themeasurement module108 may communicate the interface protocol information directly to thecomputer system102. Based on the interface protocol information, thecomputer system102 may program or configure theprogrammable hardware element106 on theRIO unit110 to implement the interface as specified by themeasurement module108. In other words, themeasurement module108 may tell theRIO110 how to “talk” with it, and theRIO110 may then tell thecomputer system102 how to program theRIO110 to communicate with themeasurement module108 accordingly (or themeasurement module108 may tell thecomputer system102 directly how to program the RIO110 (i.e., the RIO's programmable hardware element106). Thecomputer system102 may then program the RIO110 (i.e., the RIO's programmable hardware element106), thereby implementing the interface specified in the interface protocol information communicated by themeasurement module108. This process may be referred to as initialization of the measurement module/RIO. Further details of this process are described below.
• In one embodiment, the[0171]RIO device110 may include an IP address and web server capabilities. Thus theRIO device110 may be able to publish received signals or measurement data over the Internet. TheRIO device110 may similarly be operable to receive signal data over the Internet for processing. In another embodiment, one ormore measurement cartridges108 and/orsensors112 coupled to theRIO device110 may have an IP address and web server capabilities, and thus may be able to communicate with remote systems over the Internet, for example, to stream sensor data (e.g., numerical data or images) to a website for access by other systems or users.
• The[0172]computer102 may include a memory medium on which computer programs, according to the present invention may be stored. The memory medium may be comprised in thecomputer102 where the programs are executed or may be located on a second computer which is coupled to thecomputer102 through a network, such as a local area network (LAN), a wide area network (WAN), or the Internet. In this instance, the second computer operates to provide the program instructions through the network to thecomputer102 for execution. Also, thecomputer system102 may take various forms, including a personal computer system, mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television set-top box, instrument, or other device. In general, the term “computer system” can be broadly defined to encompass any device having at least one processor which executes instructions from a memory medium.
• Thus, programs of the present invention may be stored in a memory medium of the[0173]respective computer102, or in a memory medium of another computer, and executed by the CPU. The CPU executing code and data from the memory medium thus comprises a means for deploying a graphical program onto aRIO device110 according to the steps described below.
• The memory medium may store an ADE for creating programs having a desired functionality, wherein these programs are convertible to a hardware configuration program that can be deployed to a[0174]RIO device110. Deployment may be performed by converting at least a portion of a program into a form for configuring or programing a programmable hardware element. In alternate embodiments, deployment may be performed by transferring the program to execute natively on a processor, or by converting the program to a different form and transferring the converted program for execution by a processor and memory. TheRIO device110 in FIG. 1 may be controlled by or configured by programs which are deployed or downloaded to the programmable hardware element on theRIO device110. In various embodiments, the program deployed on theRIO device110 may be any of various types, such as programs created in graphical languages, text-based programming languages, or hardware description languages, etc.
• With respect to the ADE for creating the program to be deployed onto the[0175]RIO device110, input to the ADE may be textual, graphical, a hardware description language, may be through a configuration environment (e.g., a wizard) or an API structural description.
• In one embodiment, the memory medium may store a graphical programming development system for developing graphical programs. The memory medium may also store one or more deployment computer programs which are executable to deploy a program such as a graphical program.[0176]
• As described below, in one embodiment the graphical program may be deployed by either one or more of: 1) converting the graphical program (or a portion thereof) into a hardware implementation (hardware configuration program) and configuring the programmable hardware element with this hardware implementation, 2) transferring a first portion of the graphical program (or a portion thereof) to a memory for execution by a processor (where the memory and processor are on the[0177]RIO device110 or the computer system102), wherein the processor may execute a graphical program execution engine and optionally a real time operating system), and deploying a second portion of the graphical program as a hardware configuration program on a programmable hardware element (e.g., a RIO device with mixed LabVIEW RT (Real Time) and LabVIEW FPGA execution); or 3) compiling a first portion of the graphical program (or a portion thereof) into an executable program and transferring the executable program to a memory for execution by a processor (where the memory and processor are on theRIO device110 or the computer system102), (where the processor may optionally execute a real time operating system), and deploying a second portion of the graphical program as a hardware configuration program on a programmable hardware element.
• FIGS.[0178]1A-1D—Various Embodiments of a RIO System
• FIGS.[0179]1A-1D illustrate various exemplary embodiments of aRIO system110. The examples presented are meant to be illustrative only, and are not intended to limit the particular form or composition of the system.
• FIG. 1A illustrates a[0180]computer system102 coupled to a RIO measurement orcontrol device110A, according to one embodiment. As FIG. 1A shows, thecomputer system102 may couple to theRIO measurement device110A through a transmission medium, e.g., a serial bus, such as a USB109. It should be noted that although a USB109 is shown in this example, any other transmission medium may be used, including Ethernet, wireless media such as IEEE 802.11 (Wireless Ethernet) or Bluetooth, a network, such as a fieldbus, a Control Area Network (CAN) or the Internet, serial or parallel buses, or other transmission means.
• As FIG. 1A shows, the[0181]RIO measurement device110A may in turn couple to or comprise a sensor oractuator112, such as a pressure or temperature gauge, a thermocouple, an imaging device (e.g., a camera), or any other type of sensor or actuator.
• FIG. 1B illustrates a RIO system which comprises a[0182]RIO device110B coupled tosensor112. As shown in FIG. 1B, this RIO system does not include thecomputer system102. Thus, theRIO device110B may be operable to function independently of thecomputer system102 of FIGS. 1 and 1A. As may be seen, theRIO device110B may comprise a chassis having slots for one or more measurement modules. The measurement modules may be operable to perform one or more measurement, processing or control functions as described below. Each measurement module may perform various measurement and/or control functions, including data acquisition, signal conditioning, ADC, microprocessor, and optional isolation functions for sensor to digital operations. In one embodiment, theRIO device110B may include amodule108 comprising a computer on a card, i.e., the functions of thecomputer system102 may be performed by amodule108 comprised in a slot on theRIO device110B.
• The[0183]programmable hardware element106 and the fixedhardware resources204 of theRIO device110 may be comprised in the chassis, or may both be comprised on one or more of themeasurement modules108. In one embodiment, theprogrammable hardware element106 may be comprised in the chassis, and the fixedhardware resources204 may be comprised on one ormore measurement modules108, or the fixedhardware resources204 may be comprised in the chassis and in various ones of themeasurement modules108.
• In one embodiment, the[0184]RIO measurement device110B may include, in addition to the programmable hardware element106 (e.g., the FPGA) and fixedhardware resources204, a memory, such as a non-volatile memory or EEPROM, which may store a hardware configuration usable to program the FPGA.
• In an embodiment where the[0185]RIO110B implements an interface for communicating with ameasurement module108, anEEPROM 288 may contain an Electronic Data Sheet (EDS), defined by IEEE 1451.2, and an optional calibration history.
• IEEE 1451.2 defines an interface between transducers and microprocessors useful in industrial automation and other fields. The standard defines a physical interface comprising a data transport serial link, in addition to triggering, interrupt and hot swap signaling. The standard also defines a transducer electronic data sheet, TEDS, that describes the functionality of the transducer in machine-readable form. The interface supports as many as 255 independent transducer channels. These may be accessed individually or as a unit. The standard may be used to implement a variety of measurement functions.[0186]
• FIG. 1C illustrates a[0187]host computer system102 coupled to aRIO measurement device110C. FIG. 1C illustrates an exemplary measurement, control, ormachine vision system102. As FIG. 1C shows, themeasurement device110C may be a RIO device. Themotion control interface138 may also be a RIO Device. Themeasurement device110C may in turn couple to or comprise a sensor, such ascamera132. Themotion control interface138 may in turn couple to amotion control unit136.
• The[0188]measurement device110C may include a programmable hardware element for performing measurement and/or control functions as described below. Themotion control interface138 may also include aprogrammable hardware element106 and one or morefixed hardware resources204 for performing measurement and/or control functions as described below.
• In one embodiment, the[0189]device110C may not be present, and thesensor132 may be a smart sensor which is or comprises a RIO device (e.g., a smart camera which is or comprises a RIO device110). In another embodiment, thedevice138 may not be present, and themotion control unit136 may be a smart motion control device which is or comprises a RIO device.
• The[0190]host computer102 may comprise a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. Thecomputer102 may operate with the measurement device to analyze, measure or control a device orprocess150. Alternatively, thecomputer102 may be used only to configure the programmable hardware element in themeasurement device110C.
• As shown, a sensor device or[0191]camera132 may be coupled to thecomputer102 via the measurement device orcard110C. Thecamera132 and/ormeasurement device110C may couple to thecomputer102 through a serial bus, a network, or through other means. Themotion control unit136 and the RIOmotion control interface138 may also couple to thecomputer102 through any means.
• The measurement/[0192]control system100 may be used in a manufacturing assembly, test, measurement, and/or control application, among others. For illustration purposes, a unit under test (UUT)150 is shown which may be positioned by a motion control device136 (and interface card138), and imaged and analyzed by thecamera132 andmeasurement device110C. It is noted that in various other embodiments theUUT150 may comprise a process or system to be measured and/or analyzed.
• FIG. 1D illustrates an embodiment of a RIO system comprising a RIO card[0193]110D coupled tosensor112 through the card I/O connections. In this embodiment, the RIO card110D may be coupled to a computer system for initialization/configuration then decoupled102 and used independently from thecomputer system102. For example, the configured RIO card110D may be bolted or coupled to another device, e.g., a motion control device, or any other device or system.
• FIG. 1E illustrates an embodiment of a[0194]RIO device110J implemented as a small form factor device which includes a programmable hardware element, one or more fixed hardware resources, an optional processor and memory, and an interface, such as an Ethernet, Internet, USB, FireWire, or other interface. For example, theRIO device110J may be comprised in a small standalone device (e.g., a device with dimensions less than about 2″ by 2″ by 1″), a smart camera, a motion control device, wireless and wired telephones, network devices, a cable connector, a pacemaker, an I/O device, a PDA, artificial limbs, musical instruments, home appliances, surveillance devices, satellites, etc.
• Thus, the[0195]RIO device110J may assume a variety of forms and functionality, depending upon the particular application requirements. Other embodiments also contemplated are described below.
• FIGS.[0196]2A and2B—Computer Block Diagrams
• FIGS. 2A and 2B are exemplary block diagrams of the[0197]computer102 of FIGS.1A-1C. The elements of a computer not necessary to understand the operation of the present invention have been omitted for simplicity. As FIGS. 2A and 2B show, thecomputer102 may include at least one central processing unit (CPU) orprocessor160 which is coupled to a processor or host bus162. TheCPU160 may be any of various types, including an ×86 processor, a PowerPC processor, a CPU from the Motorola family of processors, a CPU from the SPARC family of RISC processors, as well as others.Main memory166 is coupled to the host bus162 by means ofmemory controller164. Themain memory166 may be operable to store one or more programs according to the present invention. For example, thememory medium164 may store a program which is executable to use interface protocol information received from theRIO110 to program or configure theprogrammable hardware element106 comprised in theRIO110. Themain memory166 may also store operating system software, i.e., software for operation of the computer system, as well as one or more application programs, as is well known to those skilled in the art. In addition, themain memory166 may store one or more measurement programs which are executable to perform measurement (including DAQ) and/or control tasks.
• The host bus[0198]162 is coupled to an expansion or input/output bus170 by means of a bus controller168 or bus bridge logic. The expansion bus170 is preferably the PCI (Peripheral Component Interconnect) expansion bus, although other bus types may be used. The expansion bus170 may include slots for various devices.
• In FIG. 2A, the devices coupled to the expansion bus[0199]170 include acontroller186, e.g., aUSB controller186, here shown coupled toRIO110. In this embodiment, theRIO110 is coupled to anoptional measurement module108, e.g., a National Instruments small form-factor measurement module108, which in turn is coupled to asensor112. In this embodiment, the devices also includenetwork controller184,video display subsystem180 andhard drive182 coupled to the expansion bus170, also shown. It should be noted that thenetwork controller184 may be any type of network controller, including Ethernet, wireless Ethernet (IEEE 802.11), Bluetooth, and CAN, among others. Furthermore, the USB controller shown is meant to be illustrative only, i.e., any other type of controller may be used as desired to communicate with theRIO device110. In other embodiments, thecontroller186 may be comprised in the bus controller168, or may be implemented in any other forms customary and known in the art.
• In FIG. 2B, the examples of devices coupled to the expansion bus[0200]170 shown include aRIO device110A, a network controller184 (such as for coupling to adevice110 over a network, as described above with reference to FIG. 1C), amotion control device138, such as shown in FIG. 1B, as well as ahard drive182, and avideo display subsystem180. TheRIO device110A may be implemented in any of various computer system components, such asnetwork device184,motion control device138, bus controller168, etc.
• FIGS.[0201]3A and3B—Reconfigurable I/O Devices
• FIGS. 3A and 3B are block diagrams of embodiments of a RIO device including one or more[0202]programmable hardware elements106, such as an FPGA, and example auxiliary components. FIGS. 3A and 3B show exemplary RIO device block diagrams, where theRIO device110 is shown as a card or board. These embodiments also apply to other RIO device embodiments and form factors.
• FIG. 3A—A RIO with Programmable Hardware[0203]
• FIG. 3A is a block diagram illustrating a RIO device, e.g., a[0204]RIO card110E, configured with programmable hardware according to one embodiment. It is noted that FIG. 3A is exemplary only, and a RIO card ordevice110E configured with programmable hardware according to the present invention may have various architectures or forms, as desired. For example, the device may be internal or external to thecomputer102, and may be connected to the computer through a network, such as the Internet. TheRIO card110E illustrated in FIG. 3A may be theRIO measurement device110C or the motioncontrol interface card138, shown in FIG. 1C, or any of the RIO devices shown in FIGS.1A-2B, or any other type of measurement or control device as desired.
• As shown in FIG. 3A, the[0205]RIO card110E preferably includesprogrammable hardware element106. In one embodiment, theprogrammable hardware106 may comprise a field programmable gate array (FPGA) such as those available from Xilinx, Altera, etc. TheRIO card110E may also include anon-volatile memory288 coupled to theprogrammable hardware element106. In this embodiment, thenon-volatile memory288 may be used for storing FPGA state information which may be used to initialize, configure, or program theFPGA106 to perform a measurement or control function or implement an interface, as described above.
• In one embodiment, the[0206]programmable hardware element106 may be operable to perform one or more of: I/O interfacing, timing and triggering, inline processing, and embedded decision-making. For example, new triggering options or a different mix of counters may be implemented on theprogrammable hardware element106 for an application. In converting the program into the hardware implementation form, thecomputer system102 may generate a hardware description which is usable to configure theFPGA106 to perform the functionality as specified in the program. Note that the term “hardware description” may refer generally to intermediate and final forms of the implementation, or may refer specifically to the form of the program used to generate a netlist. The conversion process and specific intermediate forms of the converted program are described in detail below with reference to FIGS. 12 and 13.
• The[0207]RIO card110E may also include one or morefixed hardware resources204. The fixedhardware resources204 may be coupled or connected at the boundary of theprogrammable hardware element106. The fixedhardware resources204 may provide various dedicated hardware functionality that may be used in conjunction with theprogrammable hardware element106. In one embodiment, these fixedhardware resources204 may provide various types of functionality, including one or more of: 1) control and data path to a host computer; 2) I/O interfacing to the external system; 3) optimized hardware elements; and/or 4) basic operating services. For example, the fixed hardware resources may comprise fixed physical I/O resources, including ADCs, DACs, and digital lines, among others.
• In one embodiment, these resources are low-level building blocks that may be used in creation of the system. As noted above, these fixed[0208]hardware resources204 may be used in conjunction with or by theprogrammable hardware element106, wherein the configuration deployed onto theprogrammable hardware element106 can use or build on these blocks to define a measurement and/or control system.
• As also shown in FIG. 3A, the[0209]RIO card110E may include an I/O connector202 which is operable to send/receive signals. The I/O connector202 may present analog and/or digital connections for receiving/providing analog or digital signals, such as image signals, pixel data, or any other type of signal or data, such as from a sensor oractuator112. In one embodiment, the I/O connector202 may be adapted for coupling to an external camera. The I/O connector202 may be an example of a fixedhardware resource204.
• Thus, in one embodiment, everything behind the I/O can be redefined as desired to implement a given functionality, i.e., only the physical I/O is static (e.g., more ADCs can't generally be added, unless a mixed signal FPGA, described below, is configurable to implement them). The configuration for the[0210]programmable hardware element106 may be “tuned” to a specific application, and may therefore minimize incompatibilities between the application and system hardware.
• As one example, the fixed[0211]hardware resources204 may comprise resources referred to as data acquisition (DAQ)logic204. As shown, thedata acquisition logic204 may comprise analog to digital (A/D) converters, digital to analog (D/A) converters, timer counters (TC) and signal conditioning (SC) logic as shown. TheDAQ logic204 may provide data acquisition functionality of the I/O device110E. In one embodiment, theDAQ logic204 comprises 4 A/D converters, 4 D/A converters, 23 digital I/Os, a RTSI connector, and a TIO. This extra hardware is useful for signal processing and motion control applications. Theprogrammable hardware element106 may be coupled to theDAQ logic204 and may also be coupled to a local bus interface208, described below. The programmable hardware element orFPGA106 may access these resources directly, thereby enabling creation of very powerful data processing applications, among others.
• As shown, the[0212]RIO card110E may further include bus interface logic216 and a control/data bus218. In one embodiment, theRIO card110E is a PCI bus-compliant interface card adapted for coupling to the PCI bus of thehost computer102, or adapted for coupling to a PXI (PCI eXtensions for Instrumentation) bus. The bus interface logic216 and the control/data bus218 thus present a PCI or PXI interface. The bus interface logic216 and the control data bus218 may be examples of fixedhardware resources204.
• The[0213]RIO card110E may also include local bus interface logic208. The local bus interface logic208 may interface to a local bus used for data transfer. In one embodiment, theRIO card110E may present a RTSI (Real Time System Integration) bus for routing timing and trigger signals between theRIO card110E and one or more other devices or cards, such as a motion device. The local bus interface logic208 and/or the RTSI bus may each also be an example of a fixedhardware resource204.
• Thus, in addition to the[0214]programmable hardware element106, theRIO card110 may include fixedhardware resources204 which may operate in conjunction with theprogrammable hardware element106 to perform measurement and/or control functions. Said another way, after the hardware description is deployed onto theprogrammable hardware element106, theprogrammable hardware element106 may be operable to directly perform a first portion of the measurement function, and invoke the one or morefixed hardware resources204 to perform a second portion of the measurement function. In other words, the first portion of the measurement function is actually performed by theprogrammable hardware element106, while the second portion of the measurement function, although initiated or directed by the programmable hardware element, is actually performed by the fixedhardware resources204. Thus, the hardware description may specify the first portion of the measurement function to be performed directly by the programmable hardware element, and usage of the one or morefixed hardware resources204 by theprogrammable hardware element106 to perform the second portion of the measurement function.
• As mentioned above, in a preferred embodiment, the FPGA may be configured by the[0215]computer system102 by implementing a program, such as a graphical program, on the FPGA. If the (graphical) program contains portions which are only executable on a processor (as opposed to a programmable hardware element106), then those portions may be executed by a different part of the system, such as by a processor comprised in thecomputer system102. Thus in the embodiment of FIG. 3A, any supervisory control portion of the graphical program which is necessary or desired to execute on a programmable processor in software may be executed by the host CPU in thecomputer system102, and is not executed locally on theRIO card110E. Thus a graphical program can be created on thecomputer102, or on another computer in a networked system, and at least a portion of the graphical program can be converted into a hardware implementation form for execution in theFPGA106 or by fixedhardware resources204. The portion of the graphical program converted into a hardware implementation form is preferably a portion which requires fast and/or real time execution.
• FIG. 3B—A RIO with Programmable Hardware and Processor[0216]
• In the embodiment of FIG. 3B, in addition to the programmable hardware[0217]106 (FPGA), aRIO card110F may further include a dedicated on-board processor212 andmemory214. In various embodiments, theprocessor212 may comprise one or more of a processor and memory, a micro-controller, and a digital signal processor (DSP). This enables a portion of the graphical (or other) program to be compiled into machine language for storage in thememory214 and execution by theprocessor212. A portion of the graphical program may also (or instead) be transferred to thememory214 in its native format for execution by the processor. This may be in addition to a portion of the graphical program being converted into a hardware implementation form in theFPGA106. Thememory214 may store a real time operating system (RTOS) for execution by theprocessor212. Where the graphical program executes in its native format on thedevice110F, the memory may also store a graphical program execution engine (e.g., LabVIEW RT) that is executed by theprocessor212.
• Thus, in one embodiment, after a graphical program has been created, a portion of the graphical program may be transferred and/or compiled for execution on the on-[0218]board processor212 and executed locally on theRIO card110F via theprocessor212 andmemory214, and a second portion of the graphical program may be translated or converted into a hardware executable format and downloaded to theFPGA106 for hardware implementation. One example of this is a mixed LabVIEW RT/LabVIEW FPGA embodiment, where a first portion of a LabVIEW graphical program executes on a processor and memory (e.g., LabVIEW RT), and a second portion (which may require more real time deterministic operation) executes in the FPGA.
• As mentioned above, as one example, a first portion of a block diagram (that requires real time or fast execution) of a graphical program may be converted into a hardware executable format and downloaded to the[0219]FPGA106 for hardware implementation, and a second portion of a block diagram (that may not require real time performance) may be stored in thememory214 as program instructions and executed by theprocessor212, in either a compiled or interpreted manner. As another example, a portion or all of the block diagram portion of the graphical program may be converted into a hardware executable format and downloaded to theFPGA106 for hardware implementation, and a user interface portion (or front panel portion) of the graphical program may be stored in thememory214 as program instructions and executed by theprocessor212, in either a compiled or interpreted manner. Thus the portion of the graphical program which requires the most real time or deterministic (reliable and consistent) performance may be executed directly in hardware for fast operation, and other parts of the block diagram, or the user interface portion, which may not require real time performance, may execute on theprocessor212. Where theprocessor212 executes the user interface portion, theprocessor212 may then send resulting signals to the video subsystem for display of the user interface on the computer display. The host computer CPU may also execute the user interface portion instead of theprocessor212.
• In one embodiment, the programmable hardware element itself may include a fixed, built-in (“hardcore”) processor, where at least a portion of the measurement program is operable to be executed by the processor. In another embodiment, the programmable hardware element may be configurable to implement a processor (“softcore”) which is operable to execute at least a portion of the measurement program.[0220]
• As mentioned above, the[0221]programmable hardware106 may comprise a field programmable gate array (FPGA) such as those available from Xilinx, Altera, etc. Theprogrammable hardware element106 may be coupled to theDAQ logic204 and may also be coupled to local bus interface208, described above.
• As also mentioned above, in one embodiment, the[0222]RIO card110F also includes anon-volatile memory288, which may be coupled to theprogrammable hardware element106, theprocessor212 and thememory214. Thenon-volatile memory288 may be operable to store the hardware configuration program received from the host computer system to enable execution of the hardware configuration program in theprogrammable hardware element106 prior to or during booting of thecomputer system102. Thenon-volatile memory288 may also store software transferred to thememory214 and used by theprocessor212, such as a RTOS and/or a graphical program execution engine.
• As mentioned above, a typical example of a measurement I/O device or board may include a 16 channel multiplex AI (analog input) in front of an A/D (analog to digital) converter, 2 analog outputs (AO), 8 digital lines, −10 timing/triggering lines, 2 general purpose counters, plus one or more timing/triggering engines. Generally, the timing/triggering engines and digital logic for inter-component communications and for communicating with a host are comprised in an Application Specific Integrated Circuit (ASIC). The ASIC is a fixed functionality integrated circuit, and is thus not generally subject to modification by a user. As also mentioned above, there may be many applications whose requirements don't exactly match this set of resources.[0223]
• In one embodiment of the invention, the programmable hardware element[0224]106 (e.g., the FPGA) of aRIO device110 may partially or completely replace the ASIC, i.e., the onboard digital logic, thereby providing a means to configure or program application specific components as required. For example, in one embodiment, theFPGA106 may couple to an ADC via one or more digital lines. TheFPGA106 may comprise an array of configurable low level digital pins (rudiments) which may be defined or configured to implement digital lines and logic. Thus, by replacing the standard DAQ digital (and optionally, analog) logic in a system or card with a reconfigurable core orprogrammable hardware element106, e.g., an FPGA, the functionality of the system or card may be defined by the configuration of theprogrammable hardware element106. Additionally, the configuration may be downloaded “in the field,” e.g., a pre-compiled configuration may be provided over a network or via wireless means to theRIO device110 and installed on theFPGA106 to implement the desired functionality. In one embodiment, this feature may be used to perform hardware updates on installed equipment remotely, thereby eliminating the need for a human to travel to the site and physically remove and replace the hardware. In another embodiment, new configurations for a hardware product may be defined and deployed after product release. For example, “hardware patches” fixing late bugs or flaws may be used in a similar manner as software patches in software systems.
• For example, the low level digital pins which may be configured to implement digital filters, controls, counters, timing and triggering engines, and/or other digital components. In other words, the digital logic commonly provided by the ASIC may instead be provided by a suitably configured[0225]FPGA106. In this way, the digital logic specifically required by the user (or application) may be configured on the FPGA, thereby providing a “custom fit” of the board or device to the requirements.
• Some examples of functionality which a suitably programmed or configured[0226]programmable hardware element106 may provide include, but are not limited to:
• I/O lines—for example, input lines may be defined and grouped for specific functionality, and may include various counters, custom triggers, etc., as desired. For example, a group of 4 digital input lines may be dedicated for receiving input from an on-board ADC;[0227]
• flexible timing/triggering—may provide higher level control of, organization of, and relationships between configured components, allowing groups of components to operate relatively independently from other groups of components, e.g., one group of components may operate at 1 MHz, while another group of components operates concurrently at 10 MHz; and[0228]
• algorithms—higher level constructs such as control loops, decisions, combinations of control structures, state machine decisions, control of analog and digital read/write operations, time stamps, etc., may provide software like logic and flow with hardware performance.[0229]
• Thus, in one embodiment, the ADC, possibly operating under control of the[0230]programmable hardware element106, may receive analog input from asensor112, and convert the analog signals to digital form. The configuredFPGA106 may receive the digital signals and process them according to the configured logic. The processed digital signals may then be routed to memory, to other components in themeasurement device110, and/or to an external system, such as thecomputer system102. Other fixed hardware resources may also be arranged in the vicinity of theFPGA106, such as DACs (digital/analog converter), DIOs (digital I/O ports), and/or any other type of circuit component.
• In another embodiment, the[0231]FPGA106 may be a mixed signal FPGA. As used herein, the term “mixed signal FPGA” refers to an FPGA which includes both digital gates and analog components. In one embodiment, the analog components may include relatively high-level components such as comparators, DAQs, filters, and ADCs, which may be used in conjunction with the configured digital logic and lines to provide any of a variety of measurement and/or control functions, as described above. In another embodiment, the analog components may include low-level analog components or rudiments such as transistors, op amps, capacitors, inductors, and/or resisters, from which higher-level analog components may be built or configured. Thus, if a user had need for an I/O card comprising an analog Butterworth filter and a 9-bit ADC, such a circuit could be configured on a RIO card ordevice110. Additionally, if at a later time the user's requirements changed, the circuit could be modified to accommodate the new requirements.
• Thus, the use of an[0232]FPGA106 to implement digital logic in a measurement device provides a flexible solution to application specific digital logic requirements. Additionally, the use of a mixed signal FPGA extends the approach to include programmatically configurable analog components, which, in combination with the configurable digital logic, provides a broad, flexible solution approach to measurement and control system development. More specifically, various embodiments of the RIO system may provide improved I/O solutions for real time systems and applications (e.g., LabVIEW RT based applications), providing support, for example, for simultaneous sampling, synchronized AI, AO, DIO, and TIO (timed I/O), and balanced analog I/O, as well as providing a single point architecture. Additionally, RIO may facilitate use of a simplified register map, such as for interfacing with other systems. Finally, as noted above, RIO provides for customized functionality of measurement, control, automation, and simulation hardware, thereby providing the flexibility of software based systems with the performance of hardware.
• FIG. 3C—Programmable Hardware Functionality[0233]
• FIG. 3C illustrates example functionality of a configured programmable hardware element[0234]106 (e.g., an FPGA) in aRIO device110. As FIG. 3C shows, theprogrammable hardware element106 may include a plurality of digital I/O lines, as well as analog output and analog input lines, for communicating with other components or systems. In this example configuration, theFPGA106 includes a start trigger coupled to one of the digital I/O lines, a continuous timed loop comprising a pulse width modulated output coupled to a digital I/O line, and an event counter, coupled to another digital I/O line. Additionally, the continuous timed loop component is coupled to an analog output and two analog inputs, as shown, as well as to a host interface. Thus, theprogrammable hardware element106 is configured to implement a trigger, a control structure (the continuous timed loop), including a counter and PWM digital output, and a host interface, as well as analog I/O.
• FIG. 4—A PXI RIO Card[0235]
• FIG. 4 illustrates a[0236]RIO card110G, according to one embodiment of the invention. As described previously, theRIO card110G includes a programmable hardware element106 (e.g., an FPGA) which is operable to be programmed to perform various measurement and/or control functions, and/or to implement an interface for communicating with ameasurement module108. TheRIO card110G may also include various fixedhardware resources204.
• In this embodiment, the[0237]RIO card110G may also includenon-volatile memory288, usable to store FPGA state information, such as a hardware description and/or an EDS specifying a measurement module interface, or configuration information which implements one or more measurement and/or control functions.
• In this embodiment, the[0238]RIO card110G is a PXI card. In other words, the RIO card is operable to plug into a PXI slot, such as on acomputer system102, or a PXI chassis. As FIG. 4 also indicates, theRIO card110G may include bus interface circuitry, such as aPXI interface410, for coupling to a PXI controller. Of course, the use of other controllers and corresponding interface circuitry is also contemplated, including PCI, VXI, USB, InfiniBand, Ethernet, Wireless (e.g., IEEE 802.11 Wireless Ethernet or Bluetooth), and IEEE 1394 (FireWire), among others. Thus, in one embodiment, the RIO card may be inserted into an expansion slot of a system, such ascomputer system102 or chassis.
• In one embodiment, the[0239]RIO card110G may also include one or moremeasurement module connectors406, each of which may be operable to couple to ameasurement module108, and which may be further usable to receive interface protocol information from themeasurement module108. As described above, theRIO card110G may then be programmed (such as by computer system102) to implement the communicated interface. As mentioned above with reference to FIG. 3B, theRIO110G may include other resources (fixed hardware resources204) besides those shown in FIG. 4, such as signal conditioners and/or converters, analog filters, AO and AI ports, and so forth, as desired. Additionally, as also mentioned above, theFPGA106 may be coupled to various analog components as well, allowing a broad range of functionality to be configured on theRIO card110G for a given application. Finally, theFPGA106 may include low-level analog rudiments, thus allowing the configuration of an even greater number and type of measurement and/or control circuitry.
• In another embodiment, the[0240]RIO card110G may comprise a control board. As one example, theRIO control board110G may be a PXI board running LabVIEW RT. TheRIO control board110G may also include aprogrammable hardware element106. TheRIO control board110G may also include various fixed hardware resources. For example, theRIO control board110G may include analog I/O comprising 8 analog inputs (AI) and 8 analog outputs (AO) operating at a certain frequency, e.g., between 1 kHz and 1 GHz (e.g., −100 kHz), and capable of being simultaneously sampled and/or updated. In this embodiment, the RIO control board also includes 96 digital I/O lines which are synchronous to the AI and AO. Some or all of the digital lines may be consumed by counters and triggers. Exemplary configurations for this board include a continuous timed loop, different counter options, and single point architecture with no buffers. Additionally, the RIO control board may include a flash memory for storing the configuration for the board's programmable hardware element. Finally, for connectivity, the board may use three mini68 pin connectors, or three50 pin ribbon headers (which may reduce the DIO count to 48).
• In yet another embodiment, the[0241]RIO card110G may comprise a digital board having a processor and memory running LabVIEW RT, aprogrammable hardware element106, and fixedhardware resources204 comprising 160 digital I/O lines, various counters and triggers which may consume some or all of the digital lines, flash memory for storing the configuration for the board, and four mini68 pin connectors for connectivity. Exemplary configurations include continuous timed loop, static input/output, different counter options, and single point architecture with no buffers.
• Thus, in one embodiment, the[0242]RIO device110G may be in the form of an adaptive interface card, such as a RIO PXI interface card, which includes aprogrammable hardware element106 which is programmable to implement one or both of measurement and/or control functions and a measurement module interface.
• FIG. 5A—RIO Cartridge Carrier with Measurement Cartridges[0243]
• FIG. 5A illustrates an embodiment of the invention where the[0244]RIO device110 is in the form of a RIO cartridge chassis orcarrier110H, and one or more measurement cartridges (modules)108. TheRIO cartridge carrier110H may comprise one or more slots which are operable to receive the one ormore measurement cartridges108, described in more detail below.
• In one embodiment, the[0245]RIO chassis110H may comprise a chassis, a backplane comprised in the chassis providing for electrical communication, and the one or more slots comprised in the chassis, in addition to theprogrammable hardware element106 described above. Each of the one or more slots may include a connector that is coupled to the backplane, where each of the one or more slots may be adapted for receiving one of themeasurement modules108. Thus, theRIO chassis110H may host a plurality ofmeasurement cartridges108, each of which may provide measurement and/or control functionality for a measurement or control operation or task. Eachmeasurement module108 may include fixedhardware resources204 or aprogrammable hardware element106, or both. TheRIO chassis110 may also be operable to communicate with each measurement cartridge (i.e., module)108 and be programmed or configured (e.g., by a computer system102) to implement the respective interface of eachmeasurement cartridge108. In this manner a suite ofsensors112 may be fielded, each of which feeds signals to arespective measurement cartridge108 which in turn communicates through a respective interface (protocol) with theRIO device110. Thus, theRIO device110 may support a heterogeneous plurality of interfaces without having to include a heterogeneous set of interface hardware components.
• In one embodiment, each measurement module or[0246]cartridge108 may be operable to communicate with theRIO carrier110H via SPI (Serial Peripheral Interface)316, as described with reference to FIG. 5B below, although other interface protocols are also contemplated.
• Additionally, in various embodiments, the[0247]RIO cartridge carrier110H may be operable to provide communications between themeasurement modules108 and external systems. For example, theRIO cartridge carrier110H may include logic to convert proprietary measurement module signal data into a standard format suitable for transmission tocomputer system102. For another example, in one embodiment, theRIO cartridge carrier110H may include an IP address and web server capabilities, and thus may be able to publish received signals or measurement data over the Internet. TheRIO cartridge carrier110H may similarly be operable to receive signal data over the Internet for processing. In another embodiment, one ormore measurement cartridges108 may also have an IP address and web server capabilities, and thus may be able to communicate with remote systems over the Internet, for example, to stream sensor data (e.g., numerical data or images) to a website for access by other systems or users.
• In a preferred embodiment, the measurement modules[0248]108 (or cartridges) may be easily removed, added, and replaced. In other words, measurement modules may be exchanged to change the configuration or capabilities of the measurement system. In one embodiment, themeasurement module108 may be replaced without powering down the measurement system, i.e., themeasurement module108 may be “hot-plugged” into theRIO110. During operation of the measurement system, themeasurement module108 may communicate the interface protocol information to theRIO110 upon attachment, and theRIO110 is programmed in response, as described above. In another embodiment, themeasurement module108 and/orRIO110 may require a reboot or reset after attachment to perform the described initialization.
• For example, during operation of the measurement system, a new measurement module[0249]108 (or cartridge) may be added (i.e., inserted or attached) to theRIO110. The measurement system may automatically perform the initialization described above with respect to the addedmeasurement module108. In other words, during operation of the measurement system, the newly coupledmeasurement module108 may communicate respective interface information to theRIO110, which may then be programmed (e.g., by the computer system102) to implement the respective interface, thereby enabling operations with thenew measurement module108. In one embodiment, thenew measurement module108 may replace another measurement module which was removed during operation of the measurement system.
• Thus, the interface circuitry (i.e., the measurement module[0250]108) may be operable to communicate the interface protocol to theRIO device110 upon one or more of attachment of themeasurement module108 to theRIO device110, reset of themeasurement module108, reset of theRIO device110, reboot of themeasurement module108, and reboot of theRIO device110.
• As FIG. 5A shows, in a preferred embodiment, the measurement module or[0251]cartridge108 may have a small form factor. For example, in one embodiment, themeasurement module108 may have dimensions less than or equal to approximately 1 inch by 2 inches by 3 inches. In one embodiment, themeasurement module108 may have dimensions of approximately 0.2 inches by 1 inch by 1 inch or more. An example form factor for themodule108 is shown in FIG. 5A as having a major dimension of 2 inches. Thus, in a preferred embodiment, themeasurement module108 has a compact form factor which may enable deployment in a variety of devices or carriers with minimal space requirements.
• Thus, in one embodiment, each[0252]measurement cartridge108 may include signal conditioning, ADC, microprocessor, and optional isolation, for sensor to digital operations. Additionally, eachcartridge108 may provide an SPI digital interface with simple protocol, and EDS/calibration history on board. In a preferred embodiment, the cartridges may have low channel counts, e.g., 4-channel analog, 8-channel digital.
• The[0253]RIO cartridge carrier110H is preferably able to convert SPI to standard bus/network signals, and implement power-on states, plug and play, and watchdogs. Additionally, the modules/cartridges108 and/or the cartridge carrier may be provided with application-specific form factors and functionality. In other words, the cartridges and/or the cartridge carrier may be developed specifically to match the customers space and function needs.Example RIO carriers110 may include, but are not limited to, a 4-slot Ethernet carrier (including IEEE 802.11 Wireless Ethernet), a 4-slot and 1-slot USB carrier, a multi-slot RIO carrier, a 1-slot wireless carrier, such as Bluetooth, and a CAN carrier, among others.
• FIG. 5B—RIO Device with Multiple Measurement Modules[0254]
• FIG. 5B is a block diagram of the[0255]RIO measurement system110 of FIG. 5A above, comprising a RIO cartridge chassis orcarrier110H and a plurality ofmeasurement modules108, according to one embodiment. As FIG. 5B shows, the plurality ofmeasurement modules108 may includeanalog input module108A,analog output module108B, and digital I/O module108C, as well asother measurement modules108 not shown. Thus, theRIO cartridge chassis110H may be operable to communicate with eachmeasurement module108 and be programmed or configured (e.g., by a computer system102) to implement the respective interface of eachmeasurement module108. In this manner a suite ofsensors112 may be fielded, each of which feeds signals to arespective measurement module108 which in turn may communicate through a respective interface (protocol) with theRIO110, such as through SPI+316 or any other interface protocol or interface. Thus, theRIO110 may support a heterogeneous plurality of interfaces without having to include a heterogeneous set of interface hardware components.
• It should be noted that in various embodiments, the[0256]RIO110 may be operable to perform other functions in addition to the adaptive interface functionality described above. For example, in one embodiment, theRIO110 may include network control circuitry (or have a programmable hardware element configured to perform network control functions), and thus may comprise a networked measurement and control device, or a networked data acquisition device. In other words, theRIO unit110 may comprise one or more of an Ethernet carrier, a USB carrier, and a wireless carrier (such as IEEE 802.11 Wireless Ethernet or Bluetooth), among others, to facilitate transmission of data over a network to external systems, e.g., thecomputer system102.
• As FIG. 5B shows, the[0257]RIO cartridge carrier110H may also be operable to communicate with and through any of a variety of external systems and protocols, including, but not limited to, pass-through SPI+(breakout/cable to FPGA board); board bus (PXI, PC-104, InfiniBand, etc.); Bluebus/FieldPoint adapter; network adaptors such as Ethernet, USB, CAN, and RS-232/485; wireless adapters such as 802.11B (Wireless Ethernet) and Bluetooth; handheld/PDA adapters such as Springboard, cradle, etc., and smart sensor modules, among others.
• FIG. 6—Measurement Module and RIO Architecture[0258]
• FIG. 6 is a block diagram of an architecture for a[0259]RIO system110 which includes ameasurement module108 and a RIO carrier110I. In this embodiment, theRIO carrier1101 includes not only the adaptive interface functionality described above, but also includes capabilities for performing one or more measurement and/or control functions.
• As FIG. 6 shows, the measurement system may include[0260]measurement module108, which may couple to the RIO carrier110I through one or more communication lines or terminals, as shown. The RIO carrier110I may in turn be operable to couple to any of various products orplatforms620, as indicated.
• In one embodiment, the[0261]measurement module108 may includeconnectors301 for (analog) signal I/O, i.e., for communicating with a sensor oractuator112. As shown, theconnectors301 may couple to signalconditioning circuitry302, which in this embodiment includes a signal conditioner and a MUX. Thesignal conditioning circuitry302 may couple to signal conversion circuitry, such as theADC304 shown, which may in turn couple toisolation circuitry305, which may protect the module components from spurious voltage or current surges and mismatched impedances. In this embodiment, themeasurement module108 also includes anEEPROM606 containing an EDS which may be operable to communicate the interface protocol information to theRIO carrier1101, as described above. Thus, themeasurement module108 may provide a physical connection between the sensor oractuator112 and the RIO carrier110I, as well as signal conditioning, digitization, and isolation functions for the measurement system. In addition, in one embodiment, themeasurement module108 may provide identification (for Plug-and-Play (PnP)) and/or digital I/O (parallel and/or serialized) functionality.
• As indicated in FIG. 6, the RIO carrier[0262]110I may includeprogrammable hardware element106, e.g., FPGA, which may be programmable to implement the interface specified by themeasurement module108, as described in detail above. In this embodiment, the RIO carrier110I may also include aregister set612, through which communication with the products/platforms may be effected. In various embodiments, the RIO carrier110I may provide additional functions which may include I/O scanning, timing and triggering, power-on states, logic, digital I/O timing/counting, data transfer and support for parallel and scanned backplanes, among others.
• Thus, in the RIO system, the[0263]FPGA106 may be configurable with measurement and/or control functions. Thus theFPGA106 may perform measurement/control functions instead of, or in addition to, thecomputer system102.
• The products and[0264]platforms620 indicated in FIG. 6 may provide means for theRIO carrier1101 to communicate with external systems. For example, an Application Programming Interface (API)622 may allow external systems to read and/or write to the registers in the register set612 to communicate and/or control the measurement system. For another example, a processor, e.g., amicro-controller624, and anetwork interface card626 may couple the registers to anetwork104, through which communications with external systems may be facilitated. In one embodiment, the products andplatforms620 may be comprised in theRIO110, while in other embodiments the products andplatforms620 may be external to theRIO110, e.g., may be comprised incomputer system102.
• In one embodiment, the[0265]RIO110 may comprise or be coupled to a Personal Digital Assistant (PDA). Thus the PDA may comprise theRIO110 and may include one or more slots formeasurement modules108. In other words, the PDA may itself be the RIO carrier. Alternatively, theRIO device110 may be in the form of an optionally detachable RIO module, which may in turn couple to ameasurement module108. Themeasurement module108 may in turn be operable to couple to a sensor or actuator, as described above. In one embodiment, the PDA may be operable to program the RIO110 (i.e., the RIO's programmable hardware element106) with the interface protocol information provided by themeasurement module108, as described in detail above. Alternatively, the PDA may be programmed as theRIO carrier110. In one embodiment, the PDA may be further operable to provide functionality related to a measurement and/or control task or operation. In another embodiment, the PDA may be used as an interface to anothercomputer system102. For example, a suitably equipped PDA may provide wireless communication for theRIO10/measurement module108.
• FIG. 7—RIO System with External I/O Expansion[0266]
• FIG. 7 illustrates several embodiments of the invention using a[0267]RIO card110 with external I/O expansion, i.e., with additional I/O connections for coupling to a plurality ofmeasurement modules108. As FIG. 7 shows, a RIO cartridge orcard110 may provide connectors for analog I/O710 and/or digital I/O720. As may be seen, without the use of expansion I/O devices, the number ofmeasurement modules108 which may be coupled to theRIO card110 may be limited, e.g., to one.
• In one embodiment, the digital I/[0268]O720 may couple to abreakout backplane704, for example, via parallel SPI buses730, as shown, although other buses for coupling the I/O expansion devices to theRIO110 are also contemplated. Thebreakout blackplane704 may provide connectivity for a plurality of measurement module cards orcartridges108, and may thereby be operable to facilitate external, synchronized, and conditioned I/O750 for the measurement system. For example, each measurement module orcartridge108 comprised in or on thebreakout backplane704 may be operable to couple to a sensor oractuator112. Eachmeasurement module108 may also couple to thebackplane704. Thebreakout backplane704 may then facilitate synchronization between thevarious measurement modules108. Additionally, as described above, themeasurement modules108 may provide any of a variety of DAQ, measurement, and control functions, including signal conditioning and conversion, and thus external, synchronized, and conditioned I/O750 capabilities may be included in this embodiment of the invention.
• In another embodiment, the RIO card or[0269]device110 may couple to anaddressable backplane706, for example, through an SPI with slotselect capabilities740. In other words, theaddressable backplane706 may provide a plurality of individually addressable slots for a plurality of measurement modules orcartridges108, described above, which may each be individually targeted for communication by theRIO110. Additionally, theaddressable backplane706 may be expandable, i.e., additionaladdressable backplanes706A may be coupled to theaddressable backplane706 to provide additional slots foradditional measurement modules108. Thus, in this embodiment, expandable, conditioned I/O capabilities760 may be provided by the system.
• In yet another embodiment, the RIO card or[0270]device110 may couple to a “DAQ in the cable”708, where ameasurement module108 may be comprised in a cable connector. In other words, the features of ameasurement module108, as described above, may be included in one or both connectors of a cable, as shown. For example, in the example of DAQ incable708A, one end of the cable may be coupled to theRIO device110, and the measurement module/connector108 may be operable to couple to a sensor oractuator112. In another example, the DAQ incable708B may comprisemeasurement module108 which may be operable to couple to theRIO card110, and another cable connector (without a measurement module108) for coupling to a sensor/actuator112.
• Thus, in various embodiments, the functionality of one or[0271]more measurement modules108 may be provided through the use of I/O expansion devices (e.g.,devices704,706, and708) which may extend the I/O capabilities of theRIO device110. Furthermore, in some embodiments, additional functionality may be provided by the expansion device, such as the ability to synchronize the I/O.
• FIG. 8—Platforms and Technology[0272]
• FIG. 8 illustrates embodiments of the present invention in the context of current art with respect to platforms, DAQ architectures/engines, and signal conditioning. As FIG. 8 shows, a plethora of different measurement and/or control systems may be developed using various combinations of[0273]base platforms802, DAQ architectures/engines804, and signal conditioning devices orsystems806. In particular the broad application of RIO technology is illustrated.
• For example, any of a number of[0274]base platforms802 may be used to provide a connectivity infrastructure for the system, including, but not limited to,PXI811,PCI812, DAQPads813 (from National Instruments) which may utilize USB,1394, etc.,FieldPoint814, smallnetworked measurement nodes815, and PDAs/handheld computers816.
• DAQ architectures/[0275]engines804 which may be selected include, but are not limited to, the National Instruments E Series ofDAQ devices810, FieldPoint/BlueBus818, andRIO devices110 and110A (or other RIO embodiments).
• [0276]Signal conditioning technologies806 which may be used in such systems include (but are not limited to) National Instruments SCXI 820,SCC 822, and 5B 824 signal conditioners, as well as FieldPoint/BlueBus compliant signal conditioners, andmeasurement modules108, such as National Instruments measurement modules.
• As FIG. 8 indicates, components or standards may be selected from each class of component ([0277]platforms802,engines804, signal conditioners806), and, depending on compatibility, combined to develop a wide variety of measurement systems. For example,E Series engines810 may be combined with a PXI platform803, a PCI platform805, and/or a DAQPads platform807, and may further be combined with SCXI 820,SCC 822, and SB 824 signal conditioners, while the FieldPoint/BlueBus engine812 (which also provides signal conditioning functionality) may only be combinable with the FieldPoint platform808.
• In contrast, it is contemplated that the RIO engine/architecture may be combined with all of the listed[0278]platforms802, i.e.,PXI platform811,PCI platform812, DAQPads platform813,FieldPoint platform814, smallnetworked measurement nodes815, and PDA/handhelds816), as well as other platforms not shown, e.g., InfiniBand, USB, 1394/FireWire, etc. Note that use of the RIO engine/architecture facilitates combinations with RIOsignal conditioning devices110 andmeasurement modules108, respectively, for signal conditioning functions806, as shown. The RIO engine/architecture may also be used with any of thesignal conditioning options806 shown in FIG. 8, including SCXI, SCC, 5B, Fieldpoint/Bluebus, and other types of signal conditioning or measurement modules.
• In one embodiment, the combination of a[0279]RIO device110 withmeasurement modules108 is generally capable of providing any of various desired capabilities.
• The RIO technology may be implemented or comprised in any of various platforms. For example, a[0280]RIO device110 may be included in a smart sensor. In another embodiment, theRIO device110 may include wireless logic for wireless communication with external systems, includingsensors112 and/orcomputer systems102. In another embodiment, theRIO device110 may include an interface for industrial automation, i.e., an industrial automation interface bus, such as CAN, Devicenet, and Fieldbus, among others.
• Thus, the use of[0281]measurement modules108 andvarious RIO units110 may provide complementary and overlapping functionality as compared to current approaches to development of measurement systems, and may also provide substantial cost, efficiency, and flexibility benefits. In particular, the use ofRIO devices110 and/ormeasurement modules108 leverages semiconductor technology to deliver highly modular measurement, control, and signal conditioning/conversion functionality which may be reusable in many platforms, e.g., USB, Ethernet, FieldPoint, RIO, PDAs, etc., and which may lower risk and effort in supporting new platforms, such as wireless, CAN, etc.
• FIG. 9—RIO Design Flow[0282]
• FIG. 9 illustrates design flow of a[0283]RIO system110, according to one embodiment. As FIG. 9 shows, in one embodiment in902 a program may be designed and debugged, such as oncomputer system102. The program may specify or describe a measurement function. As mentioned above, a measurement function may include any measurement (including data acquisition) or control task or function. The program created in902 may itself be executable, as opposed to being merely a specification. For example, the program may be compilable or interpretable to implement the measurement function on a computer system. In the preferred embodiment, the program may comprise a graphical program, i.e., the program may comprise a plurality of interconnected nodes which visually indicate functionality of the graphical program, such as a LabVIEW VI (Virtual Instrument). In another embodiment ofstep902, the user may create a program in a text-based programming language such as C, C++, Java, VisualBasic, Pascal, Fortran, etc.
• In another embodiment of[0284]step902, the user may specify functionality of a measurement function using a high level wizard, as described herein, wherein a hardware configuration program may be created directly (or indirectly) from this user input. An example of a high level wizard for specifying tasks is IMAQ VisionBuilder from National Instruments Corp. As an example of indirect creation of a hardware configuration program from wizard-based user input, a program may first be created based on the user input, and the hardware configuration program may then be created from this program. For example, in one embodiment a program may be programmatically created in response to user input received to a wizard-like interface, as described in U.S. patent application Ser. No. 09/886,455 titled “System and Method for Programmatically Generating a Graphical Program in Response to User Input”, which was incorporated by reference above. The hardware configuration program may then be programmatically created from this program. Further embodiments of a configuration wizard are described below with reference to FIGS.18-21.
• The host computer system may execute an application development environment (ADE) for creating the program to be deployed onto the[0285]RIO device110. Input to the ADE may be textual, graphical, a hardware description language, may be through a configuration environment (e.g., a wizard) or an API structural description, among others.
• In the embodiment described in FIG. 9, the user specifies the measurement function by creating a graphical program. In one embodiment, the graphical program may be designed in a graphical development environment, such as LabVIEW or LabVIEW FPGA. In the preferred embodiment, the graphical program may be developed in the G graphical programming language in the form of a graphical block diagram. The graphical program may then be converted to a hardware configuration program. In one embodiment, the graphical program may first be converted to source code in a text-based programming language, followed by conversion of the text-based source code to a hardware configuration program. The graphical program may be debugged in a simulation mode, as described below with reference to FIGS. 14 and 15.[0286]
• Creation of a graphical program may comprise the user arranging on a display a plurality of nodes or icons and then interconnecting the nodes to create the graphical program. In response to the user assembling the graphical program, data structures may be created and stored which represent the graphical program. The nodes may be interconnected in one or more of a data flow, control flow, or execution flow format. The graphical program may thus comprise a plurality of interconnected nodes or icons which visually indicates the functionality of the program. As noted above, the graphical program may comprise a block diagram and may also include a user interface portion or front panel portion. Where the graphical program includes a user interface portion, the user may assemble the user interface on the display. As one example, the user may use the LabVIEW graphical programming development environment to create the graphical program.[0287]
• In an alternate embodiment, the graphical program may be created by the user creating or specifying a prototype using a prototyping environment, followed by automatic or programmatic creation of the graphical program from the prototype. This functionality is described in U.S. patent application Ser. No. 09/587,682 titled “System and Method for Automatically Generating a Graphical Program to Perform an Image Processing Algorithm”, which is hereby incorporated by reference in its entirety as though fully and completely set forth herein. The graphical program may be created in other manners, either by the user or programmatically, or a combination thereof, as desired. The graphical program may implement a measurement function that is desired to be performed by the instrument.[0288]
• In[0289]904, the program (e.g., the graphical program), or a portion of the program, may be compiled to a hardware configuration program (e.g., for an FPGA). In other words, the program (or a portion thereof) may be compiled on thehost computer system102, targeting theFPGA hardware106. In one embodiment, the measurement function specified by the program or user input in902 may be designed to be deployed among multiple distributed devices, such as multiple programmable hardware elements106 (and optionally processors and/or fixed hardware resources) on asingle RIO unit110, one or more programmable hardware elements106 (and optionally processors and/or fixed hardware resources) on each of a plurality of distributedRIO units110, or combinations of the above with smart sensors, measurement modules, instruments and/orcomputer systems102. Thus different portions of the program or user input specifying the measurement function may be deployed for implementation on various distributed devices, including one ormore RIO units110, smart sensors, measurement modules, instruments, andcomputer systems102, among other devices. Within eachRIO unit110, different portions of the measurement function may be deployed to one or moreprogrammable hardware elements106, one or more processors and memory (software execution), and/or various fixed hardware resources.
• In one embodiment, in[0290]902 the user may be able to specify which distributed devices will execute which portions of a measurement function. For more information on a method for creating, deploying, and/or executing programs in a distributed system, please see U.S. patent application Ser. No. 06/312,242 titled “System and Method for Graphically Creating, Deploying and Executing Programs in a Distributed System” filed on Aug. 14, 2001, whose inventors are Jeffrey L. Kodosky, Darshan Shah, and Steven W. Rogers, which was incorporated by reference above. In an alternate embodiment, a deployment program (also called an optimization program) may examine user input to a wizard or a program created by the user in902 and may automatically or programmatically specify which distributed devices will execute which portions of a measurement function. The deployment program may then automatically deploy the program accordingly.
• In one embodiment where different graphical programs are deployed among multiple distributed devices, the graphical programs may be configured to communicate and interoperate with each other to perform the measurement function. For example, a block diagram executing on the host computer may be configured to communicate with a block diagram executing on a programmable hardware element of a RIO unit. As one example, a block diagram executing on a programmable hardware element may be a subprogram of the block diagram executing on the host computer. Where a measurement function is distributed among a plurality of devices, a plurality of block diagrams may be distributed among the various devices. The block diagram executing on the host computer system may operate to control the various block diagrams distributed among the various devices. The block diagram executing on the host computer may include one or more nodes which are configured to communicate with one or more nodes executing in a block diagram on the programmable hardware element. More generally, the block diagram executing on the host computer may include one or more nodes which are configured to communicate with one or more nodes executing in various block diagrams distributed on various different devices.[0291]
• In one embodiment, the compilation of a program into a hardware configuration program may be performed on a client/server system or architecture due to long compile times (e.g., minutes to hours) typical for hardware implementations. Said another way, because of long compile times, the compiling may be performed on a different (server) computer (different from the host computer used to specify the measurement function in[0292]902) which is coupled to the host computer system102 (client), to avoid having to use the CPU resources of thehost computer system102. Compiling the program preferably produces an FPGA hardware configuration program which is operable to be deployed on the targetedFPGA106. As noted above, portions of the program may optionally be deployed to various devices, as desired.
• In one embodiment, the[0293]host102 and/or development environment may maintain a cache for storing one or more pre-compiled portions of the program, so that successive compiles may be performed more quickly than the original compilation. In other words, in one embodiment, incremental compilation may be supported. In another embodiment, thehost102 and/or development environment may support a graphical program differencing or “diff” method for detecting changes in graphical programs. An example of a graphical program “diff” application is described in U.S. Pat. Nos. 5,974,254 and 6,138,270, which are incorporated herein by reference as though fully and completely set forth herein. The graphical program diff method may detect differences in two graphical programs (e.g., successive versions of the same graphical program), and only the differences may need to be compiled.
• Then, in[0294]906, the hardware configuration program may be downloaded or deployed onto theFPGA106. In one embodiment, downloading the hardware configuration program onto theFPGA106 may also include storing the hardware configuration program in a non-volatile memory coupled to theFPGA106.
• In one embodiment, the hardware configuration program may be downloaded or deployed onto the[0295]FPGA106 using graphical or iconic techniques. For example, a hardware configuration program icon may represent the hardware configuration program, and a device icon may represent the RIO device or the RIO FPGA. The user may associate, e.g., drag and drop, the hardware configuration program icon with the device icon to deploy the hardware configuration program onto the device. For example, the user may drag and drop the hardware configuration program icon onto the device icon to effect the deployment. In another embodiment, the graphical program created in902 may be represented by a program icon. The user may associate, e.g., drag and drop the program icon representing the graphical program with the deice icon representing theprogrammable hardware element106. This association or drag and drop of a graphical program icon onto a device icon may initiate the appropriate compile process to occur (possibly on a separate computer), followed by the deployment. In another embodiment, the processor, FPGA and/or fixed hardware resources of a RIO device may each be represented as separate icons. The user may drag and drop different portions of the graphical program onto each of the processor, FPGA, and fixed hardware device icons to deploy different portions of the graphical program to these different resources.
• In another embodiment, a distributed system may include a plurality of devices, such as a plurality of programmable hardware elements on a single RIO device, one or more programmable hardware elements on a plurality of RIO devices, as well as other devices, such as computer systems, etc. A computer system may display a configuration diagram that includes RIO device icons and other device icons for the various devices in the distributed system. The user may use iconic association drag and drop techniques (or use other graphical techniques, such as menus, speech recognition, etc.) to graphically move graphical program icons or hardware configuration program icons onto various device icons, thereby deploying graphical programs or compiled hardware configuration programs (or portions thereof) onto different devices.[0296]
• Thus, the (graphical) program may be deployed on the[0297]programmable hardware element106 of theRIO measurement device110, as described insteps904 and906. After the deployment of the program theprogrammable hardware element106 implements the measurement function of the program. In other words, theprogrammable hardware element106 is operable to perform the measurement function represented by the program. As mentioned above, the measurement function may include measurement (including data acquisition) and/or control functions, as desired.
• In an embodiment where the programmable hardware element is an FPGA, deploying the program on the programmable hardware element of the device may include converting the program into a hardware description, such as a VHDL file, which may be compiled and used to program the FPGA to perform the measurement function. For example, the hardware description may be converted into an FPGA-specific netlist which describes the components required to be present in the hardware as well as their interconnections. Conversion of the hardware description into the FPGA-specific netlist may be performed by any of various types of commercially available synthesis tools, such as those available from Xilinx, Altera, etc. The netlist may be compiled into an FPGA program file, also referred to as a software bit stream, which can be readily downloaded to program the FPGA. After the netlist has been compiled into an FPGA program file the FPGA program file may be transferred to the FPGA, thereby producing a programmed hardware equivalent to the program. Further details of the deployment of the program on the[0298]programmable hardware element106 are presented below with reference to FIGS. 12 and 13.
• After the hardware configuration program has been deployed on the[0299]FPGA106 of the RIO unit, theRIO unit110 may optionally be disconnected from the computer system (or from a network) and may be operated in a stand-alone mode. For example, theRIO device110 may be a card comprised in a chassis. TheRIO card110 may be removed from the chassis and operated in a stand-alone fashion to perform the measurement function. TheRIO device110 may alternatively be a small form factor device which includes a small housing, wherein the programmable hardware element and the fixed hardware resources are comprised in the housing. This device may be disconnected from the computer system (or from a network) and may be operated in a stand-alone mode. In one embodiment, the target device for the hardware configuration program is a standalone FPGA, e.g., an FPGA on a customer's board.
• Finally, in[0300]908, the deployed hardware configuration program may be executed on theFPGA106 to perform the functionality of the application, e.g., the measurement function. Said another way, the RIO measurement system may perform the measurement function via execution of the program by the programmable hardware element on the device, i.e., theRIO110. During execution of theFPGA106, theFPGA106 may invoke functionality of one or more fixed hardware resources comprised on theRIO110 or external to theRIO110. It is noted that in various embodiments, theFPGA106 may perform the functionality of the application in conjunction with one or more of thehost computer system102, one or more sensors and/or one ormore measurement modules108.
• In one embodiment, the block diagram may be converted to VHDL and then maybe executed using a VHDL simulator. This allows execution of the block diagram in the host computer without requiring a lengthy compile time.[0301]
• FIG. 10—A Method for Performing a Measurement Function[0302]
• FIG. 10 is a flowchart of a method for performing a measurement function, according to one embodiment of the present invention. As noted above, in some embodiments, various of the steps may occur concurrently, in a different order than shown, or may be omitted. Furthermore, one or more additional steps may be performed as desired.[0303]
• In[0304]1002, a signal may be acquired. For example, a sensor coupled to or comprised in a RIO unit may acquire the signal. The signal may originate from asensor112, or may be transmitted from an external system.
• In[0305]1004, theRIO unit110 may perform one or more of signal conditioning and signal conversion on the acquired signal. In performing the signal conditioning and/or signal conversion on the acquired signal, theRIO unit110 may generate data, e.g., results data, which may include one or more of the original signal, the conditioned and/or converted signal, or information derived from or generated in response to the signal.
• In one embodiment, the signal conditioning and/or signal conversion may be performed by one or more[0306]fixed hardware resources204 comprised on the RIO unit, as described above. In another embodiment, the signal conditioning and/or signal conversion may be performed by a measurement module, as described below in1114 of FIG. 11B. In yet another embodiment, the signal conditioning and/or signal conversion may be performed by theprogrammable hardware element106 on theRIO unit110. In other words, theprogrammable hardware element106 may be programmed or configured to perform the signal conditioning and/or signal conversion, utilizing the programmable digital and/or analog aspects of the programmable hardware element106 (e.g., the FPGA).
• Then, in an embodiment where a programmable hardware element on the[0307]RIO110 has been programmed or configured appropriately, in1008, the RIO110 (i.e., the programmable hardware element on the RIO110) may perform a measurement function, e.g., on the signal or data. In other words, theRIO110 may perform a measurement function which was programmed into the programmable hardware element. For example, the RIO110 (i.e., the programmable hardware element on the RIO110) may perform any of various data processing operations on the data, such as filtering, pattern recognition, or other analysis. For another example, the RIO may generate control signals in response to an analysis of the data, such as to control one or more plant operations. It should be noted that in performing the measurement function, theRIO110 may utilize some or all of the fixedhardware resources204 to perform portions of the function.
• In another embodiment in which the[0308]computer system102 comprises measurement software for performing a measurement function, in response to1064 above, theRIO unit110 may provide the data to thecomputer system102, as indicated in1010. Then, in1012, thecomputer system102 may perform the measurement function, e.g., on the signal, where the measurement function may include, measurement (including data acquisition) and/or control functions, as described above.
• In yet another embodiment, the[0309]RIO unit110 may perform a substantial portion of the measurement function, as indicated in1008, then pass the results to thecomputer system102, as shown in1010, after which thecomputer system102 may perform the remainder of the measurement function. For example, after a first pass measurement analysis by theRIO unit110, the computer system may perform further analysis on the signals and perform control decisions, and/or generate control signals, and/or log or store results to file.
• FIG. 11A—Method for Configuring a Measurement System[0310]
• FIG. 11A is a flowchart of a method for configuring a measurement system, according to an embodiment where the RIO device or[0311]unit110 couples to a measurement module. This embodiment corresponds to the embodiments shown in FIGS. 5A, 5B,6 and7. It should be noted that in some embodiments, various of the steps may occur concurrently, in a different order than shown, or may be omitted. Furthermore, one or more additional steps may be performed as desired.
• As FIG. 11A shows, in[0312]1102 ameasurement module108 may be coupled to aRIO unit110. For example, themeasurement module108 may be coupled to theRIO unit110 via a serial bus, a parallel bus, wireless transmission medium, a network, edge connector, or any other communication medium. In a typical embodiment, themeasurement module108 is a card or cartridge that can be inserted into a slot of theRIO unit110. In this embodiment, theRIO unit110 may comprise a chassis having a plurality of slots adapted to receivedifferent measurement modules108.
• In[0313]1104, theRIO unit110 may be coupled to acomputer system102. In one embodiment, theRIO unit110 may be coupled to thecomputer system102 via a serial bus such as an SPI cable. In other embodiments, theRIO unit110 may be coupled to thecomputer system102 through various communication media, including, but not limited to, a serial bus, a parallel bus, wireless transmission medium, a network, edge connector, or any other communication medium. In another embodiment, theRIO unit110 may include computer system functionality, e.g., theRIO unit110 may include a functional unit that performs a desired processing function. Similarly, in another embodiment, another of the measurement modules108C inserted into theRIO unit110 may include computer system functionality, i.e., the measurement module108C may itself be a “computer on a card” or a “computer on a chip”, and thus may comprise thecomputer system102. In these embodiments,step1104 may be unnecessary.
• In[0314]1106 themeasurement module108 may communicate interface information to theRIO unit110, where the interface information specifies an interface for operating with themeasurement module108. For example, as noted above, the interface information may be in the form of an EDS (Electronic Data Sheet) structure.
• In[0315]1108, theRIO unit110 may communicate the interface information to thecomputer system102. Alternatively, themeasurement module108 may communicate the interface information directly to thecomputer system102, thus steps906 and908 may occur as a single step, where the communication bypasses theRIO unit110. Note that in the embodiment mentioned above where the module108C comprises thecomputer system102, the interface information may be communicated from themeasurement module108 to the module108C (the computer system102) either directly, or through theRIO unit110.
• Finally, in[0316]1110, thecomputer system102 may program aprogrammable hardware element106 on theRIO unit110, thereby implementing the specified interface in theRIO unit110. After theRIO unit110 has been programmed, theRIO unit110 and the measurement module108 (and optionally the computer system102) may be together operable to perform a measurement and/or control task or function.
• In one embodiment, the method may further include the[0317]RIO unit110 and themeasurement module108 together performing the task or function.
• FIG. 11B—Another Method for Performing a Measurement Function[0318]
• FIG. 11B is a flowchart of a method for performing a measurement function, according to one embodiment of the present invention. FIG. 11B illustrates an embodiment where the[0319]RIO unit110 has been programmed with interface information as described in FIG. 11A. As noted above, in some embodiments, various of the steps may occur concurrently, in a different order than shown, or may be omitted. Furthermore, one or more additional steps may be performed as desired.
• In[0320]1112, a signal may be acquired. For example, ameasurement module108 coupled to or comprised in a RIO unit may acquire the signal. The signal may originate from a sensor oractuator112, or may be transmitted from an external system.
• In[0321]1114, themeasurement module108 may perform one or more of signal conditioning and signal conversion on the acquired signal, as described in more detail above. In performing the signal conditioning and/or signal conversion on the acquired signal, themeasurement module108 may generate data, e.g., results data, which may include one or more of the original signal, the conditioned and/or converted signal, or information derived from or generated in response to the signal.
• In[0322]1116, themeasurement module108 may provide the data to theRIO unit110 according to an interface protocol, as described above.
• Then, in an embodiment where a programmable hardware element on the[0323]RIO110 has been programmed or configured appropriately, in1008, the programmable hardware element on theRIO110 may perform a measurement function, e.g., on the signal or data. In other words, theRIO110 may perform a measurement function which was programmed into the programmable hardware element. For example, the RIO110 (i.e., the programmable hardware element on the RIO110) may perform any of various data processing operations on the data, such as filtering, pattern recognition, or other analysis. For another example, the RIO may generate control signals in response to an analysis of the data, such as to control one or more plant operations.
• In another embodiment in which the[0324]computer system102 comprises measurement software for performing a measurement function, in response to1116 above, theRIO unit110 may provide the data to thecomputer system102, as indicated in1010. Then, in1012, thecomputer system102 may perform the measurement function, e.g., on the signal, where the measurement function may include, measurement (including data acquisition) and/or control functions, as described above.
• In yet another embodiment, the[0325]RIO unit110 may perform a substantial portion of the measurement function, as indicated in1008, then pass the results to thecomputer system102, as shown in1010, after which thecomputer system102 may perform the remainder of the measurement function. For example, after a first pass measurement analysis by theRIO unit110, the computer system may perform further analysis on the signals and perform control decisions, and/or generate control signals, and/or log or store results to file.
• FIG. 12—Conversion of a Graphical Program into a Hardware Configuration Program[0326]
• FIG. 12 is a block diagram illustrating the conversion of a graphical program, such as a graphical image processing or machine vision program, into hardware and software descriptions, i.e., the deployment of the program, as mentioned above in step[0327]1014 of FIG. 10B. The conversion may be performed by one or more deployment or conversion programs, preferably executing on thecomputer system102. Thegraphical program1200 may comprise graphical code, such as interconnected function nodes or icons. The graphical code in the graphical program may use graphical data flow, graphical control flow and/or graphical execution flow constructs, as noted above. On a display, the graphical program may be represented as interconnected icons or function nodes. In the memory of the computer system, thegraphical program1200 may comprise data structures (or scripts or code) representing functional operations, data flow, control flow, and/or execution order. As the user assembles the graphical program on the display, e.g., by selecting, arranging, and connecting various icons or function nodes on the display, the data structures (or scripts or code) may be automatically created and stored in memory. It should be noted that although a conversion of a graphical program into hardware and software descriptions is described, a text based program may similarly be converted into hardware and software descriptions.
• The[0328]graphical program1200 may be created with various development tools. For example, the graphical program may be created using the following development systems: LabVIEW, BridgeVIEW, DASYLab, Visual Designer, HP VEE (Visual Engineering Environment), Snap-Master, GFS DiaDem, ObjectBench, Simulink, WiT, Vision Program Manager, Hypersignal, VisiDAQ, VisSim, Truly Visual, and Khoros, among others. In the preferred embodiment,graphical program1200 is a LabVIEW graphical program or virtual instrument (VI).
• In one embodiment, programs of the present invention may create a[0329]VDiagram tree1202 from the data structures of thegraphical program1200. TheVDiagram tree1202 is an abstract hardware graph which represents at least a portion of thegraphical program1200. The graph may be organized in a way that facilitates the generation of specific types of descriptions by back end programs of the present invention. In one embodiment, the graphical programming system automatically creates and stores a VDiagram tree1202 (abstract hardware graph) in response to a user's creation of a graphical program. In this instance, conversion from graphical program data structures to a VDiagram tree is not necessary.
• A[0330]hardware description1204 may be generated from theabstract hardware graph1202 by a back end program. Thehardware description1204 may be in any of various hardware description languages such as VHDL, EDIF, and Verilog. In the preferred embodiment, thehardware description1204 comprises one or more VHDL files. Ahardware netlist1206 may be generated from the hardware description using various synthesis tools. As noted above, the term “netlist” comprises various intermediate hardware-specific description formats comprising information regarding the particular hardware elements required to implement a hardware design and the relationship among those elements. In the preferred embodiment, thehardware netlist1206 is an FPGA-specific netlist. Thehardware netlist1206 is used to create a hardware configuration program1208. The hardware configuration program1208 may be used to configure one or more functional hardware devices or hardware elements which are configured to execute the portion of thegraphical program1200 that is represented by theabstract hardware graph1202.
• The hardware element configured with the hardware configuration program may comprise any of various devices. For example, the hardware may comprise a programmable logic device (PLD) such as an FPGA or CPLD. However, in other embodiments, the hardware may comprise other types of hardware devices, such as a traditional circuit board which is created using the hardware netlist (i.e., in accordance with the netlist). In the preferred embodiment, the hardware is an interface card comprising an FPGA, where the interface card is comprised in the computer system where the[0331]graphical program1200 is created. The hardware may also be comprised in an external device connected to the computer system where thegraphical program1200 is created. The hardware may be connected to the computer over an external serial or parallel bus, or over a network, such as the Internet.
• FIG. 13—Block Diagram of Conversion of a Graphical Program into a Hardware Description for an FPGA[0332]
• FIG. 13 illustrates the exportation of at least a portion of a[0333]graphical program1200 into a hardware description and the use of the hardware description to program an FPGA, i.e., the deployment of the program, as mentioned above insteps904 and906 of FIG. 9. As mentioned above with reference to FIG. 12, the exportation may be performed by one or more deployment or conversion programs, preferably executing on thecomputer system102. As also described above with reference to FIG. 12, theVDiagram tree1202 shown in FIG. 13 comprises information representing thegraphical program1200, including the functional operations of the program. As described in detail below, the VDiagram tree comprises VDiagrams, each of which may maintain a list of components. This list of components may include components which represent functional operations.
• A back end program converts the[0334]VDiagram tree1202 to ahardware description1204. Back end programs may implement the functionality of the components in the VDiagram component lists using constructs of their respective description languages. For example, a VHDL back end may create VHDL code to implement a component that performs a particular mathematical algorithm such as an exponential calculation. However, in one embodiment, such functional components are simply referenced as library components.
• FIG. 13 illustrates one embodiment in which the VDiagram tree references one or more library components. One embodiment of the present invention comprises[0335]pre-compiled function blocks1302 which implement these library components for particular hardware devices such as FPGAs. Various FPGA netlist synthesis tools may be called or used to generate anFPGA netlist1206A from thehardware description1204. These synthesis tools may incorporate thepre-compiled function blocks1302 into theFPGA netlist1206A. Also, as shown, the synthesis tools may utilize hardware target-specific information1304 in creating the netlist. For example, the exact form that the FPGA netlist takes may depend on the particular type of FPGA that will use the netlist, since FPGAs differ in their available resources.
• An FPGA bit stream program file (hardware configuration program)[0336]1307 may be generated from theFPGA netlist1206A using readily available synthesis tools. ThisFPGA program file1307 may be uploaded to anFPGA1308. TheFPGA1308 may be comprised in a hardware device such as an interface board. After being programmed with theprogram file1307, the FPGA is able to execute the portion of thegraphical program1200 that is exported to thehardware description1204. If the entire graphical program is not exported to the hardware description, then a portion of the program may execute on the general purpose CPU of the computer system. This portion preferably comprises the supervisory control and display portion of the program.
• FIG. 14—Block Diagram of a RIO FPGA Layout[0337]
• FIG. 14 is a block diagram of a RIO FPGA layout, according to one embodiment of the invention. As FIG. 14 shows, the[0338]FPGA106 may be configured to include a number of I/O and timed I/O elements for sending and receiving signals. TheFPGA106 may also be configured to include one or more of a bus, memory, such as a FIFO, a RTSI real time triggering bus, as is well known in the art, and a clock, as FIG. 14 shows. Furthermore, theFPGA106 may include various configured features or components (Feature1-Feature4) which may be provided by the vendor, e.g., from a library of pre-defined functions, described below. As FIG. 14 also shows, theFPGA106 may be configured with basic services and environment functionality which may be operable to perform various basic, infrastructure, or support services to the FPGA to aid in the performance of the user's application.
• The[0339]FPGA106 may further include one or more custom functions (Custom1 and Custom2) defined by the customer or user to perform one or more functions specific or unique to the user's application, as well as custom user code for providing custom interface functionality, such as between the custom functions on the FPGA and external systems, or between the FPGA and custom software and/or hardware specific to the user's system or application.
• Finally, as indicated in FIG. 14, the FPGA may include debug/simulation functionality which may facilitate design and debugging operations in a simulation environment on the[0340]host computer system102, as described below with reference to FIGS. 15 and 16.
• Note that the FPGA layout described above is meant to be illustrative only, and is not intended to limit or constrain actual FPGA implementations or layouts to any particular form or function.[0341]
• FIG. 15—Debugging a Progranmable Hardware Based System[0342]
• In computer software and hardware development, debugging is the process of locating, fixing, or bypassing “bugs” (errors) in computer program code or the engineering of a hardware device. Debugging a program or hardware device may involve identifying a problem, isolating the source of the problem, and then fixing it. A user of a program that does not know how to fix the problem may learn enough about the problem to be able to avoid it until it is permanently fixed.[0343]
• Debugging is a necessary process in almost any software or hardware development process, whether a commercial product or an enterprise or personal application program. For complex products, debugging may be performed for the smallest unit of a system, again at component test when parts are brought together, again at system test when the product is used with other existing products, and again during customer beta test, when users try the product out in a real world situation. Because most computer programs and many programmed hardware devices contain thousands of lines of code, almost any new product is likely to contain “bugs”.[0344]
• The general approach to developing a programmable hardware element based system with fixed hardware resources (such as a RIO system) is to develop a program for performing a function in a development environment, such as National Instruments LabVIEW graphical development environment, convert the program into a form suitable for loading onto the[0345]programmable hardware element106, e.g., an FPGA program file (hardware configuration program), load the converted program onto theprogrammable hardware element106, test the system by performing the function, observe the results, and iterate the above process until the performance of the function is correct and complete.
• For example, National Instruments LabVIEW FPGA is a technology that creates a hardware implementation of a diagram created using the LabVIEW development environment. This allows the user to create a program, i.e., a graphical program or diagram, using the standard LabVIEW primitives for algorithms, looping, timing, triggering, etc., coupled with new I/O primitives to define the behavior of the target hardware. The typical approach used by LabVIEW users is to iterate on the design using a fast failure approach: Implement a basic design and try it. If it doesn't work make a small change and try it again. Continue with this process until the desired results are achieved.[0346]
• The difficulty with this approach when targeting hardware is due to compile times. Typical compile times for creating software in LabVIEW are measured in seconds, or milliseconds, whereas typical compile times for programming hardware in LabVIEW range from minutes to hours. Thus, it is not efficient or feasible for many users to make a small change and wait hours to see the results. The system presented below, referred to as the “Ghost” system, is a mechanism to provide the compile time advantage of a software target with the real world connectivity of the hardware environment. It is noted that although the system and method are described primarily in terms of a measurement system, the approach is broadly applicable to any system which uses a programmable hardware element in conjunction with one or more fixed hardware resources, including, but not limited to measurement (including data and image acquisition), control (including automation), and simulation, among others.[0347]
• In one embodiment, there are two main components to the solution. The first is a test feed-through configuration that is precompiled for the hardware target, and provides low level access to the fixed hardware resources on the RIO device (e.g., reconfigurable board). In other words, when deployed on the programmable hardware element, the test feed-through configuration provides for communication between the program and the fixed hardware resources on the reconfigurable board. This is a general configuration and preferably does not vary based on user application. The second component is a set of I/O primitives, such as a set of standard LabVIEW I/O primitives, for the fixed hardware resources. When targeting the hardware these I/O primitives and the standard LabVIEW primitives may be converted into a hardware representation, such as an FPGA program file (hardware configuration program), as described above with reference to FIGS. 12 and 13, and may take considerable time to compile. When targeting the test or simulation environment, also referred to as the Ghost environment, the standard LabVIEW primitives may remain in software and run on the host computer, and thus compile very quickly. The I/O primitives may also remain in software, but redirect their functionality to the precompiled test feed-through configuration in hardware.[0348]
• During execution in software, the I/O primitives may communicate through the[0349]FPGA106 to the various fixedhardware resources204. Thus the fixedhardware resources204 are actually invoked and used during the simulation. As an example, assume a first portion of a function is executed directly on anFPGA106, and a second portion of the function is implemented by fixedhardware resources204 under control of theFPGA106. The simulation method described herein executes the first portion in software on thehost computer system102, and the software invokes the fixedhardware resources204 to implement the second portion of the function. Thus the fixedhardware resources204 are invoked just as if they were being invoked directly by theFPGA106.
• For example, consider a typical PID loop using an analog input and an analog output. This is commonly constructed as a while loop containing an I/O primitive for reading the analog input, the PID algorithm itself, and an I/O primitive for writing the analog output. When targeting hardware, all of these constructs may be converted to hardware and downloaded to the[0350]RIO device110. When targeting the “Ghost” (simulation) environment, the precompiled test feed-through configuration may be quickly downloaded to the board, and the while loop and PID algorithm may remain in software. As the diagram or program executes in software on the host, whenever an I/O primitive is called it communicates with theRIO device110 to interface to the actual hardware I/O.
• A key advantage to this solution is that software based debugging methodologies may be used for debugging the diagram (program) while retaining connectivity to real world signals that the hardware targeted application would provide. This functionality may be provided without any changes to the user's application and may be completely transparent. Therefore, the user may debug most functional issues related to the application or system, and so may concentrate primarily on timing issues after performing a full compilation.[0351]
• In one embodiment, the test feed-through configuration may be extended to utilize a micro-controller implemented or configured in the[0352]FPGA106. In other words, a processor (e.g., a micro-controller) may be implemented on theFPGA106, then the program may be compiled for the FPGA-implemented processor. Compilation for the FPGA-implemented processor is similar to compilation for software executing on the host computer. The program may then be executed on the FPGA-implemented processor (while maintaining the original I/O capabilities of ghost), and so any timing issues arising from sharing the processor of the host computer system may be avoided.
• FIG. 15 is a block diagram of one embodiment a system for debugging a programmable hardware element based measurement and/or control system, such as a[0353]RIO system110, where the system includes aprogrammable hardware element106 and one or morefixed hardware resources204, as described above.
• As FIG. 15 shows, the system includes a[0354]programmable hardware element106, as described above. Theprogrammable hardware element106 includes one or morefixed hardware resources204, here shown as anADC204A, aDAC204B, and afilter204C. Theprogrammable hardware element106 may be coupled to ahost computer system102 via abus1510, as shown. Thecomputer system102 preferably stores a measurement/control program1502 which specifies or represents a measurement and/or control function, as described above.
• As indicated by FIG. 15, the[0355]programmable hardware element106 may be configured or programmed with the test feed-through configuration which provides connectivity between theprogram1502 executing on thecomputer system102 and the fixedhardware resources204. It should be noted that the configuration denoted by the connections in theFPGA106 are illustrative only, and is not meant to be an actual configuration.
• FIG. 16—A Method for Debugging a Reconfigurable System[0356]
• FIG. 16 is a flowchart of one embodiment of a method for debugging a reconfigurable system. The system includes a[0357]programmable hardware element106 coupled to one or more fixed hardware resources, and acomputer system102 coupled to theprogrammable hardware element106. As noted above, in some embodiments, various of the steps may occur concurrently, in a different order than shown, or may be omitted. Furthermore, one or more additional steps may be performed as desired.
• In[0358]1602, aprogram1502 may be stored on a memory of thecomputer system102. Theprogram1502 preferably specifies a function, where the program is operable to be converted into a hardware configuration program and deployed on theprogrammable hardware element106 to perform the function. In other words, as in the systems described above, theprogram1502 is meant to be deployed on the programmable hardware element, after which the programmable hardware element may be operable to perform the function in conjunction with one or more fixed hardware resources, as described above. As mentioned above, deploying theprogram1502 may comprise converting theprogram1502 into a hardware configuration program. It is again noted that the hardware configuration program specifies usage of the one or more fixed hardware resources by the programmable hardware element (in performing the function). It should also be noted that the hardware configuration program may be a bit file, an FPGA program file, a netlist, or any other type of hardware configuration program or file.
• In[0359]1604, theprogrammable hardware element106 may be configured with a test feed-through configuration. The test feed-through configuration may be stored in host computer memory in a pre-compiled format, and thus may be quickly downloaded to theprogrammable hardware element106. After configuration with the test feed-through configuration, theprogrammable hardware element106 is operable to provide for communication between the program and the one or morefixed hardware resources204.
• In one embodiment a “simulation” bus (not shown) located on the[0360]RIO device110 and external to theprogram hardware element106 may be selectively coupled between thebus1510 and the fixedhardware resources204. Thus, instead of configuring theprogrammable hardware element106 with a test feed-through configuration, the “simulation” bus may be switched or multiphased in to provide the desired connectivity.
• Finally, in[0361]1606, the computer system may execute the program for test and analysis, where executing the program includes the program communicating with the one or more fixed hardware resources through theprogrammable hardware element106. In other words, thecomputer system102 may execute theprogram1502 while maintaining connectivity with the one or morefixed hardware resources204 via the test feed-through configuredprogrammable hardware element106, and thus interacting with the “real world” signals and behavior of thehardware resources204.
• In the preferred embodiment, the test feed-through configuration is pre-compiled, so that the programmable hardware element may be configured without having to perform a lengthy compilation. It should be noted that the debugging system and method described herein is applicable to any reconfigurable system using a programmable hardware element (or any other type of functional unit, including a processor/memory unit, FPGA, or any other configurable/programmable hardware). For example, the program may be any of a measurement program which is executable to perform a measurement function, an automation program which is executable to perform an automation function, a control program which is executable to perform a control function, and a simulation program which is executable to perform a simulation function, among others.[0362]
• FIG. 17—A Configuration Tool for User Configuration of a RIO System[0363]
• In one embodiment of the present invention, a configuration tool may be used to configure the[0364]RIO system110. For example, the configuration tool may comprise one or more programs implementing a configuration wizard. The wizard may be operable to lead a user through the configuration process, receiving user input specifying the user requirements for the system, and generating a hardware configuration program for deployment on theRIO device110. In one embodiment, the configuration tool (e.g., the wizard) may also be operable to deploy the hardware configuration program onto theRIO device110. After development and/or deployment of a hardware configuration program, the user may return to the configuration wizard to make modifications or adjustments.
• The configuration wizard program may thus operate to receive user input specifying or characterizing the RIO system configuration. The wizard may then generate the hardware configuration program and deploy the hardware configuration program onto the[0365]RIO device110. The configuration wizard program may take various forms and may be operable to receive various types of user input.
• In one embodiment, the configuration wizard program may present one or more graphical user interfaces (GUIs) for receiving user input specifying or characterizing the RIO system configuration. This user input may then be used in creating the desired hardware configuration program. The configuration wizard program may take various forms, and one exemplary embodiment is described herein. As another example, the configuration wizard program may be similar to the IMAQ VisionBuilder program available from National Instruments Corporation.[0366]
• In one embodiment, the hardware configuration program may be created directly from the configuration wizard program user input. In another embodiment, a source code program may first be created by the configuration wizard program based on the user input received to the wizard. The source code program may either be graphical program source code or textual source code. This source code program may be an intermediate form used in creating the hardware configuration program. In one embodiment, the user may be able to modify or edit this source code program to further specify desired operation of the RIO device. After any desired editing of the source code program, the hardware configuration program may be created based on the modified source code program. Thus the user may be able to specify general desired operation of the RIO system using a high level GUI-based wizard, and then may be able to further specify details of the desired RIO operation by modifying source code created based on the input to the high level GUI-based wizard.[0367]
• As another example, the configuration wizard program may be a graphical programming development environment wherein the user creates a graphical program to specify or characterize the RIO system configuration. Exemplary graphical programming development environments include LabVIEW, Simulink, Agilent VEE, SoftWIRE, VisSim, etc. As another example, the configuration wizard program may be a text-based programming environment, wherein the user creates textual source code to specify or characterize the RIO system configuration. Exemplary text-based programming environments include VisualBasic, Visual C++, Delphi, and Measurement Studio from National Instruments.[0368]
• As another example, the configuration wizard program may be a development environment that utilizes conventional hardware synthesis, selection from a library of pre-generated files, and/or direct implementation in an FPGA, or combinations thereof, etc. For example, the configuration wizard program may be a synthesis tool.[0369]
• The configuration wizard program may thus be any of various types and may be operable to directly create a hardware configuration program through a variety of user input. The user input may include high level “wizard-like” GUI input, source code input (graphical or textual source code), a synthesis tool, a HDL tool, or combinations thereof.[0370]
• In one embodiment, the configuration wizard program may be operable to receive user input of various types. For example, the configuration wizard program may first provide various GUI panels which receive input from the user specifying a high level configuration of the desired RIO system. The configuration wizard program may then programmatically generate program source code (graphical or textual source code), or a graphical representation that is similar to program source code, based on the user input to the GUI panels. The user may then provide further user input modifying the program source code, wherein these source code modifications further specify the desired RIO configuration. The configuration wizard program may then programmatically generate a hardware description based on the program source code. The user may then provide further user input to the hardware description, e.g., by using a synthesis tool.[0371]
• In one embodiment, operations for creation and deployment of the hardware configuration program may occur on the customer or[0372]client computer system102, as shown in FIG. 1A. Theclient computer system102, shown coupled to theRIO device110, may store and execute a configuration wizard program to receive user input specifying or characterizing the system configuration. The wizard may then generate the hardware configuration program and deploy the hardware configuration program onto the RIO device110 (i.e., theFPGA106 in the RIO device110). The advantage to this approach is that the customer does not need to be connected to a vendor server. However, if software updates are required, for example, for backend tools or third party tools used in the process, it may be necessary to request the customer to perform the updates.
• In another embodiment, a vendor may operate or host the configuration wizard on a server computer system, such as an e-commerce server, which may be accessible to users (i.e., customers) over a network, e.g., the Internet, as shown in FIG. 17. As indicated in FIG. 17,[0373]client computer system102 may be coupled to aserver computer system103 over anetwork104, such as the Internet. The configuration wizard program may be stored and executed on theserver computer103. Software executing on the client computer system102 (e.g., a browser program) may be used to access the server103 (i.e., the configuration wizard). The user may thereby engage the configuration wizard remotely to specify a configuration of the RIO system, and to download or deploy the resulting hardware configuration program generated by the configuration wizard onto theRIO device110. In one embodiment, the vendor server may provide sales and purchasing services to the customer in addition to system configuration.
• In one embodiment, the server program (configuration wizard) may present a graphical user interface (GUI) to the user on the[0374]client computer system102 and receive input therefrom specifying user requirements for the system to be configured. Further description of the configuration wizard GUI is provided below with reference to FIGS.18-21.
• In one embodiment, the user, or software executing on the user (customer)[0375]computer102, may generate a description file indicating resources and features the user requires or has selected, and may submit the description file (possibly through an Internet interface) to theserver103, i.e., thevendor server103. Then, another computer program, e.g., executing on theserver103 or on a different computer system coupled to theserver103, may analyze the description file and return a hardware configuration file, (and optionally documentation in the form of a G program) to the customer. One advantage to this approach is that the amount of software required on the customer computer is relatively small, and control of updates and run-time issues may be maintained by the vendor.
• As described above, the RIO architecture provides a reconfigurable solution for adapting or customizing a measurement product to application requirements. There are several different approaches or support levels for performing the customization, each targeting a different class of users. For example, a basic support level may include providing precompiled hardware configurations from which the user may select a solution. This approach offers the least flexibility, but simplifies the choices that the user may consider. This approach may in many ways be considered a parameterized solution, in that the pre-defined nature of the hardware resources is very structured, with well defined acquisition modes and functionality. In other words, what the user does with the data (e.g., in LabVIEW) is very flexible, but the interface (e.g., the wizard) essentially accepts parameters to control its operation.[0376]
• In contrast, another embodiment of the invention offers very little pre-defined structure. This embodiment mixes program primitives, e.g., LabVIEW primitives, with low level I/O, and allows for the construction of timing, triggering, inline processing, and more. These building blocks can be pieced together to create the same functionality as the existing solutions, as well as much more capable operations. These blocks can often be combined in different ways to provide similar solutions, but one may be preferable to the other in terms of extensibility, resource utilization, etc. Thus, in this embodiment, a development environment for configuring programmable hardware elements, e.g., LabVIEW FPGA, may be provided to the user, who may then create any arbitrary diagram or program as needed. This approach offers the greatest flexibility, but requires a more sophisticated user.[0377]
• In one embodiment, as mentioned above, a configuration wizard may bridge the gap between flexibility and ease of use. For example, in one embodiment, the wizard may provide a drag and drop interface for creating the user defined RIO configuration. In another embodiment, the wizard may provide a menu and/or button based graphical interface for creating the user defined RIO configuration. In yet another embodiment, the wizard may provide a list or diagram of available resources, e.g., low level interface primitives such as AI, AO, and DIO, as well as a list or diagram of higher level functions that can be applied to these low-level primitives, including higher level interface functions such as counters built on top of DIO lines, or inline processing such as linearization or filtering for AI lines.[0378]
• The user may select the resources required by an application, and configure any resources as necessary (for example, setting gain parameters on an analog input resource) using the configuration wizard. For another example, the user may be building a motion control application containing a main control loop (analog output for command, quadrature encoder for feedback) for a servo motor and a temperature monitoring loop (analog input for a thermocouple) for the power electronics. The user may first select low level resources, including, for example, two digital inputs, an analog output, and an analog input. In one embodiment, the selections may be hierarchical, and may allow the user to add the higher level interface or inline processing in the same window. The user may then identify the timing and triggering requirements of the application, selecting from the resources identified/created in the previous step.[0379]
• As mentioned above, there are a number of approaches for creating the appropriate configuration for the reconfigurable core (i.e., the programmable hardware element[0380]106) based on information provided from the wizard. The various approaches to generation of the FPGA hardware configuration program differ primarily in which parts execute on theuser computer system102. In each of these approaches a description file is preferably generated which uniquely identifies resources and features the user has selected. From this description file, G code (graphical code, i.e., National Instruments G graphical programming language) may be generated. HDL code may then be generated from the G code, or directly from the description file. A program binary file, i.e., a hardware configuration program, for the FPGA may then be generated from the HDL code. In these approaches, caching schemes are preferably used so that the number of compilations may be minimized.
• In one embodiment, specific features (as opposed to complete configurations) may be pre-compiled in such a way that they may be assembled or composed quickly into an appropriate configuration at the customer site. The advantage of this approach is that most of the relative placement and routing has been done up front, and so only a “quick” replacement and rerouting is needed to put the configuration together. In another embodiment of this approach, a set or library of complete configurations may be maintained and made available to the customer for a wide variety of applications. The user may select a best solution (i.e., configuration), then make modifications as needed.[0381]
• Thus, in a preferred embodiment, one or more configuration wizards may generate graphical programs, e.g., LabVIEW diagrams based on customer entered requirements that are architecturally more scaleable to allow for changing customer requirements.[0382]
• For example, suppose a customer wants to create a basic post-triggered acquisition. This is a simple task that may be implemented in several ways. The customer chooses a for loop as the basic counting structure. Later, the customer decides to add pre-triggering, and further decides that a while loop with a small state machine in a shift register is a better approach and redraws the diagram. Finally, the customer decides that a minimum number of pre-trigger points is required, and redraws three loops: a for loop for the minimum number of points, a while loop to wait for the post-trigger, and another for loop for the post-trigger points. A common recommended diagram structure for these common or classic applications may greatly speed the customer's development task.[0383]
• In one embodiment, typical applications may be grouped into a small number of classes. A wizard for each of these classes may be provided which queries the user about the application, then builds an appropriate LabVIEW diagram for the application. In one embodiment, there may be two aspects to this solution. The first is the definition of the classes and corresponding data structures. The second is the collection of wizards. In one embodiment, the wizards may use scripting, such as LabVIEW scripting, to generate the graphical programs or diagrams for each class of application.[0384]
• Thus, representative diagrams of user applications, including timing, triggering, and data transfer to the host may be developed and grouped into classes. The different diagrams in a given class preferably have very similar structure. For example, a diagram for timed acquisition of analog input channels may look nearly identical to a diagram for timed acquisition of analog and digital input channels, even though it is possible to draw the diagrams very differently. A configuration wizard for each class may then be provided which may generate the appropriate graphical program in response to user input specifying a particular application or function.[0385]
EXAMPLE
• A customer wishes to implement a control loop with National Instruments LabVIEW RT for an algorithm and LabVIEW FPGA for the timing and triggering. A control wizard may query the user about the I/O structure: How many synchronous analog inputs, analog outputs, digital inputs, digital outputs, and counters are in the system? How many asynchronous channels are in the system?[0386]
• After receiving user input answering these queries, the control wizard may script a diagram with just the I/O the customer needs, as well as the required controls and indicators. The customer may then focus on the LabVIEW RT control algorithm instead of low level I/O details. If the customer discovers later that further customization of the timing and triggering is needed, the LabVIEW FPGA diagram may be modified directly.[0387]
• In one embodiment, wizards may only include support for rudimentary functionality. In other words, wizards for basic acquisition, control loops, hardware in the loop testing, etc., may be provided. In another embodiment, the wizards may provide broad functionality in their respective areas of application. For example, in one embodiment, an acquisition wizard may only support pre- and post-triggering. In another embodiment, the acquisition wizard may also support external conversion, hardware gating, and other more advanced functionality.[0388]
• Thus, in one embodiment, configuration wizards may be provided for basic timing and triggering functionality, without a broad application focus. In another embodiment, application-specific wizards may be provided, possibly built on top of the timing and triggering wizards.[0389]
• In one embodiment, a wizard may provide a palette of basic I/O components and allow the user to select a variety of components and configure them individually. In one embodiment, the wizard may provide substantially the same user experience for progressively more complex components. Thus, the available features selectable by the user include a combination of the simple I/O components and complex structures. In one embodiment, the wizard may be upgradeable with new features as they are developed. Thus, the wizard may allow the user to collect various blocks into a configuration, and to configure these blocks and the resulting configuration to the user's specific requirements.[0390]
• In one embodiment, the wizard may be based on a standard configuration framework, such as National Instruments Workshops framework, and may host a configuration VI (Virtual Instrument) or diagram provided for each selectable feature. The diagrams of each selected feature may be combined (by the wizard) into a single diagram. In one embodiment, after the final diagram has been constructed or assembled, the wizard may contact a compile server automatically, and a compiler program, such as LabVIEW FPGA, may be used to create a hardware configuration program, e.g., a bit file.[0391]
• Thus, the use of one or more configuration wizards may provide an easy to use interface which allows the user or customer to configure or construct custom configurations for a reconfigurable system (i.e., the programmable hardware element in a RIO system[0392]110). More specifically, a wizard may provide the user access to configurable RIO functionality without the user having to be familiar with a particular development environment, such as LabVIEW.
• FIG. 18—A Method for Configuring a RIO System Using A Configuration Tool[0393]
• FIG. 18 is a flowchart of a method for configuring a reconfigurable system (i.e., a RIO system), according to one embodiment. The reconfigurable system preferably comprises a programmable hardware element and one or more fixed hardware resources coupled to the programmable hardware element. As noted above, in some embodiments, various of the steps may occur concurrently, in a different order than shown, or may be omitted. Furthermore, one or more additional steps may be performed as desired.[0394]
• As FIG. 18 shows, in[0395]1802, a graphical user interface may be displayed on a display which is useable for configuring the reconfigurable system. The graphical user interface may display fixed hardware resource icons corresponding to each of at least a subset of the fixed hardware resources.
• In[0396]1804, user input to the graphical user interface may be received which specifies a function. For example, the reconfigurable system may be a reconfigurable measurement system, and the function may be a measurement function. In other embodiments, the reconfigurable system may be one or more of a reconfigurable control system, a reconfigurable automation system, and a reconfigurable simulation system, and the function may correspondingly be one or more of a control function, an automation function, and a simulation function.
• As noted above, the user input to the graphical user interface may include text or numerical input, menu or button selections, iconic selection, drag and drop, or any other technique of entering data with a GUI. In one embodiment, the received user input may be regarding one or more of the fixed hardware resources required by an application to perform the function. The received user input may further specify timing and triggering requirements of the application with respect to the specified fixed hardware resources.[0397]
• In one embodiment, an appearance of respective fixed hardware resource icons may be modified as the corresponding fixed hardware resources are allocated to perform functions in response to the user input. In other words, the modified appearance of the respective fixed hardware resource icons may visually indicate to the user that the corresponding fixed hardware resources have been allocated for use.[0398]
• In another embodiment, an icon corresponding to the programmable hardware element may be displayed. Furthermore, proposed configurations of the programmable hardware element may be displayed interactively in response to receiving the user input. Thus, the user may be provided visual feedback regarding the configuration currently specified.[0399]
• In[0400]1806, a hardware configuration program may be generated based on the user input, where the hardware configuration program is deployable on the reconfigurable system. In other words, the hardware configuration program may be loadable onto the programmable hardware element of theRIO device110, thereby configuring or programming theRIO device110 to perform the specified function.
• In one embodiment, generating the hardware configuration program may include generating a description file which identifies resources and features to perform the function indicated by the user, generating a program from the description file, generating hardware description language (HDL) code from the program, and generating the hardware configuration program from the HDL code. In one embodiment, the program is a graphical program.[0401]
• Finally, in[0402]1808, the hardware configuration program may be deployed on the programmable hardware element, where the hardware configuration program specifies use of one or more of the fixed hardware resources in performing the specified function. Said another way, after deploying the hardware configuration program onto the programmable hardware element, the reconfigurable system, including the one or more fixed hardware resources, is operable to perform the function.
• In one embodiment, the programmable hardware element is a field programmable gate array (FPGA), and the hardware configuration program is a program binary file for the FPGA.[0403]
• After the programmable hardware element has been configured with the hardware configuration program, the hardware configuration program may be executed on the programmable hardware element to perform the function. In one embodiment, the programmable hardware element may execute a first portion of the function, and the programmable hardware element may invoke operation of one or more of the fixed hardware resources to perform a second portion of the function.[0404]
• FIGS.[0405]19A-19E—Example Configuration Wizard Interface
• FIGS.[0406]19A-19E illustrate various example displays of a configuration wizard, according to one embodiment. It should be noted that these displays are meant to be illustrative only, and are not intended to limit the form or function of a configuration wizard to those shown.
• FIGS.[0407]19A and19B—Wizard User Interface
• FIGS. 19A and 19B illustrate one embodiment of a user interface of a configuration wizard. As FIGS. 19A and 19B show, in one embodiment, the interface may include a blocks section or panel indicating the various components or control structures the user may configure, such as digital I/O, analog input, analog output, timed loop, and free running looping, among others. In one embodiment, the user may select or click a particular block to activate the configuration panels for that component or control structure.[0408]
• In one embodiment, the interface may include an icon strip, shown between the blocks panel and a main panel. Each icon represents a configured component or control structure corresponding to one of the blocks in the block panel, a listed above. In another embodiment, each icon in the icon strip may represent a step or function of the function being created. Thus, as the user selects and configures functions, corresponding icons are added to the icon strip. It should be noted that each time a block is selected indicating a new function, an icon may be added to the icon strip. In one embodiment, when a user selects (clicks) an icon in the icon list, the configuration wizard may present one or more panels corresponding to that component or control structure, thereby allowing the user to quickly access any function specification for review, revision, replication, or deletion.[0409]
• In the example shown in FIG. 19A, a digital I/O component has been selected, and so the main panel presents digital I/O configuration parameters which may be set by the user. In one embodiment, default values for each component may be provided by the wizard which may be over-ridden by user input.[0410]
• FIG. 19B illustrates the use of the wizard to configure components in the free running loop. As FIG. 19B shows,[0411]analog input2 has been selected for inclusion in the loop.
• After the user has set the parameters for the selected components and/or control structures, the wizard may generate a diagram or VI, preferably via a scripting language. Example diagrams are described below with reference to FIGS.[0412]19C-19E.
• FIGS.[0413]19C-19E—Wizard User Interface: Scripting Diagrams
• FIGS.[0414]19C-19E illustrate the process whereby the wizard generates a diagram or VI representing the specified functionality of an application. As noted above, the wizard preferably generates the diagram via a scripting process, although other means of generation are also contemplated, including compilation, look-up tables, etc.
• FIG. 19C illustrates the placement of timing loops onto the diagram. Specifically, a timed loop and a free running loop are each added to the diagram. Note that in this case the loops are not nested.[0415]
• FIG. 19D illustrates the placement of I/O components onto the diagram. As FIG. 19C shows, an analog input component is added to both the timed loop and the free running loop. Additionally, an analog input is added to the timed loop, along with two DIO inputs. Thus, based on the user input configuration information, the wizard may generate a diagram or VI which implements the functionality specified by the user. FIG. 19E shows the state of the diagram after the loops have been added and populated with the digital and analog I/O components. The addition of these structures and components to the diagram may result in a dynamically created front or main panel, as shown in FIG. 19F, described below.[0416]
• FIG. 19F illustrates a dynamically created front or main panel of the wizard graphical user interface. As shown in FIG. 19F, the main panel may include a configuration field for each of the added analog and digital I/O components whereby the user may view and modify the parameter values for each component.[0417]
• After the diagram has been finalized (saved), the diagram may be converted or exported to a bit file, e.g., a hardware configuration program. In one embodiment, the diagram may be converted to a graphical program diagram in another development environment, such as LabVIEW. Thus, a wizard may be allow a user to specify a function or task and generate a graphical program implementing the function or task.[0418]
• Where a reconfigurable system comprises a programmable hardware element coupled to one or more fixed hardware resources, as described above, the system may be configured by a wizard in the following manner:[0419]
• Initially, the wizard may display a graphical user interface on a display (i.e., a computer display) which is useable for configuring the reconfigurable system, where the graphical user interface displays fixed hardware resource icons corresponding to each of at least a subset of the fixed hardware resources. In other words, the wizard may represent some or all of the fixed hardware resources by graphical icons, referred to as fixed hardware resource icons.[0420]
• The wizard may then receive user input specifying a function, as described above. The user input may include selection of components and/or control structures, as well as selection or setting of component or control structure parameter values. In one embodiment, receiving user input may include receiving user input regarding one or more of the fixed hardware resources required by an application to perform the function, as well as receiving user input specifying timing and triggering requirements of the application with respect to the specified fixed hardware resources. Said another way, the wizard may receive user input specifying resources required by an application to perform a function, as well as user input specifying timing and triggering requirements of the application with respect to the specified resources. In one embodiment, specifying resources may comprise selecting one or more of hardware and software resources, and indicating configuration settings for the resources.[0421]
• In one embodiment, receiving the user input specifying the function may be performed by a server computer system. Additionally, in one embodiment, prior to the server computer system receiving the user input, a user (client) computer system may access the server computer system over a network. In other words, the user may engage the configuration wizard over the Internet by using the client computer system to access a vendor's server computer system, and use the configuration wizard, as described above.[0422]
• A hardware configuration program may then be generated which is deployable on the reconfigurable system, as described in detail above. For example, in one embodiment, generating a hardware configuration program may comprise generating a description file identifying resources and features to perform the function indicated by the user, generating a program from the description file, generating hardware description language (HDL) code from the program, and generating the hardware configuration program from the HDL code. As described above, the hardware configuration program is usable to configure the programmable hardware element comprised in the reconfigurable system to perform the function. In one embodiment, the program generated from the description file may be a graphical program, such as a LabVIEW graphical program.[0423]
• Configuration Storage and Matching[0424]
• In one embodiment, the host and/or development environment may maintain a cache for storing one or more pre-compiled hardware configuration programs (configurations). For example, a library of such pre-compiled configurations may be developed representing common measurement tasks. Additionally, new configurations developed in response to new user specified requirements may be stored, i.e., may be added to the original library. By storing such pre-compiled configurations, the number of configurations developed from scratch in response to new user requirements may be minimized.[0425]
• In one embodiment, in response to user input specifying a measurement task, a pre-compiled configuration may be selected from the stored configurations in the following manner. First, a determination may be made as to whether there is a pre-compiled configuration that precisely matches the customer's requirements (task definition). If such a match is found, the configuration may be retrieved and provided to the user.[0426]
• If a direct match is not found, then a search may be made for a configuration which provides a strict superset of the required functionality, i.e., one that has all the requirements and more. Although the superset configuration provides more functionality than the user requires, the configuration meets the requirements, and may not take much more time to compile. Therefore, (after confirmation by the user, if such an option is enabled), the superset configuration may be retrieved and provided to the user. It is noted that compilation of a configuration generally requires much more time than selection of a configuration, thus, because the more complex configuration is pre-compiled, the selection of a larger configuration may not require substantially more time than a smaller configuration. Having a larger configuration may make the interface more complex, but the user can easily ignore those functions not needed by the user.[0427]
• In one embodiment, if a suitable superset configuration is not found, or if the user chooses not to use the superset configuration, a search may be made for a “closest”configuration, i.e., a configuration with similar, although not quite the same functionality specified by the user. For example, a “closest” match configuration may have the same number of digital I/O but may have one less analog channel. If this is acceptable to the user, then the configuration may be selected and provided to the user.[0428]
• Alternatively, if an exact configuration is required by the user, the configuration may be developed as described above, and provided to the user.[0429]
• After the hardware configuration program is generated (or selected), the hardware configuration program may be deployed on the programmable hardware element, where the hardware configuration program specifies use of one or more of the fixed hardware resources. In other words, the hardware configuration program may specify not only the behavior or the programmable hardware element, but may also specify how the one or more fixed hardware resources are to be used by the programmable hardware element in performing the specified function. After the hardware configuration program has been deployed, the reconfigurable system may be operable to perform the function.[0430]
• In one embodiment, after the hardware configuration program has been deployed on the programmable hardware element, the hardware configuration program may be executed on the programmable hardware element to perform the function. Executing the hardware configuration program on the programmable hardware element may include the programmable hardware element executing a first portion of the function, and the programmable hardware element invoking operation of one or more of the fixed hardware resources to perform a second portion of the function. In other words, different portions of the hardware configuration program (and therefore, the function) may be directed respectively to performing operations directly on the programmable hardware element, and to operation of one or more of the fixed hardware resources coupled to the programmable hardware element.[0431]
• In one embodiment, the wizard may modify an appearance of respective fixed hardware resource icons as the corresponding fixed hardware resources are allocated to perform functions in response to the user input, where the modified appearance of the respective fixed hardware resource icons visually indicates to the user that the corresponding fixed hardware resources have been allocated for use. For example, selected fixed hardware resource icons may be “grayed out” on the display, indicating that the corresponding fixed hardware resource is already being used, thus preventing the user from over tasking a given resource.[0432]
• In one embodiment, the wizard may display an icon corresponding to the programmable hardware element, and interactively display proposed configurations of the programmable hardware element in response to receiving the user input. Said another way, the wizard may graphically illustrate the current configuration of the programmable hardware element as a result of the user specified parameters, components, resources, etc.[0433]
• In one embodiment, the reconfigurable system may be a reconfigurable measurement system, and the function may be a measurement function. In other embodiments, the reconfigurable system may be one or more of a reconfigurable control system, a reconfigurable automation system, and a reconfigurable simulation system, and the function may be a corresponding one or more of a respective control function, an automation function, and a simulation function.[0434]
• As noted above, in one embodiment, the programmable hardware element may be a field programmable gate array (FPGA), and the hardware configuration program may comprise a program binary file for the FPGA.[0435]
• Thus, when the reconfigurable system comprises a reconfigurable measurement system, the method may include the wizard displaying a graphical user interface on a display which is useable for configuring the reconfigurable measurement system, where the graphical user interface may display icons corresponding to each of at least a subset of the fixed hardware resources. The wizard may then receive user input specifying a measurement function, and generate a hardware configuration program, where the hardware configuration program is deployable on the reconfigurable measurement system. Finally, the hardware configuration program may be deployed on the programmable hardware element, where the hardware configuration program specifies use of one or more of the fixed hardware resources. Additionally, receiving the user input may include receiving user input regarding one or more of the fixed hardware resources required by an application to perform the function, as well as timing and triggering requirements of the application with respect to the fixed hardware resources. As mentioned above, after deploying the hardware configuration program, the reconfigurable system may be operable to perform the measurement function.[0436]
• FIG. 20—A Hardware Block Module Generator[0437]
• As described above, in the course of generating a hardware configuration program from user specifications, a graphical program, such as a LabVIEW diagram or VI, may be created, analyzed and converted into a form suitable for deployment on the programmable hardware element. As is well known in the art, many graphical programs may include nodes or elements which themselves represent other graphical programs or diagrams. In the context of LabVIEW, these sub-programs are referred to as sub Vis or blocks.[0438]
• In such a conversion, when a sub VI is encountered on a LabVIEW diagram, one approach is to explore the sub VI and automatically generate a corresponding hardware configuration. Alternatively, custom logic that the user has developed may be used to convert the sub VI. In one embodiment, the user may create such custom logic through the use of module generators. To create a module generator, the user may start by using a configuration tool, such as the configuration wizard described above, to set up an API to the corresponding hardware component. A screen shot of one embodiment of this tool is shown in FIG. 20.[0439]
• Referring to FIG. 20, in the first field of the block generator tool, a “Wrapper VI Path” may define an API to a corresponding hardware component. After selecting a VI, “Static Implementation Code” may be started with a port list for the hardware component. If the hardware component is a purely static implementation, the user may simply type VHDL code into the “Static Implementation Code” tab and then hit “Save Modifications to Module Generator” and be done. The options tab may allow the user to request resources off the board to be used in the selected component. If the resource is used elsewhere, a backend program may automatically arbitrate between competing accessors, i.e., the components which are concurrently configured to use the selected component.[0440]
• A powerful feature of module generators may become apparent when the code generated is not entirely static. In other words, the VHDL created may vary depending on inputs to the block or sub VI (whether the inputs are constant or not), the structure of the parent diagram, and/or information on the front panel of the sub VI that defines the class of the object (this may be useful for arbitration options or other options that apply to a component everywhere in a particular application). In one embodiment, the dynamic behavior of the hardware created may be controlled using the G language itself. The module generators may just be VIs which the user can access and modify at will. An example block diagram is illustrated in FIG. 21, described below.[0441]
• FIG. 21—Example Block Diagram[0442]
• FIG. 21 illustrates a block diagram or VI generated by a module generator, as described above. In other words, the VI of FIG. 21 is the result of a dynamic code generation process. The interesting parameters for dynamic code creation are the Node Refnum (a reference to the node on the block diagram) and the VI Refnum (a reference to the VI that is being used as a sub VI).[0443]
• In one embodiment, the module generator framework may be pseudo-object oriented. In one embodiment, a set of VIs may be automatically generated for a specified component. For example, in one embodiment, the module generator VIs automatically created may be as follows:[0444]
• 1. Constructor—Allows the user to initialize instance data that is passed between all the following VIs, and may also support the use of multiple languages, where the constructor specifies the possible languages and the Get Mod Info VI, described below, gets passed which language should be implemented, e.g., “VHDL”.[0445]
• 2. Get Mod Info—Allows the user to request hardware resources (ADCs, DACs, DIO lines, etc). In one embodiment, this VI may also tell the backend how many cycles the block takes to execute and other information the backend may use to optimize surrounding logic.[0446]
• 3. Get Mod Implementation—Allows the user to specify the implementation for the hardware component.[0447]
• 4. Get Mod Declaration—Allows the user to specify a custom declaration for his component. In one embodiment, a default value may be provided by the backend.[0448]
• 5. Get Mod Instantiation—Allows the user to specify a custom instantiation for the selected component. In one embodiment, a default value may be provided by the backend.[0449]
• 6. Destructor—Allows the user to clean up any instance data passed between the above VIs.[0450]
• These VIs may be called in sequence from the backend when a matching component is found on the users original diagram.[0451]
• Communication[0452]
• Communication is important for distributed applications. For RIO, the communication is between the board and the host, or between a[0453]measurement module108 andRIO110, or between hardware glue and a soft-core instantiated on theprogrammable hardware element106, e.g., the FPGA.
• Automatic API Generation[0454]
• Many times an application (VI) developed using a hardware configuration development environment, e.g., LabVIEW FPGA, is part of a larger system. Therefore, in one embodiment, an API may be automatically generated for the user for accessing the hardware application from a host. This wizard application may list all resources used in a user's application (controls and indicators on the front panel, DMA channels, and interrupts) and give the user the option to not create an API entry for that particular channel. When the user is satisfied, he may simply hit a button and the wizard application may generate a palette of VIs for controlling and communicating with his application on our board. The user may then use these VIs in a larger system on the host. The basic services offered by the automatically generated API may include:[0455]
• 1. Open—Reserve resources, open references, etc.[0456]
• 2. Close—Opposite of open.[0457]
• 3. Download—Deploy a configuration to the board.[0458]
• 4. Control—Control the execution of the deployed configuration (run, stop, halt, etc)[0459]
• 5. Access—Channels and ports that hide the implementation of registers, interrupts, and DMA. Automatic synchronization of data may be supported. Alternatively, the user may build synchronization into his application.[0460]
• One problem which may arise with this automatic interface generation is that it may be strongly tied to the application created in hardware. In other words, if the application changes, the API may change, which means the host based application may require change as well. Therefore, in one embodiment, the user may be allowed to group particular resources into classes where all members of a class have exactly the same API. Subclasses may implement inheritance for extending the API.[0461]
• The particular resources here may be communication channels and ports. These channels and ports may be uni- or bi-directional but are preferably always visible and locatable from both sides. The concept of channels and ports may hide the particular implementation of registers, interrupts, dma, and synchronization logic. The channel or port may be configured to take advantage of a particular communication method or synchronization method. For synchronization, channels/ports may be grouped together into one synchronized group. In a further embodiment, interface templates may be provided such that the user may just modify the template for a particular application but needn't modify the API. Then as long as the user's operations remain inside the framework, the same API will exist. These mechanisms may allow the policy of the implementation to change while keeping the same API.[0462]
• In one embodiment, the ‘calling of VIs’ may be distributable between different machines and boards, thereby providing communication, synchronization, and system level design capabilities to the development environment, e.g., LabVIEW.[0463]
• Embedded Microcontroller Interfacing[0464]
• It is possible to implement microcontrollers inside FPGAs. These can be either hard or soft cores depending on whether they are implemented using custom silicon or not. The soft cores are reconfigurable but the performance is not as great. In one embodiment, interfacing to one of these microcontrollers may be performed in a similar way to interfacing to the host as described above under the section titled “Automatic API generation”. Potentially, the same API generation mechanism could be used for hardware-hardware, software-software, and hardware-software interfaces.[0465]
• Arbitration for Shared Resources[0466]
• In one embodiment, resources may be used more than once in an application. Resources are usually hardware (ADCs, DACs, DIO lines, etc), but may also be processing elements or sub VIs. If resources are used more than once an arbiter may need to be placed between the users of the resource and the resource. The arbiter may be responsible for serializing access to the resource. In one embodiment, the arbiter may be implemented as a series of flip flops connected in a ring with enables to move from one accessor to the next. Each flip flop may take one cycle, so a worst case delay through an arbiter may be equal to the total number of possible accessors. Generally, just one accessor is active at a particular time, and so a small circuit may be included that determines whether there is only one accessor. If there is only one accessor, access may be granted and the flip flop state machine with its variable delay may be ignored. A simple diagram illustrating this approach is shown in FIG. 22, described below.[0467]
• FIG. 22—Arbitration of Access to a Component[0468]
• FIG. 22 illustrates an approach for determining if there is only one accessor is general knowledge for figuring out if a number is a power of two:[0469]
• If( requests && !(requests & (requests−1)))[0470]
• Requests is a power of 2 and so there is a single accessor.[0471]
• Else[0472]
• There is more than one simultaneous access so use the round robin flip flop state machine.[0473]
• This design has two useful aspects. For one, the round robin flip flop state machine is very simple and so is very likely to meet static timing requirements no matter how many possible accessors there are (within reason). Additionally, the single accessor check improves the performance for non simultaneous accesses at a minimal logic cost.[0474]
• Hardware State and Logic Sharing[0475]
• Logic takes up space on an FPGA. Multiple instances of much logic could possibly share the same logic for space savings assuming the timing requirements are not tight. In this case the logic may become similar to a hardware resource to which access may be arbitrated. In doing this, some parallelism available in hardware may be lost because access to a resource (logic) is being serialized but space may be saved. Sharing access to logic is similar to non reentrant sub VIs in LabVIEW.[0476]
• One problem with sharing access to sub VIs is state must sometimes be saved from one execution of a sub VI to the next from the same instance on a parent block diagram. This may be done in LabVIEW using reentrant sub VIs with front panel controls and indicators that are unconnected and also uninitialized shift registers. One approach using LabVIEW FPGA is to use registers to hold state information. These are behind the scenes, in that the user still uses shift registers and front panel controls. A more efficient implementation for shared sub VIs may be to use block RAM inside or outside the FPGA to store the state information. A reference may then used for every instance of a sub VI to pull out the correct state information. In the first approach all the state information is in effect being passed in and out of the sub VI. With the second approach only the reference is passed. The second approach may be inefficient for non shared sub VIs, but for shared sub VIs may be an efficient solution.[0477]
• Simulation Environment[0478]
• Simulation environments are useful to figure out how a system will respond in certain situations before implementing them. This is particularly important in hardware configuration development environments, e.g., LabVIEW FPGA, because the compile times are typically very long.[0479]
• System Level Simulation[0480]
• If the user develops a hardware application for incorporation into a larger system, as mentioned above, it may be desirable to simulate the entire system before compiling the hardware application. If everything is written in a graphical programming language such as LabVIEW this may not be difficult. All API VIs just need to have special simulation logic that gets executed when in simulation mode. For front panel register access, the simulation target can just use VI server calls to set/get values from the front panel. For DMA, the API VIs can use LabVIEW Queues. For Interrupts, the API VIs can use LabVIEW occurrences.[0481]
• Example RIO Configurations[0482]
• The configurations for the RIO board are created from a collection of I/O components. These I/O components can be grouped in different ways to create configurations for focused applications. The I/O components may include typical DAQ like interfaces such as analog input, analog output, digital I/O, and timing I/O. The grouping provides the timing and triggering layer on top of these components, which may include free running resources, fully synchronous mixed I/O, hardware triggered operations, and more.[0483]
• The configurations for the RIO board can be organized into a small number of classes, with minor permutations within each class. An example configuration class would be “post trigger”, with permutations including SW triggered, HW triggered, etc.[0484]
• Low Level Components[0485]
• The primary I/O components are low level and directly access the hardware I/O. They are used for the basic analog input, analog output, and digital I/O interfaces.[0486]
• 1. Analog Input[0487]
• This component initiates an analog to digital conversion from an ADC. It returns the result of the conversion. This component tends to exist in timed loops, but can also be used in free running applications.[0488]
• 2. Analog Output[0489]
• This component writes a value to a DAC and initiates the digital to analog conversion. It returns no data. This component is commonly used for continuous and discrete output, existing in both timed and free running applications.[0490]
• 3. Digital Input/Output[0491]
• This is really a collection of components that act on a single hardware resource. A given digital line can be used for input, output, or bidirectional applications. This component is more commonly used in static DIO applications or as a building block for higher level functionality, with some timed applications.[0492]
• High Level Components[0493]
• The DIO lines are the resources most commonly used to build higher level I/O components. These are components that interface to digital signals but need some amount of logic or processing to be meaningful, with the best example being counter applications. Note that it is possible to use the analog components for these applications, it is simply not as common. There are many more minor and major variations than listed below, but these are very common examples.[0494]
• 1. Event Counter[0495]
• This high level component counts active edges on a digital input. It typically offers polarity control over the incoming signal, a means to control the start and stop of counting, and a readable register with the counter data. When used in a timed loop application, this counter typically returns the number of counts during the previous loop iteration.[0496]
• 2. Period Counter[0497]
• This high level component counts the time between active edges on a digital input. It typically offers polarity control over the incoming signal, a means to control the start and stop of counting, and a readable register with the counter data. When used in a timed loop application, this counter typically returns data for the most recent measured period.[0498]
• 3. Semi Period Counter[0499]
• This high level component counts the time between opposite edges on a digital input. It typically offers polarity control over the incoming signal, a means to control the start and stop of counting, and a readable register with the counter data. When used in a timed loop application, this counter typically returns data for the most recent measured period.[0500]
• 4. Quadrature Decoder[0501]
• This high level component increments or decrements based on two digital inputs. It typically offers polarity control over the incoming signals, a means to control the start and stop of counting, and a readable register with the counter data. When used in a timed loop application, this counter typically returns the final counter value during the previous loop iteration.[0502]
• 5. PWM Input[0503]
• This high level component counts the high and low times of a pulse train. It typically offers polarity control over the incoming signal, a means to control the start and stop of counting, and a readable register with the counter data. When used in a timed loop application, this counter typically returns data for the most recent measured high and low periods.[0504]
• 6. PWM Output[0505]
• This high level component generates a pulse train with controllable high and low times. It typically offers polarity control over the generated signal, a means to control the start and stop of generation, and two writeable registers for period data. When used in a timed loop application, this counter is typically configured to run at a multiple of the loop rate for synchronous behavior.[0506]
• Grouping of Components[0507]
• The components by themselves do not provide much functionality. It is the grouping of the components in structured wrappers that define a particular configuration. These wrappers provide the timing and triggering of the components as well as the interface to the host diagram. These wrappers can be grouped into classes of functionality.[0508]
• 1. Free Running[0509]
• This configuration resembles a PLC in that it continuously samples and updates it's I/O as fast as possible. The input registers always contain the most recent data, and can be read at any time. The output registers can be written at any time, and the outputs will be updated as soon as possible. It is the simplest of the configurations in that there is no real timing, triggering, or data transfer synchronization issues for the customer.[0510]
• Recommended Permutations[0511]
• Different counter I/O combinations[0512]
• 2. Continuous Timed Loop[0513]
• This configuration provides a single timed loop for all synchronous resources. This is well suited to control loops with fully correlated I/O. The host is notified when it is time to access the I/O resources.[0514]
• Recommended Permutations[0515]
• SW & HW triggered[0516]
• Mixes of synch/asynch DIO[0517]
• Mixes of counter I/O[0518]
• Different transfer mechanisms (Poll, Interrupt, DMA)[0519]
• 3. Post Trigger Acquisition[0520]
• This configuration provides the typical post triggered data acquisition functionality. A fixed number of points will be acquired when a SW or HW trigger is received. The same behavior is provided in different combinations for the other resources.[0521]
• Recommended Permutations[0522]
• Single and independent loops per resource type[0523]
• SW & HW triggered[0524]
• Mixes of synch/asynch DIO[0525]
• Mixes of counter I/O[0526]
• Different transfer mechanisms (Poll, Interrupt, DMA)[0527]
• 4. Pre Trigger Acquisition[0528]
• This configuration provides the typical pre triggered data acquisition functionality. A minimum number of pre trigger points will be acquired, and a post trigger will cause a fixed number of remaining samples to be taken. Note that there is not a comparable model for the output resources.[0529]
• Recommended Permutations[0530]
• Single and independent loops per resource type[0531]
• SW & HW triggered[0532]
• Mixes of synch/asynch DIO[0533]
• Mixes of counter I/O[0534]
• Different transfer mechanisms (Poll, Interrupt, DMA)[0535]
• It should be noted that the above are meant to be illustrative examples of RIO configurations, and are not meant to limit the scope or form of configurations usable in the RIO system. Other features which may be considered configuring the[0536]RIO system110 include, but are not limited to, other I/O features such as the number of channels, resolution, rates, protection, range, simultaneity and/or synchronization, and enhanced I/O functionality; timing models, including continuous, post trigger, and independent loops; signal conditioning, e.g., sensor interface; form factor, e.g., PXI, PCI, standalone, etc.; and environmental conditions, such as vibration, temperature range, humidity, among others.
• FIGS.[0537]23A and23B—Configuration Generation
• There are a number of ways in which a configuration may be generated for a user. In one embodiment, the user may select from a set of pre-built configurations, for example, maintained by a vendor. In this embodiment, the user may select the configuration which most closely matches requirements for the desired task. For example, the set of pre-built configurations may focus on common configurations, including base I/O types such as AI, AO, DI, and DO, as well as derived I/O types including counters, timers, period measurement, and frequency measurement. In a preferred version of this embodiment, all of the I/O may be timed, and basic triggering is supported. A host interface may be memory mapped and exported as registers. For example, a set of registers may serve to show the state of the hardware, and allow the software to write new values or command actions by setting appropriate bits in the register set. A user may initiate a command action by setting one or more bits, and the system may responds by performing a specified action. In one embodiment, a host interface may be provided for each application development environment (ADE). Additionally, in one embodiment, each configuration may be defined by a G diagram, which may also serve as documentation for the configuration.[0538]
• In another embodiment, the hardware software boundary may be viewed as an interface between two objects that exchange messages. These messages may be either method invocations or set/get of attribute values. A standard interface may be defined that permits generic software-hardware calls. In one embodiment, the register set may be organized such that a first read starts a call, and if completed, returns an error code or status; if not completed the call may return an ID of the buffer in which the rest of the transaction will take place. If the hardware allows multiple threads to access the object, then the ID may be returned in the first call as well. The caller may pass and receive data in the buffer. Finally, after a sequence of reads and writes, the status returned may be completed on the last read. The code for the host interface (proxy), as described above, may be generated by a host interface generator executing in the development environment. In this manner, synchronization functionality may be provided while minimizing overhead.[0539]
• As described above, based on a LabVIEW FPGA diagram a host interface may be generated that provides access to some or all of the configurable aspects of a VI or object. In various embodiments, the generated host interface may be static or dynamic, i.e., it may be generated with specialized and optimized code to interface with one specific VI or object (static), or with multiple Vis or objects (dynamic). In the static case, communication and associated overhead between the host and the VI or object may be minimized. However, changes made to the VI or object may require corresponding changes to the application and/or the generated interface (register set). In one embodiment, an application target manager (as part of the ADE) may be used to help the user manage these target-related changes. For example, the target-specific host interface VIs (or text-based code) in the application may be marked with a special tag, allowing the application target manager to track such changes and update the application as necessary.[0540]
• In one embodiment, tools may be provided to the user to configure the board. For example, tools may be provided to locate the board (such as in a network), to download a configuration to the board, or to determine and locate measurement resources, among others. Additionally, tools may be provided to program the board, including tools to access the interface (registers) on a board for a given configuration. In a further embodiment, the user may make modifications to the selected pre-built configuration to more closely match the requirements.[0541]
• FIG. 23A illustrates one example of a breakout of the responsibilities of the main system components of a RIO based system using this approach. As FIG. 23A shows, in one embodiment,[0542]RIO hardware110 may provide timing, I/O, power on states, etc., while acontroller2302, such as LabVIEW RT, may provide algorithmic functionality, such as inline processing, control, and determinism (prescribed functionality). At runtime ahost102, e.g., a Windows based host, may optionally be present. At runtime the host may provide a GUI (graphical user interface), and supervisory behavior, among other host functions. As shown, thehost102 is the highest-level component of these primary system components, and communicates with thecontroller2302, which is the mid-level component. Thecontroller2302 in turn communicates with theRIO unit110, which is the low level system component, i.e., is the closest to the phenomenon being measured, controlled, etc. The fact that the presence of thehost102 at runtime is optional means that after the hardware configuration program has been created and deployed on theRIO unit110, the presence of the host (the computer system102) may not be required for the system to perform the specified measurement and/or control function.
• In another embodiment, the user may build a configuration from pre-defined blocks (configuration components), diagrams, or software modules using a configuration wizard, described above, to specify and assemble the configuration from the pre-defined blocks. In other words, the wizard may allow the user to select pre-defined blocks to build a custom configuration for the user's application. In one embodiment, the wizard may be used by the vendor to build the pre-built configurations mentioned. In one embodiment, a host interface may be generated to match the user-defined configuration. Similarly, host interfaces may be generated for each of the pre-built configurations mentioned above in the same manner.[0543]
• In yet another embodiment, the user may build a configuration using a development environment and user defined blocks, diagrams, or software components. For example, the user may create the configuration using user defined blocks based on the G graphical programming language, from National Instruments. In other words, the user may create G diagrams to define blocks. In one embodiment, these user-defined blocks may then be used by the wizard mentioned above as pre-built blocks. Thus, in one embodiment, an entire configuration may be defined with a G diagram. As mentioned above, a host interface may be generated to match each configuration.[0544]
• FIG. 23B illustrates another example of the breakout of the responsibilities of the main system components of a RIO based system using this approach (user-defined blocks). As FIG. 23B shows, in this embodiment, the[0545]RIO hardware110 may provide timing, I/O, power on states, etc., as well as algorithmic functionality, such as inline processing, control, and determinism (prescribed functions). Optionally, at runtime, thecontroller2302, (e.g., LabVIEW RT) may provide additional algorithmic functionality, as described above. Thus a first portion of a graphical program may be deployed on a processor and memory (e.g., LabVIEW RT), and a second portion of the graphical program may be deployed on a programmable hardware element (e.g., LabVIEW FPGA). Thehost102 may provide a development environment, a user interface which may provide configuration capabilities, a GUI (graphical user interface), and supervisory behavior, as also noted above. As indicated, when theRIO unit110 is configured with algorithmic functionality, thehost102 andcontroller2302 may not be required at runtime to perform the specified task, because the configuredRIO unit110 may be operable to perform the low-level basic hardware functions, as well as the algorithmic functionality required to perform the measurement task.
• In one embodiment, the G defined blocks may comprise a subset of the G language (the LabVIEW environment) which may be used to synthesize a diagram into a hardware implementation, e.g., an FPGA hardware configuration program. The use of the G defined blocks may provide software developers the ability to develop their own hardware in a constrained environment. In other words, the pre-defined blocks provide a limited palette of functionality usable by software developers to specify and configure hardware. Additionally, this approach may provide for substantially identical semantics between the hardware and software (development).[0546]
• FIG. 24—RIO Application Domains[0547]
• FIG. 24 illustrates a number of example application domains for RIO, with representative characteristic times for each domain. Although the times shown in FIG. 24 range from over a second down to roughly a microsecond, it is noted that as the performance of programmable hardware elements increases, the time resolution of possible applications may increase, perhaps dramatically, and so the domains shown in FIG. 24 are not meant to be limiting, but merely illustrative. As FIG. 24 shows, exemplary applications for RIO may range from relatively slow or low performance business applications, including retail point of sale (POS), trading, banking, and wholesale, where characteristic interaction times may be on the order of a second, to telecom testing, simulation, and hardware in the loop applications, where characteristic times approach 1 microsecond or less. Applications with characteristic times between these examples include (ordered approximately from slower to faster) industrial automation, medical diagnostics, mechanical test, hydraulic control, engine test, dynamic signal analysis, network control, and motion control. Thus, RIO technology is broadly applicable across a wide spectrum of application types and performance levels.[0548]
• Thus, in various embodiments, a programmable hardware element in a RIO system may be programmed or configured to implement a variety of digital and/or analog components capable of performing measurement (including data acquisition) and/or control (including automation) functions. The systems and methods described herein are particularly suitable for developing simple hardware functionality which is difficult to express in fixed hardware resources, including complex triggering, quadrature encoding, simple bit transfers, and the like. Additionally, in various embodiments, the programmable hardware element in the RIO system may be programmed or configured to implement an interface for communicating with a measurement module, where the interface is defined by interface protocol information transmitted by the measurement module.[0549]
• Although the system and method of the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.[0550]

Claims (105)

We claim:

1. A reconfigurable measurement system, comprising:

a computer system comprising a processor and a memory;

wherein the memory stores a measurement program, wherein the measurement program specifies a measurement function;

wherein the memory also stores a program which is executable to generate a hardware configuration program based on the measurement program; and

a device coupled to the computer system, wherein the device includes:

a programmable hardware element, wherein the hardware configuration program is operable to be deployed onto the programmable hardware element; and

one or more fixed hardware resources coupled to the programmable hardware element;

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the measurement function;

wherein the hardware configuration program further specifies usage of the one or more fixed hardware resources by the programmable hardware element in performing the measurement function; and

wherein, after the hardware configuration program is deployed onto the programmable hardware element, the device is operable to perform the measurement function.

2. The reconfigurable measurement system ofclaim 1,

wherein the device being operable to perform the measurement function comprises the programmable hardware element being operable to perform the measurement function in conjunction with the one or more fixed hardware resources.

3. The reconfigurable measurement system ofclaim 1,

wherein, after the hardware configuration program is deployed onto the programmable hardware element, the programmable hardware element is operable to:

directly perform a first portion of the measurement function; and

invoke the one or more fixed hardware resources to perform a second portion of the measurement function.

4. The reconfigurable measurement system ofclaim 3,

wherein the hardware configuration program specifies:

the first portion of the measurement function to be performed directly by the programmable hardware element; and

usage of the one or more fixed hardware resources by the programmable hardware element to perform the second portion of the measurement function.

5. The reconfigurable measurement system ofclaim 1,

wherein the one or more fixed hardware resources are operable to provide one or more of:

a control and data path to the computer system;

I/O interfacing to an external system;

optimized hardware elements; and

basic operating services.

6. The reconfigurable measurement system ofclaim 1,

wherein the programmable hardware element is operable to perform one or more of: I/O interfacing, timing and triggering, inline processing, and embedded decision-making.

7. The reconfigurable measurement system ofclaim 1,

wherein the device further comprises a processor and memory;

wherein at least a portion of the measurement program is operable to be stored in the memory and executed by the processor.

8. The reconfigurable measurement system ofclaim 1,

wherein the programmable hardware element includes a processor;

wherein at least a portion of the measurement program is operable to be executed by the processor.

9. The reconfigurable measurement system ofclaim 1,

wherein the programmable hardware element is configurable to implement a processor;

wherein at least a portion of the measurement program is operable to be executed by the processor.

10. The reconfigurable measurement system ofclaim 1,

wherein the programmable hardware element includes a reconfigurable analog portion;

wherein at least a portion of the measurement program is operable to be implemented by the reconfigurable analog portion.

11. The reconfigurable measurement system ofclaim 10,

wherein the reconfigurable analog portion comprises high-level analog components.

12. The reconfigurable measurement system ofclaim 10,

wherein the reconfigurable analog portion comprises low-level analog components which are operable to be configured to implement high-level analog components.

13. The reconfigurable measurement system ofclaim 1,

wherein the memory stores an application development environment for creating the measurement program.

14. The reconfigurable measurement system ofclaim 1,

wherein the device includes one or more slots adapted to receive one or more measurement modules;

wherein the device further includes a measurement module included in a slot of the device, wherein the measurement module implements a portion of the measurement function.

15. The reconfigurable measurement system ofclaim 1,

wherein the measurement program comprises a graphical program.

16. The reconfigurable measurement system ofclaim 15,

wherein the graphical program comprises a block diagram portion and a front panel portion;

wherein the program is executable to generate a hardware configuration program based on the block diagram portion; and

wherein the computer system is operable to display the front panel portion.

17. The reconfigurable measurement system ofclaim 1, wherein the measurement function comprises one or more of signal acquisition, signal conditioning, signal conversion, and measurement analysis.

18. The reconfigurable measurement system ofclaim 1,

wherein the programmable hardware element is a field programmable gate array (FPGA).

19. The reconfigurable measurement system ofclaim 1,

wherein the computer system is operable to display one or more panels on the display while the programmable hardware element in the device executes to perform the measurement function on the signal, wherein at least one of the one or more panels displays the measured signal.

20. The reconfigurable measurement system ofclaim 1,

wherein the device includes one or more slots adapted to receive one or more measurement modules;

wherein the device further includes a measurement module included in a slot of the device, wherein the measurement module implements a portion of the measurement function.

21. The reconfigurable measurement system ofclaim 20,

wherein the measurement module includes:

an input for acquiring a signal; and

measurement circuitry coupled to the input, wherein the measurement circuitry is operable to perform one or more of signal conditioning and signal conversion;

wherein the device is executable to perform the measurement function on an acquired signal.

22. The reconfigurable measurement system ofclaim 20,

wherein the measurement module further includes:

interface circuitry, wherein the interface circuitry is operable to provide an interface for the measurement circuitry;

wherein the interface circuitry is operable to provide an interface protocol describing the interface;

wherein the programmable hardware element is programmable to interface with the measurement module in accordance with the communicated interface protocol; and

wherein the device is operable to perform as one or more of a measurement device and a control device.

23. The reconfigurable measurement system ofclaim 22,

wherein the device is operable to communicate the provided interface protocol describing the interface to the computer system; and

wherein the computer system is operable to program the programmable hardware element to implement the interface protocol.

24. The reconfigurable measurement system ofclaim 22,

wherein the device is a card comprised in a slot of the computer system

25. The reconfigurable measurement system ofclaim 22,

wherein the device is coupled to the computer system over a network

26. A reconfigurable control system, comprising:

a computer system comprising a processor and a memory;

wherein the memory stores a control program, wherein the control program specifies a control function;

wherein the memory also stores a program which is executable to generate a hardware configuration program based on the control program; and

a device coupled to the computer system, wherein the device includes:

a programmable hardware element, wherein the hardware configuration program is operable to be deployed onto the programmable hardware element;

one or more fixed hardware resources coupled to the programmable hardware element;

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the control function;

wherein the hardware configuration program further specifies usage of the one or more fixed hardware resources by the programmable hardware element in performing the control function; and

wherein, after the hardware configuration program is deployed onto the programmable hardware element, the device is operable to perform the control function.

27. The reconfigurable control system ofclaim 26,

wherein the device being operable to perform the control function comprises the programmable hardware element being operable to perform the control function in conjunction with the one or more fixed hardware resources.

28. The reconfigurable control system ofclaim 26,

wherein, after the hardware configuration program is deployed onto the programmable hardware element, the programmable hardware element is operable to:

directly perform a first portion of the control function; and

invoke the one or more fixed hardware resources to perform a second portion of the control function.

29. The reconfigurable control system ofclaim 28,

wherein the hardware configuration program specifies:

the first portion of the control function to be performed directly by the programmable hardware element; and

usage of the one or more fixed hardware resources by the programmable hardware element to perform the second portion of the control function.

30. The reconfigurable control system ofclaim 26,

wherein the one or more fixed hardware resources are operable to provide one or more of:

a control and data path to the computer system;

I/O interfacing to an external system;

optimized hardware elements; and

basic operating services.

31. The reconfigurable control system ofclaim 26,

wherein the programmable hardware element is operable to perform one or more of: I/O interfacing, timing and triggering, inline processing, and embedded decision-making.

32. The reconfigurable control system ofclaim 26,

wherein the device further comprises a processor and memory; and

wherein at least a portion of the control program is operable to be stored in the memory and executed by the processor.

33. The reconfigurable control system ofclaim 26,

wherein the programmable hardware element includes a processor; and

wherein at least a portion of the control program is operable to be executed by the processor.

34. The reconfigurable control system ofclaim 26,

wherein the programmable hardware element is configurable to implement a processor; and

wherein at least a portion of the control program is operable to be executed by the processor.

35. The reconfigurable control system ofclaim 26,

wherein the programmable hardware element includes a reconfigurable analog portion; and

wherein at least a portion of the control program is operable to be implemented by the reconfigurable analog portion.

36. The reconfigurable control system ofclaim 26,

wherein the reconfigurable analog portion comprises high-level analog components.

37. The reconfigurable control system ofclaim 26,

wherein the reconfigurable analog portion comprises low-level analog components which are operable to be configured to implement high-level analog components.

38. The reconfigurable control system ofclaim 26,

wherein the memory stores an application development environment for creating the control program.

39. The reconfigurable measurement system ofclaim 38,

wherein the device includes one or more slots adapted to receive one or more control modules; and

wherein the device further includes a control module included in a slot of the device, and wherein the control module implements a portion of the measurement function.

40. The reconfigurable control system ofclaim 26,

wherein the control program comprises a graphical program.

41. The reconfigurable control system ofclaim 40,

wherein the graphical program comprises a block diagram portion and a front panel portion;

wherein the program is executable to generate a hardware configuration program based on the block diagram portion;

wherein the computer system is operable to display the front panel portion.

42. The reconfigurable control system ofclaim 26, wherein the control function comprises one or more of signal acquisition, signal conditioning, signal conversion, and control analysis.

43. The reconfigurable control system ofclaim 26,

wherein the programmable hardware element is an FPGA.

44. The reconfigurable control system ofclaim 26,

wherein the computer system is operable to display one or more panels on the display while the programmable hardware element in the device executes to perform the control function on the signal, wherein at least one of the one or more panels displays the measured signal.

45. The reconfigurable control system ofclaim 26,

wherein the device includes one or more slots adapted to receive one or more control modules; and

wherein the device further includes a control module included in a slot of the device, wherein the control module implements a portion of the control function.

46. The reconfigurable control system ofclaim 26,

wherein the control module includes:

an input for acquiring a signal; and

control circuitry coupled to the input, wherein the control circuitry is operable to perform one or more of signal conditioning and signal conversion;

wherein the device is executable to perform the control function on an acquired signal.

47. The reconfigurable control system ofclaim 46,

wherein the control module further includes:

interface circuitry, wherein the interface circuitry is operable to provide an interface for the control circuitry;

wherein the interface circuitry is operable to provide an interface protocol describing the interface;

wherein the programmable hardware element is programmable to interface with the control module in accordance with the communicated interface protocol; and

wherein the device is operable to perform as one or more of a control device and a control device.

48. The reconfigurable control system ofclaim 47,

wherein the device is operable to communicate the provided interface protocol describing the interface to the computer system; and

wherein the computer system is operable to program the programmable hardware element to implement the interface protocol.

49. The reconfigurable control system ofclaim 47,

wherein the device is operable to communicate the provided interface protocol describing the interface to the computer system; and

wherein the computer system is operable to program the programmable hardware element to implement the interface protocol.

50. The reconfigurable control system ofclaim 26,

wherein the device is a card comprised in a slot of the computer system

51. A method for configuring a device to perform a function, wherein the device includes a programmable hardware element and one or more fixed hardware resources, the method comprising:

creating a program, wherein the program represents the function;

generating a hardware configuration program based on the program, wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the function, and wherein the hardware configuration program further specifies usage of the one or more fixed hardware resources by the programmable hardware element in performing the function; and

configuring the programmable hardware element utilizing the hardware configuration program;

wherein, after said configuring, the device is operable to perform the function; and

wherein said device being operable to perform the function comprises the programmable hardware element being operable to directly perform a first portion of the function, and the programmable hardware element being operable to invoke operation of one or more of the fixed hardware resources to perform a second portion of the function.

52. The method ofclaim 51,

wherein the device comprises a measurement device; and

wherein the function comprises a measurement function.

53. The method ofclaim 51,

wherein the device comprises a control device; and

wherein the function comprises a control function.

54. The method ofclaim 51, further comprising:

the device operating to perform the function, wherein the device operating comprises:

the programmable hardware element directly performing the first portion of the function; and

the programmable hardware element invoking operation of one or more of the fixed hardware resources to perform the second portion of the function.

55. The method ofclaim 54,

wherein the device operating to perform the function comprises:

the device acquiring a signal from an external source; and

the programmable hardware element in the device executing to perform the function on the signal.

56. The method ofclaim 51, further comprising:

the device acquiring a signal from an external source after said configuring; and

the programmable hardware element in the device executing to perform the function on the signal.

57. The method ofclaim 56,

wherein, in performing the function, the programmable hardware element performs one or more of: I/O interfacing, timing and triggering, inline processing, and embedded decision-making.

58. The method ofclaim 56,

wherein the programmable hardware element in the device executing to perform the function on the signal comprises:

the programmable hardware element directly performing the first portion of the function; and

the programmable hardware element invoking operation of the one or more of the fixed hardware resources to perform the second portion of the function.

59. The method ofclaim 58,

wherein the one or more fixed hardware resources performing the second portion of the function comprises one or more of:

providing a control and data path from the device to the computer system;

providing I/O interfacing between the device and an external system;

providing optimized hardware elements for the device; and

providing basic operating services for the device.

60. The method ofclaim 51,

wherein the programmable hardware element includes a reconfigurable analog portion, the method further comprising:

the reconfigurable analog portion executing a portion of the program to perform a third portion of the function.

61. The method ofclaim 60,

wherein the reconfigurable analog portion comprises high-level analog components.

62. The method ofclaim 60,

wherein the reconfigurable analog portion comprises low-level analog components which are operable to be configured to implement high-level analog components.

63. The method ofclaim 51,

wherein the device further comprises a processor and memory, wherein a portion of the program is operable to be stored in the memory, the method further comprising:

the processor executing said portion of the program to perform a third portion of the function.

64. The method ofclaim 51,

wherein the programmable hardware element is configured to implement a processor, wherein the device further comprises a memory, and wherein a portion of the program is stored in the memory, the method further comprising:

the implemented processor executing said portion of the program to perform a third portion of the function.

65. The method ofclaim 51,

wherein the program comprises a graphical program.

66. The method ofclaim 65,

wherein the graphical program comprises a block diagram portion and a front panel portion;

wherein the program is executable to generate a hardware configuration program based on the block diagram portion; and

wherein the computer system is operable to display the front panel portion.

67. The method ofclaim 51, wherein the function comprises one or more of signal acquisition, signal conditioning, signal conversion, and measurement analysis.

68. The method ofclaim 51,

wherein the device is a small form factor device with dimensions less than about 2″ by 2″ by 1″.

69. The method ofclaim 51,

wherein the device includes an interface, wherein the interface comprises one or more of an Ethernet, Internet, USB, or FireWire interface.

70. The method ofclaim 51,

wherein the device includes one or more slots adapted to receive one or more measurement modules; and

wherein the device further includes a measurement module included in a slot of the device, the method further comprising:

the measurement module implementing a third portion of the function.

71. The method ofclaim 70,

wherein the measurement module includes:

an input for acquiring a signal; and

measurement circuitry coupled to the input, wherein the measurement circuitry is operable to perform one or more of signal conditioning and signal conversion;

the method further comprising:

the measurement module acquiring the signal via the input; and

the measurement circuitry performing one or more of signal conditioning and signal conversion on the acquired signal, thereby producing a conditioned signal;

the measurement module sending the conditioned signal to the device; and

the device performing the function on the conditioned signal.

72. The method ofclaim 70,

wherein the measurement module further includes interface circuitry for providing an interface for the measurement circuitry, the method further comprising:

the interface circuitry providing an interface protocol describing said interface; and

programming the programmable hardware element to interface with the measurement module in accordance with the communicated interface protocol.

73. The method ofclaim 72,

wherein said interface protocol describing the interface is provided to a computer system coupled to the device; and

wherein said programming the programmable hardware element to implement the interface protocol is performed by the computer system.

74. The method ofclaim 51,

wherein the device is a card comprised in a slot of a computer system.

75. The method ofclaim 51,

wherein the device is coupled to a computer system over a network.

76. The method ofclaim 51, further comprising:

displaying one or more panels on a display while the programmable hardware element in the device executes to perform the function on the signal, wherein at least one of the one or more panels displays the measured signal.

77. The method ofclaim 51,

wherein the programmable hardware element is an FPGA.

78. A reconfigurable measurement system, comprising:

a computer system comprising a processor and a memory;

wherein the memory stores a program, wherein the program specifies a function;

wherein the memory also stores a program which is executable to generate a hardware configuration program based on the program; and

a device coupled to the computer system, wherein the device includes:

a programmable hardware element, wherein the hardware configuration program is operable to be deployed onto the programmable hardware element; and

one or more fixed hardware resources coupled to the programmable hardware element;

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the function;

wherein the hardware configuration program further specifies usage of the one or more fixed hardware resources by the programmable hardware element in performing the function; and

wherein, after the hardware configuration program is deployed onto the programmable hardware element, the device is operable to perform the function.

79. The reconfigurable measurement system ofclaim 78,

wherein the device being operable to perform the function comprises the programmable hardware element being operable to perform the function in conjunction with the one or more fixed hardware resources.

80. The reconfigurable measurement system ofclaim 78,

wherein, after the hardware configuration program is deployed onto the programmable hardware element, the programmable hardware element is operable to:

directly perform a first portion of the function; and

invoke the one or more fixed hardware resources to perform a second portion of the function.

81. A memory medium comprising program instructions which are executable to configure a device to perform a function, wherein the device includes a programmable hardware element and one or more fixed hardware resources, wherein the memory medium stores:

a program, wherein the program specifies the function;

a hardware configuration program generated based on the program, wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the function, and wherein the hardware configuration program further specifies usage of the one or more fixed hardware resources by the programmable hardware element in performing the function; and

a deployment program executable to deploy the hardware configuration program onto the programmable hardware element;

wherein, after deployment, the device is operable to perform the function, wherein said device being operable to perform the function comprises the programmable hardware element being operable to directly perform a first portion of the function, and the programmable hardware element being operable to invoke operation of one or more of the fixed hardware resources to perform a second portion of the function.

82. The memory medium ofclaim 81,

wherein the function comprises a measurement function; and

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the measurement function.

83. The memory medium ofclaim 81,

wherein the function comprises a control function; and

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the control function.

84. The memory medium ofclaim 81, wherein the hardware configuration program comprises:

a first portion which is executable in the programmable hardware element to directly perform a first portion of the function; and

a second portion which is executable in the programmable hardware element to invoke operation of one or more of the fixed hardware resources to perform the second portion of the function.

85. The memory medium ofclaim 84,

wherein the hardware configuration program is executable to receive an acquired signal from an external source and execute to perform the function on the signal.

86. The memory medium ofclaim 85,

wherein the hardware configuration program includes functionality to perform one or more of: I/O interfacing, timing and triggering, inline processing, and embedded decision-making.

87. The memory medium ofclaim 85,

wherein the second portion of the hardware configuration is executable to invoke one or more fixed hardware resources to provide one or more of:

a control and data path from the device to the computer system;

I/O interfacing between the device and an external system;

optimized hardware elements for the device; and

basic operating services for the device.

88. The memory medium ofclaim 84,

wherein the hardware configuration program includes a third portion for configuring a reconfigurable analog portion in the programmable hardware element.

89. The memory medium ofclaim 81, wherein the device further comprises a processor and memory;

wherein at least a portion of the program is operable to be stored in the memory for execution by the processor to perform a third portion of the function.

90. The memory medium ofclaim 81,

wherein the program comprises a graphical program.

91. The memory medium ofclaim 90,

wherein the graphical program comprises a block diagram portion and a front panel portion;

wherein the deployment program is executable to generate a hardware configuration program based on the block diagram portion; and

wherein the computer system is operable to display the front panel portion.

92. The memory medium ofclaim 81, wherein the function comprises one or more of signal acquisition, signal conditioning, signal conversion, and measurement analysis.

93. The memory medium ofclaim 81,

wherein the device is a small form factor device with dimensions less than about 2″ by 2″ by 1″.

94. The memory medium ofclaim 81,

wherein the device is a card comprised in a slot of a computer system.

95. The memory medium ofclaim 81,

wherein the device is coupled to a computer system over a network.

96. The memory medium ofclaim 81, further comprising:

a display program for displaying one or more panels on a display while the hardware configuration executes in the programmable hardware element in the device to perform the function on an acquired signal, wherein at least one of the one or more panels displays the acquired signal.

97. The memory medium ofclaim 81,

wherein the programmable hardware element is an FPGA.

98. A memory medium comprising program instructions which are executable to configure a device to perform a function, wherein the device includes a programmable hardware element and one or more fixed hardware resources, wherein said program instructions are executable to perform:

creating a program, wherein the program implements the function;

generating a hardware configuration program based on the program, wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the function, and wherein the hardware configuration program further specifies usage of the one or more fixed hardware resources by the programmable hardware element in performing the function; and

deploying the hardware configuration program onto the programmable hardware element;

wherein, after said deploying, the device is operable to perform the function, wherein said device being operable to perform the function comprises the programmable hardware element being operable to directly perform a first portion of the function, and the programmable hardware element being operable to invoke operation of one or more of the fixed hardware resources to perform a second portion of the function.

99. The memory medium ofclaim 98,

wherein the function comprises a measurement function;

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the measurement function.

100. The memory medium ofclaim 98,

wherein the function comprises a control function;

wherein the hardware configuration program specifies a configuration for the programmable hardware element that implements the control function.

101. The memory medium ofclaim 98,

wherein the hardware configuration program comprises:

a first portion which is executable in the programmable hardware element to directly perform a first portion of the function; and

a second portion which is executable in the programmable hardware element to invoke operation of one or more of the fixed hardware resources to perform the second portion of the function.

102. The memory medium ofclaim 98, wherein said program instructions are further executable to perform:

receiving user input specifying the function, wherein said program is created based on the user input.

103. The memory medium ofclaim 98, wherein the program comprises a graphical data flow program.

104. A programmable hardware element which is configured with a hardware configuration program to perform a function, wherein the hardware configuration program comprises:

a first portion which is executable in the programmable hardware element to directly perform a first portion of the function; and

a second portion which is executable in the programmable hardware element to invoke operation of one or more of the fixed hardware resources to perform the second portion of the function.

105. The programmable hardware element ofclaim 104,

wherein the hardware configuration program further includes:

a third portion for configuring a reconfigurable analog portion in the programmable hardware element.

Images