LabVIEW FPGA Idea Exchange

On the cRIO-9068, the third serial port and the second Ethernet adapter is actually mounted on the FPGA, resources are consumed to redirect to realtime. Currently there are no access to this resource on the FPGA for developers, only from the Realtime.

I would like some I/O Nodes for interacting with these devices on the FPGA. NI could put up some examples how they could be used.

Today the resources are invisible to the developer, except for the additional long compile time and resources used (about 7%).

I attached pictures of the FPGA design and the resources consumed for a blank vi.

Sincerly,

Jens Eriksen

Long compile times are a necessary evil of FPGA code.  Even with the vast improvements of Vivado, compile time still ranks as the biggest killer of large project efficiency.  As compile times approach 3-4 hours, their successful completion becomes paramount.  All too often I find that the Xilinx compiler running on the compile worker has completed successfully however some small communication glitch either between my development machine and the farmer or the farmer and the worker has caused the compile to be lost.  It is quite frustrating to know you have a completed bitfile from Xilinx but the NI tools will not perform the final processing steps required to create the lvbitx file.  The only solution is to restart the compile costing another 3-4 hours of productivity.

Typical workflow in our company for these large projects is to spend mornings testing and stressing the compile(s) from overnight.  Then make any bug fixes and incremental feature improvements and try to start a compile by mid-morning.  By mid-afternoon when the compile is complete do the process again so that you can process another build for overnight.  If one of the compiles fails because of timing or resource problems, there's nothing that can be done.  But if it fails because of glitches in NI's compile wrapper code, that becomes a waste of a half of a day of productivity.

I propose that the current methods for compiling bitfiles be modified.  The goal is to improve user productivity.  Some of my suggestions include:

• For a given build specification, give it the ability to re-attempt to retrieve the last completed compile. This option would be available even if the VI's that created that compile had been modified.
• If a compile was completed previously for this build specification and there has yet to be a successful lvbitx generation, prompt the user before doing anything that would destroy the ability to retrieve it.
• Make sure that all of this still works when changing connections to the worker.  For example if I start my compile at work then take my laptop home and want to login to my VPN at night to check on my compile
• Don't remove any chance to get a compile if there was a communication error.  Right now when I get the communication error, I see a red X in the compilation status and my only option is to remove it from the list.

When working with LabVIEW FPGA if so much as the value of a block diagram constant is changed, the entire application must be recompiled.

It seems that there could be a smarter method to deal with recompiling that might allow selected portions of the block diagram to be recompiled without the need to recompile the entire app.

Some of the tradeoffs might be lower FPGA utilization efficency and timing constraints, but allowing minor changes to the FPGA code without the overhead of a complete recompile would certainly make debugging applications much faster.

I am not necessarily proposing an implementation just posting an idea that seems like it would add value to the LV-FPGA development experience.