Here is my feedback:
1. Fix broken Desktop Execution Node. I raised this issue at start of 2015.
Current work around is to develop/test on myRIO where it works.
2. Support more powerful Zynq FPGAs with high speed differential GTX pins.
One use case is AC coupled high speed data link (HD video & touch screen data) between FPGAs
where one FPGA is floating system contain display drivers and touch screen measurements.
Another use case is PCIe end point for high speed PC data transfer with low overheads as my 35MB/s
data rates are not supported by NI's USB2 and Gigabit Ethernet implementation (open support requests).
3. FPGA DDR access (not FIFO).
Current FPGA processing holds touch screen measurements and associated processed data in Block
RAM.This just fits for touch sensor of 874 nodes. I run out of block RAM when the touch sensor has 2952
nodes. Another use case is FPGA generating HD video test data where RT host updates at slow rate and
FPGA reads & outputs data at much higher frame rate.
4. RT functions for all FPGA peripherals.
I have tablets/phones interfacing to FPGA using I2C and SPI. Zynq FPGA has tested I2C and SPI
peripherals with proven Linux drivers. NI provides no RT functions for these peripherals. The NI
recommended solution is to re-implement I2C and SPI in FPGA. This is a waste of FPGA resources
and introduces issues to get reliable/stable I2C and SPI.
5. FPGA hardware data streaming interfaces.
Tested & proven high speed FPGA data logging and data streaming would be invaluable. Current NI
implementation does not support 35MB/s data rates. One key issue is RT host runs out of resources
trying to move data at high data rates - so FPGA implementation is good. SD card is too slow. We are
looking at data logging to Compact Flash (50MB/s write looks feasible if I am given time to do it).
We have tried NI hardware with Orange Tree TCP/IP Ethernet Card and saw 75MB/s data streaming
to PC with no overheads in RT host. Other solution we have is FTDI USB card streaming 35MB/s
data to PC for data logging and limited data processing. Would NI consider adding Cypress USB3
controller to allow high speed FPGA data streaming (look at Enclustra FPGA boards)?
6. Improve performance/efficiency of LabVIEW Real-Time code
LabVIEW Real-TIme looks to be very inefficient (confirmed by NI in numerous service requests on
various issues). This is "hidden" in tutorials/examples as data rates/volumes are low. This issue
becomes obvious as data rates/volumes increase. I have algorithms which fit and run on a small
slow AVR processing. LabVIEW Real-Time fails to run same algorithms on large/fast ARM processor.
Our current work around is to replace LabVIEW Real-Time with MathWorks Simulink generated code
(their generated code is smaller and ~8 times faster). One obvious LabVIEW Real-Time improvement
is to support concept of streaming data by reference only (in other words, manage flow of pointer
addresses from FIFO read, pass to sub VIs for update, use in queues with minimal memory management
overheads).
Conclusion. SOM is a very exciting and promising product which needs more work.
