C-to-gates experiences

I was present at this presentation at MAPLD a couple of weeks ago and also spoke with several of the authors. I work with Nallatech, one of the companies who gave Brian Holland a product to evaluate.

I don't think that you can read from this presentation that any 'C-to-gates' tool is superior to VHDL. Given the time, an experienced VHDL designer will generally do a better job than an automated tool. The key word here though is time. The logic density on FPGAs is increasing at a high rate. The performance of this logic is also increasing.

In the past, when balancing Design Time, Performance and Resource Use, automated tools would use up too much precious resource and wouldn't reach the challenging performance targets. As high-level-language hardware-description compilers have improved their performance with respect to resource use and performance, so has the pressure in these areas decreased. This leaves the key area of design time. Where design time is tight, a HLL-HDL compiler might be the only viable option.

Take a look at the following presentation and abstract:

Here a team with experienced VHDL designers and, notably, not C-to-gates iconoclasts, chose to go the Handel-C route on their project. We're not talking a 'Mickey Mouse' project either. We're talking about a system being built to repair the Hubble Space Telescope by Lockheed Martin. Time was short, I believe they were given three years from getting the contract till launch (not long, in space terms). They reported positively on their experiences. One thing they pointed out though, was that it would have been a good idea to have an experienced user of the Handel-C tool onboard from the start. They're useful tools, but they're not gcc-for-FPGAs just yet!

I don't think that Brian would claim to be an expert in all the languages he examined for this project, and I don't think anyone's making any claims about this study being the last word in comparing and contrasting these languages to each other and VHDL.

At cpa2005 I saw something like MAPD - C-Gates discussion using simulink as a bridge.

I think most EEs using Verilog or VHDL would think differently. What HandleC does well is in figuring out possible mappings from C to hardware but the performance I usually see isn't anything to write home about.

In FPGAs the fully automatic approach usually peaks at 80MHz while many EEs routinely work at 150-300MHz. That means about 4x less hardware for the same job or 4x more performance. If you only want to prototype an idea in hardware, then HC is probably okay assuming you can eat the rather stiff license. Most of the applications you mentioned (except perhaps N Queens) are relatively simple and can be done by EEs in hours (not secs) and can also be done with free software. EEs also have available a vast breadth of specialized techniques available that can be used to further reduce HW or increase speed, I don't believe much of that knowledge can be encoded into HandelC.

I think the HandelC results will get better by simply absorbing many more predefined parameterized solutions that have been pre built in HDL and glued together within the DK framework, atleast thats what I see at Celoxica shows these days. They have a nice board with lots of standard I/O ports with ready made IP cores you can glue together within the tool and use HandelC for whatever else they didn't give you.

regards

at usa dotcom

IMHO another big issue with "compiler" approaches is memory management. Given the variety and flexibility available in hardware, it is very hard to determine the right memory organization and chaching strategy. Significant performance losses would follow in memory-bound applications.