Embedded system designers today have a plethora of off-the-shelf computing platforms in a variety of form factors that feature multiple cores per processor, sometimes multiple processors per board, and in many instances the processors are capable of multithreaded operation. But how do embedded design teams easily leverage the available computing resources? Certainly teams can develop parallel structures in carefully-coded embedded applications, although many teams lack multithreading expertise. The broad proliferation of Intel Architecture multi-core technology has created momentum across the embedded space resulting in far simpler development options relative to other processor architectures. For Instance, a graphical tool such as National Instruments* LabView allows engineers that lack multithreading programming experience to quickly develop applications using a dataflow approach that takes advantage of the multi-core trend.


While LabView’s roots are in the test and measurement area, the graphical programming environment finds use today in a variety of embedded applications including real-time control and as a product development and prototyping tool. Teams can use LabView both with hardware offered by National Instruments and with board and system level products from a variety of third parties. Teams will find off-the-shelf hardware modules for applications ranging from data acquisition to visualization to communications. For instance, you can easily prototype a cellular base station using LabView software and off-the-shelf hardware modules.


National Instruments added multithreading support to LabView 5.0 back in the late 1990’s after the advent of multithreaded processors but before multi-core processors were available. Casey Weltzin, LabView Real Time Product Marketing Engineer, states, “We chose to support multithreading so that we could ensure both a very responsive user interface and very responsive program code.” From inception, LabView has combined a graphical user interface with the ability to create and execute software-based functions that might or might not rely on hardware that connects to the real world.


LabView is generally considered to be a dataflow programming language or environment. Users typically define a program based on inputs flowing into computation functions with the results driving outputs. Clearly that’s an over simplification because LabView certainly supports feedback, loops, and the ability to accept user input and display results. But the graphical development tool is generally based on dataflow (See the example screen shot below that shows part of the graphical program representation in the right portion of the screen and the UI in the left portion).














































Both the internal multithreading support in LabView and the dataflow programming model combine to optimize code execution on multi-core targets. Weltzin points out that the data-flow code-definition process naturally results in users defining parallel software functions that operate on parallel data. And at run time, LabView attempts to find all parts of the code that can run in parallel. Weltzin relates that the LabView teams calls these objects lumps, although the industry might call them tasks. LabView identifies the number of available cores, examines the lumps, and breaks the code into the optimum number of threads for fastest execution.


Here are several additional resources if you would like to learn more about the multi-core capabilities in LabView. Learn why dataflow languages map well to multi-core processors. You can get more help on handling multi-core designs with LabView. And the latest revision of LabView offers some dedicated tools to boost multi-core performance.


You might also want to peruse some case studies that demonstrate the advantage LabView brings to multi-core designs. The Max Planck Institute in Germany has used LabView and multi-core processors in its Fusion research. The result was a factor five improvement in matrix multiplications required for real-time loop control.


Eaton, meanwhile, used a multi-core approach and LabView in a truck transmission testing system. The combination quadrupled the number of data channels that the system can examine in real time.


You might notice that both of the case studies have a real-time component inherent in the quick study. National Instruments does offer LabView Real-Time for applications that require such response. Moreover, you can combine the real-time software, and standard LabView in one system using Intel® Virtualization Technology (Intel® VT) and the National Instruments Hypervisor. Weltzin points out that typical implementations dedicate one core to the user interface on standard LabView and the remaining cores to LabView Real-Time.


For more information on Intel multi-core technology and processors, you can peruse a broad look at Intel’s multi-core technology and look specifically at multi-core technology for embedded and communication applications.


What approach do you take to multi-core designs to get the most out of the available compute resources? Have you used LabView in a multi-core system? Please share your experience via a comment so that fellow followers of the Intel® Embedded Community can learn from your experience.


Maury Wright

Roving Reporter (Intel Contractor)

Intel® Embedded Alliance


*National Instruments is an Associate member of the Intel® Embedded Alliance.