Thanks for your questions and I hope I can answer them appropriately
1. LabVIEW FPGA utilizes the intuitive graphical dataflow language of LabVIEW to target FPGA technology. LabVIEW is particularly nice for FPGA programming because of its ability to represent parallelism inherent to FPGAs. It also serves as a software-like programming experience with loops and structures which has become a focus of industry lately with C-to-gates and other abstraction efforts. Here are some general comparison along the vectors you mentioned
Code Size and speed optimization - LabVIEW FPGA is a programming language. As such, one can program badly and create designs that are too big to fit on a chip and too slow to meet timing. However, there are two main programming paradigms which you can use. The normal LabVIEW dataflow programming (meaning outside a single-cycle loop) adds registers in order to enforce dataflow and synchronization in parity with the LabVIEW model of computation. As with any abstraction, this use of registers is logic necessary to enforce LabVIEW dataflow and might not be what an expert HDL programmer would create. You trade off the simplicity of LabVIEW dataflow in this case. On the other hand, when you program inside a Single-Cycle timed loop you can achieve size and speed efficiencies comparable to many VHDL implementations. We have had many users that understand that way LabVIEW is transformed to hardware and program in such a way to create very efficient and complex systems.
Development Time - Compared to VHDL many of our users get near infinite improvements in development time due to the fact that they do not know (nor do they have to know) VHDL or Verilog. Someone who knows LabVIEW can now reach the speeds and parallelism afforded by FPGAs without learning a new language. For harware engineers (that might actually have an alternative to LabVIEW) there are still extreme time saving aspects of LabVIEW including ready-made I/O interfaces, Simple FIFO DMA transfers, stichable IP blocks, and visualizable parallism. I talk to many hardware engineers that are able to drastically improve development time with LabVIEW, especially since they are more knowledgable about the target hardware.
Compilation Time - Comparable to slightly longer to due to the extra step of generating intermediate files from the LabVIEW diagram, and the increased level of hierarchy in the design to handle abstraction.
Verification Time - One of our key development initiatives moving forward is increased debugging capabilities. Today we have the abilities to functionally simulate anything included in LabVIEW FPGA, and we recently added simluation capabilities for Imported IP through the IP Integration node on NI Labs and the ability to excite your design with simulated I/O. This functional simualation is very fast and is great for verification and quick-turn design iteration. However, we still want to provide more debugging from the timing prespective with better cycle-accurate simulation. Although significantly slower than functional simulation. Cycle-accuracy give us the next level of verification before compilation. The single cycle loop running in emulation mode is cycle accurate simluation, but we want more system level simulation moving forwrad. Finally, we have worked to import things like Xilinx chipscope (soon to be on NI Labs) for on-chip debugging, which is the final step in the verification process. In terms of verification time there are aspects (like functional simulation) that are faster than traditional methods and others that are comparable, and still other that we are continuing to refine.
Ability to develop in the future - I am not sure what you mean here but we are certainly continuing to activiely develop on the RIO platform which includes FPGA as the key diffentiating technolgoy. If you take a look at the NI Week keynote videos (ni.com/niweek) there is no doubt from both Day 1 and Day 2 that FPGA will be an important well maintained platform for many years to come.
By Rick Kuhlman | LabVIEW FPGA Product Manager