I never thought I would be able to quote Karl Marx, the bearded philosopher, historian, revolutionary, and founder of communism, in an article on FPGAs, but here we go. “History repeats itself, first as tragedy, second as farce.”

What I am thinking about is the way in which we design components. With ASICs and SoCs, we have seen a steady progression of increased abstraction in the EDA tools, from drawing the individual transistors as rectangles in the layers of silicon, up through schematic entry, through hardware description languages, to the emergence of today’s work on tools that describe entire systems. ESL (Electronic System Level) design is a good buzzword here, and we are seeing a lot of tools (plus a lot of smoke and mirrors) emerging in this domain. Tragedy is perhaps a harsh word to describe the evolution of these tools, but there haven’t been a lot of laughs in trying to ride Moore’s Law as process nodes get smaller and smaller and re-spins escalate into the stratosphere.

And again, perhaps farce is too harsh a word to use as we watch FPGA designers chasing the same moving targets. On the positive side is that so far it has been possible to get rolling with very little cost by using the FPGA companies’ own tools. (The tools for third party EDA tools are traditionally eye-wateringly expensive, at least at list price.) And of course re-spins are free – or at least they don’t involve giving a third party large amounts of cash. But they still have a cost in internal time, in increased time to market, and in reduced opportunity benefits.

But surely it should be easier? Here is an industry spending its time making life easier and more pleasant for the rest of the world and it still wrestles with tools that are difficult to use.

Let’s look at one of today’s big juicy FPGA designs. It will likely include a processor or two, some DSP, memory, communications and interfacing, and some special logic. It is very rare to start with a completely blank sheet of paper, or blank screen, so the designer will probably be using some bought-in IP, exploiting some of the functions available from the FPGA manufacturer, reusing internally produced design elements (possibly not as well documented as they could be), and creating new logic. To create the new elements, the designer may be using MatLab, C or C++ algorithms, System-C, or HDL.

National Instruments (NI) reckons that this is just the point at which you should open up its LabVIEW graphical design environment. LabVIEW is a relatively inexpensive graphical programming tool that can work at multiple layers of abstraction, can run designs in simulation mode for fast debugging, and can compile to produce an FPGA programming bit-stream. (Graphical programming, in this sense, means that you drag, drop and link symbols to create your design.)

According to Wikipedia, LabVIEW is “short for Laboratory Virtual Instrumentation Engineering Workbench”, which sounds like a nicely contrived back-formation. It was launched in 1986 as a way for non-programmers to connect laboratory instruments to those new-fangled microcomputers, and the first versions ran on the Apple Mac. (IBM PC versions came later.) Underlying the interface is a data-flow programming language, and the whole package has evolved from its earliest days to cover a wide range of applications.

As we said, with LabVIEW, you drag symbols for different functions from a library into the design and join them with lines that indicate the flow of data between these functions. The functions were originally only the kinds of algorithms that you might use in data conditioning or preparing data for analysis and display on a screen or a printer. Over the last nearly 25 years these functions have grown markedly as the LabVIEW team has added implementations for a range of applications. The applications page on the website lists acquiring data and processing signals, controlling instruments, automating test and validation, measuring and controlling industrial systems, teaching and research, and designing embedded systems. The company also makes great play with robotics and FPGAs. (And don’t forget that if you want to play with Lego Mindstorm – sorry – evaluate different approaches to implementations through Lego Mindstorm, you program it through a stripped-down version of LabVIEW.)

One added value for the FPGA user is that NI’s RIO and CompactRIO prototyping and data acquisition products are FPGA based — initially to give great flexibility in deployment, but it does mean that the FPGA tools are proven in use.

So when you sit down in front of the screen to design your FPGA, you can draw on a huge range of different functions. Obviously there are massive resources for signal processing, advanced control, communications, data acquisition, logging and so on. And as the system has been targeted at FPGA development for some years now, there is a wide range of FPGA-specific functionality.

One of the great joys of LabVIEW is that it can cope with concurrency: not just in the narrow sense that Intel has recently re-discovered, although it can easily handle multi-core processors, but in the broader sense. On your FPGA, there may be several things happening at once, and these can all be represented in parallel, with any interaction expressed graphically.

LabVIEW has never really existed in a constrained world, and NI has worked hard to open interfaces. MatLab interfacing has been around for a while; in fact it is possible to have a two-way flow, both into LabVIEW and back into MatLab. C has recently been added, and there is the facility to use and manipulate blocks of IP, whether third party or locally created. An HDL interface is also available.

Another new LabVIEW feature is a statechart module. This will generate statecharts and documentation and debug the statechart on the host computer (a PC normally). Multiple states and transitions can be run simultaneously, modelling the real world that the state machine represents.

During development, the host PC can be used to simulate the design as a whole or parts of the design, allowing multiple tweakings before the design is compiled to a bit stream for the target FPGA.

As we mentioned, NI has hardware for prototyping systems, so you can load the design into an FPGA on a RIO board or a CompactRIO module for testing and use the range of tools available to provide a rigorous test regime. 

Now that is simplifying greatly a lot of good stuff; if you are interested, there is plenty of material on the NI web site about programming FPGAs. But the people at NI themselves are emphatic that graphical programming is also about the system level, not just the device level.

In many embedded systems, the FPGA is only a part of the system: normally it sits on a board with a microprocessor and a range of other components. In this context the NI people suggest (well – perhaps they would put it more strongly than “suggest”) that you should be using LabVIEW to design the whole embedded system, not just the FPGA.

But we have another title to cover that, so there may be something in Embedded Technology Journal later this year.

Link: www.ni.com