Correct way to stop and run again a FPGA reference

[Afghow]

Hi guys ! 🙂

I have some issues when I try to stop and run again an FPGA vi, I explain.

I have two DMA FIFO, one to send data to the FPGA from the CPU, and another from the CPU to the FPGA. When it receives data, the FPGA processes them and sends them back to the CPU and according to the result the CPU makes something. For instance it can be switch on LEDs or rotate a DC motor.

But to do this kind of actions, I have to use an "FPGA Personality", LEDs and I/O Pins seem to be managed by the FPGA core. So I've to close my FPGA vi reference in charge of receive data from the CPU, make my LEDs switching on and then after rerun again my FPGA VI again, If I don't do that LEDs blinking or motor rotation stay without effect... But close and start again the FPGA VI creates problems during the execution, especially for previous waiting of reading on the DMA FIFO... I've tried to catch errors on the FIFO to start again the FPGA VI with a right timing but nothing... I'm lost and I think that I'm missing something, a concept or something else.

I can't share my code because I'm working for a company but I would like to know if you have VI with this type of structure : an FPGA reference which have to be halted to allow hardware interaction with the default FPGA personality and then run again, everything with a good synchronisation...

I hope I'm clear, but if it's not the case, I can reword if necessary.

Thank you for the help !

Afghow.

[crossrulz · Accepted solution]

I don't understand why you need to change which bit file is loaded into the FPGA.  Why can't you add the code that handles the I/O to your processing FPGA?  Why do you even need to send the processed data to the host (CPU)?  Just have the FPGA process the data and change the outputs directly.

[Afghow]

Hi !

Thank you for your post !

You're right but specifications say that the frist time data are coming from the CPU (first time they are detected in the system), send to the FPGA and according to the result, the CPU take decisions (and start a DC motor can be one decision). I agree with your solution to make run the motor from the FPGA bitfile without passing by the CPU, but it's against the philosophy of the pattern CPU => FPGA => CPU => Action. So, if there isn't a proper way to switch bitfile I will do what you said in the previous post but it's not very adapted.

Afghow.

[ToeCutter]

If there's some advantage to having the CPU make the final decision, simply build the motor/LED control into your FPGA personality and have a parallel messaging stream where it is controlled from the CPU. Swapping FPGA personalities in and out is something I would avoid unless there is an extremely compelling reason.

[crossrulz]

ToeCutter said what I was trying to get at.  You do not need to change bit files.  You can have your IO and your data processing done in the same FPGA.  You like probably need a DMA to send data to the FPGA for data processing, another DMA to send the results back to the host, and probably some front panel controls for controlling the stepper motor that the host can directly access.

[Afghow]

Thank you everybody for your replies !

I understand the concept and I think it's the easier way to do what I want to do. But I'm sad to see there is no trick to do this in a transparent way.

I think the end user doesn't have to know that when he wants to make LEDs blinking he has to call a FPGA bitfile. I mean running an FPGA VI and want to make LEDs blink from the CPU VI at the same time should be transparent for the user and this without keep in mind horrors like bitfile switching for instance.

Maybe in a future version 🙂

Afghow.

[crossrulz]

---

Afghow wrote:

I think the end user doesn't have to know that when he wants to make LEDs blinking he has to call a FPGA bitfile. I mean running an FPGA VI and want to make LEDs blink from the CPU VI at the same time should be transparent for the user and this without keep in mind horrors like bitfile switching for instance.

---

He doesn't have to load a different FPGA bitfile.  Everything you need that FPGA to do should be in the bitfile.  Keep in mind that we are talking about HARDWARE when we talk about FPGA.  Each time you change bitfiles, the hardware has to be reconfigured.  That takes time and is pointless for the situation you are talking about.  Build your FPGA code to do everything you need it to and you will be fine.

[speleato]

---

@crossrulz wrote:

---

Afghow wrote:

I think the end user doesn't have to know that when he wants to make LEDs blinking he has to call a FPGA bitfile. I mean running an FPGA VI and want to make LEDs blink from the CPU VI at the same time should be transparent for the user and this without keep in mind horrors like bitfile switching for instance.

---

He doesn't have to load a different FPGA bitfile.  Everything you need that FPGA to do should be in the bitfile.  Keep in mind that we are talking about HARDWARE when we talk about FPGA.  Each time you change bitfiles, the hardware has to be reconfigured.  That takes time and is pointless for the situation you are talking about.  Build your FPGA code to do everything you need it to and you will be fine.

---

I want to second this. Switching personalities at runtime is the kind of thing you should only take on if there is some resource limitation that requries it or maybe if the hardware is being used for two completely different tasks. In this case it sounds like all the logic is part of the same control flow, so I also think the best solution is to write one FPGA personality that can do everything.

Afghow, does that make sense? Is there something we're missing about your application that makes switching bitfiles easier than combining the functionality in to one?

Sebastian

[Afghow]

I understand what you mean. I just feel it strange when I was able to add some FPGA code in the CPU VI side and see that it was not working because of a FPGA bitfile conflict. I was like "Oh nice I can do that.... Oh it's not working, maybe I can't..."

But I will centralize all my FPGA parts of code into one and flash it on the FPGA core. It is (by far) the best solution 🙂

Afghow.

[ToeCutter]

Conceptually at least, and pretty much in reality, when you upload a new bitfile you've effectively created a totally new piece of hardware, with a new interface. Hence it can't be expected to run with the old client side code. If I'm labouring the point, then ignore me. 🙂