07-18-2022 12:03 PM
I am looking for a more efficient method for configuring the IP node integration block in FPGA.
Problem: I am constantly integrating new HDL into FPGA VIs using the IP integration node. The most laboring problem with this is that I have to manually adjust the fixed point values of the IP terminals. This can be a very tedious task when an IP node has 300 inputs and if by some chance you have made a mistake and didn't notice until you completed your 3 hour compile and a few hours of debugging. The HDL code is created via HDL coder and it is very easy to read the code generation report and identify the correct fixed point for LabVIEW. It would be great to at the minimum be able to script the IP terminal setup, this would eliminate the tedious task and QA time required to ensure the IP terminals are correct.
NI has undocumented VIs for the IP integration XNode in C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\rvi\IPIntegrationNode, for example, but I have no clue where to start to even explore this as an option.
Any help appreciated.
Solved! Go to Solution.
07-20-2022 12:50 PM
Hi Wolleee,
You can achieve that with classic scripting if you wire constant values to your IP node inputs.
It is of course not as ideal as configuring default values directly in the XNode (especially since your node will have 300 inputs), but nevertheless it offers all generic scripting features and you can still wrap it in a subVI to prevent editor performance issues due to the size of the XNode.
I also tried with the IP Integration APIs, but as far as I understand, it is only useful for the configuration dialog itself. It may require some more investigation...
Find attached an example project where the 1st solution is implemented. It requires FPGA/cRIO drivers for the FPGA part, and OpenG toolkit for the script.
07-20-2022 01:05 PM
raphschru,
The issue is not wiring up the IP node, but it is configuring the XNode. The XNode requires configuring the fixed point data types for the IP terminals.
07-20-2022 01:18 PM
With Xilinx IP, they use the AXI to stream many values into an IP block (e.g., say you want to reconfigure a FIR filter which has a few hundred coefficients). Maybe you could stream the values into your IP so that you can reduce the input/output count? I understand this would add latency but if you can afford that, it may simplify the reconfiguration process.
The stuff in the RVI folder is very interesting but as you have noted it is not documented.
07-21-2022 06:04 AM
@Wolleee a écrit :
The XNode requires configuring the fixed point data types for the IP terminals.
Ok I thought you just wanted to set the values, since the port types are normally pre-configured when you load the model...
I've looked into the API more in details and found the entry points to script the IP Node entirely (yes I have weird hobbies 😁) :
- vi.lib\rvi\IPIntegrationNode\IPINode_ModGen\niFpgaIPINodeGetUpdatedState.vi to retrieve the IP node state data.
- vi.lib\rvi\IPIntegrationNode\IPINode_BatchRegen\niFpgaIPINodeBRScript.vi to update the IP node from a given state data.
In between you can modify the data as you wish to configure the node.
However you must know what you are doing because incoherent state data may crash LV when updating the node.
Here is the updated example project with the undocumented scripting solution.
07-21-2022 10:10 AM
Hi Terry,
That is certainly an option. Our IP is developed with HDL coder, and I think this would require an extra step to add in the stream. Id have to talk with the IP developers about that. Good tip.
07-21-2022 10:31 AM
raphschru,
Your example is perfect. I'm going to do a little bit of tweaking to get this to do what I need, but this is a great starting point. It is even easier to do than I thought. Ill report back if I run into any issues with this method.
07-21-2022 10:38 AM
This is a classic case where work has to be done 'somewhere.' The work can be done on the IP side of things or on the LabVIEW side of things. An objective review of the two approaches is something only you can really do since you have access to the code and people who do the work. Curious to see how it develops.