Get reference to currently deployed bitfile on FPGA target

[smithd]

Basically I want a VI like open FPGA VI ref which takes a RIO interface and returns a reference, except that it doesn't deploy a reference if one doesn't exist. It would instead pop out a boolean or error if you try to get a reference and there is no bitfile already deployed.

Two use cases I have in mind:

-Imagine if you need a cRIO to start working ASAP so you deploy your bitfile to flash and tell it to run on power-up. You still have to package the exact same bitfile with your RTEXE, even though its already deployed. This increases the size of your RTexe significantly. Lets say you version your RTexe and don't version the FPGA deployed to flash. Depending on what the signature check is, obtaining a reference to your bitfile may cause the "new" bitfile to be redeployed, eliminating the advantage of loading your bitfile onto flash in the first place.

-Imagine if you have a framework like veristand where you need to use a single bitfile in multiple locations which were written by different developers and possibly released at different times. The tools on NI labs (https://decibel.ni.com/content/docs/DOC-35574) help a lot and let you, once you have a reference, confirm the reference has all the interfaces you need to run your code. However, if you need to share references between code modules you must still be sure to obtain it in just one place and then share the reference yourself using a global or FGV.

Having the RIO driver solve this would be very helpful.

[timtamslam]

Just a heads up, your community hyperlink is broken. Looks like you accidently got the ")" in there as well. 

[StephenB]

Interesting idea. I have some thoughts.

An FPGA bitfile includes 3 main things (at least for the purposes of this discussion)

• bitstream - The actual 1s and 0s to program the FPGA
• meta data describing the interface of the bitstream - This describes the registers, DMA, etc that the bitstream implements in glorious detail down to names, addresses, and data types (even labview data types).
• signature - this is a cryptographic hash of the entire bitfile

When an FPGA has been programmed with a bitfile, the FPGA has a signature register that holds the value from the signature of the bitfile it is programmed with. When NI RIO attempts to 'open a bitfile reference', it first checks if the FPGA is already loaded, and if it is, it reads the signature register and compares it to the user provided bitfile. If they match, then it knows the interfaces of that FPGA by looking at the meta data included in the bitfile. Therefore, there currently is no way for NI-RIO to know how to interface an FPGA that has been preloaded without the bitfile. Even if you used the link you mentioned (https://decibel.ni.com/content/docs/DOC-35574), it wouldn't work because you couldn't open single-resource-sessions without the driver knowing what resources are available.

To enable this functionality, you really would have to compress and save the meta data that is in the bitfile down to the FPGA. This would take up more space on the FPGA, but allow a host to open a reference without the bitfile. This would be a big change for LabVIEW and NI-RIO.

If bitfile size is the main concern, then perhaps an alternate bitfile format that omits the bitstream but still contains the signature and meta data could be used to open a reference. And it would error if the FPGA wasn't already loaded with that signature.

For your two use cases:

1) You dont actually have to package the bitfile with the RTEXE. You can put the bitfile on disk on the target and use the Open Dynamic Bitfile Reference function. This avoids RTEXE bloat and is really useful if you have multiple bitfiles you might choose between. You still have the bitstream in the bitfiles though, which if preloaded, is unneeded. So perhaps the alternate format bitfile could be helpful here. For the rest of this use case description (the versioning thing), that just sounds like a messed up program situation and isn't really related to the new API call. If you have one bitfile preloaded and you then load a new one in the RTEXE... you chose to do that.

2) When would you need to share references between code modules? This causes coupling which isn't recommended for a modular framework. Each module should just open its own reference. NI-RIO already does ref counting to handle having multiple clients open a reference to the same FPGA, so this works fine. Having a shared reference makes things much more complicated as there has to be something that opens up a reference first, distributes it to client modules, then waits for them to finish and close the reference. If each module just opens its own reference and closes it when its done... its all good.

[smithd]

Tim: Sadly ideas are not editable so I can't fix that 😞

Stephen: Interesting details about the fpga references and how they work, I didn't know all those pieces. I do however think that putting data down on the FPGA. After all, every flash is RT-accessible, and I assume (but could be wrong) that the RT system can read as well as write. If thats the case, on boot the cRIO or other system can check to see if a bitfile is loaded and read the biftile (including the interface metadata) out of the flash. If a user deploys using any of the normal RIO functions, it can be cached in the RIO driver without requiring us to re-read the data back from the FPGA. That is, it sounds like everything can be done in software, right now, assuming that the flash can be read as well as written to.

I also like your idea of a interface-only bitfile. Maybe when you wrote to flash using the utility it could store the interface-only bitfile in a special location and the rio driver can just yank that out. Again, once read, the RIO driver can cache it.

As to your use case comments:

1) Dynamic might help in some cases but it also ends up being a pain as you have to deploy it yourself. As for "you chose to do that"...I mean, yes, technically. There are lots of things people "choose" to do if they make mistakes or simply don't know any better. I would also argue that in some situations you don't "choose" that at all, LabVIEW does it for you. Lets say I have two devs, one working on FPGA one on RT. RT dev is expecting a certain bitfile because thats what they're testing with. FPGA dev is iterating on his stuff. RT dev could sync their repo without knowing the FPGA interface has changed and accidentally deploy a completely different bitfile than what they're intending. -> tl;dr is that there are plenty of things that can go wrong with the automagic relink and redeploy stuff that happens in LabVIEW, and the options are to improve the tools to make them safer (what I'm requesting) or simply not to use the tools and load the bitfiles manually from disk from a file location you deployed to yourself.

2) So I talked to andrew about this and he said in vstand there are situations where you may need to specify one bitfile multiple times, to make sure all the custom devices get a reference. I encountered the same issue with a different plugin architecture.

To answer your specific question, "When would you need to share references between code modules?", the obvious answer is "when that reference is to the hardware its running on"...which is exactly what we're talking about here. There is a single, shared, globally accessible HW resource. Rather than opening 50 references, each one of which has the risk of accidentally redeploying the bitfile if versions or files change, it seems easier to push bitfile deployment to a higher level and let the modules simply ask the driver what bitfile they are supposed to have access to.

Since we're talking about modular plugin based frameworks, that "something that opens up a reference first, distributes it to client modules, then waits for them to finish and close the reference" is free, part of the structure of the framework.

If what I'm asking for were in RIO it could still do reference counting, but I'm not sure why that is required here anyway. The framework defines the lifetime of the modules so they should all release their references at the same time, I would imagine.

[StephenB]

Good points. I hadn't thought about the flash.

Version management of bitfiles would be nice. I agree. That could assist with the mistakes.

As far your last comment on #2. I think that yes, if NI VeriStand handled opening a single bitfile reference for the entire target, the user only had to specify the bitfile in one place, and that bitfile reference was at run-time distributed out to code modules that needed it and cleaned up after them... it would be nice. However, that would only works for targets with one FPGA, and at least in NI VeriStand's case, we primarly run on PXI with lots of FPGAs. So rather than having a scaled up architecture to handle all of that, its simply easier for a module to open a reference when it needs it and close it when its done.

I guess I'm agreeing with you that it would be nice, I just don't know of the ROI considering the work involved to update the framework to handle this when its so trivial (two function calls) for a module to open and close a ref itself. For a PXI system with 3 R series cards and a FlexRIO using those FPGAs in 4 custom devices... the user still has to specify the same ammount of information, so it doesnt save anything. For a system with 2 R series card used in 4 custom devices... the user has to specify the bitfile 2 less times... which is nice but not ground breaking considering the UI work, API work, and Engine work that the feature would require.

[KiwiWires]

Hi

here is my use case for this feature:

I have a FPGA running with the DCAF framework on the cRIO. 

To calibrate the system I want to a Windows Laptop connect to the FPGA over the network and effectively scrape the values of some known indicators. I pretty much reversed engineered the DCAF FPGA module to do what I needed. But is basically this:

 https://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-FPGA-Advanced-Session-Resources/ta-p/3500447

I have this working but it requires the matching deployed bit file for the connection. This is also preferable to our first attempt which used the cRIO module variables - as it requires the cRIO to be reconfigured into scan interface and RAD imaged again. 

@StephenB based on your comment above, the C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\NI\LVFPGA Adv Session Resources\GetResources.vi is not reading from the deployed FPGA - rather the description in the associated bit file. This is good to know.

Nick

[Terry_ALE]

This feature feels like security hole.

It should be settable by the build specification. 

I wonder if Xilinx prevents this intentionally. 

[KiwiWires]

I agree downloading bit file meta data from FPGA doesn't feel very secure and has copy implications. Microcontrollers have lock bits set when programming that prevent readback. 

I would like to connect without downloading if signatures don't match. So the Open Dynamic Bitfile Reference could have an optional "Download Bit File (T)" Input - so if this input if false and the signature check fails it throws an error rather than downloading the specified bit file. 

That way you still need to have the correct bit file to connect (which is fine for me) - but if its different the connection fails and an error "FPGA is running a different bit file" is returned.