LV FPGA Instruction Framework

[cyphish]

Hi

NI is using the Instruction Framwork for almost all their FPGA designs today. I would like to get a deeper understanding of it and start using it in my own designs. However, I haven't found any resources describing which classes I should create on my own, which classes they should inherit from, which methods that needs to be overridden etc.

Are there any Instruction Framework development guides or tutorials somewhere?

Best regards

Anders

[MihneaTr]

Hello Anders,

Can you give me more details regarding how and where you want to use the Instruction Framework? Are you trying to communicate with a cRIO? If yes? What model?

After I made a quick research into this matter the only thing that I could find is an overview of the Instruction Framework on our website.

http://zone.ni.com/reference/en-XX/help/374716A-01/niifdigitizers/instr_frmwk_design_library_overvie...

Best regards,

Mihnea T

[cyphish]

Hi Mihnea

Unfortunately that's the only resource I found as well and it doesn't really say much about how to actually implement the code.

In the first project we would use a FlexRIO 7976, but if we find that it works well, we'll probably use for future projects as well and then we'll use 5668, 7975, 6592 etc.

Best regards

Anders

[dklipec]

I might know something about this.

So, R&D built the instruction framework with the express intent that it could be used by third parties.  We even have a reserved range of numbers for 3rd parties to use for identifying their private subsystems.  However, we have not followed up on that intent with public examples on how to create one of your own.  There are a number of concepts that need to be addressed, and they might be best illustrated with either instances that are used "in practice" (look at the code behind existing subsystems) or a set of pedagogical examples (we have such examples like a "calculator" implemented using the Instruction Framework, or an addressable memory that we use in our automated tests).

If you are interested, we could probably look at packaging one of these up for consumption.  Do you have any information you could share about how you would like to use the Instruction Framework?  It might help us choose the right example to point you to as being "most like" what you are trying to do.  For example, if you intend to map some hardware resource, like an AXI4-Lite interface to a CLIP, we actually already have shipping wrappers to facilitate that exact use case.  However, if you want to look at using it as a way of exposing an addressable/encapsulated interface to a set of LabVIEW code, we'd want to point you more toward a "best practices" for a G implementation.

[cyphish]

Hello,

Thank you for the answer.

In short, this is our application:

We use FlexRIO together with adapter modules.

We have a digitizer adapter module X using two inputs, and a digitizer adapter module Y (not the same model as X) using one input and want to be able to have the same configuration options for all three of the data streams. The solution I'm thinking about now involves OOP with a inheritance hierarchy something like this (this is still in the design phase):

 - Digitizer

 - Digitizer X

 - Stream A / Stream B

 - Digitizer

 - Digitizer Y

 - Stream C

So, we have a base class Digitizer with some common configuration options. Digitizer X/Y inherit from that one but open different FPGA references and so on.

On the host side Stream A/B/C would map to different read/write nodes specific for that stream. Using dynamic FPGA interface Stream C could use the exact same API as Stream A or B (if the read/write nodes and the different FIFO's have the same name and type etc), but A and B need to have specific controls/indicators since A and B must be able to be configured individually.

What I thought might be an option was to use the instruction framework in some way to make it possible to reuse all code (i.e. being able to configure both A,B and C with the same API even on the lowest level). However, when I think about it I'm not sure that would solve the problem since A and B need to be able to have unique configurations. So, even using the Instruction Framework it would be necessary to make some distiction between A and B (need to write to different addresses). So, the instruction framework is probably not the solution if my assumptions regarding how it works are correct.

Not sure if I gave a good explanation... but the conclusion is probably that the instruction framework won't solve anything...

However, I would be glad to get some advice regarding best practices for dynamic and modular FPGA interfaces 

For example, if we have a lot of settings in SubVI's... what is the best way of sending settings to the SubVI?

Best regards

Anders

[balexand]

The Instruction Framework library may help solve some of the problems you are facing.  It sounds like you want to have a generic "Digitizer Stream Configuration" block for reuse on your FPGA designs.  You want 2 instances of the block on one FlexRIO device, and 1 instance of the block on another FlexRIO device.  Is that about right?

One problem you face with using Controls and Indicators to configure these blocks, is that it is not easy to dynamically pick which register to read from / write to on the host.  We have solved this problem on occasion using a FPGA reference that has all of the possible registers on it, and a case structure.  See attached 2015 VI, "Dynamic Register Read".

The Instruction Framework allows you to use a more general-purpose, address-data scheme to do reads and writes.  It takes more effort to implement an Instruction Framework compatible Address Space, compared to dropping some Controls / Indicators, but once you have implemented it, you get to use some of the built-in features like:

• Dynamic discoverability of FPGA libraries from the host
• Version checks
• Support for multiple instances of the same address space class

and more.  It sounds like your use-case might warrant you to write an Address Space class, but you could likely get away with using Controls and Indicators too.

What version of LabVIEW are you using?

About how many control / status registers do you think you'll need per digitizer input?

What do you think you would use for the data types of these registers?

Concerning your question about sending settings to a SubVI; you can use either a Handshake or a Register to write the configuration settings at a high level, and then read those settings back at a low level.  You just need to wire a register reference down to the low level.  If you have several references, then you could use either a 'resources' cluster, or a class's private data.

These topics may be helpful:

http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgaconcepts/fpga_storing_reentrant/

http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgaconcepts/fpga_name_controls/

[mmccord]

I am also interested in an example implementation and documentation for the Instruction Framework. I'm also curious the benefits of the the Instruction Framework over the register bus like it was used in the VST libraries? Register bus seems to provide most of the benfits, with a much simpler implementation. I understand that Instruction Framework is OO, but from my initial digging through it, it doesn't seem like the additional complexity is worth it over the register bus. Both systems use a host -> target DMA for sending instructions and frotnpanel indicators for target -> host communication. 

I'm using Labview 2014, so if you can provide example code, like the AXI4-Lite Instruction Framework interface, please save it for LV2014 if possible. Thanks.

[balexand]

The Instruction Framework library evolved from the Register Bus library used in the VST LV FPGA designs.  The library defines two interfaces which may be implemented by clients.

1. Address Space
• Receives instructions from the framework, and is expected to provide a response.
• See instr.lib\_niInstr\Instruction Framework\v1\FPGA\Interfaces\Address Space\Address Space.lvclass
2. Instruction Producer
• Sends instructions into the framework, and waits for a response.
• See instr.lib\_niInstr\Instruction Framework\v1\FPGA\Interfaces\Instruction Producer\Instruction Producer.lvclass

At this time, the FIFO Register Bus is the only library with an Instruction Producer.  

• See instr.lib\_niInstr\FIFO Register Bus\v1\FPGA

This FIFO Register Bus library is nearly identical to the VST Register Bus, except this library implements the Instruction Producer interface that lets it hook into the Instruction Framework.  It may be worth noting that the FIFO Register Bus library also augmented the capabilities of the VST Register Bus by allowing for instructions with 64-bits of data, and a 32-bit address.

One of the benefits of using the Instruction Framework is that it provides encapsulation of details that you don't necessarily care about.  On VST, the Register Bus is placed in a SCTL at the top level of the design.  The instruction output from each Register Bus is passed to a network comprised of Register VIs, Arbiters, and Muxes, and the read data is passed back.  With Instruction Framework, you create a Register Configuration object, and connect Address Spaces and Instruction Producers using a simple registration API.

Some Instruction Framework features that were added:

• Improved arbitration between shared subsystems (producers can talk to unblocked subsystems while shared subsystems are blocked)
• Added inspection of attached address spaces / subsystems using metadata parameters: UID, instance number, parent.
• Added version check capability using metadata parameters: version, oldest compatible version

I will take some time to post some instructions on how to get started with the Instruction Framework shortly.  95% of clients only need to implement the Address Space, so I will focus on that.  I would recommend that customer designs use the FIFO Register Bus Instruction Producer that is provided by NI, at least to get things working.

[dklipec]

The AXI4-Lite address space wrappers shipped for LV 2014 with the version of the Instrument Design Libraries included with NI High Speed Serial/PXIe-659xR.  The VIs should have been included with other releases of software designed instruments after January of this year, but if you want to see them in action for an example, you should look at the Aurora or Eye Scan sample projects.

http://www.ni.com/download/ni-labview-instrument-design-libraries-for-high-speed-serial-instruments-...  

You can find the libraries themselves at instr.lib\_niInstr\CLIP Adapters\v1\FPGA\AXI4-Lite

As balexand noted, the reason to use the Instruction Framework over the VST Register Bus is primarily around the improved feature coverage.  It is also where future investment is planned.  The older VST-style register bus will receive maintenance/sustaining engineering. It will not receive new features, and probably will not be ported to new targets or performance optimizations planned for the Instruction Framework.

[cyphish]

Thank you for the input.

I will look into it but will probably not spend too much time on it before Balexand have posted the instructions. Did you intend to post the instructions here in this thread or do something more "official" like a LV Community page?