Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
6608638
Kodosky , ; et al.
August 19, 2003
Title
System and method for configuring a programmable hardware instrument to perform measurement functions utilizing estimation of the hardware implentation and management of hardware resources
Abstract
A computer-implemented system and method for generating a hardware implementation of graphical code. The method may operate to configure an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element. The method comprises first creating a graphical program, wherein the graphical program may implement a measurement function. A portion of the graphical program may optionally be compiled into machine code for execution by a CPU, and another portion of the graphical program may be converted into a hardware implementation on a programmable hardware element. The programmable hardware element is configured utilizing a hardware description to produce a configured hardware element. The configured hardware element thus implements a hardware implementation of the second portion of the graphical program. During generation of the hardware implementation, the computer system may operate to estimate and/or display one or more of size and cost of a hardware implementation of the graphical program. In one embodiment, the graphical program manipulates one or more hardware resources of an instrument, and an indication of usage of the one or more hardware resources are displayed during creation of the graphical program. Probes may also be inserted into the graphical program, wherein corresponding probe elements are placed in the hardware implementation to implement the probe function.
Inventors:
Kodosky; Jeffrey L.
(Austin,
TX
)
, Andrade; Hugo
(Austin,
TX
)
, Odom; Brian Keith
(Georgetown,
TX
)
, Butler; Cary Paul
(Austin,
TX
)
, Mihal; Andrew
(Oakland,
CA
)
Assignee:
National Instruments Corporation
(Austin,
TX
)
Appl. No.:
499503
Filed:
February 7, 2000
Current U.S. Class:
715/771
703/22
Current International Class:
G09G 5/00 (20060101)
Field of Search:
345/773,839,771,967,965,964 702/57,66,69 703/22
U.S. Patent Documents
5555201
September 1996
Dangelo et al.
5603043
February 1997
Taylor et al.
5673198
September 1997
Lawman et al.
5732277
March 1998
Kodosky et al.
5987246
November 1999
Thomsen et al.
6212566
April 2001
Vanhoof et al.
6219628
April 2001
Kodosky et al.
6226776
May 2001
Panchul et al.
6230307
May 2001
Davis et al.
Other References
Wayne H. Wolf, "How to Build a Hardware Description and Measurement System on an Object-Oriented Programming Language," IEEE, 1989, pp., 288-301.
Primary Examiner:
Cabeca; John
Assistant Examiner:
Hailu; Tadesse
Attorney, Agent or Firm:
Meyertons Hood Kivlin Kowert & Goetzel, P.C. Hood; Jeffrey C.
Claims
We claim:
1. A computer-implemented method for configuring an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element, the method comprising: creating a graphical program, wherein the graphical program implements a measurement function; the computer system estimating one or more of size and cost of a hardware implementation of the graphical program; and the computer system displaying one or more of the size and cost of the hardware implementation of the graphical program to a user; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; configuring the programmable hardware element in the instrument utilizing the hardware description to produce a configured hardware element, wherein the configured hardware element implements a hardware implementation of the at least a portion of the graphical program; the instrument acquiring a signal from an external source after said configuring; and the programmable hardware element in the instrument executing to perform the measurement function on the signal.
2. The method of claim 1, wherein the graphical program comprises a plurality of elements, the method further comprising: storing a data structure including a listing of each of the elements and a corresponding cost of each element; wherein said estimating uses said data structure.
3. The method of claim 2, wherein the data structure stores cost in terms of one or more of gates and time of execution.
4. The method of claim 1, further comprising: determining if the programmable hardware element has sufficient capacity to implement the graphical program in response to said estimating, wherein said determining is performed prior to said generating the hardware description.
5. The method of claim 4, wherein said determining comprises: totaling the amount of gates utilized with regard to each element being used in the graphical program, and determining if the programmable hardware element has sufficient capacity to implement the graphical program based on the amount of gates.
6. The method of claim 1, further comprising: determining how fast the graphical program will execute in the programmable hardware element, wherein said determining is performed prior to said generating the hardware description.
7. The method of claim 1, further comprising: receiving user input regarding desired execution time of the hardware implementation of the graphical program; determining if the hardware implementation can execute according to the desired execution time, wherein said determining utilizes the execution times of each of the elements; displaying information to the user indicating whether the graphical program satisfies user input regarding time of execution.
8. The method of claim 1, further comprising: storing in the memory of the computer system a plurality of components, wherein said plurality of components include a first component of a first type and a second component of the first type, wherein the first component requires a first number of gates and wherein the second component requires a second larger number of gates; wherein said generating the hardware description includes selecting either said first component or said second component.
9. The method of claim 8, wherein either said first component or said second component is selected based on said estimating.
10. The method of claim 8, further comprising receiving user input indicating desired execution information; wherein either said first component or said second component is selected based on said user input.
11. The method of claim 10, wherein said desired execution information includes one or more of number of gates comprised in the programmable hardware element and a desired time of execution.
12. The method of claim 8, further comprising: storing in the memory of the computer system a library of components, wherein said library of components includes slower, less complex versions of components and faster, more complex versions of components; wherein said generating includes selecting among said slower, less complex versions of components and said faster, more complex versions of components.
13. The method of claim 1, wherein the instrument is selected based on one or more of the size and cost of the hardware implementation of the graphical program.
14. A computer-implemented method for configuring an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element, the method comprising: creating a graphical program, wherein the graphical program implements a measurement function, wherein the graphical program manipulates one or more hardware resources of the instrument, wherein said creating includes displaying an indication of usage of said one or more hardware resources during creation of the graphical program; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; configuring the programmable hardware element in the instrument utilizing the hardware description to produce a configured hardware element, wherein the configured hardware element implements a hardware implementation of the at least a portion of the graphical program; the instrument acquiring a signal from an external source after said configuring; the programmable hardware element in the instrument executing to perform the measurement function on the signal, wherein said executing includes manipulating one or more of the hardware resources of the instrument.
15. The method of claim 14, wherein said one or more hardware resources comprise non-reusable hardware resources; wherein said displaying an indication of usage of said one or more hardware resources during creation of the graphical program is designed to prevent a user from erroneously re-using said non-reusable hardware resources.
16. The method of claim 14, wherein said one or more hardware resources comprise non-reusable hardware esources; wherein said displaying an indication of usage comprises displaying icons representing said one or more hardware resources on a palette during creation of the graphical program; wherein said icons representing said one or more hardware resources disappear from said palette as said one or more hardware resources are used in the graphical program.
17. The method of claim 16, wherein, in said creating the graphical program, the icons representing said one or more hardware resources may be dragged from the palette into the graphical program.
18. The method of claim 14, wherein the one or more hardware resources include one or more of: A/D converters, D/A converters, timers, counters, clocks, input channels, output channels, and filters.
19. A computer-implemented method for configuring an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element, the method comprising: creating a graphical program, wherein the graphical program implements a measurement function, wherein the graphical program manipulates a non-reusable hardware resource of the instrument a plurality of times, wherein said creating the graphical program includes: constructing sequencing in the graphical program, wherein said sequencing prevents the non-reusable hardware resource from being used simultaneously within the graphical program; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; configuring the programmable hardware element in the instrument utilizing the hardware description to produce a configured hardware element, wherein the configured hardware element implements a hardware implementation of the at least a portion of the graphical program; the instrument acquiring a signal from an external source after said configuring; the programmable hardware element in the instrument executing to perform the measurement function on the signal, wherein said executing includes manipulating the non-reusable resource of the instrument a plurality of times according to said sequencing.
20. The computer-implemented method of claim 19, wherein said constructing sequencing is performed using a sequence structure.
21. The method of claim 19, further comprising: exporting at least a portion of the graphical program into a hardware description, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; wherein said exporting includes utilizing at least one multiplexer to multiplex control and data inputs to the non-reusable hardware resource with signals to guarantee that simultaneous accesses are impossible, as indicated by the sequencing.
22. A computer-implemented method for configuring a programmable hardware element to perform a function, the method comprising: creating a graphical program, wherein the graphical program comprises a plurality of interconnected nodes which visually indicate functionality of the program, wherein the graphical program specifies a function; the computer system estimating one or more of size and cost of a hardware implementation of the graphical program; the computer system displaying one or more of the size and cost of the hardware implementation of the graphical program to a user; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; and configuring the programmable hardware element utilizing the hardware description to produce a configured programmable hardware element, wherein the configured programmable hardware element implements a hardware implementation of the at least a portion of the graphical program.
23. The method of claim 22, further comprising: the configured programmable hardware element executing to perform the function.
24. The method of claim 22, wherein the programmable hardware element is comprised in a device, wherein the device includes an input for receiving a signal; the method further comprising: the device acquiring a signal from an external source after said configuring; and the configured programmable hardware element in the device executing to perform the function using the signal.
25. The method of claim 22, wherein the graphical program comprises a plurality of elements, the method further comprising: storing a data structure including a listing of each of the elements and a corresponding cost of each element; wherein said estimating uses said data structure.
26. The method of claim 25, wherein the data structure stores cost in terms of one or more of gates and time of execution.
27. The method of claim 22, further comprising: determining if the programmable hardware element has sufficient capacity to implement the graphical program in response to said estimating, wherein said determining is performed prior to said generating the hardware description.
28. The method of claim 27, wherein said determining comprises: totaling the amount of gates utilized with regard to each element being used in the graphical program; and determining if the programmable hardware element has sufficient capacity to implement the graphical program based on the amount of gates.
29. The method of claim 22, further comprising: determining how fast the graphical program will execute in the programmable hardware element, wherein said determining is performed prior to said generating the hardware description.
30. The method of claim 22, further comprising: receiving user input regarding desired execution time of the hardware implementation of the graphical program; determining if the hardware implementation can execute according to the desired execution time, wherein said determining utilizes the execution times of each of the elements; displaying information to the user indicating whether the graphical program satisfies the user input regarding time of execution.
31. The method of claim 22, further comprising: storing in the memory of the computer system a plurality of components, wherein said plurality of components include a first component of a first type and a second component of the first type, wherein the first component requires a first number of gates and wherein the second component requires a second larger number of gates; wherein said generating the hardware description includes selecting either said first component or said second component.
32. The method of claim 31, wherein either said first component or said second component is selected based on said estimating.
33. The method of claim 31, further comprising: receiving user input indicating desired execution information; wherein either said first component or said second component is selected based on said user input.
34. The method of claim 33, wherein said desired execution information includes one or more of number of gates comprised in the programmable hardware element and a desired time of execution.
35. The method of claim 31, further comprising: storing in the memory of the computer system a library of components, wherein said library of components includes slower, less complex versions of components and faster, more complex versions of components; wherein said generating includes selecting among said slower, less complex versions of components and said faster, more complex versions of components.
36. The method of claim 22, wherein the graphical program comprises a data flow diagram.
37. A computer-implemented method for configuring a device to perform a function, wherein the device includes a programmable hardware element, wherein the device also includes one or more hardware resources, the method comprising: creating a graphical program, wherein the graphical program comprises a plurality of interconnected nodes which visually indicate functionality of the program, wherein the graphical program implements a function, wherein the graphical program manipulates one or more hardware resources of the device, wherein said creating includes displaying an indication of usage of said one or more hardware resources during creation of the graphical program; generating a hardware description based on at least a portion of the graphical program, wherein the hardware, description describes a hardware implementation of the at least a portion of the graphical program; configuring the programmable hardware element in the device utilizing the hardware description to produce a configured programmable hardware element, wherein the configured programmable hardware element implements a hardware implementation of the at least a portion of the graphical program; the device executing, wherein the device executing includes the configured programmable hardware element in the device executing to perform the function, wherein said executing includes manipulating one or more of the hardware resources of the device.
38. The method of claim 37, further comprising: the device acquiring a signal from an external source after said configuring; the configured programmable hardware element in the device executing to perform the function on the signal, wherein said executing includes manipulating one or more of the hardware resources of the device.
39. The method of claim 37, wherein said one or more hardware resources comprise non-reusable hardware resources; wherein said displaying an indication of usage of said one or more hardware resources during creation of the graphical program is designed to prevent a user from erroneously re-using said non-reusable hardware resources.
40. The method of claim 37, wherein said displaying an indication of usage of said one or more hardware resources during creation of the graphical program is designed to prevent a user from creating the graphical program to use a hardware resource two or more times simultaneously during execution of the graphical program.
41. The method of claim 37, wherein said displaying an indication of usage comprises displaying icons representing said one or more hardware resources on a palette during creation of the graphical program; wherein said icons representing said one or more hardware resources disappear from said palette as said one or more hardware resources are used in the graphical program.
42. The method of claim 37, further comprising: displaying a palette comprising icons representing said one or more hardware resources during creation of the graphical program; wherein, in said creating the graphical program, the icons representing said one or more hardware resources may be dragged from the palette into the graphical program.
43. The method of claim 37, wherein said displaying an indication of usage comprises displaying icons representing said one or more hardware resources on a palette during creation of the graphical program; wherein said displaying comprises altering said icons in said palette to visually indicate the one or more hardware resources being used in the graphical program.
44. The method of claim 37, wherein the one or more hardware resources include one or more of: A/D converters, D/A converters, timers, counters, clocks, input channels, output channels, and filters.
45. The method of claim 37, wherein the graphical program comprises a data flow diagram.
46. A computer-implemented method for configuring a device, wherein the device includes a programmable hardware element, wherein the device also includes at least one hardware resource, the method comprising: creating a graphical program, wherein the graphical program implements a function, wherein the graphical program manipulates a first hardware resource of the device a plurality of times, wherein said creating the graphical program includes: constructing sequencing in the graphical program, wherein said sequencing prevents the first hardware resource from being used two or more times simultaneously within the graphical program; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; configuring the programmable hardware element in the device utilizing the hardware description to produce a configured programmable hardware element, wherein the configured programmable hardware element implements a hardware implementation of the at least a portion of the graphical program.
47. The method of claim 46, further comprising: the configured programmable hardware element in the device executing, wherein said executing includes manipulating the first hardware resource of the device a plurality of times according to said sequencing.
48. The method of claim 46, further comprising: the device acquiring a signal from an external source after said configuring; the configured programmable hardware element in the device executing to perform a function on the signal, wherein said executing includes manipulating the first hardware resource of the device a plurality of times according to said sequencing.
49. The method of claim 46, wherein said generating a hardware description includes utilizing at least one multiplexer to multiplex control and data inputs to the first hardware resource with signals to provide that simultaneous accesses are not performed, as indicated by the sequencing.
50. The method of claim 46, wherein the graphical program comprises a data flow diagram; and wherein said constructing sequencing operates to specify a sequence of execution of portions of the data flow diagram.
51. The computer-implemented method of claim 46, wherein said constructing sequencing is performed using a sequence structure.
52. The computer-implemented method of claim 51, wherein the sequence structure comprises a plurality of frames, wherein each of the frames includes a portion of graphical code that utilizes the first hardware resource; wherein the sequence structure specifies a sequencing of the frames to prevent simultaneous execution of the portions of graphical code comprised within the frames.
53. The computer-implemented method of claim 51, wherein the graphical program comprises a data flow diagram; wherein the sequence structure comprises a plurality of frames, wherein each of the frames includes a portion of the data flow diagram that utilizes the first hardware resource; wherein the sequence structure specifies a sequencing of the frames to prevent simultaneous execution of the portions of the data flow diagram comprised within the frames.
54. A memory medium comprising program instructions for configuring a programmable hardware element to perform a function, wherein the memory medium stores a graphical program, wherein the graphical program comprises a plurality of interconnected nodes which visually indicate functionality of the program, wherein the graphical program specifies a function; wherein the program instructions are executable to implement: estimating one or more of size and cost of a hardware implementation of the graphical program; displaying one or more of the size and cost of the hardware implementation of the graphical program to a user; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; and configuring the programmable hardware element utilizing the hardware description to produce a configured programmable hardware element, wherein the configured programmable hardware element implements a hardware implementation of the at least a portion of the graphical program.
55. The memory medium of claim 54, wherein the configured programmable hardware element is operable to execute to perform the function.
56. The memory medium of claim 54, wherein the programmable hardware element is comprised in a device, wherein the device includes an input for receiving a signal; wherein the device is operable to acquire a signal from an external source after being configured; and wherein the configured programmable hardware element in the device is operable to execute to perform the function using the signal.
57. The memory medium of claim 54, wherein the graphical program comprises a plurality of elements; wherein the program instructions comprise a data structure including a listing of each of the elements and a corresponding cost of each element; wherein said estimating uses said data structure.
58. The memory medium of claim 57, wherein the data structure stores cost in terms of one or more of gates and time of execution.
59. The memory medium of claim 54, wherein the program instructions are further executable to implement: determining if the programmable hardware element has sufficient capacity to implement the graphical program in response to said estimating, wherein said determining is performed prior to said generating the hardware description.
60. The memory medium of claim 59, wherein said determining comprises: totaling the amount of gates utilized with regard to each element being used in the graphical program; and determining if the programmable hardware element has sufficient capacity to implement the graphical program based on the amount of gates.
61. The memory medium of claim 54, wherein the program instructions are further executable to implement: determining how fast the graphical program will execute in the programmable hardware element, wherein said determining is performed prior to said generating the hardware description.
62. The memory medium of claim 54, wherein the program instructions are further executable to implement: receiving user input regarding desired execution time of the hardware implementation of the graphical program; determining if the hardware implementation can execute according to the desired execution time, wherein said determining utilizes the execution times of each of the elements; displaying information to the user indicating whether the graphical program satisfies the user input regarding time of execution.
63. The memory medium of claim 54, wherein the memory medium stores a plurality of components, wherein said plurality of components include a first component of a first type and a second component of the first type, wherein the first component requires a first number of gates and wherein the second component requires a second larger number of gates; wherein said generating the hardware description includes selecting either said first component or said second component.
64. The memory medium of claim 63, wherein either said first component or said second component is selected based on said estimating.
65. The memory medium of claim 63, wherein the program instructions are further executable to implement: receiving user input indicating desired execution information; wherein either said first component or said second component is selected based on said user input.
66. The memory medium of claim 65, wherein said desired execution information includes one or more of number of gates comprised in the programmable hardware element and a desired time of execution.
67. The memory medium of claim 63, wherein the memory medium stores a library of components, wherein said library of components includes slower, less complex versions of components and faster, more complex versions of components; wherein said generating includes selecting among said slower, less complex versions of components and said faster, more complex versions of components.
68. The memory medium of claim 54, wherein the graphical program comprises a data flow diagram.
69. A memory medium comprising program instructions for configuring a device to perform a function, wherein the device includes a programmable hardware element, wherein the device also includes one or more hardware resources, wherein the program instructions are executable to implement: creating a graphical program, wherein the graphical program comprises a plurality of interconnected nodes which visually indicate functionality of the program, wherein the graphical program implements a function, wherein the graphical program manipulates one or more hardware resources of the device, wherein said creating includes displaying an indication of usage of said one or more hardware resources during creation of the graphical program; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; configuring the programmable hardware element in the device utilizing the hardware description to produce a configured programmable hardware element, wherein the configured programmable hardware element implements a hardware implementation of the at least a portion of the graphical program.
70. The memory medium of claim 69, wherein the device is operable to execute, wherein execution of the device includes the configured programmable hardware element in the device executing to perform the function, wherein during execution the configured programmable hardware element manipulates one or more of the hardware resources of the device.
71. The memory medium of claim 69, wherein said one or more hardware resources comprise non-reusable hardware resources; wherein said displaying an indication of usage of said one or more hardware resources during creation of the graphical program is designed to prevent a user from erroneously re-using said non-reusable hardware resources.
72. The memory medium of claim 69, wherein said displaying an indication of usage of said one or more hardware resources during creation of the graphical program is designed to prevent a user from configuring the graphical program.to simultaneously accessing a hardware resource from two or more locations in the graphical program.
73. The memory medium of claim 69, wherein said displaying an indication of usage comprises displaying icons representing said one or more hardware resources on a palette during creation of the graphical program; wherein said icons representing said one or more hardware resources disappear from said palette as said one or more hardware resources are used in the graphical program.
74. The memory medium of claim 73, wherein, in said creating the graphical program, the icons representing said one or more hardware resources may be dragged from the palette into the graphical program.
75. The memory medium of claim 69, wherein said displaying an indication of usage comprises displaying icons representing said one or more hardware resources on a palette during creation of the graphical program; wherein said displaying comprises altering said icons in said palette to visually indicate the one or more hardware resources being used in the graphical program.
76. The memory medium of claim 69, wherein the program instructions are further executable to implement: displaying a palette comprising icons representing said one or more hardware resources during creation of the graphical program; wherein, in said creating the graphical program, the icons representing said one or more hardware resources may be dragged from the palette into the graphical program.
77. The memory medium of claim 69, wherein the one or more hardware resources include one or more of: A/D converters, D/A converters, timers, counters, clocks, input channels, output channels, and filters.
78. The memory medium of claim 69, wherein the graphical program comprises a data flow diagram.
79. A memory medium comprising program instructions for configuring a device, wherein the device includes a programmable hardware element, wherein the device also includes at least one hardware resource, the memory medium comprising: creating a graphical program, wherein the graphical program implements a function, wherein the graphical program manipulates a first hardware resource of the device a plurality of times, wherein said creating the graphical program includes: constructing sequencing in the graphical program, wherein said sequencing prevents the first hardware resource from being used two or more times simultaneously within the graphical program; generating a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program; and configuring the programmable hardware element in the device utilizing the hardware description to produce a configured programmable hardware element, wherein the configured programmable hardware element implements a hardware implementation of the at least a portion of the graphical program.
80. The memory medium of claim 79, wherein the configured programmable hardware element in the device is executable to manipulate the first hardware resource of the device a plurality of times according to said sequencing.
81. The memory medium of claim 79, wherein the device is operable to acquire a signal from an external source after said configuring; wherein the configured programmable hardware element in the device is executable to perform a function on the signal, wherein said executing includes manipulating the first hardware resource of the device a plurality of times according to said sequencing.
82. The memory medium of claim 79, wherein the graphical program comprises a data flow diagram.
83. The memory medium of claim 82, wherein said constructing sequencing operates to specify a sequence of execution of portions of the data flow diagram.
84. The computer-implemented memory medium of claim 79, wherein said constructing sequencing is performed using a sequence structure.
85. The computer-implemented memory medium of claim 84, wherein the sequence structure comprises a plurality of frames, wherein each of the frames includes a portion of graphical code that utilizes the first hardware resource; wherein the sequence structure specifies a sequencing of the frames to prevent simultaneous execution of the portions of graphical code comprised within the frames.
86. The computer-implemented memory medium of claim 84, wherein the graphical program comprises a data flow diagram; wherein said constructing sequencing is performed using a sequence structure, wherein the sequence structure comprises a plurality of frames, wherein each of the frames includes a portion of the data flow diagram that utilizes the first hardware resource; wherein the sequence structure specifies a sequencing of the frames to prevent simultaneous execution of the portions of the data flow diagram comprised within the frames.
87. The memory medium of claim 79, wherein said generating a hardware description includes utilizing at least one multiplexer to multiplex control and data inputs to the first hardware resource with signals to provide that simultaneous accesses are not performed, as indicated by the sequencing.
Description
FIELD OF THE INVENTION
The present invention relates to graphical programming, and in particular to a system and method for converting a graphical program into a hardware implementation. The present invention further relates to a system and method for configuring an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element
DESCRIPTION OF THE RELATED ART
Traditionally, high level text-based programming languages have been used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers or interpreters. The high level programming languages in this level, as well as the assembly language level, are referred to as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model or implement a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
Examples of fields in which computer systems are employed to model and/or control physical systems are the fields of instrumentation, process control, industrial automation, and simulation. Computer modeling or control of devices such as instruments or industrial automation hardware has become increasingly desirable in view of the increasing complexity and variety of instruments and devices available for use. However, due to the wide variety of possible testing/control situations and environments, and also the wide array of instruments or devices available, it is often necessary for a user to develop a program to control a desired system. As discussed above, computer programs used to control such systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of these systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation or industrial automation data. Thus, development and maintenance of the software elements in these systems often proved to be difficult.
U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; among others, to Kodosky et al disclose a graphical system and method for modeling a process, i.e., a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. A graphically based programming environment can be represented at a level above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor, such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. In response to the user constructing a data flow diagram or graphical program using the block diagram editor, data structures are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer. Therefore, a user can create a computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems, industrial automation systems, modeling processes, and simulation, as well as for any type of general programming.
Therefore, Kodosky et al teaches a graphical programming environment wherein a user places or manipulates icons in a block diagram using a block diagram editor to create a data flow "program." A graphical program for controlling or modeling devices, such as instruments, processes or industrial automation hardware, may be referred to as a virtual instrument (VI). In creating a virtual instrument, a user may create a front panel or user interface panel. The front panel includes various user interface elements or front panel objects, such as controls or indicators, that represent or display the respective input and output that will be used by the graphical program or VI, and may include other icons which represent devices being controlled. The front panel may be comprised in a single window of user interface elements, or may comprise a plurality of individual windows each having a user interface element, wherein the individual windows may optionally be tiled together. When the controls and indicators are created in the front panel, corresponding icons or terminals may be automatically created in the block diagram by the block diagram editor. Alternatively, the user can place terminal icons in the block diagram which may cause the display of corresponding front panel objects in the front panel, either at edit time or later at run time. As another example, the front panel objects may be embedded in the block diagram.
During creation of the graphical program, the user may selects various function nodes or icons that accomplish his desired result and connects the function nodes together. For example, the function nodes may be connected in a data flow or control flow format. The function nodes may be connected between the terminals of the respective controls and indicators. Thus the user may create or assemble a data flow program, referred to as a block diagram, representing the graphical data flow which accomplishes his desired process. The assembled graphical program may then be compiled or interpreted to produce machine language that accomplishes the desired method or process as shown in the block diagram.
A user may input data to a virtual instrument using front panel controls. This input data may propagate through the data flow block diagram or graphical program and appear as changes on the output indicators. In an instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial automation application the front panel can be analogized to the MMI (Man Machine Interface) of a device. The user may adjust the controls on the front panel to affect the input and view the output on the respective indicators. Alternatively, the front panel may be used merely to view the input and output, and the input may not be interactively manipulable by the user during program execution.
Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, simulation, and machine vision applications, among others.
A primary goal of graphical programming, including virtual instrumentation, is to provide the user the maximum amount of flexibility to create his/her own applications and/or define his/her own instrument functionality. In this regard, it is desirable to extend the level at which the user is able to program a device, e.g., extend the level at which a user of instrumentation or industrial automation hardware is able to program an instrument. The evolution of the levels at which the user has been able to program an instrument is essentially as follows. 1. User level software (LabVIEW, LabWindows CVI, Visual Basic, etc.) 2. Kernel level software 3. Auxiliary kernel level software (a second kernel running along side the main OS, e.g., InTime, VentureCom, etc.) 4. Embedded kernel level software 5. Hardware level software (FPGA--the present patent application)
In general, going down the above list, the user is able to create software applications which provide a more deterministic real-time response. Currently, most programming development tools for instrumentation or industrial automation provide an interface at level 1 above. In general, most users are unable and/or not allowed to program at the kernel level or auxiliary kernel level. The user level software typically takes the form of software tools that can be used to create software which operates at levels 1 and/or 4.
Current instrumentation solutions at level 5 primarily exist as vendor-defined solutions, i.e., vendor created modules. However, it would be highly desirable to provide the user with the ability to develop user level software which operates at the hardware level. More particularly, it would be desirable to provide the user with the ability to develop high level software, such as graphical programs, which can then be readily converted into hardware level functionality. This would provide the user with the dual benefits of being able to program device functionality at the highest level possible (text-based or graphical programs), while also providing the ability to have the created program operate directly in hardware for increased speed and efficiency.
SUMMARY OF THE INVENTION
The present invention comprises a computer-implemented system and method for automatically generating hardware level functionality, e.g., programmable hardware such as FPGAs or CPLDs, in response to a graphical program created by a user. This provides the user the ability to develop or define desired functionality using graphical programming techniques, while enabling the resulting program to operate directly in hardware.
The user first creates a graphical program which performs or represents the desired functionality. The graphical program may include one or more modules or a hierarchy of subprograms. In the preferred embodiment, the user may place various constructs in portions of the graphical program to aid in conversion of these portions into hardware form. As the user creates or assembles the graphical program on the display, data structures are automatically created and stored in memory corresponding to the graphical program being created.
The user may then select an option to convert the graphical program into executable form, wherein at least a portion of the graphical program is converted into a hardware implementation. According to one embodiment of the present invention, the user can select which portions of modules (or sub-VIs) are to be translated into hardware form, either during creation of the graphical program or when selecting the option to convert the graphical program into executable form. Thus the user can select a first portion of the graphical program, preferably comprising the supervisory control and display portion of the program, to be compiled into machine language for execution on a CPU. The user can select a second portion of the graphical program which is desired for hardware implementation. Alternatively, the selection of portions of the graphical program to be compiled for execution by the host CPU or to be provided for hardware implementation may be automatically performed by the system.
The portion of the graphical program selected for hardware implementation may first be converted to an abstract hardware graph, also referred to as a VDiagram tree. More specifically, the data structures corresponding to the graphical program may be converted into the abstract hardware graph or VDiagram tree. Thus the conversion may not be a one-step process of generating a hardware description directly from graphical program internal data structures, but rather preferably involves the VDiagram intermediate format. The VDiagram tree comprises data structures representing the functional objects of the graphical program and the data flow between them. VDiagrams are described in detail below.
The VDiagram tree may be parsed by a back end program module which generates a specific hardware description from the tree, such as a VHDL or EDIF hardware description. The hardware description may then converted into a hardware netlist. Netlists for various types of hardware devices may be created from a hardware description (e.g., FPGA-specific netlists, CPLD-specific netlists, etc.). As used herein, 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. For example, the back end may generate a VHDL file containing a hardware description of the graphical program. An FPGA-specific netlist may then be created from the VHDL file, wherein the netlist comprises information regarding the various FPGA components (and the logical relationship among those components) necessary to implement the hardware design described in the VHDL file.
The process of converting a hardware description such as a VHDL file into a netlist may be performed by readily available synthesis tools, as is well known in the art. The netlist may then be compiled into a hardware program file (also called a software bit stream) which may be used to program a programmable logic device (PLD) such as an FPGA or a CPLD, or other types of (re)configurable hardware devices. In the preferred embodiment, the hardware description is converted into an FPGA program file.
The step of compiling the resulting netlist into a PLD program file preferably uses a library of pre-compiled function blocks to aid in the compilation, as well as hardware target specific information. The library of pre-compiled function blocks includes netlist libraries for programmatic structures, such as for/next loops, while/do loops, case structures, and sequence structures, among others. This allows the user to program with high-level programming constructs, such as iteration, looping, and case structures, while allowing the resulting program to execute directly in hardware.
The resulting bit stream is then transferred to a PLD or other (re)configurable hardware device such as an FPGA to produce a programmed hardware device equivalent to the graphical program or block diagram.
The preferred embodiment of the invention comprises a general purpose computer system which includes a CPU and memory, and an interface card or device coupled to the computer system which includes programmable hardware or logic, such as an FPGA. The computer system includes a graphical programming system which is used to develop the graphical program. The computer system also includes software according to the present invention which is operable to convert the graphical program into an abstract hardware graph, and then convert the abstract hardware graph into a hardware description. The computer system further includes a synthesis tool which is used to compile the hardware description into a netlist, as well as other tools for converting the netlist into a PLD program file for uploading into the PLD. The computer system further includes a library of pre-compiled function blocks according to the present invention which are used by the synthesis tool to aid in creating the netlist.
As described above, in the preferred embodiment, a user creates a graphical program and then uses the system and method of the present invention to convert at least a portion of the graphical program into a hardware description. The hardware description may then be converted to a hardware program which executes on a PLD. The present invention thus extends the traditional model of software development to include the possibility of running at least a portion of a program on hardware created specifically for the program instead of running the entire program on the general-purpose processor.
However, it is noted that the use of the present invention is not limited to the creation of application programs as described above. The present invention comprises a system and method to create an abstract hardware graph from a graphical program. Various back end programs may be called to generate disparate types of hardware descriptions from the abstract hardware graph. These hardware descriptions may be used for purposes other than creating a bit stream for programming a PLD. For example, a hardware description may be used in the process of creating and printing a traditional circuit board which may be produced in mass quantities.
It is also noted that various back end programs may be called to generate software source code, such as C language code, from the abstract hardware graph. As described in detail below, the abstract hardware graph (VDiagram tree) generated by the present invention contains information regarding the execution order and data flow of the graphical program. This information may be used to establish a procedural order in a traditional programming language. Also, since the execution order for portions of a graphical program may be inherently parallel, the system and method of the present invention are well-suited for creating a program in a text-based parallel programming language.
In one embodiment, the target device including the reconfigurable hardware or PLD being programmed comprises a measurement device or card in the computer system, such as a data acquisition device or card, a GPIB interface card, a VXI interface card, or other measurement device. In an alternate embodiment, the target device being programmed comprises an instrument or device connected to the computer, such as through a serial connection. It is noted that the target instrument or device being programmed, which includes a PLD or other (re)configurable hardware element, can take any of various forms, as desired.
Thus the method may operate to configure an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element. First, the method creates a graphical program, wherein the graphical program implements a measurement function. The computer system may then estimate and then optionally display one or more of the size and cost of a hardware implementation of the graphical program.
In one embodiment, for example where the graphical program implements a measurement function, the graphical program manipulates one or more hardware resources of the instrument. Examples of hardware resources include A/D converters, D/A converters, timers, counters, clocks, etc. In this embodiment, creating the graphical program includes displaying an indication of usage, or the status of usage, of the one or more hardware resources during creation of the graphical program.
In another embodiment, the user may insert a probe at a location in the graphical program, wherein the probe is operable to display data generated at the location during execution of the graphical program. In this embodiment, the configured hardware element includes the probe element for implementing probing in the configured hardware element.
It is noted that non real-time clock cycle observations are possible in current FPGA's, such as Xilinx FPGAs, without external/explicit hooks. However, explicit probes/probe interfaces on the program of the FPGA allow external visibility and real-time performance.
The method then generates a hardware description based on at least a portion of the graphical program, wherein the hardware description describes a hardware implementation of the at least a portion of the graphical program. The programmable hardware element is then configured in the instrument utilizing the hardware description to produce a configured hardware element, wherein the configured hardware element implements a hardware implementation of the at least a portion of the graphical program. After the hardware element has been configured, the system may be executed. During execution, the instrument acquires a signal from an external source, and the programmable hardware element in the instrument executes to perform the measurement function on the signal.
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:
FIG. 1 illustrates the conversion of a graphical program to hardware and software implementations;
FIG. 2 illustrates the generation of various types of hardware and software descriptions from a VDiagram tree;
FIG. 3 illustrates the conversion of a graphical program into a hardware description and the use of the hardware description to program an FPGA;
FIG. 4 illustrates the conversion of a graphical program into a software source code description and the compilation and linkage of the source code;
FIG. 5A illustrates an instrumentation control system;
FIG. 5B illustrates an industrial automation system;
FIG. 6 is a block diagram of the instrumentation control system of FIG. 5A;
FIGS. 7, 7A and 7B are block diagrams illustrating an interface card configured with programmable hardware according to various embodiments of the present invention;
FIG. 8 is a flowchart diagram illustrating operation of the preferred embodiment of the invention, including compiling a first portion of the graphical program into machine language and converting a second portion of the graphical program into a hardware implementation;
FIG. 9 is a more detailed flowchart diagram illustrating creation of a graphical program according to the preferred embodiment;
FIG. 10 is a graphical representation of a VDiagram and the relationship among its elements;
FIG. 11 is an example VDiagram hierarchy illustrating the relationship of a parent VDiagram, child VDiagram, and srnholder for a simple graphical program;
FIG. 12 is a flowchart diagram illustrating the process of building a VDiagram tree for a graphical program;
FIG. 13 is a simple graphical program used as an example of building a VDiagram;
FIG. 14 is a more detailed flowchart diagram illustrating the step adding VDiagram information for each object in a graphical program;
FIG. 15 is a block diagram representing a VDiagram for the example program of FIG. 13;
FIG. 16 is an example graphical program containing a while loop structure;
FIGS. 17A and 17B are partial graphical programs illustrating aspects of the graphical program of FIG. 16;
FIG. 18 is a flowchart diagram illustrating how the flow of data from a parent VDiagram to a child VDiagram is represented;
FIG. 19 is a block diagram illustrating the relationship among structure controllers, srnholders, and child VDiagrams;
FIG. 20 is a block diagram illustrating how a structure controller drives the enable ports for a VDiagram representing a while loop subframe;
FIG. 21 is an example program hierarchy in which the same global variable is read in one subprogram and written in another subprogram;
FIGS. 22 and 23 are block diagrams illustrating the hardware represented by VDiagrams for various subprograms of FIG. 21;
FIGS. 24 and 25 are block diagrams illustrating the ports, components, and connections added to VDiagrams for various subprograms of FIG. 21;
FIG. 26 is a block diagram illustrating the ports, signals, and components that are created to manage a global variable resource with two read and two write access points;
FIG. 27 is a flowchart diagram illustrating operation where the method exports an output terminal into a hardware description;
FIG. 28 is a flowchart diagram illustrating operation where the method exports an input terminal into a hardware description;
FIG. 29 is a flowchart diagram illustrating how a back end program may generate VHDL syntax from a VDiagram tree;
FIGS. 30 and 31 illustrate a simple example of operation of the present invention, wherein FIG. 30 illustrates a simple graphical program and FIG. 31 is a conceptual diagram of the hardware description of the graphical program of FIG. 30;
FIGS. 32-34 illustrate another example of operation of the present invention, wherein FIG. 32 illustrates a graphical program, FIG. 33 illustrates a tree of data structures created in response to the graphical program of FIG. 32, and FIG. 34 is a conceptual diagram of the hardware description of the graphical program of FIG. 32; and
FIGS. 35-36 illustrate a graphical program called example1.vi.
FIG. 37 illustrates storing data structure listing graphical programing elements and corresponding cost;
FIG. 38 illustrates receiving user input regarding execution time of the hardware implementation of the graphical program;
FIG. 39 illustrates displaying an indication of usage of hardware resources during creation of the graphical program.
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.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Incorporation by Reference
The following U.S. Patents and patent applications are hereby incorporated by reference in their entirety as though fully and completely set forth herein.
U.S. Pat. No. 4,901,221 titled "Graphical System for Modeling a Process and Associated Method," issued on Feb. 13, 1990.
U.S. Pat. No. 4,914,568 titled "Graphical System for Modeling a Process and Associated Method," issued on Apr. 3, 1990.
U.S. Pat. No. 5,481,741 titled "Method and Apparatus for Providing Attribute Nodes in a Graphical Data Flow Environment".
U.S. patent application Ser. No. 08/292,091 filed Aug. 17, 1994, titled "Method and Apparatus for Providing Improved Type Compatibility and Data Structure Organization in a Graphical Data Flow Diagram".
U.S. Pat. No. 5,475,851 titled "Method and Apparatus for Improved Local and Global Variable Capabilities in a Graphical Data Flow Program".
U.S. Pat. No. 5,497,500 titled "Method and Apparatus for More Efficient Function Synchronization in a Data Flow Program".
U.S. patent application Ser. No. 08/474,307 titled "Method and Apparatus for Providing Stricter Data Type Capabilities in a Graphical Data Flow Environment" filed Jun. 7, 1995.
U.S. Pat. No. 5,481,740 titled "Method and Apparatus for Providing Autoprobe Features in a Graphical Data Flow Diagram".
U.S. patent application Ser. No. 08/870,262 titled "System and Method for Detecting Differences in Graphical Programs" filed Jun. 6, 1997, whose inventor is Ray Hsu.
U.S. patent application Ser. No. 08/912,445 titled "Embedded Graphical Programming System" filed Aug. 18, 1997, whose inventors are Jeffrey L. Kodosky, Darshan Shah, Samson DeKey, and Steve Rogers.
The above-referenced patents and patent applications disclose various aspects of the LabVIEW graphical programming and development system.
The LabVIEW and BridgeVIEW graphical programming manuals, including the "G Programming Reference Manual", available from National Instruments Corporation, are also hereby incorporated by reference in their entirety.
FIG. 1--Block Diagram
FIG. 1 is a block diagram illustrating the conversion of a graphical program into hardware and software descriptions. The graphical program 300 comprises graphical code, such as interconnected function nodes or icons. The graphical code in the graphical program may use graphical data flow and/or graphical control flow constructs. On the display, the graphical program is represented as interconnected icons or function nodes. In the memory of the computer system, the graphical program 300
comprises data structures representing functional operations, data flow and/or control flow, and 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 are automatically created and stored in memory.
The graphical program 300 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 program 300 is a LabVIEW graphical program or virtual instrument (VI).
Programs of the present invention create the VDiagram tree 302 from the data structures of the graphical program 300. The VDiagram tree 302 is an abstract hardware graph which represents at least a portion of the graphical program 300. The graph is 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 tree 302
(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 hardware description 304 may be generated from the abstract hardware graph 302 by a back end program. The hardware description 304 may be in various hardware description languages such as VHDL, EDIF, and Verilog. In the preferred embodiment, the hardware description 304 comprises one or more VHDL files. A hardware netlist 306 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, the hardware netlist 306 is an FPGA-specific netlist. The hardware netlist 306 is used to create or configure one or more functional hardware devices or hardware elements 308 which are configured to execute the portion of the graphical program 300 that is represented by the abstract hardware graph 302.
Hardware element 308 may comprise any of various devices. For example, hardware 308 may comprise a programmable logic device (PLD) such as an FPGA or CPLD. However, hardware 308 may comprise other types of hardware devices, such as a traditional circuit board which is created using the hardware netlist 306. In the preferred embodiment, hardware 308 is an interface card comprising an FPGA, wherein the interface card is comprised in the computer system where the graphical program 300
is created. The hardware 308 may also be comprised in an external device connected to the computer system where the graphical program 300 is created. The hardware 308 may be connected to the computer over an external serial or parallel bus, or over a network, such as the Internet.
As shown in FIG. 1, software description source code 310 may also be generated from the abstract hardware graph 302 by a back end program. The source code 310 may be in various source code languages such as C, C++, Java, etc. Machine code 312
may be produced from the source code 310 using various source code compilers. Linked machine code 314 may be produced from the machine code 312 using various machine code linkers. The linked machine code 314 is executable to perform the operations of the portion of the graphical program 300 that is represented by the abstract hardware graph 302.
FIG. 2--Block Diagram
FIG. 2 is a block diagram illustrating the generation of various types of hardware and software descriptions from a VDiagram tree. As described for FIG. 1, programs of the present invention create a VDiagram tree 302 from a graphical program
300. The VDiagram tree 302 represents at least a portion of the graphical program 300. Back end programs 330 generate hardware descriptions from the VDiagram tree 302. Exemplary back end programs 330A, 330B, and 330C are illustrated. Back end 330A generates a VHDL hardware description comprising one or more VHDL files. Back end 330B generates an EDIF hardware description comprising one or more EDIF files. Back end 330C generates a C source code software description comprising one or more C files.
The number and type of back end programs that may be present are not limited. In the preferred embodiment, one or more back end programs may be called automatically as part of a process initiated by a user to generate hardware/software descriptions for the graphical program 300. In another embodiment, the VDiagram tree 302 may be generated and saved to a file, and the user may call a back end program at a later time to generate a hardware/software description.
As described above for FIG. 1, appropriate synthesis tools or compilers may be called to convert a hardware/software description into another format such as an FPGA-specific netlist or compiled machine code.
FIG. 3--Block Diagram
FIG. 3 illustrates the exportation of at least a portion of a graphical program 300 into a hardware description and the use of the hardware description to program an FPGA. As described above for FIG. 1, the VDiagram tree 302 comprises information representing the graphical program 300, including the functional operations of the program. As described in detail below, the VDiagram tree comprises VDiagrams, each of which maintains a list of components. This list of components includes components which represent functional operations.
A back end program converts the VDiagram tree 302 to a hardware description 304. 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 the preferred embodiment, such functional components are simply referenced as library components.
FIG. 3 illustrates the preferred embodiment in which the VDiagram tree references one or more library components. The present invention comprises pre-compiled function blocks 342 which implement these library components for particular hardware devices such as FPGAs. Various FPGA netlist synthesis tools may be called to generate an FPGA netlist 340 from the hardware description 304. These synthesis tools may incorporate the pre-compiled function blocks 342 into the FPGA netlist 340. Also, as shown, the synthesis tools may 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.
An FPGA bit stream program file 346 may be generated from the FPGA netlist 340 using readily available synthesis tools. This FPGA program file may be uploaded to an FPGA 348. The FPGA 348 may be comprised in a hardware device such as an interface board. After being programmed with the program file 346, the FPGA is able to execute the portion of the graphical program 300 that is exported to the hardware description 304. 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. Details follow on how the execution of the FPGA portion is coordinated with the execution of the main CPU portion and how the external hardware resource requirements for the FPGA portion are managed.
FIG. 4--Block Diagram
FIG. 4 illustrates the exportation of at least a portion of a graphical program 300 into a software source code description and the compilation and linkage of the source code. As shown, the graphical program data structures may be first converted to a VDiagram tree 302 and then to software description source code 310.
As described above for FIG. 3, in the preferred embodiment the VDiagram tree 302 references library components to represent various functional components of the graphical program. These library components may be implemented in libraries, class libraries, macro definitions, etc. 360. As shown in FIG. 4, these class libraries, etc. may be used to produce the machine code 312 from the source code 310. Also, binary object libraries 362 may implement some functionality of the software description. These binary object libraries may be linked in with the machine code 312 is linked to produce the linked executable code 314. Libraries 360 and 362 may also contain compiler-specific or platform-specific information necessary to produce executable code 314. Linked code 314 may be executed to perform the operations of the portion of the graphical program that is exported to the software source code description 310.
FIGS. 5A and 5B--Instrumentation and Industrial Automation Systems
The following describes embodiments of the present invention involved with controlling and/or modeling instrumentation or industrial automation hardware. However, it is noted that the present invention can be used to create hardware implementations of graphical programs for a plethora of applications and are not limited to instrumentation or industrial automation applications. In other words, the following description is exemplary only, and the present invention may be used in any of various types of systems. Thus, the system and method of the present invention is operable for automatically creating hardware implementations of graphical programs or graphical code for any of various types of applications, including the control of other types of devices such as multimedia devices, video devices, audio devices, telephony devices, Internet devices, etc., as well as general purpose software applications such as word processing, spreadsheets, network control, games, etc.
FIG. 5A illustrates an instrumentation control system 100. The system 100 comprises a host computer 102 which connects to one or more instruments. The host computer 102 comprises a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects through the one or more instruments to analyze, measure or control a unit under test (UUT) or process 150.
The one or more instruments may include a GPIB instrument 112 and associated GPIB interface card 122, a data acquisition board 114 and associated signal conditioning circuitry 124, a VXI instrument 116, a PXI instrument 118, a video device 132
and associated image acquisition card 134, a motion control device 136 and associated motion control interface card 138, and/or one or more computer based instrument cards 142, among other types of devices.
The GPIB instrument 112 is coupled to the computer 102 via the GPIB interface card 122 provided by the computer 102. In a similar manner, the video device 132 is coupled to the computer 102 via the image acquisition card 134, and the motion control device 136 is coupled to the computer 102 through the motion control interface card 138. The data acquisition board 114 is coupled to the computer 102, and preferably interfaces through signal conditioning circuitry 124 to the UUT. The signal conditioning circuitry 124 preferably comprises an SCXI (Signal Conditioning eXtensions for Instrumentation) chassis comprising one or more SCXI modules 126.
The GPIB card 122, the image acquisition card 134, the motion control interface card 138, and the DAQ card 114 are typically plugged in to an I/O slot in the computer 102, such as a PCI bus slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot provided by the computer 102. However, these cards 122, 134, 138 and 114 are shown external to computer 102 for illustrative purposes. These devices may also be connected to the computer 102 through a serial bus or through other means.
The VXI chassis or instrument 116 is coupled to the computer 102 via a VXI bus, MXI bus, or other serial or parallel bus provided by the computer 102. The computer 102 preferably includes VXI interface logic, such as a VXI, MXI or GPIB interface card (not shown), which interfaces to the VXI chassis 116. The PXI chassis or instrument is preferably coupled to the computer 102 through the computer's PCI bus.
A serial instrument (not shown) may also be coupled to the computer 102 through a serial port, such as an RS-232 port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 bus, provided by the computer 102. In typical instrumentation control systems an instrument will not be present of each interface type, and in fact many systems may only have one or more instruments of a single interface type, such as only GPIB instruments.
In the embodiment of FIG. 5A, one or more of the devices connected to the computer 102 include programmable or reconfigurable hardware according to the present invention. For example, one or more of the GPIB card 122, the DAQ card 114, a VXI card in VXI chassis 116, a PXI card in PXI chassis 118, the image acquisition board 134, the motion control board 138, or a computer-based instrument, include programmable hardware according to the present invention. Alternatively, or in addition, one or more of the GPIB instrument 112, the VXI instrument 116, the serial instrument, or another type of device include programmable hardware according to the present invention. Where the programmable hardware is comprised on a VXI or PXI card, the programmable hardware may be configured to control one or more other VXI or PXI cards, respectively, comprised in the respective chassis. In the preferred embodiment, the programmable hardware comprises a field programmable gate array (FPGA).
The instruments are coupled to the unit under test (UUT) or process 150, or are coupled to receive field signals, typically generated by transducers. The system 100 may be used in a data acquisition and control application, in a test and measurement application, a process control application, or a man-machine interface application.
FIG. 5B illustrates an exemplary industrial automation system 160. The industrial automation system 160 is similar to the instrumentation or test and measurement system 100 shown in FIG. 5A. Elements which are similar or identical to elements in FIG. 5A have the same reference numerals for convenience. The system 160 comprises a computer 102 which connects to one or more devices or instruments. The computer 102 comprises a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects through the one or more devices to a process or device 150 to perform an automation function, such as MMI (Man Machine Interface), SCADA (Supervisory Control and Data Acquisition), portable or distributed data acquisition, process control, advanced analysis, or other control.
The one or more devices may include a data acquisition board 114 and associated signal conditioning circuitry 124, a PXI instrument 118, a video device 132 and associated image acquisition card 134, a motion control device 136 and associated motion control interface card 138, a fieldbus device 170 and associated fieldbus interface card 172, a PLC (Programmable Logic Controller) 176, a serial instrument 182 and associated serial interface card 184, or a distributed data acquisition system, such as the Fieldpoint system available from National Instruments, among other types of devices.
The DAQ card 114, the PXI chassis 118, the video device 132, and the image acquisition card 136 are preferably connected to the computer 102 as described above. The serial instrument 182 is coupled to the computer 102 through a serial interface card 184, or through a serial port, such as an RS-232 port, provided by the computer 102. The PLC 176 couples to the computer 102 through a serial port, Ethernet port, or a proprietary interface. The fieldbus interface card 172 is preferably comprised in the computer 102 and interfaces through a fieldbus network to one or more fieldbus devices. Each of the DAQ card 114, the serial card 184, the fieldbus card 172, the image acquisition card 134, and the motion control card 138 are typically plugged in to an I/O slot in the computer 102 as described above. However, these cards 114, 184, 172, 134, and 138 are shown external to computer 102 for illustrative purposes. In typical industrial automation systems a device will not be present of each interface type, and in fact many systems may only have one or more devices of a single interface type, such as only PLCs. The devices are coupled to the device or process 150.
In the embodiment of FIG. 5B, one or more of the devices connected to the computer 102 include programmable hardware according to the present invention. For example, one or more of the data acquisition board 114, the serial instrument 142, the serial interface card 152, the PLC 144, or the fieldbus network card 156 include programmable hardware according to the present invention. In the preferred embodiment, the programmable hardware comprises a field programmable gate array (FPGA).
As noted above, the programmable hardware may be comprised in a device which connects to the computer 102 over a network, such as the Internet. In one embodiment, the user operates to select a target device from a plurality of possible target devices for programming or configuration according to the present invention.
Referring again to FIGS. 5A and 5B, the computer 102 preferably includes a memory medium on which computer programs according to the present invention are stored. 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 floppy disks 104, on which the computer programs according to the present invention are stored for loading into the computer system. The term "memory medium" may also include other types of memory.
The memory medium may be comprised in the computer 102 where the programs are executed or may be located on a second computer which is coupled to the computer 102 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 the computer 102 for execution.
The software programs of the present invention are stored in a memory medium of the respective computer 102, 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 converting graphical programs into hardware implementations according to the steps described below.
The memory medium preferably stores a graphical programming development system for developing graphical programs. The memory medium also stores computer programs according to the present invention which are executable to convert at least a portion of a graphical program into a form for configuring or programming the programmable hardware or FPGA.
The instruments or devices in FIGS. 5A and 5B are controlled by graphical software programs, optionally a portion of which execute on the CPU of the computer 102, and at least a portion of which are uploaded to the programmable hardware element for hardware execution. The graphical software programs which perform data acquisition, analysis and/or presentation, e.g., for instrumentation control or industrial automation, may be referred to as virtual instruments.
In the preferred embodiment, the present invention is comprised in the LabVIEW or BridgeVIEW graphical programming systems, hereafter collectively referred to as LabVIEW, available from National Instruments. Also, in the preferred embodiment, the term "LabVIEW" is intended to include graphical programming systems which include G programming functionality, i.e., which include at least a portion of LabVIEW graphical programming functionality, including the BridgeVIEW graphical programming system.
Also, the term "graphical programming system" is intended to include any of various types of systems which are used to develop or create graphical code or graphical programs, including LabVIEW, BridgeVIEW, and DASYLab from National Instruments, Visual Designer from Intelligent Instrumentation, Hewlett-Packard's VEE (Visual Engineering Environment), Snap-Master by HEM Data Corporation, GFS DiaDem, and ObjectBench by SES (Scientific and Engineering Software), Simulink, WiT, Vision Program Manager, Hypersignal, VisiDAQ, VisSim, and Khoros, among others.
Although in the preferred embodiment the graphical programs and programmable hardware are involved with data acquisition/generation, analysis, and/or display, and for controlling or modeling instrumentation or industrial automation hardware, as noted above the present invention can be used to create hardware implementations of graphical programs for a plethora of applications and is not limited to instrumentation or industrial automation applications. In other words, FIGS. 5A and 5B are exemplary only, and the present invention may be used in any of various types of systems. Thus, the system and method of the present invention is operable for automatically creating hardware implementations of graphical programs or graphical code for any of various types of applications, including general purpose software applications such as word processing, spreadsheets, network control, games, etc.
FIG. 6--Computer Block Diagram
FIG. 6 is a block diagram of the computer 102 of FIGS. 5A and 5B. The elements of a computer not necessary to understand the operation of the present invention have been omitted for simplicity. The computer 102 includes at least one central processing unit or CPU 160 which is coupled to a processor or host bus 162. The CPU 160 may be any of various types, including an x86 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 memory 166 is coupled to the host bus 162 by means of memory controller 164. The main memory 166 stores a graphical programming system, and also stores software for converting at least a portion of a graphical program into a hardware implementation. This software will be discussed in more detail below. The main memory 166 also stores operating system software as well as the software for operation of the computer system, as well known to those skilled in the art.
The host bus 162 is coupled to an expansion or input/output bus 170 by means of a bus controller 168 or bus bridge logic. The expansion bus 170 is preferably the PCI (Peripheral Component Interconnect) expansion bus, although other bus types can be used. The expansion bus 170 includes slots for various devices such as the data acquisition board 114 (of FIG. 5), a GPIB interface card 122 which provides a GPIB bus interface to the GPIB instrument 112 (of FIG. 5), and a VXI or MXI bus card 230
coupled to the VXI chassis 116 for receiving VXI instruments. The computer 102 further comprises a video display subsystem 180 and hard drive 182 coupled to the expansion bus 170.
One or more of the interface cards or devices coupled to the expansion bus, such as the DAQ card 114, the GPIB interface card 122, or the GPIB instrument 112 comprises programmable hardware such as a field programmable gate array (FPGA). The computer 102 may also include a network interface card for coupling to a network, wherein the target device containing the programmable hardware is coupled to the network.
FIG. 7--Programmable Hardware Diagram
FIG. 7 is a block diagram illustrating a device, e.g., an interface card, configured with programmable hardware according to the present invention. It is noted that FIG. 7 is exemplary only, and an interface card or device 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 the computer 102, and may be connected to the computer through a network, such as the Internet. The interface card illustrated in FIG. 7 is the DAQ interface card 114 shown in either of FIG. 5A or 5B. However, as noted above, the programmable hardware may be included on any of the various devices shown in FIG. 5A or 5B, or on other devices, as desired. Also, the programmable hardware illustrated in FIG. 7 is an FPGA, but the device may include another type of programmable hardware instead, such as a CPLD or other type of (re)configurable hardware.
As shown, the interface card 114 includes an I/O connector 202 which is coupled for receiving signals. In the embodiments of FIGS. 5A and 5B, the I/O connector 202 presents analog and/or digital connections for receiving/providing analog or digital signals. The I/O connector 202 is adapted for coupling to SCXI conditioning logic 124 and 126, or is adapted to be coupled directly to a unit under test 130 or process 160.
The interface card 114 also includes data acquisition (DAQ) logic 204. As shown, the data acquisition logic 204 comprises analog to digital (A/D) converters, digital to analog (D/A) converters, timer counters (TC) and signal conditioning (SC) logic as shown. The DAQ logic 204 provides the data acquisition functionality of the DAQ card 114. In one embodiment, the DAQ logic 204 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. The programmable hardware element or FPGA can access these resources directly, thereby enabling creation of very powerful DSP and control applications, among others.
According to the preferred embodiment of the invention, the interface card 114 includes a programmable hardware element or programmable processor 206. In the preferred embodiment, the programmable hardware 206 comprises a field programmable gate array (FPGA) such as those available from Xilinx, Altera, etc. The programmable hardware element 206 is coupled to the DAQ logic 204 and is also coupled to the local bus interface 208. Thus a graphical program can be created on the computer 102, 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 the FPGA 206. The portion of the graphical program converted into a hardware implementation form is preferably a portion which requires fast and/or real-time execution
In the embodiment of FIG. 7, the interface card 114 further includes a dedicated on-board microprocessor 212 and memory 214. This enables a portion of the graphical program to be compiled into machine language for storage in the memory 214 and execution by the microprocessor 212. This is in addition to a portion of the graphical program being converted into a hardware implementation form in the FPGA 206. Thus, in one embodiment, after a graphical program has been created, a portion of the graphical program is compiled for execution on the embedded CPU 212 and executes locally on the interface card 114 via the CPU 212 and memory 214, and a second portion of the graphical program is translated or converted into a hardware executable format and uploaded to the FPGA 206 for hardware implementation.
As shown, the interface card 114 further includes bus interface logic 216 and a control/data bus 218. In the preferred embodiment, the interface card 114 is a PCI bus-compliant interface card adapted for coupling to the PCI bus of the host computer 102, or adapted for coupling to a PXI (PCI eXtensions for Instrumentation) bus. The bus interface logic 216 and the control/data bus 218 thus present a PCI or PXI interface.
The interface card 114 also includes local bus interface logic 208. In the preferred embodiment, the local bus interface logic 208 presents a RTSI (Real Time System Integration) bus for routing timing and trigger signals between the interface card 114 and one or more other devices or cards.
In one embodiment, the interface card 114 also includes a non-volatile memory (not shown) coupled to the programmable hardware element 206. The non-volatile memory is operable to store the hardware description received from the host computer system to enable execution of the hardware description in the programmable hardware element 206 prior to or during booting of the computer system 102.
In the embodiment of FIG. 7A, the CPU 212 and memory 214 are not included on the interface card 114, and thus only the portion of the graphical program which is converted into hardware implementation form is uploaded to the FPGA 206. Thus in the embodiment of FIG. 7A, any supervisory control portion of the graphical program which is necessary or desired to execute in machine language on a programmable CPU may be executed by the host CPU in the computer system 102, and is not executed locally by a CPU on the interface card 114.
In the embodiment of FIG. 7B, the CPU 212 is not included on the interface card 114, i.e., the interface card 114 includes the FPGA 206 and the memory 214. In this embodiment, the memory 214 is used for storing FPGA state information. FIG. 7B is the currently preferred embodiment of the present invention.
FIG. 8--Conversion of a Graphical Program into a Hardware Implementations
FIG. 8 is a flowchart diagram illustrating operation of the preferred embodiment of the present invention. The present invention comprises a computer-implemented method for generating hardware and/or software implementations of graphical programs or graphical code. It is noted that various of the steps in the flowchart can occur concurrently or in different orders.
One goal of the present invention is to provide a development environment that will seamlessly allow use of a graphical programming system to design applications for reconfigurable or programmable hardware. In the preferred embodiment where the graphical programming system is LabVIEW, the present invention allows LabVIEW users to design applications in LabVIEW for reconfigurable hardware.
Many applications, such as signal processing and real-time motion control, are easily implemented in a graphical programming language, such as the LabVIEW G language. However, in some instances traditional software compilation methods cannot produce an application that is fast enough to meet a user's needs. The present invention solves this problem by allowing a user to convert their graphical program, e.g., a G program, into application-specific hardware such as a programmed FPGA. The hardware maintains the exact functionality of the graphical program while running at speeds far exceeding that of traditional general-purpose processor platforms. The current implementation of the present invention is a desktop or embedded PC that contains an FPGA-based daughter card.
In one embodiment, the present invention appears as a conventional graphical programming system while providing a seamless interface to the reconfigurable hardware. For example, the preferred embodiment of the invention, referred to as "FPGA LabVIEW", provides a seamless interface to an FPGA. FPGA LabVIEW appears from the outside to be exactly the same as the normal LabVIEW graphical program development system.
FIG. 8 illustrates the translation process from a graphical program to a hardware description that corresponds to the graphical program. A graphical programming application that is being targeted for a hardware implementation is designed in exactly the same way as an ordinary graphical programming application. As shown, in step 402 the user first creates a graphical program, also sometimes referred to as a block diagram. A design is entered and debugged in the traditional software-based manner. In the preferred embodiment, the graphical program comprises a graphical data flow diagram which specifies functionality of the program to be performed. This graphical data flow diagram is preferably directly compilable into machine language code for execution on a computer system.
When the design is finalized, the user can instruct the system to compile the design for the FPGA hardware. Unfortunately, some graphical programming constructs may not be efficiently implemented in FPGA hardware. For example, file I/O is a task that is usually better left to the general-purpose host processor. The present invention is capable of bisecting a design into hardware portions and software portions.
In step 404, the user selects a first portion of the graphical program for conversion to a hardware implementation. This first portion of the graphical program which is desired for hardware implementation preferably comprises portions of the graphical program, e.g., particular subprograms, which require a fast or deterministic implementation and/or are desired to execute in a stand-alone hardware unit. In general, portions of the graphical program which are desired to have a faster or more deterministic execution are selected in step 404 and converted into the hardware implementation in steps 406-414.
In step 422 the remaining portions of the graphical program which were not selected in step 404 are compiled into machine code for execution on a CPU, such as the host CPU in the computer 102 or the CPU 212 comprised on the interface card 114. The first portion of the program selected in step 404 preferably excludes program portions involving supervisory control and display. This enables the supervisory control and display portions to execute on the host CPU, which is optimal for these elements of the program.
In one embodiment, during creation of the graphical program in step 402 the user specifies portions, e.g. subprograms, which are to be exported to the hardware description format for conversion into a hardware implementation. In another embodiment the user selects which modules or subprograms to export to the hardware implementation at the time when the conversion process is initiated. In another embodiment, the entire graphical program is selected for conversion to a hardware implementation, and thus step 422 is not performed.
In step 406 the graphical program portion selected in step 404 is first processed to create an abstract hardware graph called a VDiagram tree which serves as an intermediate data structure. The VDiagram tree contains a complete hardware representation of the program, but is not specific to any hardware description language. For example, the VDiagram tree comprises data structures representing hardware signals that implement the data flow within the graphical program, as well as data structures representing hardware signals that are added to preserve the proper execution flow (enable signals).
In step 408, a back end program is called to parse the VDiagram tree and generate a hardware description from it. The back end translates the information contained in the VDiagram tree into a specific hardware description language. For example, a VHDL back end may be called to generate a VHDL file or set of files describing the program. The hardware description comprises a high-level hardware description of function blocks, logic, inputs, and outputs which perform the operation indicated by the portion of the graphical program selected in step 404.
Various types of back end programs may be present. Back end programs may generate software source code descriptions as well as hardware description language descriptions. For example, FIG. 2 illustrates a back end 330A which uses the VDiagram tree to generate one or more VHDL files; back end 330B which generates one or more EDIF files; and back end 330C which generates one or more C files. These three back ends are representative only. Other back ends may generate other types of descriptions for the program. For example, a Verilog back end may generate a Verilog file for the program. Also, more than one back end may be called to generate different program descriptions. In the preferred embodiment, a VHDL back end generates a VHDL description which may then be compiled and used to program a programmable logic device such as an FPGA.
In step 410 the method operates to convert the hardware description into an FPGA-specific netlist. The netlist 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 is preferably performed by any of various types of commercially available synthesis tools, such as those available from Xilinx, Altera, etc.
In the preferred embodiment, the converting step 410 may utilize one or more pre-compiled function blocks from a library of pre-compiled function blocks 342. Thus, for certain function blocks which are difficult to compile, or less efficient to compile, from a hardware description into a netlist format, the hardware description created in step 408 includes a reference to a pre-compiled function block from the library 342. Alternatively, hardware implementations for all of the function blocks are included in the function library. The respective pre-compiled function blocks are simply inserted into the netlist in place of these references in step 410. The preferred embodiment of the invention thus includes the library 342 of pre-compiled function blocks, also referred to as the component library, which are used in creating the netlist. The preferred embodiment also includes hardware target specific information 344 which is used by step 410 in converting the hardware description into a netlist which is specific to a certain type or class of FPGA.
In step 412 the method operates to compile the netlist into an FPGA program file, also referred to as a software bit stream. The FPGA program file is a file that can be readily uploaded to program an FPGA.
After the netlist has been compiled into an FPGA program file in step 412, then in step 414 the method operates to transfer the FPGA program file to the FPGA, to produce a programmed hardware equivalent to the graphical program. Thus, upon completion of step 414, the portion of a graphical program referenced in step 404 is comprised as a hardware implementation in an FPGA or other programmable hardware element.
In the preferred embodiment, the hardware description is passed transparently through the FPGA vendor's synthesis tools. Because the vendor's tools may take a considerable amount of time to process the design and generate a programming bitstream, it is recommended that this only be done after the design has been debugged using traditional software-compilation techniques.
As described above, the present invention may run on PC computers equipped with an FPGA-based expansion card on the PCI bus. Embodiments of the FPGA-based expansion card were described with reference to FIGS. 7, 7A and 7B. The graphical programming system uploads the programming bitstream generated by the FPGA vendor's design tools into the FPGA on this board. The FPGA then begins processing data, and the graphical programming system may coordinate data flow between the FPGA and the host CPU.
It is noted that various of the above steps can be combined and/or can be made to appear invisible to the user. For example, steps 410 and 412 can be combined into a single step, as can steps 404-410. In the preferred embodiment, after the user creates the graphical program in step 402, the user simply selects a hardware export option and indicates the hardware target or destination, causing steps 404-414 to be automatically performed.
FIG. 8 applies to the preferred embodiment in which the programmable hardware element is an FPGA. However, the same or similar steps may be applied to convert a graphical program into a hardware implementation for other types of programmable or (re)configurable hardware, such as a CPLD.
FIG. 9--Creation of a Graphical Program
FIG. 9 is a more detailed flowchart diagram of step 402 of FIG. 8, illustrating creation of a graphical program according to the preferred embodiment of the invention. As shown, in step 420 the user arranges on the screen a graphical program or block diagram. This includes the user placing and connecting, e.g., wiring, various icons or nodes on the display screen in order to configure a graphical program. More specifically, the user selects various function icons or other icons and places or drops the icons in a block diagram panel, and then connects or "wires up" the icons to assemble the graphical program. The user also preferably assembles a user interface, referred to as a front panel, comprising controls and indicators which indicate or represent input/output to/from the graphical program. The graphical program is sometimes referred to as a virtual instrument (VI). The graphical program or VI will typically have a hierarchy of sub-graphical programs or sub-VIs.
In the preferred embodiment, the graphical programming system is the LabVIEW graphical programming system available from National Instruments. For more information on creating a graphical program in the LabVIEW graphical programming system, please refer to the LabVIEW system available from National Instruments as well as the above patent applications incorporated by reference.
In response to the user arranging on the screen a graphical program, the method operates to develop and store a tree of data structures which represent the graphical program. Thus, as the user places and arranges on the screen function nodes, structure nodes, input/output terminals, and connections or wires, etc., the graphical programming system operates to develop and store a tree of data structures which represent the graphical program. More specifically, as the user assembles each individual node and wire, the graphical programming system operates to develop and store a corresponding data structure in the tree of data structures which represents the individual portion of the graphical program that was assembled. Thus, steps 420
and 421 are an iterative process which is repetitively performed as the user creates the graphical program. In one embodiment, the graphical programming system automatically develops and stores VDiagram data structures in response to the user creating the graphical program.
In one embodiment, the user optionally places constructs in the graphical program which indicate respective portions of graphical code which are either to be compiled into machine code for execution by a CPU or converted to a hardware description for implementation in a programmable hardware device such as an FPGA.
FIGS. 10 and 11--VDiagram Tree Structures
The VDiagram tree comprises data structures called VDiagrams. The root VDiagram contains information for the program items present in the top-level graphical program, such as wires, constants, etc. Any complex items such as sub-programs, functions, loop structures, etc. are represented as child VDiagrams. Parent VDiagrams have pointers to all their child VDiagrams so that a tree is formed for the program hierarchy. Each child VDiagram also has a pointer back to its parent.
The VDiagram code is preferably written in C++. The following pseudocode describes the contents of each VDiagram:
class VDiagram { public: VComponentList complist; VSignalList signallist; VAssignmentList assignlist; VSubviList srnlist; VSubviList subvilist; VPortMap topportmap; VResourceList resourcelist; private: int isSubvi; VDiagram *owner; VComponent *srnholder; ObjID rootobj; char *entityname; };
FIG. 10 provides a graphical representation of a VDiagram and the relationship among its elements. Each of these elements is discussed below. Note that specific graphical program components and constructs are discussed below, such as wires, functions, sequence structures, case structures, loops, loop tunnels, shift registers, etc. For more information on these concepts, please see the above-referenced patents or the LabVIEW documentation available from National Instruments.
complist
The component list contains a list of components that appear in the graphical program. The VDiagram thus preserves some of the structure present in a graphical program so that it appears in the resulting hardware description. Components include functions such as adders, multipliers, and comparators. Components also include objects that represent higher-level programming constructs such as while loops and sequences. Components also include sub-programs. Components on the list are subdivided by type. In the preferred embodiment in which a VHDL description is generated from the VDiagram tree, components generally correspond exactly to entities in a VHDL file.
signallist
The signal list stores all of the wires for the VDiagram. This includes all of the wires that appear on the graphical program itself, as well as any hardware-specific wires that are added, such as the clock and reset signals. Each signal stores a list of the components that it attaches to.
assignlist
Signals can be divided into two groups: signals that are driven by components and signals that are driven by other signals. The assignment list contains objects that describe relations of the latter type. Examples include boolean expressions, multiplexers, and decoders. For example, if a component has multiple input signals, it will need to have an enable signal that is composed of an AND of the enable out signals corresponding to the inputs. The assignment list will contain an entry specifying this relationship.
srnlist
This list contains pointers to additional VDiagrams, each of which represents a subframe of a graphical program. A subframe is the area inside of a structural component such as a while loop, a sequence frame, a case structure, etc. The root object of a subframe is a self reference node (SRN) which encloses the entire subframe. See the descriptions below and the above-referenced documentation for more information.
subvilist
Similar to the srnlist, the subvilist contains pointers to additional VDiagrams. These VDiagrams represent subvi's (subprograms) instead of subframes. The distinction between subvi and subframe is made to help the VDiagram back ends keep the hardware description organized. For example, the VHDL back end may keep all of the subframes of a program together in the same file, but may place the VHDL generated for subprograms in separate files.
The root object of a subprogram is a self reference node (SRN) which encloses the entire subprogram. See the descriptions below for more information.
topportmap
The topportmap is a list of ports that describe the connections between a graphical subprogram