Back in the 1980s, bus standards such as VMEbus and Multibus appeared, pushed by vendors who hoped that embedded systems designers – particularly those working in low- to medium-volume markets would shift from building their own hardware to buying in readymade platforms.
About the same time, National Instruments launched the first version of its graphical programming environment LabView, then largely aimed at the developer of custom, one-off test systems based around another standard bus protocol – this time the cable-based GPIB.
Fast-forward 25 years, in which time NI developed code-generation technology that could compile LabView applications down onto combinations of microprocessors and FPGAs, we are beginning to see the shift to heterogeneous computing platforms. In contrast to companies such as Imagination Technologies who are focusing their efforts on the combination of microprocessors and graphics processors (GPUs), NI sees a future for FPGAs running alongside those two and has done for some time. The company started working on compiling LabView programs to FPGA targets more than a decade ago.
Pictured NI president and CEO James Truchard speaking at NI Week
The NI Week conference in the summer saw the launch of a PXIbus instrument that marked the next step in the evolution of LabView-based development. Taking advantage of some new compilation and optimization techniques, the company’s engineers built the firmware for the vector signal transceiver in LabView. The firmware was then compiled to a mixture of processor and FPGA. By developing the low-level software in this way, NI expects users to be able to modify the instrument itself.
Fast-forward to the NI Days conference in London, UK last week and it was clear that the company expects this approach to move into wider embedded systems.
James Truchard, NI’s president and CEO, said in his keynote: “We don’t want embedded systems engineers to start with a blank sheet paper and a set of components. We want them to be able to put systems together in a fraction of the time that it usually takes and do for embedded systems what the PC did for the desktop.”
Truchard claimed that using graphical systems design, “engineers and scientists are building systems in weeks, days or even hours”.
NI’s primary competitor in graphical systems design, MathWorks, operates using a more DIY approach – generating either C or HDL from Simulink models that can be compiled for custom hardware. NI is working on the basis that readymade hardware offers shorter timescales.
“Customers are starting further along because NI has done the work of bridging to the FPGA. They were able to set up sensors and actuators instead of taking time to do build the interfaces themselves,” explained Brett Burger, product marketing manager at NI, in an interview.
The potential downside is that the embedded-systems designer needs to point LabView’s code generation at NI hardware, removing the ability to achieve cost reductions on hardware. Burger argued that for many users, many of them operating in low- to medium-volume markets, this may not be all that important.
“There are two things that are often overlooked by the machine designer,” said Burger. “First, the cost of your design is not just the hardware cost. You have to count in software development time. There is also the maintenance cost and that of lifecycle management. What happens when the FPGA you use goes end of life? That’s going to start taking up resources. Life-cycle management a lot of the burden. We have very good relationships with Intel, Freescale and Xilinx. Get insights that they would not give to a smaller design firm.
“The more resources and components you have to add, the less of your pie chart is about what you are bringing to the market. The one thing we say: ‘Don’t focus so much on what is going to cost you’.
“Second, when it comes to your product idea, until it’s been adopted there is no guarantee that you will hit 500, 1000, 10,000 pieces. If you focus on that 1000-, 10,000-unit cost you spend so long hacking out the cost on hardware you can end up missing your market windows and or your ability to attract funding. That is where the real value of graphical systems design comes in.”
Burger said for cost- or size-sensitive systems, a target the company now supports in addition to its rack-mounted FPGA- and processor-based CompactRIO systems is the Single-Board RIO. This looks more like a Arduino or BeagleBoard, comprising a Freescale PowerPC-based MPC5200 host processor, Xilinx Spartan FPGA, some basic I/O and a high-density connector for I/O expansion to custom mezzanine cards.
Diagram NI's Single-Board RIO
There are a lot of similarities between the NI approach and that seen in the FPGA business historically. Winding back the clock to the early 2000s, a bunch of ASIC vendors emerged who expected to be able to relaunch the gate-array concept – targetting users in the mid-market who thought FPGAs too costly on a per-unit basis but standards ASICs to be prohibitively expensive from an NRE perspective.
History demonstrated that the middle market did not really exist or at least was too small to support more than the bare minimum of players. It was too unstable largely because no-one has a very good idea of how many products they are going to sell early on in development. By the time anyone gets around to worrying about the per-unit cost of the FPGA, the team working on the successor product is either well on its way to ASIC territory or doing what it can to squeeze the design into an FPGA with a cheaper package or reduced feature set. Similarly, NI expects customers that embrace its approach to spend more of their time on programming – graphically – than performing low-level hardware optimization, something that the off-the-shelf board vendors wanted when they started.