Gray Thomas

Well that is certainly encouraging! But the quest for FPGA abstraction continues... One key feature of the scripting language that would need to work to accomplish 6-9 is the ability to add objects to the block diagram that are based in the project, rather than in files. Outside of the FPGA module this is relatively rare, I think shared variables do it, but they are also associated with libraries. on the fpga, all descriptions of inputs, large scale memory, and large scale communication with the outside world are done through project based objects.

Hello, I'm new to these scripting features, but I was wondering if it could support the following proposed style of programming: Write a vi as you normally might Replace some labels with an escape character and a number (~1, ~2, etc..) Have a generic script vi which will read your "template vi" and record its structure Replace every reference which had a "~x "label with object x from an array of user input objects (inputs to the script not the template) rebuild the vi with scripting, while maintaining algorithmic changes Thereby subvert unusual requirements in the FPGA module, such as the requirement that constants be passed for memory locations and IO references Thereby allow multiple instantiations of asynchronous parallel state machines--like sonar drivers, multiplier-sharing machines, lidar data parsers, and neuron implementers Thereby allow re-use of parallel code Thereby raise the abstraction barrier of writing such code The benefits are clear for those of us stuck programming on reduced abstraction systems where labview is unable to offer the shortcuts we usually use to avoid templating, but for the vast majority of labview users, this is probably not the biggest concern. I'm curious to learn what the scripting system really excels at, and how others have dealt with the FPGA abstraction problem.