Announce: Impulse C-to-RTL Version 2 now available

How about adding a simple example of C source in and HDL out. That might help you sell some books and get some evals.

-- Mike Treseler

I am not really convinced of basic un RTL C to RTL conversion myself, since its already possible to write RTL in C to some degree but why don't the plain C to RTL folks try to persuade me with examples.

My other doubt comes from the fact that for FPGA, HDLs are almost free except for large designs and does C bring anything to the table for the high end.

Lets see perhaps a quicksort or other obviously NOT HW type algorithm C code from the Sedgewick or any algorithm book along with output and give us the synth results without having to touch the HDL code, and compare that with hand designed HDL version. I am curious to know what the upfront C tax cost is v potential coding effort savings, and relative speed, used resources of the two approaches.

And how does Impulse C compare with Precision C, HandelC, even SystemC, are they all using occam/CSP add ons to specify timing and parallelism?

johnjakson at usa dot com

I'll look out for the book though

The problem is that any HDL language is still timed and you have to sort out the concurrency. How many engineers write an algorithm in C/C++ (matlab,

first before translating it to HDL? probably quite a lot (including myself :-). Using a sequential untimed language like C is much easier to learn than any HDL language and for some applications far more suited. So why not bypass the whole algorithm to HDL translation and go straight to gates, it makes sense to me.

Have a look at the free Spark tool

The issue is that you can take a complex algorithm written is a "simple" sequential language and then use the synthesis tool to perform architectural exploration. Once you start hand coding the algorithm in HDL it is very difficult to change the architecture later. I am pretty sure that the HDL written quicksort is smaller/faster than the C-translated one, but on a similar note it is easier to write quicksort in C than it is in assembly.

I believe that most arguments will be similar to the assembly/high-level language discussions of 2 decades ago.

Personally, I believe in these tools simply because I still code in C first. I was also very impressed by the Catapult-C demo at DAC but from what I understand the price is the same as for a nice villa in the south of France :-)

Hans

That's exactly right. We (Impulse) are not going to pretend that "RTL in C" is a useful replacement for VHDL and/or Verilog programming. As has been pointed out, if you need to decompose the problem to the level of register-by-register, clock-by-clock behaviors, then there is little benefit to rewriting in C. There is also little benefit in doing "baby applications" (small filters and the like) in C if there are already existing hand-crafted hardware equivalents or pre-optimized library blocks (Simulink or otherwise) available to you.

So we don't do "RTL in C".

What we are promoting is a way to develop larger, highly parallel software applications in C, and to compile these applications into hardware without HDL programming. These applications represent untimed behavior (no explicit clocks or resets, little or no explicit description of parallel vs. sequential statements). We optimize the code for parallelism by scheduling operations, identifying clock boundaries, pipelining loops, and other techniques. We also provide CSP-like functions (in a C-compatible library) useful for creating larger parallel systems using a "processes and streams" programming model. These parallel systems of processes can span embedded processors and FPGA fabric in platforms such as the Xilinx Virtex-4 and Altera Nios 2.

Again, the goal with this tool is to allow software programmers access to FPGAs, not to replace existing hardware design methods. A secondary goal is to provide hardware designers a faster way to generate hardware (whether a prototype or an actual end-product) using software-to-hardware compiler tools. If the result is a prototype, then perhaps the hardware-savvy engineer will eventually replace the generated code with hand-crafted HDL. We aren't offended when that happens, though as FPGAs and their applications grow larger (and the compilers get better and better) we'll see that sort of hand-optimizing happening less and less often.

The analogy of C and assembly is a good one: there are many application domains (DSP for example) where assembly code is still the best approach, but as C compilers have improved and applications have grown larger, the need for assembly-level programming has diminished. VHDL and Verilog are the assembly languages of FPGAs.

Comparisons to other tools? Well, there's that villa in France, for one thing... But I'll leave it there, because this isn't the right forum for competitive comments and blatant sales pitches. There are some good C-to-hardware tools out there, and we believe we have some unique advantages, price being just one of them. We have 30-day evaluation software (with many examples) available free on request.

David Pellerin

*snip*

I disagree. VHDL and Verilog are the C/C++ of FPGAs. They're pretty good, they're reasonably optimized, but they'll never take full advantage of the hardware features that are available in structural netlists (which are the assembly of FPGAs). VHDL and Verilog replaced structural netlists (mostly) because they were higher level, quicker and easier to write. Synthesized C is the Java of FPGAs. It's passable, but will nevery be as efficient or well suited for the task as the lower level languages.

Good day, Arlen

This paper shows a nice application where their tool was used:

Daniel Leu