NI LabView solves embedded and multicore problems!

Some time ago, National Instruments (NI) introduced LabView 8.6. LabVIEW is a very data flow programming tool! And inherently, it has always been parallel processing!

Take note folks, as parallel is now increasingly becoming regular! And your multi-core problems could well be solved by NI's LabView.

Given the ongoing recession, interestingly, NI projects double digit growth in 2009 for the region comprising India, Arabia and Russia. Jayaram Pillai, MD, India, Russia & Arabia, NI, says that these places have been traditionally strong in localization. The key is: what can NI's technology bring in for indigenization!

Pillai notes: "We have always talked about virtual instrumentation. How can you bring the local content into the system?" NI's LabView's ability has generally been to create a program out of a non-program. "Images are your natural language. We feel engineers can express themselves using graphical language," he adds.

LabView inherently meant for parallel programming
Most embedded systems provide quick and easy solutions. NI is trying to put electronics into every problem that it confronts. About 98 percent of the processing environments are used elsewhere, other than the PCs. What embedded can do today is tremendous! NI's LabView is inherently meant for parallel programming.

Pillai says: "When you are running two cores, it is important how you share the data between the cores. We have multi-core for Windows. We can do multi-core programming for embedded as well." NI's tools perform multi-core programming, which itself is a software program.

Besides targeting particular silicon and other resources, there are other problems or areas to deal with, such as test maths, state chart and data flow programming, etc. NI has built all of these components into LabView 8.6 -- things such as programming MCUs, FPGAs, Power PCs, etc., can be handled.

Solve embedded problems by developing simpler systems!
Coming back to embedded systems, there are two requisite steps -- programming the electronics and programming the system. "We see ourselves getting into the space of solving multi-core problems," adds Pillai. "Everything today is software enabled. We intend doing for T&M what spreadsheet has done for financial analysis."

Definitely, software is the instrument in virtual instrumentation. "It means, to solve 98 percent problems of the embedded applications, there is a need to make the development of embedded systems even simpler," he contends, and rightly so!

"As we went higher in abstraction, we found that we were able to solve more problems. You've got to get into a high level of abstraction, which can be done by LabView, called system design platform. LabView today, is the platform for test and embedded," notes Pillai.

In grahical system design, there is a need to leverage and collaborate in parallel. Graphical programming harnesses multi-core processors. LabView has also been the runaway software tool for DAQ and instrument control. As a result, more and more people can now do embedded programming.

Pillai advices: "If you want to build systems, you need to integrate NI design tools with third-party design tools to share the data. The integration of data has to be seamless."

Benefits of graphical system design
Graphical system design should do for embedded what PCs did for desktops. "We are a graphical design company and are now building systems," he adds. The concepts of graphical system design include design, prototype and deploy.

So, what are the product lifecycle benefits of graphical system design? There are multiple hardware systems priced at different cost points based on performance. A LabView user can install the software into an expensive system for testing purposes, and later, deploy on to a lower platform.

Legacy problem and major paradigm shift
Sharing of data between cores is key! Parallel programming in sequential does not make sense. Rather, data flow programming makes a lot of sense. However, there is a legacy problem as far as multi-core programming is concerned. That is: how do you shift so much of the sequential programming knowledge into data flow? This will require a major paradigm shift.

Besides, there are a lot of sequential tools as well. There is a need to integrate all of that into multi-core. So far, multi-core problems have been addressed in test and embedded systems. It is still on in gaming, though! Maybe, this too will be cracked in a matter of time!

To all of my Chinese friends, Kung Hei Fat Choy!