Do you think the success of running refactoring software on hardware hinges on expensive tools or smart coders? This question is often masked by arguments over the merits of different design tools. However, we (the guys and gals at Impulse Accelerated Technologies) think that the results are more dependent on the coder than the tools, and that the tools have a long way to go to make this otherwise.
With the relatively recent entry of two very competent tools -- Xilinx's Vivado HLS and Altera's OpenCL -- we're no longer quite so lonely promoting the merits of C-based FPGA programming. Of course, now we need to consider the differences in the tools' approaches. These differences are actually fairly few; there really are only a couple of ways to skin this particular cat. Most C-to-RTL (sometimes called C-to-FPGA) tools work by helping you refactor your C code into coarse-grained logic that's easier to machine compile into an FPGA.
This really is not rocket science (I'm not a rocket surgeon). Some tools strive more toward the iPhone approach of making things appear easy-peasy by making you press/click only a single button. Others, like Impulse C, are more Android in nature in that they reveal the nitty-gritty behind the curtain to developers.
What the tools discussion hides is the fact that it ain't the tool -- it's the coder. The quality of results we've seen in the past 10 years usually reflects the patience and skill of the coder. In the case of patience, we're talking about a couple of things:
- Waiting hours for RTL-level results running in hardware
- Calmly backing up when you fall into some hidden design hole, such as running out of hardware resources and/or handling memory as if the FPGA were a CPU
Skill is trickier. The winners at this methodology are smart about the system architecture level and can make hardware/software decisions independently. They are also language flexible. High-level languages (HLLs) are brilliant for algorithms, filters, FFT, and more, but hardware description languages are better for glue, static, or critical modules (i.e., those occupying a disproportionate amount of the processing).
In recent months, we have become so tool agnostic that we've opened Impulse's design services team up to Vivado HLS and OpenCL projects. We know refactoring, and we don't really care what tool our customers want to use. We are typically pinch hitting for teams that need help with performance tuning or data streaming.
The point is that, though we think Impulse C is the coolest thing since the toaster oven, we really don't care which tool we use, so we are happily stepping into Vivado HLS and OpenCL projects. Again, if you can understand adapting software for hardware, and if you can stay calm when you fall off some hardware cliff, then HLL design is a powerful option for offloading CPU code into hardware.
Just don't blame the tool if something ends up being suboptimal. Instead, take another look. See if you can use your superior reasoning powers and knowledge to guide the tool to achieve an optimal solution.
How about you? Have you used Vivado HLS or OpenCL for any of your projects? Can you share your experiences with the rest of us?
Related posts:
Tweet This
