Thanks again
Grant

Thanks for your comment, and I’m glad you brought up the point that “all the current C/C++/SystemC HLS tools take extra pragmas or synthesis controls and directives” to steer the synthesis towards a desirable architecture (many people are unaware of this, and are surprised when they first see this). I have several follow-up comments on this.

(1) The first comment is that algorithms people write in C/C++, the starting point for C/C++ synthesis tools, may simply be bad algorithms for parallel implementation. This is why we have fat textbooks on parallel algorithms, and high-quality conferences like ACM SPAA and PODC engaging some of the best minds in the business.

(2) The second and perhaps most serious comment is that these pragmas are very weak and indirect knobs to control the final architecture, like pushing on a rope. In many head-to-head comparisons, we’ve found that although these tools may get you quickly to initial RTL, there’s often a very long and tedious tail in trying to squeeze it down to acceptable area, precisely because of lack of architectural transparency and control. So, yes, I am claiming that BSV’s (Bluespec SystemVerilog)’s means of specification for parallel algorithms and architectures is much more direct, transparent, and controlled. See also my comment here for more on this.

(3) Another comment is that all these “extra pragmas or synthesis controls and directives” detract from the “ANSI C/C++” rhetoric, because producing these pragmata involves most of the hard labor in getting a good synthesis result, and they are usually extremely tool-specific.

(4) SystemC is of course a parallel language (albeit an unrealistically weak one, because of the non-preemptive thread scheduling semantics). But when people use the phrase “SystemC synthesis”, it’s hard to tell whether they mean synthesis from RTL-like SystemC– using sc_signals, sc_in, sc_outs, sc_clocked threads (equivalent to RTL’s ‘always’ blocks), etc, or whether they mean CDFG-based synthesis. In the former case, it’s no better than RTL, and in the latter case, it’s no better than C/C++ synthesis.

Thanks very much for your comment. However, I don’t think you can make a claim that Bluespec is the only high level synthesis input that deals with the “denial” issues. The reason for that is that none of the high-level synthesis tools using C/C++/SystemC takes “sequential” C/C++ alone as its input. All of them take extra pragmas or synthesis controls and directives in one form or another that allow users to specify and explore potential concurrency/parallelism and also explore various input mechanisms and memory models/access methods. This may be more inherent in the language, such as SystemC, or more provided by pragmas or special methods as in other languages. But none of them as far as I know lack a means to explore these aspects.

So if there is an advantage to Bluespec – which users will confirm – it will be because its means of specification is more efficient, or more capable, or because its underlying synthesis target architecture allows better results, or its algorithms are better. But you should discuss these aspects in a follow up if you feel it explains the better results in the competitions you mention.

Last week, another university professor, Bill Dally of Stanford University and NVidia, gave a keynote speech at DAC that is already creating much buzz (Richard Goering: http://tinyurl.com/ldrt9a, Grant Martin: http://tinyurl.com/lla2j4, Tech On: http://tinyurl.com/nfuuwj, EE Times: http://tinyurl.com/mbe22q, DAC Blogspot: http://tinyurl.com/lfldbs).

Dally called on the community to abandon what he termed “denial architectures”. He identified the two principal features of widespread denial:

Sequential computation model (and weak variants like instruction-level parallelism)

Flat memory model (fixed, equal cost of access to all data)

Between C++ and BSV (Bluespec SystemVerilog), guess which one is the poster child for these two denial features?

The HW/SW design competitions at the last three MEMOCODE conferences (http://csg.csail.mit.edu/Memocode2009/) were, in the end, all about quickly designing the most efficient parallel architectures. Is it any surprise that the winners did not use sequential C/C++ (2007: http://tinyurl.com/mszr77, 2008: http://tinyurl.com/nzgku2, 2009: http://tinyurl.com/ms6yvl)?

Are we the ones in denial? No, we’re at the Denali Party (enjoying a DACiri)!

Rishiyur S. Nikhil, CTO Bluespec, Inc.