LVOOP on FPGA with LV 2009

[Götz Becker]

Hi,

I just played a little with LV2009 and the FPGA module. I even could compile a small VI with LVOOP in it. Does anyone know some examples for LVOOP on FPGA? Or even benchmarks of the possible hit on size and speed of such code? Currently I don't have access to our cRIO so I can't test myself.

Greetings from Munich

Götz

[Aristos Queue]

I can't point to any examples, but the code generated is identical to a cluster of the same size as your class.

[Götz Becker]

Thx for the quick reply.

Same size as the class itself or same as self+parent(s)? I guess dynamic dispatching on FPGA is then some hierarchy of hidden case contructs in the background? (too bad all the intermediate .vhd file are encrypted these days )

[Aristos Queue]

Thx for the quick reply.

Same size as the class itself or same as self+parent(s)? I guess dynamic dispatching on FPGA is then some hierarchy of hidden case contructs in the background? (too bad all the intermediate .vhd file are encrypted these days )

Sorry -- I include the parent cluster in the size of the child... that's me having too much knowledge of what goes on behind the scenes. ;-)

Dynamic dispatching is entirely folded out in the compiler -- if we cannot resolve it to a static dispatch at compile time, the VI returns a compile error.

[Aristos Queue]

Regarding benchmarks, one of the FPGA team passed along this tidbit:

You can compile FPGA VIs on a computer that is not attached to any LabVIEW FPGA targets, which lets you see the resource utilization and whether the code met timing constraints. In other words, you can do a reasonable deal of benchmarking without access to the hardware; you do need to have LabVIEW FPGA and NI-RIO installed to compile for a cRIO system.

[Götz Becker]

Thx for the clarification with some behind the scene knowledge .

For doing real benchmarks on my own, I would have to convert some real-life code to LVOOP and compare the results... too bad I just don't enough spare time . I guess I have to convince my management to give me free (payed) time at every major release of LV to play with new features .

[WallStreetFPGA]

It seems that using OOP on an FPGA would be counter-intuitive. The paradigm for programming FPGAs and their end use make this hard to understand why this would be done.

That said, could more info be provided on why this is being done? Is there an algorithm that needs to be ported over? Also, most OOP code isn't parallelized to take advantage of the FPGA's parallel computing.

[jgcode]

It seems that using OOP on an FPGA would be counter-intuitive. The paradigm for programming FPGAs and their end use make this hard to understand why this would be done.

That said, could more info be provided on why this is being done? Is there an algorithm that needs to be ported over? Also, most OOP code isn't parallelized to take advantage of the FPGA's parallel computing.

I haven't used it when programming FPGA so I can't comment there, but I have seen it used for creating the simulation FPGA code for debugging RT applications.

[Aristos Queue]

It seems that using OOP on an FPGA would be counter-intuitive. The paradigm for programming FPGAs and their end use make this hard to understand why this would be done.

I see FPGA as one of the more critical platforms to have OOP supported. I pushed really hard for it despite a lot of doubt from others. I understand that it isn't typically done, but as I see it, that's largely because in most languages, objects tend to be reference based and don't deploy to the FPGA, so FPGA programmers never get used to thinking about them.

Class encapsulation provides protection for data. It allows a programmer to prove -- conclusively -- that a given value is definitely within a given range, or that two values always maintain a particular relationship. Most academics researching software engineering tell me that OOP improves debugability and code maintainability as code base increases in size, regardless of what the task of the software is. That to me means that the more important that verification and validation are to a platform, the more valuable OOP becomes. FPGA programming is often used for direct hardware controls, often in some very high risk domains, situations where you want to be damn sure that the software is correct. OOP is one programming paradigm that helps assert correctness of code. You could pass raw numbers around through your program, but a little bit of class wrapping can help make sure that numbers representing Quantity X do not get routed to functions that are supposed to have numbers representing Quantity Y, and, more importantly, that only meaningful operations on X are ever performed.

Class inheritance provides better code reuse. It's true that dynamic dispatching at runtime cannot be done on the FPGA. The compile fails unless every dynamic dispatch node can be processed at compile time to figure out which subVI will actually be called. However, if you're writing many different FPGAs that each have a slight variation in some aspect of their data, it is a lot easier to change out the upstream class type and override one member VI than to "Save As" a copy of your entire VI hierarchy, change a cluster typedef, and rewrite a core function.

Also, most OOP code isn't parallelized to take advantage of the FPGA's parallel computing.

It can be. It just often isn't because so many folks think in references instead of in values. With LV's compiler, the classes are proptyped through the entire VI hierarchy to statically determine every dynamic dispatch, then are reduced to clusters, and from there the rest of the FPGA compilation takes over, which allows parallel operations on multiple elements of the cluster. So OOP code written with LabVIEW classes does often get that parallelism kick. Even when it doesn't take full advantage of the parallelism, running on an FPGA is sometimes done for speed, and being able to deploy an OOP algorithm onto HW may be important to some folks.