Does the market want simple, single-purpose tools or more complex tools?
Switchblade or Swiss Army Knife?
The Impulse C-to-FPGA development environment serves two types of users. On the one hand, the designers of SoC (system on chip) devices seem to want to accelerate, or offload, one or two modules onto simple platforms. In contrast, high-performance users need to go deep in the tool flow to squeeze every ounce of performance out of complex platforms. Trying to manage a C-to-FPGA development environment that serves two quite different types of users has left us with a bit of a split personality. Which way is the user base evolving?
Hardware compilation for the iPhone generation?
Some pundits predict that the shorter attention span of younger developers will shift the market towards switchblade-like tools -- that is, tools that take little learning and do just one trick well.
A good analogy here would be iPhone apps, which are cheap-and-cheerful, single-purpose, disposable, and don't come with a manual. In the case of the equivalent types of EDA tools, maybe they are accompanied by reference designs or a reference book at best. But the days of folk learning a tool before they need it may be passing.
We received some solid advice about EDA tools from an IBM scientist. He explained that learning a proprietary language is not "career enhancing." His point was that everyone is now stretched so thin that learning a new language just for a specific task is unproductive. Ironically, this is what is driving FPGA manufacturers to move upstream towards HLLs (high-level languages) like C, OpenCL, and System C. However, if these C-to-FPGA environments themselves become a chore, then the problem starts all over again.
A couple of hurdles exist that make the FPGA HLLs tricky. The first hurdle is that FPGAs handle memory, I/O, and resources differently from the ways in which microprocessor engineers are comfortable. This creates design "cliffs" where -- without warning -- some critical hardware resource is used up, or an off-chip memory path gets plugged up, and performance falls through a hole. The other hurdle is the iteration time. The dark side of the impressive growth in gates per device is the unavoidable growth in the time it takes to compile all the way to the chip. These iterations are painfully long and can be a bit of a "gotcha."
We have faith in the essential value of FPGAs in the designer's tool box. They are compelling. If we can collectively create some easier ways to engage them, they will grow in the mainstream. Our guess is that the switchblades will win. Product manuals will continue to fade. If the tool isn't intuitive and fairly easy to use, its user base will be limited to those who have to use it. So the bottom line is that we think many engineers will compromise on hardware selection based on the ease of use of the tools.
What do you think -- does the market want simple, single-purpose tools or more complex tools?