How can I create a Malleable FPGA SubVI without the use of variant?

[eli.barber]

I have an FPGA subVI that looks for input change and automatically ramps the values using the internal clock (y=mx+b)

It needs to accept 3 different input types U32, U0,32, and U4,28 for now. Potentially more in the future.

Do I need to create 3 separate VIs or is it still possible to use malleable vis without the variant datatype?

[Terry_ALE]

---

@eli.barber wrote:

I have an FPGA subVI that looks for input change and automatically ramps the values using the internal clock (y=mx+b)

It needs to accept 3 different input types U32, U0,32, and U4,28 for now. Potentially more in the future.

Do I need to create 3 separate VIs or is it still possible to use malleable vis without the variant datatype?

---

How about Polymorphic VIs?  I think you may need to make a VI for each instance but worth digging into the options.

[eli.barber]

My inputs do not change in shape but in type. The exact same operations are being performed in all three cases.

[altenbach]

Malleable VIs don't require any variant datatype. You can write it in any of your existing datatypes and save it as "*.vim" and it will adapt to whatever is wired.

(I am not sure if any of this works on FPGA, though.)

[Terry_ALE]

The DRAM functions convert certain inputs into arrays of booleans.  That is one way that functions that come with LabVIEW FPGA handle these kinds of scenarios.

[raphschru]

Malleable VIs (VIMs) work perfectly with LabVIEW FPGA. The only tricky part is that you may have to temporarily open your VIM in a non-FPGA context to make the "Inline subVI into calling VIs" checkbox appear in "VI properties" > "Execution", so you can check it.

There's no need for variants, as soon as you have a typical data type that makes the VIM's diagram not broken.

The potential issue I can see is that your mathematical operations have non-default output configurations (blue coercion dots), so their output type will not adapt with the VIM's input data type.

The solutions I would try:

1. No specific output configurations for operations, let the results take as much space as needed. 

2. Use specific output configurations that are big and precise enough to work with any of your possible input data types.

In both cases, you'll have to measure whether that takes too much FPGA space or not (using the compilation statistics) and you'll also have to check whether the results do not saturate or lose precision.

3. If you want maximal FPGA space efficiency, have a specific diagram with specific operation output configurations for each possible input data type.

Regards,

Raphaël.

[eli.barber]

I Got it! I Think???

Here is what I did which appears to be working for me. 

1.  The FPGA does not include variant, but using Assert Structural Type Match and wiring a control from that works 
2. The Variant Controls/Indicators must be inside the Type Specialization diagram, Leave "Accepted" unwired as your default case should fail for invalid datatypes. Set controls to required on the front panel.
3. From here, you can place a second Type Specialization Block to handle each of the different data types you want to process. In my case, I want to handle U32, U4,28 and U0,32. 
4. You must wire a constant (Void) for your 2nd Type Specialization Block "Accepted" Case This is what will trigger the error for data types to not be accepted from this polymorphic terminal

[raphschru · Accepted solution]

Almost. As said, there's no need for variants and one Type Specialization Structure (TSS) is enough.

Regards,

Raphaël.