785x FPGA development and control without LabVIEW

[Dimi11]

Hello,

I am looking for a strategy to use a few different NI FPGA models (one or more of the PCIe-7852, USB-7855, USB-7856) while reducing or eliminating the need of LabVIEW software. I would like some advice, please, on the feasibility and where to look first.

Currently FPGA Target code and PC-side (Host/intermediary and User Interface) code is developed and run in LabVIEW. Information is exchanged mainly via FIFO memory blocks, and a small amount via direct writing/reading to/from the Target VI. All code is within the same LabVIEW project.

In the first instance, I am considering moving the PC-side code to (perhaps) Python. Will it be straightforward to communicate with the card (with Target code for that already compiled, in this example)? Apart from NI's Python API, is anything else needed - will that take care of loading and running the FPGA bitfile? Are there other ways to do that?

Furthermore, I am wondering about a way to also write FPGA code outside LabVIEW. I have come across the MyHDL (Python) and HDL Coder (MATLAB) tools, and then there is straightforward HDL coding as well. Can someone advise with an overview of development steps, please? After code is written, I assume it can be compiled via one of the above-mentioned tools and/or some Xilinx software. How is then the bitfile loaded into the card? How can you communicate with the card, without an NI API?

Best,

Dimi

[ZYOng]

In the first instance, I am considering moving the PC-side code to (perhaps) Python. Will it be straightforward to communicate with the card (with Target code for that already compiled, in this example)? Apart from NI's Python API, is anything else needed - will that take care of loading and running the FPGA bitfile? Are there other ways to do that?

See Basic Examples — FPGA Interface Python API 19.0.0 documentation. It is pretty straightforward and includes running the lvbitx file, FPGA I/O R/W, FIFO R/W and Interrupt.

Furthermore, I am wondering about a way to also write FPGA code outside LabVIEW. I have come across the MyHDL (Python) and HDL Coder (MATLAB) tools, and then there is straightforward HDL coding as well. 

There is IP to FPGA Conversion Utility which was released recently. However, it only supports a limited number of PXIe R Series devices for now.

[santo_13]

Not using LVFPGA to develop the code would make your life harder as it is not the preferred way of development. Nevertheless, you need a paid tool from NI to generate a bit file for the NI FPGA cards.

Even the Simulink to bitfile conversion still requires LabVIEW and FPGA module licenses

[Terry_ALE]

If a non-LabVIEW FPGA approach is required then I do not think NI FPGA hardware is the way to go.

Otherwise you would have to develop your own workflows which sounds like more risk than is needed.

[Dimi11]

Thank you for the responses, all.

Starting from the last one, and to give some context, there has been a significant investement for some years in the above-mentioned NI FPGA hardware, and it is trusted to work. Identifying and buying new, non-NI hardware would be difficult - it might be indeed easier than going without LV, but I am exploring the latter option at this stage. At the same time, it would be good to give the end users the ability to run and tweak the user interface part, without them needing to use LV.

For moving the PC-side code away from LV, it seems that the NI Python API is a sufficient and good choice, @ZYOng. I understand that - assuming a compiled bitfile - it will not require any LV software.

For also writing FPGA code without LV, the Simulink-to-bitfile tool still needs LV license (@santo_13), and the FPGA models of interest are not yet supported.

Can someone share a general workflow, assuming the HDL code is already written (perhaps with MyHDL or straightforward HDL coding)? Is that simply compiled with some toolbox from the chip manufacturer (e.g., Xilinx), and then I will be in the same step to use the NI Python API?

Best,

Dimi

[santo_13 · Accepted solution]

It is practically not possible to program the FPGA on the 785x card without NI utilities as there are several associated circuits and other PXIe bus related stuff that are completely abstracted from the user and you cannot implement them without advanced knowledge of the entire circuit of the 785x card.

Simple term, even if you generate HDL, you need NI's help in adding other HW specific boilerplate code to get it functional as a 785x card not just as a bare FPGA.

[AustinManinTown]

Out of curiosity @Dimi11, what are your reasons for not wanting to use LabVIEW for FPGA development? 

[Dimi11]

Thank you for the insight, @santo_13, it seems that an LV full development/FPGA license will be needed in any case.

@AustinManinTown, to start with I would like the end user of the project (who has an FPGA card, but is content with just interacting with or slightly modifying the user interface) can get away without using LV.

Then, if that step is reached, they might want to edit some core functionality (alter FPGA code), continuing on without LV. But also, on the main FPGA code development, versioning would ideally become much easier.

Best,

Dimi

[santo_13]

---

@Dimi11 wrote:

Thank you for the insight, @santo_13, it seems that an LV full development/FPGA license will be needed in any case.

@AustinManinTown, to start with I would like the end user of the project (who has an FPGA card, but is content with just interacting with or slightly modifying the user interface) can get away without using LV.

Then, if that step is reached, they might want to edit some core functionality (alter FPGA code), continuing on without LV. But also, on the main FPGA code development, versioning would ideally become much easier.

Best,

Dimi

---

If the core functionality of the FPGA will not change, then you can add an abstraction layer between the host code and the UI, thereby allowing the user to edit the UI part. Only advanced users with LVFPGA experience can edit the core functionality, or you could even create a utility that modified the LVFPGA code as per the user-provided configuration and generate an LVBITX file.

[Dimi11]

Yes, I meant to say that a license will be needed in any case of changing the FPGA code.

For the UI part, it should be straightforward with the NI Python API, as you can read/write FIFOs and variables, and that's all that's needed for communication with the card.

Thank you,

Dimi