Hi,

Working in wireless communication project, we use lot of signal processing C coded modules, and we have a deal. we need to know what is the diference between Impulse Codeveloper and Mentor Graphics Catapult. Both of them convert C untimed code to RTL implementation but Codeveloper is too unexpensive compared to mentor product.

Are there any technical diferences between this two product?
The generated VHDL or verilog codes, have they the same quality ( Area on chip, performance, speed....)?

Hello,

I can't speak with authority about Mentor's Catapult C, because we don't have a license for it and I have not heard any recent, direct comparisons made by any of our customers. Having said that, I believe that Catapult C and Impulse C are intended for quite different types of applications and users. Mentor is most focused on ASIC and system-on-chip, while our focus is exclusively on programmable architectures. The potential user base for Catapult C is much smaller than the potential user base for Impulse C, which partly explains the dramatic difference in price.

Technically, there are many similarities between Impulse C and Catapult C. Both accept "untimed" C for hardware generation. In their case the input is a subset of C++, in our case a subset of ANSI C. Both maintain compatibility with current C/C++ tool flows and debuggers. Both have automated and interactive optimization features, loop pipelining, etc. and both tools generate HDL compatible with simulation and synthesis tools.

Perhaps where we differ most is in our strong focus on FPGAs as co-processors. Our users are often (although not always) using Impulse C to create hardware accelerated functions that attach to a processor, either embedded within or adjacent to the FPGA. This focus means that many (most?) of our customers are software programmers/engineers, not hardware designers. Our typical users would not accept pricing (or for that matter, product design) that reflects an "EDA" or "ESL" emphasis. We sell software cross-development tools for FPGA platforms, and we design and price our tools accordingly.

I hope this helps. We can certainly discuss this with you more in one of our weekly online sessions, or privately via email or phone.

David Pellerin

I am completing a Catapult eval and preparing to begin an Impulse eval.
A notable difference is that Catapult will synthesize substantially unmodified C++ routines,
while Impulse wants explicit directives for generating HDL. However
my experience has been that code for Catapult needed substantially refactoring in order to synthesize useful RTL,
even starting with source which had already been rewritten to better match optimized VHDL (already implemented).
In other words, even knowing how to factor algorithms for RTL,
I have to "guess" what C idioms are needed by Catapult to generate them.
I anticipate that annotating C code with explicit directives (e.g. for Impulse) will be more productive in the long run.

My judgment is that, for the money, Catapult has relatively poor feedback about
what it needs to achieve RTL with good pipelining and timing performance, which forces many iterations,
and iterations are slow even on fast workstations (single-threaded execution does not help).

Catapult seems to have only nominal integration with other Mentor products and produced unimpressive ASIC RTL.
I found no facility for invoking custom RTL e.g. as called functions.
I did not evaluate its "system-on-chip" capabilities (which did not seem well-documented).

I must admit, David Pellerin's statement that "our focus is exclusively on programmable architectures"
makes me somewhat uneasy.

Impulse C's focus is between explicitly specified parallelism and implicit, inferred parallelism. C is not a parallel language, but we're trying to find the middle ground that will allow programmers to write code that can run in an inherently parallel fabric, while still allowing the great accumulated talent and knowledge of C developers to be applied to FPGAs. We will continue to improve feedback from our tools and documentation of how to use our API and compiler to best take advantage of the target hardware.

As for "our focus is exclusively on programmable architectures", I would say it's still an accurate statement. FPGAs are our focus, and will be for the foreseeable future. However, we recognize that other parallel architectures can be supported by a tool like ours, and are keeping our ears open.

Ralph

Well, I certainly don't mean to make anybody uneasy.

We have customers today who are using Impulse C to generate RTL which is later migrated to ASIC, so I hope I didn't give the impression that using Impulse C for non-FPGA devices is not possible or practical. And, as Ralph suggests, there are certainly other, non-traditional programmable architectures on the horizon that could be future targets for our compiler.

However, to provide the best possible tools for our users, we have to narrow our focus on FPGA devices and on the most common applications for FPGA acceleration. I hope that as you begin your evaluation you'll see that the RTL generated from Impulse C is readable and portable. Nothing is hidden in the outputs, and you can combine with external, hand-crafted HDL using callable functions as needed.

As you've pointed out, the C language is an inherently sequential programming language. Programming C for FPGAs therefore requires some refactoring of applications to take advantage of FPGA parallelism, and the features of Impulse C are designed to make that refactoring easier. Not trivial or automatic, but easier and within the capabilities of software developers.

Best regards,

David Pellerin