Jump to content

Confusion regarding FPGA deployment


Daklu

Recommended Posts

[Posted to NI's forums yesterday, but no response yet. Cross-posting here to expand the audience--this is time critical.]

I have the attached fpga code (cRIO 9074) that works as intended... most of the time. (Open the png in a new browser window to view it.) Sometimes I'll start up an rt vi written to interact with the fpga vi and the fpga vi just doesn't respond. Specifically, setting the value of the Start button from the rt side doesn't do anything. I suspect it's something I'm doing wrong rather than a bug in Labview. It's apparent the deployment relationship between fpga and rt code doesn't work the way I think it works, but I'm not sure where the model I've mentally created differs from what it really does.

Questions:

1. I've written the fpga vi with the idea that it runs continuously and the rt code can connect to it dynamically. My intent is to load the fpga vi onto the crio, and have different rt vis interacting with it depending on what I need. We're still in the R&D phase, so when I need to use a different rt vi I stop the previous one and click the run button in the new one and it gets deployed to the crio. Sometimes this works fine, other times the fpga Start button doesn't seem to be working and I'm stuck in Standby mode. Is this kind of dynamic connection a valid way to use fpga vis?

2. The fpga vi is written so the fpga led on the crio flashes anytime it is running. Sometimes when I stop the rt vi the led stops flashing, indicating the fpga vi was stopped. I don't understand why this is happening.

3. The Open FPGA Reference vi has three different linking options. You can link to the build spec, the vi, or the bitfile. It's not clear to me exactly how, or even if, these options change the runtime behavior of the vi. Do I need to write my code differently depending on which of those three options I select, or are they options designed to allow developers to use the edit-time workflow that suits them best? (i.e. If I link to a build spec, I can change the top level vi in the build spec, whereas if I link directly to a vi I need to change the Open FPGA Reference configuration--a source code change.)

4. I've read that the Open FPGA Reference vi includes the bitfile in its saved data, and the bitfile is deployed to the fpga when that vi executes. Does that happen regardless of which of the 3 linking options you select?

5. If 4 is true, that implies there is no way to start an rt vi that interacts with an fpga vi that is already running, since the Open FPGA Reference vi will overwrite the fpga code currently executing. Is that correct?

6. There are several places where one can choose to "Run FPGA vi when loaded." The build spec, the Open FPGA Ref configuration, and the fgpa vi's properties ("Run when opened" option) are three I can think of off the top of my head. When those setting conflict, how do I know which setting will take precedence?

7. How do the reentrancy options on a top level fpga vi affect it? Help files mention rt vis, but not fpga vis. Intuitively it doesn't seem like it should do anything since the vi is only being called once.

I have lots of other questions too, but they're somewhat dependent on the answers to these questions, so I'll stop for now. 16x16_smiley-happy.gif

TIA,

Dave

post-7603-0-76519200-1355519928_thumb.pn

FPGA Main (DMA).vi

Link to comment

Hi Daklu,

To answer your questions in more of an order of execution:

Open FPGA VI Reference

This VI can either connect to an existing running FPGA VI, if it is already running, or download the bitfile it is linked to if it is not. Whichever ever linking mechanism you use the runtime behaviour is the same. Linking to a bitfile will always work but linking to a build specification or VI will query the project at edit time for which bitfile is the correct one to use (or break the VI if it still requires compilation).

I have not had a use for the other options for run when loaded yet! I always stick to the open reference (which I think is what will take precendence when you run your RT VI anyway, the others must be something edit time related I think). In the open reference VI, if run when loaded is selected the FPGA VI will immediately start. If unselected it is not started until you manual start it using an invoke node. This can be used to set intial register values before the code starting. If the VI is already running through some other means (such as it is already running), these functions will return a warning at run time.

Close Reference

Your problem in 2 is probably related to the Close FPGA reference VI. If you right click you have an option to close or by default close and reset. This means the FPGA VI is reset (read aborted in standard LV speak) when we close the reference. If you want it to continue you should change this to just close.

FPGA Image Deployment

If you want the FPGA to run continuously independent of any RT code you either need a piece of RT code that you use to deploy it initially by opening a reference and closing it without the reset. Or you can actually flash the VI to the FPGA using the RIO Device Setup application which will be in your start menu. This will even cause the VI to persist over power cycles as well.

FPGA Top Level Re-entrancy

Any FPGA VI is re-entrant by default, this makes the most sense more of the time on FPGA. For the top level VI though it will make no difference as you can only ever run one top level VI on the FPGA at a time. As it is a VI though this is just going to apply if you wanted to call it as a subVI.

I hope this helps clarify a few points and I think covers your questions.

Cheers,

James

  • Like 2
Link to comment

I do nearly all of FPGA work with the sbRIO line, so here are some of things I do when I have an FPGA VI that needs to run independent of the RT:

Download the Bitfile and set it to Run when loaded -- There is an option to reset the FPGA VI on a reset of the RT, this is up to you are if you wish that.

I do this mostly cause my projects require the FPGA to be active as soon as power is applied. If it was loaded with the RT, there is usually some delay, 20-30 for sbRIOs.

I don't usually download the bitfile until I start testing outside of the IDE (you can run the FPGA VI independently in IDE easily) and for the final deployment.

In the Open FPGA Reference I usually use the link to Bitfile option and do not select the Run option. -- This is a personal preference mostly. If you link it to the Build file or the VI, Your RT Vi will break if you change the FPGA VI.

The reason I don't select the Run option is: I don't want the RT to reset my FPGA and I consider it an error, if the FPGA is not already running.

To my knowledge the RT Build(the rtexe) always includes the FPGA Bitfile; but if you do not select the Run option, then the RT will simply connect to the FPGA.

I don't use the Close Reference since the only time I "STOP" either the RT or FPGA is when power if removed. I open the Reference once and pass it to any subVI that needs it.

I leave all my FPGA VIs as Re-entrant. The only time I would even consider using a non re-entrant VI in FPGA is if space is a premium (I have yet to even come close).

I would like to note; that when deploying FPGA to multiple targets outside of the IDE, to my knowledge (LabVIEW 2012 and prior), the FPGA Target System Replication tool is needed as the System Configuration API does not, yet, support FPGA deployment.

  • Like 1
Link to comment
  • 5 weeks later...

I don't see a FPGA reference being passed between the nodes being used.  The image os of the host VI and not the FPGA VI, right?

 

OR did the snippet simply create property nodes for your terminals.... That's kind of confusing me a little.....

 

How does your host VI look?

 

Shane

Edited by shoneill
Link to comment

Sorry for the delayed response.  I was out of town for two weeks and returned home to a self-induced pc meltdown.

 

Thanks for the tips James and Ryan--it was a big help in getting the fpga to behave consistently.

 

 

I don't see a FPGA reference being passed between the nodes being used.  The image os of the host VI and not the FPGA VI, right?

 

Neil is correct, the image and attached vi are of the fpga vi.

Link to comment
  • 4 weeks later...
FPGA Image Deployment

If you want the FPGA to run continuously independent of any RT code you either need a piece of RT code that you use to deploy it initially by opening a reference and closing it without the reset. Or you can actually flash the VI to the FPGA using the RIO Device Setup application which will be in your start menu. This will even cause the VI to persist over power cycles as well.

Cheers,

James

 

 

Hi,

 

using the onboard flash with our 785x's is exactly what I want to do but up to now I only managed with "Open FPGA VI Reference" containing the bitstream and downloading it to the FPGA. Are there additional parameters to give to the "Open FPGA VI Reference" VI or is this the wrong approach?

 

Cheers,

flintstone

Link to comment

Hi,

 

You should use the open reference in the same way. LabVIEW has some check that the running bitfile matches what the code expects (I am not sure exactly how but I think there is a checksum involved). The one thing to be aware of that if LabVIEW tries to run the VI again and it is already running it will spit out a warning.

 

Cheers,

James

Link to comment

Thanks James for your reply. I think this is where I've had problems, due to this thingy http://lavag.org/topic/16218-lv-fpga-master-typedef-not-found-issue/ I had to rebuild everything at the deployment site but did not download it again to the flash (after all the FPGA design is expected to work the same apart from P&R subtleties) and then, of course, the FPGA VIs won't match anymore.

 

Sometimes I wonder if I've just worked too long with FPGAs to use LV FPGA ;) .

 

Cheers,

flintstone

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.