INLINE VI'S for FPGA ...

[manu.NET]

Hello,

In Labview 2010, the implementation of INLINE VIs has been improved. But this feature is not aivalable in Labview FPGA.

When you are looking for ticks/space you have to replace the VI calls by their content ... and then the FPGA VIs becames rapidly unreadable.

I think that inline VI could be very interresting in FPGA because ...

• Ability to create userfriendly / updatable / readable / clear FPGA diagrams 
•  Optimize the time/space needed to call a real VI

By default, FPGA VIs should all be "Inline" VIs !

Manu.

[stbe]

I thought, I was pretty sure that FPGA VIs are already "inline" since they default to reentrant with preallocation for each instance (=place a copy of the code wherever the VI is placed)

I don't think, there's an additional calling overhead when the G code is translated into HDL and later into the bitfile.

KR, stbe

[manu.NET]

Hello,

I think you should be right. I looked at the online help ...

"Note  (FPGA Module) The Share clones between instances and Preallocate clone for each instance options do not apply. If you use a reentrant subVI in an FPGA VI, each instance of the subVI on the block diagram becomes a separate hardware resource."

So according to the online help, when "reentrant" is selected a separate hardware ressource is created for each VI call.

But what means "a separate hardware ressource" ... is it really an inline call ? or only a standard call with duplication of controls and indacators ?

The online help is not clear ! And with the new paragraph "Inline VI", nothing is said about FPGA ! 

Manu.

[tsteel]

Whilst that is true about the separate instances in hardware, the LV FPGA compiler must still do "something" about the way SubVI's are called.  I have a truly horrible diagram in one application at the moment, consisting of 4 copies of identical code, that would be ideal for a SubVI (and originally was). 

I have run into problems with clock boundaries when calling subVI's containing SCTL's, which are not an issue when the code is inline.  If the VI's were truly inline, this would not be a problem.

Implementing "true" inline SubVI's would be great for LV FPGA!!!!

[manu.NET]

Hello tsteel,

I was not completly sure about the answer of stbe ... but i didn't had the time to make some investigations.

The answer could have been right, but one thing was not clear !

Why NI, in theyre FPGA course, talk about the "overhead" due to VI calls ... and also speak about "reentrant" property. 

If "reentrant" was really "Inline" ... they wouldn't have do so !

Thank you very much for your feedback !

Manu.

[Donovan_B]

Hi Manu,

In LabVIEW on a desktop or real-time system, there is generally some overhead involved in a subVI call as data can be copied before being passed into subVIs, non-reentrant VIs may cause waits in the calling VI if the subVI is already in use, and other things like that.  Reentrant does not mean inlined.  Reentrant means that multiple copies of the same subVI can be loaded into memory and running at the same time.  Inline means you remove the overhead of subVI calls because you will not always have to copy data or wait for a subVI to return before calling it again.

In LabVIEW FPGA, because your LabVIEW diagram is converted to a hardware circuit, you do not have the same overhead of calling subVIs.  Since the code is running in hardware, there is no operating system that has to make data copies or load VIs into memory.  These overheads are removed by the process of compiling for hardware, the same way that inlining removes them when running code on a computer processor.  For calling LabVIEW FPGA subVIs, there is no duplication of controls or indicators, it is simply a wiring operation that should not introduce any overhead.

For reentrancy, if a subVI is set to be reentrant on the FPGA, this means that a separate circuit is created on the hardware for each instance of the VI called.  This prevents the code from having to wait until one call is complete before another can begin to speed up execution, just like in LabVIEW for the desktop, but also uses more hardware space than a single circuit would.  If a subVI is non-reentrant, only one copy of the VI's circuitry will be made, which saves hardware resources, but can slow down execution if the same subVI is being called simultaneously from different points in the code.

tsteel, can you comment on what types of clock boundary problems you see when calling subVIs?  Are you using different derived clocks to govern each of the loops or a single clock for all?

[clicks]

Inlining of subVIs is definitely a missing feature in LabVIEW FPGA!

The code example shows a loop that takes 602 cycles. With inlined subVIs it would take 202 cycles. The wait node is just a placeholder for some other code that could run in parallel. The subvi as a hole only starts to execute when all inputs are ready. when inlining, some parts of the vi could already start executing even when some unrelated data is not yet ready.   

programming languages are not justified about what is technically possible but about how simple you can express a code.

upper box shows the code of the subvi

[crossrulz]

clicks, I think your assumption is wrong.  Even with inlining, there is an execution barrier at the VI call.  It is just that the compiled code goes into the calling VI and a VI call is replaced with a sequence structure.

[clicks]

Aha! Thanks for clarifying this. Then inlining is not exactly the same as placing the code of the vi on the calling vi. There is still a "frame" around it! I thought this was the point of inlining vs subroutine… 

But then:

It would be a nice feature on FPGA targets, to have inlining without execution barrier!

However, inside single cycle loops, placed subvi behave as if the code would be placed there. There is no aligning of the "execution front", since it is free propagation through the logic cells.

Sometimes it is quite hard to understand what the meaning of the code is and some reverse engineering is needed to understand. The documentation is not very precise at this point.