LabVIEW FPGA for pure computation, CELL processors

[altenbach]

LabVIEW FPGA is marketed very I/O centric. However, there are a few applications where FPGAs can dramatically increase the computation speed compared to a conventional CPU. Some random example links:

Cryptography and Bioinformatics.

Chess move generation (It would have been interesting to make an FPGA based entry for the Checkers Challenge at the end of 2003 :))

Simulations

etc.

The ease of programming using LabVIEW FPGA compared to VHDL code would seem to make it a fantastic tool for purely computational projects. Is anyone doing this already?

Has anyone done any benchmarking for FPGA computations (no AI/AO, etc. involved)?

---

On a side note, it seems there is a new CPU design that would seem to be almost custom tailored to run LabVIEW because of its natural parallelism. Have a look at e.g. The Cell processor prototype by IBM, Sony and Toshiba. Some preliminary information can be found e.g. in Electronics Weekly. There is also a more detailed analysis elsewhere.

Looks very, very promising! Hopefully, NI will keep an eye on these things. I want "LabVIEW Cell"! 🙂

[ZenerII]

Altenbach,

While I agree with you that this could be a great tool from a pure processing stand-point. I think the main reason we have focused the FPGA module towards I/O is due to making the FPGA technology fit within the context of what many of our customers are doing and needing. Nearly every LabVIEW customer need to interface to I/O, so we are using FPGAs and LabVIEW to give them a great way to customize their I/O boards for I/O mix, custom digital I/O, very high-speed control, etc... While there is a minor focus on signal processing (at the signal level), we are mostly focusing on the custom I/O problem many customers face.

I think as we ooch into this area more and more, you will begin to see a shift. I'd be interested in hearing any more of you thoughts. Thanks.

[Ben]

The phrase "Nearly every LabVIEW customer need to interface to I/O,..." struck a bad cord with me.

LabVIEW WILL take over the world someday, but only after we stop thinking like that.

"
Long rant about thinking ouside the box deleted.
"

I like the LV Zone Challenge idea. Maybe get some loaners for people who want to participate.

Great topic Altenbach!

Ben

[Matthew_Williams]

Had to repair a data file from a 15 year old DOS application this week. Decided to do it in LV rather than fire up the old, intact development system. 20 minute later I had repaired the file and also had a spiffy new tool to simplify future repairs. The only I/O involved was that in the internals of the hard drive. Way to go, LV!

Matt

[shoneill]

I agree with Altenbach.

Of course I/O is the target market for NI, as the name LabVIEW effectively transmits.

LV CAN do "normal" things in many scenarios where I/O is totally irrelevant. The benefits of visual programming goes WAY beyond I/O, even if this is where NI makes money on hardware. The marketing implications of LV as an I/O solution for a company who wants to earn on hardware is obvious.

I agree that LV is capable of much more, and although I don't feel like predicting LV will "take over the world", I agree with the sentiments of the statement fully. Perhaps a better point is LV SHOULD take over the world, provided NI releases the (mental) I/O shackles when it comes to target markets.

Just my 2 Rappen

Shane

[shoneill]

Oops,

Sorry Ben, it was yourself who said LV would take over the world. So many experts in the forum reminds me of the film 2010 "My God, it's full of stars!". 😉

Shane.

[Ben]

Thank yo ufor your support Shane!

It took me 1-1/2 hours to post the original reply becuase I found myself ranting.

The last time I felt so certain about future trends was back in 1983 or there abouts.

At that time I said "Some day there will not be air conditioners in computer rooms but there will be computers in air conditioners." That comment was laughed at as being rediculous.

This time I will go on the record.

LV WILL take over the world someday! I hope I am here to see it.

Ben

[Joe_Guo]

Labview will help building a new world, but I doubt it will take over the world completely. I envision a new program language with combined features from labview and text-based ones. There is no doubt labview is fast in many ways, however, there are many times I prefer using a text based language. Mouse click is still too slow when compared with typing.

-Joe

[Ben]

"Mouse click is still too slow when compared with typing".

Yes for the time being.

When the technology used to track pilot eye and head motions in helecopters is made cost effective for the common devloper, we will be able to look at a terminal, "right-blink" and develop hands free.

Trying to insire creativity*

Ben

*Years ago I read a book called "A Wack on the Side of the Head, A Guide to Creative Thinking" (I can not recall the authors name). One of the key elements when trying to come up with new ideas is to concider the rediculous ideas and make them practical. When I post rediculous sounding statements on threads like this, I am attempting to inspire creative thoughts. So, as you read, please give some thoughts to the rediclous, they may be the next iPod, Frisbee, or Pet Rock.

[shoneill]

Joe,

I agree. There are certain activities where I wish I could type some code, ActiveX control for example. The mess of icons and wires when working with Excel is just terrible.

I still think that the overriding attractiveness of LV is the simplicity with which the visual style gives the whole structure of the code. I think it allows the brain to process the goings-on more efficiently than with a purely text-based language.

Having seen a brief glimpse of a screenshot of LV 8, I think that NI is going in this direction. From the low-res pic I got to see, it looked like there was a BIT of a shift to (for want of better words) VB-style interface with property windows for ocntrols and so on. Personally, I think this would be great as dealing with control properties is a bit of a nightmare at the moment.

Anyway, I've already overspent my 2c.

Shane.