LV FPGA Instruction Framework

[balexand · Accepted solution]

Sorry for the delay.  I wanted to get the examples just right, and peer reviewed.

I posted an Instruction Framework Tutorial on the NI Labs community space ( ni.com/labs )

https://decibel.ni.com/content/docs/DOC-45669

[cyphish]

Hi

Thank you for your help.

The holidays interrupted my investigation of this question but I have begun looking into it now again.

I don't fully understand everything in the tutorial and the surrounding code yet but I think that it will become clear when I start testing out more on my own so I marked it as the solution 🙂

If I have questions about the tutorial, I guess you would prefer if I post on the NI Labs Community space so that the information is in the same place, correct?

[balexand]

How about:

For comments directly related to the tutorial  (e.g. "Can you explain this sentence?"), post on the tutorial page.

For general Instruction Framework questions, this thread might be better.

[cyphish]

The Instruction Framework seems to be able to handle 4 producers and 16 subsystems at all times, are there other versions with less producers and subssystems?

I think I will only need one producer and two subsystems. I also looked at the 5624R example (by creating a 5624 project) which only use one producer and one subsystem.

Does the unused producers and subsystems consume space on the FPGA or does LabVIEW optimize the code so that those VI calls are removed. My reasoning is that since LabVIEW must know in compile time which VI to run, and since the abstract VI's does not contain any code, LabVIEW might understand that no code needs to be executed and then remove it.

For example, in the VI:

C:\Program Files (x86)\National Instruments\LabVIEW 2014\instr.lib\_niInstr\Instruction Framework\v1\FPGA\Top Level Bus\Register Configuration\Private\Subsystem Port.vi

There are 16 calls to the Interface Bus VI including wiring etc, but 15 of them will call the abstract VI.

1. Are there other versions with less producers and subssystems?

2. If they are not removed during optimization, is the general idea and philosophy that the additional code is so small (not sure how much space we're talking about) and won't take any significant space and won't cause any timing issues and that the benefit of having some space to grow is worth it? I'm asking because we are very tight on space and often run into timing issues in some of our designs.

3. Beside from getting more modular code, would the instruction framework also reduce the resource utilization because there are less front panel objects? If we have 50 FP objects which we instead access via instruction framework, do you expect that to give any impact?

[balexand]

The intention was that we would specify a maximum number of producers and subsystems, but only the ones that get populated with meaningful objects would affect resource utilization.  You are basically left with a bunch of empty slots, which will be optimized away.

1. No.  It is conceivable that someone could branch the Register Configuration class and make the necessary modifications, but nobody has done that as far as I know.

2. Yes.  I haven't looked into how much of the 4-input arbiter gets optimized away, but the bottom line is that any instruction wire going to that Subsystem Port.vi will not be driving any logic if it's just calling into the abstract VI.

3. Yes.  This is actually one of the reasons we switched to using the 'Register Bus' instead of controls and indicators for some of our more complicated applications.  Large numbers or sizes of "Controls+Indicators" in fast clock domains do not scale well for timing performance (there are muxes that become congestion problems as the design scales up).

[cyphish]

Thanks.

I see many benefits of using Instruction framework, but is it something that is future-safe to start working with and relying on in our future designs?

I'm guessing that there aren't that many LV users outside of NI that create their own child classes. From an NI perspective it means that if you want to use some other way of implementing this in the future... it might be okay to cut support for instruction framework (support as in instruction framework base classes are not included anymore, not support as in answering questions) since relatively few people will be affected.

Do you think the classes I make now still will work in... three to five years?

[dklipec]

I want to start with a kind of "plain English," standard disclaimer.  This is software.  No one can give an unconditional guarantee that the next version of anything will change nothing.  I can only share what our intent is.  Something unforeseen may force our hand to be different.

Our internal policy is:

1. Don't break people.  Internally, we use this feature in several ways on several products.  We are unlikely to "just" break it both from an internal efficiency standpoint and with respect to breaking customers.
   
   
2. If we have to break compatibility, we should not break compatibility in place.  That is to say, major changes will align with major LabVIEW versions, and we will not transparently upgrade into a break.  We don't have any concrete instances where we plan to do this, but we've thought out scenarios where some change may be okay.
   
   An example of this would be if something changed where a user might have to accept mutation in order to progress.  Our intent would be to align this with situations where a user likely is resaving VIs anyway in a newer version of LabVIEW (such as moving a project from LV 2014 to LV 2015).
   
   
3. If we have to break compatibility more invasively, it is handled with a version change.  You'll note that all interfaces in _niInstr have suffixes attached to them (for example: v1).  It is our intent that if a library ended up having interfaces which do not fit future requirements, that the "v1" version of that library remains in place, and will have critical bugs fixed.  But new code will adapt to use a new v2 variant of that library.

I wouldn't want to get into a very detailed analysis of different kinds of scenarios, because I wouldn't want to imply a guarantee that a given situation shall be handled in a particular way.  But you should expect that code you write today will work tomorrow.

[cyphish]

Thanks. And don't worry, I fully understand that there are no guarantees 🙂

But your answer was reassuring either way and it answered my question.

Btw, I really like that NI is using OOP and lets customer create child classes etc (it might have been there before... just that I haven't noticed it...).

[cyphish]

Hi again,

I want to distribute VIs that use Instruction Framework. It will not be distributed as an executable. The VIs will be accessing a bitfile with Instruction Framework included.

The idea is that the user of the VIs shouldn't have to install the FPGA module or any instrument design libraries, only the FlexRIO driver.

From what I understand the Instruction Framework is installed with Instrument design driver libraries and not the FlexRIO driver or FPGA Module, is this correct?

What would be the minimum install needed to get the Instruction Framework host VI's on a computer?

I tested creating a project and put all the Instruction Framework VIs in a VI, to see which depencies there are.

Is there an official distribution from NI with just these files (didn't find any in VI Package Manager).
Do you have any recommendation regarding distributing VI's with Instruction Framework dependencies?

Best regards

[dklipec]

So, as far as binary installation, you'd need the FlexRIO installer and LabVIEW.  If you use a modern FlexRIO distribution (15.1 or later), the libraries should install with LabVIEW without needing to install anything else.  I just checked this on a clean VM, installing only LV 2015 and FlexRIO 15.1.  The Instruction Framework (et al) were installed and usable.  I obviously can't compile FPGAs without LabVIEW FPGA installed too, but it seems you are looking for the minimum runtime.

One way to automate a smaller footprint from the existing media is to use Specfiles.  You'd go through the installation process on a machine and deselect all the optional components (like example support, adapter module support, etc).  You'd need to read up on this, but there is a shortcut with the command line options to the setup.exe:

Like the dialog says: there's more information online about how to automate installers.

If you are looking to have a slimmer installation media, you'd need to create a runtime installer that pulls in the FlexRIO Runtime from your development machine (or use one that is already shipped), and overlay the design libraries on top of that with their MSI (ie: "FlexRIO_Installer_Folder\Products\NI_DSGNLIB_COM_2015\niCmnDL2015i.msi"), along with all the other development support stuff that doesn't ship with the runtime.  You can probably get to something that works, but you're going to have to spend some time getting it there.  It would be difficult to support such an installation because you are slicing in individual installer components until it works.

Put simply, I don't recommend messing with that unless there is no other choice.  But that is the only way to make a smaller installer that also installs the development support, which is what is needed if you are distributing VIs to run inside of LabVIEW.  (ie: not building an executable or a DLL, which is what the runtime edition supports).