Modular design approach for FPGA

[BradPID]

I would like to design a FPGA module having an access to the resources like DIO,AIO or CAN which I can develop and test within one LabVIEW project and then use it within another. Idealy, I would like to have an API for RT implemented as a .lvlib and one VI which I have to drop on on my main FPGA vi.

 

Currently, I have a .lvlib with virtual folders for RT and FPGA stuff. I have a few issues with this approach like requirement for changing FPGA typedef when I want to use it within another project and manual adding FIFO to the project.

 

Well, I can live with this, but maybe you have a better approach which you woluld like to share. I have found something like FPGA Advanced Session Resources https://decibel.ni.com/content/docs/DOC-35574 , but still I am not sure whether it something I am looking for.

 

Any thoughts?

[shoneill]

Well the first thing I would recommend is VI-defined Registers.  I have used these and it's cool being able to simply instantiate X versions of a given register in code.  I try to keep as much as possible out of the project definition.  DMA channels and so on need to be project-defined but normal FIFOs, Registers, Block RAM and so can be defined within the VIs.  I have also used LVOOP (calling mainly static methods although FPGA DOES support Dynamic Dispatch only if the concrete class at every node is discernable at compile time.

[Omar Mussa]

I saw Stephen Barrett present on the topic at the CLA Summit based on the document you linked to.  Buried in that doc he created a GIT repo with the source code to his demo:

https://github.com/BarrettStephen/FPGA-Middleware-Demo

 

This was a very awesome approach to FPGA reuse and I have been aiming to replicate this on my projects but have not had the time to fully invest in reorganizing my existing code, however if I were to start a new project I would definitely consider this approach.

[BradPID]

Well the first thing I would recommend is VI-defined Registers.  I have used these and it's cool being able to simply instantiate X versions of a given register in code.  I try to keep as much as possible out of the project definition.  DMA channels and so on need to be project-defined but normal FIFOs, Registers, Block RAM and so can be defined within the VIs.  I have also used LVOOP (calling mainly static methods although FPGA DOES support Dynamic Dispatch only if the concrete class at every node is discernable at compile time.

That's good advice. I am already using it and it helped a lot. At the moment I have only two FIFO which are communicating with host computer. The next thing I want to do is using project defined FIFO with references as well. Now, when I place a 'module VI' on the 'Main FPGA VI' within other project, the code is broken and I have to manauly change all the nodes. Using reference should fix this issue - changes only at the beginning. The other issue I have is using FPGA FP controls/indicators. In my case they have names like: 'Start Acquistion', 'Stop Acquistion'. I have to define them within my 'Main FPGA VI' so when I change the project I have to make their copy. I found quite a good way to deal with this, but it is still require some work.

 

I saw Stephen Barrett present on the topic at the CLA Summit based on the document you linked to.  Buried in that doc he created a GIT repo with the source code to his demo:

https://github.com/BarrettStephen/FPGA-Middleware-Demo

 

This was a very awesome approach to FPGA reuse and I have been aiming to replicate this on my projects but have not had the time to fully invest in reorganizing my existing code, however if I were to start a new project I would definitely consider this approach.

I guess I still not have enough experience with FPGA but I can't fit FPGA Advanced Resource Session with what I would like to acomplish. Using bitfiles allows me to use developed code within one project in multiple other projects but I am thinking about something different, I guess. Let's say I have three persons: person D1 person D2 and person A0. A0 is responsible for whole project and work only on high-level stuff. D1 is responsible for communication with instrument 1 and D2 is responsible for communication with instrument 2. I would like to these three person to work on three different LabVIEW project and in the end A0 should easily merge their work. D1 and D2 work on FPGA, A0 don't.

[shoneill]

I have recently started using LVOOP on my FPGA targets to implement "pipes".  I declare a datatype and then have aq base class with a Read and Write method.  I can then choose at compile-time whether these will be Registers, Handshakes, BRAM FIFOs or whatever.  By defining these items outside of the sub-VIs and passing them in as arguments, I can dynamically link parallel lloops on the FPGA, essentially creating an interface between processes.  Using this and multiple clock domains allows for some pretty cool re-use of code.

[BradPID]

Well I don't feel I need LVOOP rigth now but the idea is brilliant. For me using 'pipes' simplifed a lot. I used global variables before. I have heard that on FPGA it is ok. I don't think in this way anymore. Getting back to the modularity... Now, my module has: pipe creator, input writer, output reader and main loop. The attached image describes all I need to drop on th BD. I haven't tested this idea entirely and it would be better If I could access clusters elements separetely on RT host. I guess I still will have to create seperate controls for each input.