LV FPGA Library with Xilinx IP

[usman66]

I have LabVIEW FPGA IP that I want to distribute to the customer in the form of a password protected library. 

The FPGA IP has xilinx IP integration node from the pallette, specifically the DDS and Complex Multiplier. 

To create a library, I created a distribution with the option of "add files to new project library" checked in the Destinations Page. 

This creates a library that has the .dll files corresponding to the Xilinx IPs but not the other support files. 

However, when I move that library to a new PC, add the library to a new project and try to compile it the top level VI, it still asks me to re-configure the xilinx IPs as it cannot locate .xci file. 

So, the question is:

What is the recommended way to create a library for a LV FPGA IP that has Xilinx IP nodes in it, without needing the customer to regenerate the Xilinx IPs, because I will have to give access to the block diagram which I don't want to do. 

Thanks

[ZYOng]

If you are using LVFPGA 2019 or earlier, LVFPGA IP Builder is included. However, FPGA IP Builder does not support all FPGA targets.

For LVFPGA 2020 or later, it has been replaced by a licensed LabVIEW FPGA IP Export Utility.

Both of them create IPs that can be imported using IP Integration Node. See Importing External IP Into LabVIEW FPGA\

[usman66]

Thanks for the reply.

Two follow up questions: 

1. In case of FPGA IP Export Utility, how should I handle the Enable_in, Enable_clr ports generated by the utility for each IP Integration node? Is there any example?

2. I am using several Xilinx IPs like FFT, FIR, DDS etc. Let's say, I import each one of these using IP Integration node, and then use these as building blocks to create the final IP, can I again export the final IP using IP Export Utility and then import it back using IP Integration Node? 

[Intaris]

The DLLs are for simulation only, you need the others if you want to be able to compile or re-compile the Xilinx IP Cores.

[ZYOng]

---

@usman66 wrote:

Thanks for the reply.

Two follow up questions: 

1. In case of FPGA IP Export Utility, how should I handle the Enable_in, Enable_clr ports generated by the utility for each IP Integration node? Is there any example?

2. I am using several Xilinx IPs like FFT, FIR, DDS etc. Let's say, I import each one of these using IP Integration node, and then use these as building blocks to create the final IP, can I again export the final IP using IP Export Utility and then import it back using IP Integration Node? 

---

I have only used this utility with Xilinx Vivado so I don't have solid answers to your questions. For the first question, it is explained in the Figure 9 of the Getting Started Guide.

There is an example written in VHDL at labview\manuals\LabVIEW FPGA IP Export Utility\Example

[UMASO]

Followings are my experiences with LabVIEW 2019 SP1.  

When I use Xilinx LogiCore IPs available on LabVIEW FPGA palette, I always create wrapper SubVIs for every single LogiCore IPs.  If you would like to protect the IPs by passwords, you you may set a password to the SubVIs and the library files.  LogiCore IPs automatically create many files with long file names, which sometimes make LabVIEW have difficulties to properly load all necessary files.  To avoid this situation, I always set a root folder for Xilinx IPs as close to the project root folder as possible.  Then, I distribute all the files by a VI package.  

Xilinx IPs on FPGA palette are very powerful, but it requires some efforts to make it work.  You can check the behavior of IP on Vivado environment, or LabVIEW can do simulation with Xilinx IP.  Some topics in LabVIEW FPGA help describes some tips for using Xilinx IPs, such as establishing handshake between LV 4-wire and AXI-4 stream.  

Below is an example of such a wrapper SubVI I created years ago for LogiCore IP.  Handling Xilinx IP by a wrapper SubVI, automatic duplication of files and folders, when you copy and paste Xilinx IP itself, are avoided. 

[usman66]

Thanks for the suggestions.

So, making all the Xilinx IP node support files part of the library and forcing the user to copy the library in the same directory as my development PC has worked for me. If the user copies it somewhere else, the IP node still needs to be re-configured. So, it's not an ideal solution. 

The suggestion by @ZYOng for using IP Export and then importing it back using IP integration node seems to be better in my opinion, as it won't need to regenerate the support files, plus it gives better IP protection. Any suggestions on the the follow-up queries on that, posted earlier?