Excel is definitely something that I have overlooked as a “compute model”, even if to me Excel + VBA sounds pretty horrible to analyze and do some kind of static analysis on Also interesting since Excel would seem to have a very opaque type system for data. I will look it up!

/jakob

C to Hardware is also intended to target the FPGA Accelerated Computing space. For legacy HPC applications this is much less painful than hand conversion to Verilog.

I’ve argued on my blog that the spreadsheet should be the primitive model for parallel computing to replace von Neumann instruction streams. If you look back to last September, you’ll find a similar rant on the use of C for parallel programming. Excel+VBA is by far the most widely understood combined data-flow and control-flow environment. I think that because Excel+VBA dominates this programming model by so much that it’s overlooked by most experts and rarely considered in the same breath as Matlab+Simulink or Labview.

We posted code for a Python-Excel interpreter that performs non-blocking assignments and synchronizes data with your visible range in Excel (see the blog for info). We can only do trivial Excel to Verilog conversions currently so nothing terribly cool on the FPGA side.

So the gain in using C/C++ may be more the “mental reuse” by the developers of their worldview, than the actual reuse of the code (although even badly written code can serve as a reference model for rewritten HLS-friendly code, to confirm that it implements the same algorithm).

I also see moves to other languages for control, but control has also not been the forte (pun intended) of HLS, which has concentrated on dataflow oriented signal and media processing algorithms more. Bluespec seems to be an exception here, although its current most natural form is in an HDVL, SystemVerilog.

That embedded programmers are by and large wedded to C/C++ is well-known, but I see a very strong trend to move to Javam and UML in the control plane and model-driven architectures in control algorithms. Most such high-level tools generate C (and occasionally Java) to be able to compile to something executable, that is the best way to do it.

But what I am uncertain about is whether the code provided by embedded developers, generated from domain-specific languages, or obtained as reference implementation is a actually a useful start for synthesis. In my experience, it would likely not be, as all that code is not designed to fit a restricted easy-to-manipulate subset of C.

To me it would look like you would have to at the very least go through the code and do a lot of rewriting and fixing to make it fit for synthesis. Negating most of the gain of reusing “existing” code.

Just about everything you say is true and easy to agree with. (Other domain-oriented specification languages such as the family of actor-oriented dataflow notations – Mathworks Simulink, Ptolemy, CoWare SPW are also worth a mention). However, the decision to use C is much easier to understand than by looking at the EDA companies marketing literature and the rationalisations about abstraction levels and productivity. Stated pure and simply, C (and C++) IS the market for ESL synthesis, and IS the market for a lot of embedded code writing. Most embedded software developers developing application code for media type applications use C/C++. Many of the standards being implemented start with reference implementations in C/C++. Most of the legacy code for embedded systems is in C/C++. And all this legacy and current practice shows a reluctance to consider alternatives and a persistence in continuing to use C/C++ that is both surprising and not-surprising at the same time. I do know that if there was a concerted and visible movement by embedded systems developers to move to other languages or input notations in a serious way, then it would garner a lot more attention. Periodically there is interest in trying to do something more directly with Matlab and the dataflow actor-oriented languages such as Simulink. However, since most of these toolsets generate C or C++ as an intermediate form, it is all too easy to rely on our old friends of C-based languages and keep building them into the flow.

Those who build flows and tools based on other languages share the optimism of “if we build it, they will come”. But too often in the past the new edifice is built and no-one has shown up! I fondly expect that at some time there will be a sea change and something new will become the new new thing and receive wide adoption. But I recommend that no-one hold their breath waiting for that to happen.

Grant