Disclosure - I am from Impulse.
C to HDL selection kinda depends on a) your existing IP and tools and b) what hardware you are selecting. There are some good products in the area but you might consider if you are going to target FPGA, FPGA enabled boards or ultimately ASIC. Compatibility with these considerations is critical. I'd recommend you white board out your flow: what IP you are starting with, what other tools you already use and what your final hardware target is. You might find that there are only one or two products that are actually compatible with your needs. Most of us will give you a free license for 30 - 90 days to play with it and ensure compatibility with your existing tools and target hw flow.
Hi Dr. DSP. Disclosure -- I am from Impulse. OK, we are old dogs and previously were part of the original ABEL team. The dialog re languages is reminiscent of the Assembly vs. HDL arguments of the 80's. Well coded assembly was better than HDL in the same way well coded VHDL (or Verilog) is going to beat machine generated code. We embrace that and highly recommend a mixed design methodology. Impulse C outputs synthesizable VHDL or Verilog as an intermediate file format to pass to place & route. Many of our users pull key portions of the HDL back out and hand optimize it. There is no one answer to design language. Use C for rapid prototyping, algorithmic design or infrastructure. Use HDL for static or mature code areas. We strongly feel solutions should be open and inclusive. Thanks for your comments.
The trouble with this is that (a) it's very subjective and (b) it depends on what you are trying to do. A big differentiator with Impulse is that you can profile your C code, then select the time-hogging functions to be implemented in an FPGA, and the system automatically partitions everything, converts the functions you've selected into RTL, synthesized them and loads them in the FPGA, compiles the remaining C, and adds all of the hooks required to link the software to the stuff in the FPGA. Pretty Cool!
"I guess the experienced Verilog coder isn't interested in moving to a new language until there is a clear advantage..." Exactly. In addition there is atleast 5 variations of C language and SystemVerilog which hope to replace Verilog and havent gain much traction except in the verification space.
C does seem to work well for compute intensive applications. How does it do on simple data paths and state machines? Should work well there too, but I don;t see much of a shift to C for these 'traditional' designs. I guess the experienced Verilog coder isn't interested in moving to a new language until there is a clear advantage...