Last week EDN named Palladium DPA a 2009 EDN Innovation Award Winner, and C-to-Silicon Compiler (a finalist) received two write-ups in www.deepchip.com.
One of the write-ups is by Gernot Koch of Micronas who evaluated CtoS last fall. I checked with the CtoS AEs who supported Gernot and his team, and learned the Micronas guys were about as exacting/demanding of customers as anyone could find. So to see Gernot write a letter like that to John Cooley, reminds me of a really tough Circuits & Systems professor I had in college who told everyone the first day "I guarantee 2/3 of you will get a C or lower", and I worked really hard and ended up with a B+ (there were no As).
Tough, but fair. Gernot gave CtoS several kudos: very good QoR, support for control and datapath logic, ease of use, etc. and the critique he raised about CtoS' lack of support for certain C++ classes, making CtoS unable to map certain types of arrays to memories, were valid (CtoS R&D has promised a fix in the next release). Therefore as "CtoS-Marketeer-in-Chief" I was pretty pleased.
CtoS was also featured in another write-up by Synfora CTO Vinod Kathail, it included the type of spin intended to create confusion that customers so often complain to me about. There were some truths in there: high-level synthesized designs tend to have a lot fewer bugs than hand-coded; that power, performance and area are all very important; hierarchical capacity is very important, etc. But there were also some falsehoods, like saying that converting C++ into SystemC is "ugly", and that CtoS forces designers to debug linting-type errors in RTL (totally false).
What needs to be stated is that SystemC is a superset of C++, which means it can do everything C++ allows, and MORE. The "more" is the real-world aspects of hardware, such as concurrency, resets, comm interfaces. Software is NOT "hardware at a higher level of abstraction"...both are fundamentally distinct! CtoS takes SystemC as input because it is made to generate optimized hardware. If the algorithmic C++ is "standard", e.g. no "software weenie" tricks with pointers/arrays, converting it to SystemC is usually straightforward.
Unlike Synfora users, CtoS users rarely (if ever) touch the generated RTL. They simulate/debug/verify everything in SystemC, *before* they synthesize. Debugging/Verifying machine-generated RTL *is* painful and cumbersome, which is why CtoS designers don't touch it! Sadly, Syfora (and Catapult) users have no choice but to verify designs using machine-generated RTL (the input C++ doesn't capture enough of the design's behavior to be useful for verification). CtoS also has the additional HUGE advantage that it lets you incorporate ECOs into your source-code, and minimize any impact to your synthesis results but I digress. CtoS also lets you vary FIFO and memory sizes automatically.
Finally, Vinod's "challenge" to try to synthesize an motion-estimation engine, or video deblocking filter, is dubious. To be fair, I have heard Synfora has excellent support for certain types of pipelining (which is why Vinod proposed those particular types of designs). CtoS can handle pipelines very well also, but this contest would be like deciding the US Open Tennis Champion based on having the fastest serve. Rafael Nadal (125 mph) is ranked # 1, Andy Roddick (155 mph) is # 6.
Designer friends of mine tell me what they really want is to use fewer tools, not more. So this places a major premium on the tools having well-rounded capabilities (able to serve, volley, play baseline, on grass, clay and hard-court) The guiding philosophy for CtoS since the beginning has been to build a "general purpose" rather than "niche" tool/solution. For this reason I'm confident that in 3-4 years, CtoS is the HLS technology that will be (to use Vinod's words) "left standing".