Abstract: System and method for convergence analysis. One or more state variables of a first program may be determined based on dependencies of variables in a first program. A second program corresponding to the first program is created based on the state variables and their dependencies, and executed multiple times. Each execution may include recording values of the state variables, determining an execution count, comparing the values to corresponding values from previous executions of the second program, and terminating the executing in response to the values matching corresponding values from at least one previous execution of the second program. A convergence property for the first program is determined based on the execution count, and indicating a number of executions of the first program required to generate all possible values of the one or more variables. The convergence property is stored, and may be useable to optimize the first program.

Abstract: When compiling high-level, graphical code (e.g. LabVIEW™ code) to a different representation (e.g. different software code or hardware FPGA), information relating to characteristics of the design may be collected/captured from the compilation process, and automatically provided to all the earlier stages of the compilation process to obtain more optimal results. Without automated feedback of this information, users have to manually identify, produce, and provide the feedback information, or forego the process altogether, having to assume that the tool has produced the best possible results when that may not be the case. To correct timing, failed constraints paths may be parsed and compared to delays obtained during a previous compile, and previous adjustments that didn't yield desired results may be undone. The longest delay that didn't result from an undone path may then be identified, and adjusted, and the process may be repeated until all paths are predicted to pass.

Abstract: When compiling high level, graphical code (e.g. LabVIEW™ code) representative of a design, parts of the code that do not depend on external input data may be executed during the compilation process. Specific variables and/or value traces of specific variables in the program, e.g. constant values and/or repeating patterns may be recorded then analyzed, and certain transformations may be applied in the compilation process according to the results of the analysis, thereby optimizing the design. In one approach, the graph may be dynamically stepped through one node at a time, and it may be determined whether all inputs to the stepped-through node are known. If those inputs are known, type conversion and the operation corresponding to the stepped-through node may be dynamically performed. In another approach, a subset of the graphical code not depending on external data may be compiled and executed, thereby obtaining the same results as described above.

Abstract: When compiling high level, graphical code (e.g. LabVIEW™ code) representative of a design, parts of the code that do not depend on external input data may be executed during the compilation process. Specific variables and/or value traces of specific variables in the program, e.g. constant values and/or repeating patterns may be recorded then analyzed, and certain transformations may be applied in the compilation process according to the results of the analysis, thereby optimizing the design. In one approach, the graph may be dynamically stepped through one node at a time, and it may be determined whether all inputs to the stepped-through node are known. If those inputs are known, type conversion and the operation corresponding to the stepped-through node may be dynamically performed. In another approach, a subset of the graphical code not depending on external data may be compiled and executed, thereby obtaining the same results as described above.

Abstract: System and method for extending programmable device functionality while preserving functionality of the device driver and driver IP. User input may be received specifying functionality of custom IP for a programmable measurement device with standard driver IP. The custom IP may be generated accordingly, and may be deployable to the programmable measurement device. During operation the custom IP may communicate directly with the standard driver IP and may provide custom functionality of the programmable measurement device while preserving functionality of the standard driver IP on the programmable measurement device and the standard device driver.

Abstract: System and method for specifying and implementing relative hardware clocking in a high level programming language. User input specifying a program may be received. The program is specified for deployment to a programmable hardware element (PHE), and includes first and second code portions configured to communicate with each other during execution. The user input may further specify a rational ratio of respective execution rates for the first and second code portions. A hardware configuration program (HCP) implementing the specified program is automatically generated, including automatically determining a respective clock rate for at least one of the first and second code portions based on the rational ratio. The HCP may be deployable to the PHE, including implementing first and second clocks for controlling execution of the first and second code portions in accordance with the rational ratio and the automatically determined respective clock rate for the at least one code portion.

Abstract: When compiling high-level, graphical code (e.g. LabVIEW™ code) to a different representation (e.g. different software code or hardware FPGA), information relating to characteristics of the design may be collected/captured from the compilation process, and automatically provided to all the earlier stages of the compilation process to obtain more optimal results. Without automated feedback of this information, users have to manually identify, produce, and provide the feedback information, or forego the process altogether, having to assume that the tool has produced the best possible results when that may not be the case. To correct timing, failed constraints paths may be parsed and compared to delays obtained during a previous compile, and previous adjustments that didn't yield desired results may be undone. The longest delay that didn't result from an undone path may then be identified, and adjusted, and the process may be repeated until all paths are predicted to pass.

Abstract: When compiling high level, graphical code (e.g. LabVIEW™ code) representative of a design, parts of the code that do not depend on external input data may be executed during the compilation process. Specific variables and/or value traces of specific variables in the program, e.g. constant values and/or repeating patterns may be recorded then analyzed, and certain transformations may be applied in the compilation process according to the results of the analysis, thereby optimizing the design. In one approach, the graph may be dynamically stepped through one node at a time, and it may be determined whether all inputs to the stepped-through node are known. If those inputs are known, type conversion and the operation corresponding to the stepped-through node may be dynamically performed. In another approach, a subset of the graphical code not depending on external data may be compiled and executed, thereby obtaining the same results as described above.

Abstract: Testing a first graphical program intended for implementation on a programmable hardware element. The first graphical program may be stored. The first graphical program may include a first plurality of nodes connected by lines which visually specify first functionality. The first graphical program may be intended for implementation by the programmable hardware element. A second graphical program may be stored which visually specifies testing functionality for the first graphical program. The second graphical program may be executable by a host computer to simulate input to the programmable hardware element when configured by the first graphical program. The first graphical program and the second graphical program may be executed (e.g., by a host computer) to test the first functionality when implemented by the programmable hardware element. During execution, simulated outputs may be monitored.

Abstract: Testing a first graphical program intended for implementation on a programmable hardware element. The first graphical program may be stored. The first graphical program may include a first plurality of nodes connected by lines which visually specify first functionality. The first graphical program may be intended for implementation by the programmable hardware element. A second graphical program may be stored which visually specifies testing functionality for the first graphical program. The second graphical program may be executable by a host computer to simulate input to the programmable hardware element when configured by the first graphical program. The first graphical program and the second graphical program may be executed (e.g., by a host computer) to test the first functionality when implemented by the programmable hardware element. During execution, simulated outputs may be monitored.