07-01-2014 01:03 PM
I'm in the project where we would like to use NI hardware (more likely cRIO system). With NI hardware we will read/wright several AI/AO and DIO and perform some math and controls on the result of readings. We are planning to design FPGA code for project, but we are thinking about implement all data processing and control logic in VHDL and link it with AI, AO and DIO with help CLIP or IP Integration Node as explained in this : "white-paper": http://www.ni.com/white-paper/7444/en/
Mentioned above paper explain how to implement VHDL code in LabVIEW FPGA VI using CLIP or IP Integration Node, but the topic that is not highlight explicitly is how these construction CLIP and IP Integration Node will be handled by Compiler. The main reason for such approach (VHDL linked with part that read/write into hardware AI AO and DIO) we expect that our VHDL code will be handled by LabVIEW compiler without modification and passed to Xilinx Compiler synthesis as is (path for Compile process I've taken from here: http://www.ni.com/white-paper/9381/en/ ), so we will be able at some level bypass the intermediate process of compilation and get almost the same result as if we design pure VHDL code and use Xilinx ISE for Synthesis Mapping and Bit File generation.
Will this approach work? I was not able to find any documents that explain the Compiler behavior and confirm that VHDL code handled untouched or will modified, does such document exist?
Note. I've requested official assistance from NI support on topic above, but I would like to post this question on forum hoping get more feedback.
07-01-2014 02:00 PM
07-01-2014 06:11 PM
Thank you very much for answer.
First of all we understand that we will not be able to skip the compilation. Project has to go through "Start Compilation" and "Generation of Intermediate Files" (see: http://www.ni.com/white-paper/9381/en/ for details). Our objectives that on these two steps our VHDL code will stay untouched by LabView compiler. And intermediate files that came to Xilinx Analyzer-Synthesizer-Mapper-Placer/Router will include our original VHDL code without any additions/modifications from LabView Compiler. Basically we want all logic implemented in the same way (or as close as possible) as if it was processed by Xilinx ISE for custom FPGA without LabView compiler "middle man".
Desire to implement code in VHDL approach based on assumption that LabVIEW "converter from VI to VHDL code" is not ideal and have some issues (see: http://www.ni.com/tutorial/14536/en/ for example) that potentially may introduce risk to operation of our system. This does not mean that LabView FPGA will not work; we just want to minimize risk by decreasing amount of intermediate processes at the same time we would like to have convenience of quick design with LabVIEW and NI hardware. (It is not so easy to find or design system with customable FPGA on board with 20-30 simultaneously sampling Analog Inputs, Analog Outputs and DIO that can easy transfer data and controlled from GUI)
Another reason for our approach is that we already have part of logic implemented in VHDL code, so we do not want to rewrite it in LabVIEW FPGA.
07-01-2014 10:13 PM
I believe that your compiled .ngc file will not be disturbed by the LabVIEW xilinx compiler as given in this link. Yes I agree that there is few glitches with the LabVIEW FPGA compiler (I have this issue), but anyway I am not really aware of what is happening under the hood.
07-02-2014 09:10 AM - edited 07-02-2014 09:20 AM
To be honest, I'm not sure what you're concerned about here. An IP integration node is analogous to a library call in other compiled languages. The compiler is going to do what it needs to do to integrate your code into the final bitfile, but thats it. What are you worried the compiler is doing?
I also understand the desire to use the ip integration node to reuse existing VHDL, but I'm not sure why a list of known issues has convinced you that LV FPGA is more risky than having your developers code the VHDL themselves. To me that seems like a flaw in your logic. Anyway, I'm sure I won't convince you here but I would at least recommend looking around at what the product has to offer.
07-02-2014 01:39 PM - edited 07-02-2014 01:48 PM
There won't be any modications to the internal logic of the VHDL that you implement in the IP integration node. Though I've seen developers unfamiliar with LabVIEW FPGA get tripped up on the synchronization registers that LabVIEW FPGA inserts into the code around the integration node. Learning where and why these syncrhonization registers are inserted has in my experience always resolved this issue. These two help documents do a good job of explaining the 'where and why' of synch registers when the enable chain is present, or when working with IO inside of a SCTL.
With regards to the stability of LabVIEW FPGA, I would second Daniel's sentiments. What about the known issues list conveys instability and risk? As a point of comparison, here are the known issues for ISE 14.x.
If you are looking to minimize risk, I would recommend developing the critical logic in the development enviroment in which you are comfortable setting up a comprehensive test bench since testing the code is the only way to truly verify its functionality. For me this would be LabVIEW FPGA as it has excellent trouble shooting tools and I've been developing in it for quite some time. Perhaps you're more familiar with ISE than LabVIEW FPGA and that is the source of your trepidation? If that is the case then you may find the High Performance FPGA Developers Guide a good read. You may also find a few of the case studies on our website reassuring since they demonstrate other teams successfully implementing a solution using LabVIEW FPGA. Here's one that used LabVIEW FPGA in conjnction with VHDL IP similiar to what you are doing.
10-08-2018 04:38 AM
You guys exactly sound like me 🙂 almost same problem here.
although this has been 4 years since you posted this question, but still today people like me facing problems like these.
NI guys should really pay a good attention to the needs of those who are HDL guys(specially Verilog guys).