LabVIEW FPGA Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Intaris

Ability to define datatype of Registers / FIFOs from code (without needing the configuration dialog)

Status: New

This is the current situation when dealing with register creation on FPGA targets:

 

Regsiter Create.png

 

This is what I would like:

 

Regsiter Create wishful thinking.png

 

I am currently creating a group of classes to abstract out inter-loop communication and the ONLY thing changing between classes (aside from variations between Ragister vs FIFO vs Global and so on) is the datatype.  Being able to link the Register creation to a data input (the data value of the class itself for example) would save a lot of work in such operations.  If it were also possible to do the same for the Register stored within the class private data then implementing different classes int his way would be really easy.

 

Even without classes, the ability to autoadapt the type of registers / FIFOs in this way would be a real step towards re-usable code on FPGA.

 

 

5 Comments
Intaris
Proven Zealot

Oops, the fact that the icon and the label datatypes don't match was not intentional but it WAS an image in the process of creating a new instance of the class, so I suppose it's actually representative of the approach.....

Intaris
Proven Zealot

I want to draw new attention to this idea.  Given the appearance of VI Macros (.vim) I see a LOT of application for auto-adapting creation of transfer registers or BRAM entities where only the datatype changes.  It would be great to have nodes which accept values from the block diagram to determine their type.

Intaris
Proven Zealot

With the advent of Malleable VIs, this idea would make a whole lot of my code SOOO much easier to maintain.

 

Intaris
Proven Zealot

OK, just getting back from a major overhaul of our main FPGA code base, I need this more than ever.

 

We should be able to specify inputs for all valid configurations for Registers, FIFOs, BRAMs and so forth. Yes, such inputs must resolve to constants, no problem, this can be done.  In addition, for a FIFO or BRAM instance, the latency of the read port should be accessible somewhere so that flexibility is increased.  Personally, when implementing a set of LVOOP types on FPGA, read latency is of extreme importance to create portable code.

 

So for a Register, the datatype, the arbitration options. the initial value (using a VI may be awkward to implement) and Name should all be available as inputs to a "Instantiate Register" primitive.  The "Datatype" input should auto-adapt to whichever wire is attached.  This will preclude the need to open a configuration dialog and allows us to create some self-adapting code which (at least in my case) massively reduce the number of VIs I need to actively maintain.

 

With FIFOs, the number of options icnreases, but surely there's no logical reason not to facilitate this?

raphschru
Active Participant

You can use the unsupported FPGA scripting tools under

"LabVIEW xxxx\vi.lib\rvi\ClientSDK\Core\Script\Container\Item\Public".

Get the ref to your VI-defined register node, use "Open", then "Rename" and "SetValue" to configure it. Finally "Commit" and "Close".

raphschru_0-1621363270639.png

To get the ref of the node, I used "TRef Find Object by Label" from "vi.lib\Utility\traverseref.llb".