Why should I adopt LABVIEW FPGA as a tool for developing my FPGA projects?

Question

Dear Friends, 
Since I have started using LABVIEW FPGA, I got too many questions in my mind looking for answers! 
1-      Does anybody can tell me “why should I adopt LABVIEW FPGA as a tool for developing my FPGA projects?”
I mean there are many great tools in this field (e.g. Xilinx ISE, ….); what makes LABVIEW FPGA the perfect tools that can save my time and my money? 
I’m looking for a comparison can show the following points:
·         The Code size and speed optimization.
·         Developing time.
·         Compiling time.
·         Verifying time.
·         Ability to developing in future.
·         …etc.. 2-     
I’ve Spartan-3E kit, I’m so glad that LABVIEW support this kit; I do enjoyed programming the kit using LABVIEW FPGA, but there are too many obstacles!
The examples come with Spartan-3E driver don't cover all peripherals on board (e.g. LAN port is not covered)! There is a declaration at NI website which is "LabVIEW FPGA drivers and examples for all on-board resources" Located at: http://digital.ni.com/express.nsf/bycode/spartan3eI don’t think that is true!
Anyway, I will try to develop examples for the unsupported peripherals, but if the Pins of these peripherals are not defined in the UCF file, the effort is worthless! The only solution in this case is to develop VHDL code in ISE and use it in Labview FPGA using HDL node!?
3-      I wonder if NI has any plan to add support for Processor setup in Labview FPGA (Like we do in EDK)?
4-      I wonder if NI has any plan to develop a driver for Virtex-5 OpenSPARC Evaluation Platform ?http://www.digilentinc.com/Products/Detail.cfm?Nav​Path=2,400,599&Prod=XUPV5 
Thnaks & regards,Walid
Solved!
Go to Solution.

Answer 1

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.
2. Apologies for the statement in the document. The sentence should read that there are example for most board resources.
3. We do have plans to support a processor on the FPGA through LabVIEW FPGA. In fact, you will see technology on NI Labs soon that addresses this with MicroBlaze.
4. We do not currently have plans to support any other evaluation platforms. This support was created for our counterparts in the academic space to have a platform to learn the basics of digital design on a board that many schools already have in house. We are currently foccussing on rounding out more of our off-the-shelf platform with new PCI Express R Series boards, FlexRIO with new adapter modules, cRIO with new Virtex 5 backplanes, and more.
 I hope this has anwered some of the questions you have.
Regards 
Rick Kuhlman | LabVIEW FPGA Product Manager | National Instruments | ni.com/fpga
Check out the FPGA IPNet for browsing, downloading, and learning about LabVIEW FPGA IP Cores