The Real Story on HLS With ANSI-C/C++ vs. SystemC

17 Feb 2009 • 3 minute read

There's a new post worth reading for anyone interested in the current state of high-level synthesis (HLS). http://www.deepchip.com/items/0479-04.html, apparently posted by Mentor.

The article highlighted the results of a worldwide survey that asked 1500+ engineers their reasons for considering/using HLS. 800+ engineers responded, overwhelmingly citing "faster time to RTL" and "faster verification" as the top two reasons. This is excellent news for everyone with a stake in the HLS technology market. These results clearly support the notion that HLS is a rapidly emerging market with a promising future. The article claims that use of ANSI-C/C++ (vs. SystemC) makes Catapult-C inherently superior to other SystemC HLS tools.

In my view, this went too far, to the point of being misleading...If you were to ask EDA industry folks/customers who have known me a long time, whether SteveS tells the truth, you'd probably get a smile and the comment "maybe a little too often". I have a reputation for being pretty frank (whether I'm wrong or right) and more than once have gotten in "hot water" because of that. So, for whatever it's worth, let me tell you what I really think.

While for a limited subset of (i.e. datapath-logic intensive) designs the arguments have some merit, as design-complexity increases and/or control-logic is added, the potential advantages of C/C++ become significantly outweighed by SystemC's natural support for hierarchy, concurrency, resets, timing, etc. These latter characteristics are essential when trying to specify any functionality that is targeting hardware. In fact, across numerous customer benchmarks, without mentioning numbers, CtoS fared EXTREMELY well, and you can deduce what 'extremely well' means. For highly datapath-intensive designs (e.g. FIR filters, FFTs) CtoS area/timing results were right on-par with Catapult-C. While for control-intensive, or mixed control-datapath designs, CtoS results were always superior.

The problem is, in marketing Catapult-C, there seems to be running a Fear-Uncertainty-Doubt "FUD" campaign against SystemC, and it's customers/users who will suffer most from that. For example, claiming SystemC requires designing at a lower abstraction than C++ is misleading. The article neglects to mention that SystemC is a *superset* (rather than a subset) of C++. For datapath code, CtoS (and probably other SystemC HLS tools as well) uses the exact same untimed, high-abstraction C/C++ as Catapult-C. Moreover, CtoS (and probably other SystemC HLS tools) allow designers to add the necessary SystemC constructs in order to specify the hierarchy, concurrency, timing information, resets, etc. which are essential for any complex, multi-state, designs. Contrary to the article's assertions about SystemC HLS tools, CtoS does not require (or even recommend) low-abstraction code or hard-coded timing unless dictated by the protocol. CtoS prefers that designers enter information at the highest level of abstraction possible, because that allows CtoS maximum flexibility to move logic around for better resource sharing, area-power-timing optimization, and IP reuse-automation.

Every customer considering an investment in HLS to realize productivity and IP reuse gains ought to care a lot about this. Given the current economic climate, customers are under intense pressure to increase designer productivity, automate IP reuse, and HLS is receiving a lot of interest. Adopting HLS requires not only a major investment in HLS tools, but also in teaching engineers new design skills and methodologies. Prospective HLS customers have a lot to consider in deciding what HLS solution to adopt.

I honestly believe CtoS is the best HLS technology on the market today, but I want customers/users to judge for themselves. My hope is by pointing out FUD such as this, I can help customers make informed decisions and select the best HLS technology for *their* needs. If once in a while customers decide to pick an HLS tool other than CtoS, that's OK. Variety, choices are good for customers...but I'm confident that enough will! ;-)