Home > Community > Blogs > Industry Insights > what language is best for high level synthesis
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

What Language Is Best For High Level Synthesis?

Comments(3)Filed under: Industry Insights, DAC, ESL, SystemC, High-level Synthesis, HLS, TLM, Cadence Academic Network, synthesis, McNamara

I was not expecting the last panel on the last day of the Design Automation Conference to be well attended, but it was - along with animated discussions and a long line of audience members waiting to ask questions. It turns out that a lot of people were interested in the panel's title: "What input language is best for high-level synthesis?"

The panel comes at a time when most high-level synthesis (HLS) providers, like Cadence, have embraced SystemC. Mentor Graphics is the most recent addition to the list. But not all HLS tools take SystemC. Synopsys (not on the panel) introduced synthesis from Matlab/Simulink earlier this year. Bluespec (on the panel and very vocal) provides synthesis from SystemVerilog. The panel included some pointed debates between Rishiyur Nikhil of Bluespec and most of the other panelists.

The panel was moderated by synthesis pioneer Dan Gajski of U.C. Irvine (not mentioned was Prof. Gajski's role in developing the SpecC language in the 1990s). Panelists included:

  • Michael "Mac" McNamara, Cadence
  • Rishiyur Nikhil, Bluespec
  • John Sanguinetti, Forte Design
  • Andres Takach, Mentor Graphics
  • Anmol Mathur, Calypto
  • Devadas Varma, AutoESL

SystemVerilog Versus C/SystemC

I have to give Nikhil credit for taking a controversial position and sticking to it, even while standing alone. "I think SystemC is the wrong tool for the problem," he said, in the opening minutes of the panel. "We're designing algorithms and architectures, and these are highly concurrent." He argued that C/C++ is inherently sequential, and noted that an abstract model may have nothing to do with the desired hardware architecture.

Mac noted that C has been around for 30 years and that many algorithms have already been captured in C. Thus, a specialized language for HLS is unlikely to catch on at this point. Varma (AutoESL) said "a language that is primarily a hardware description language is not the right language" for HLS. Takach (Mentor) noted that C++ provides the ability to express algorithms, and said that "when you really need to specify things for which timing is an integral part of the functionality, you may have to resort to SystemC."

An audience member took up the debate by saying that "C is the bane of any effort to create parallelism" and that "we have to get past 40 year old languages that have way too many side effects." Mac replied: "If you look inside our tools, we're taking your input language and trying to find the parallelism in there. We're capturing algorithms at the highest level of abstraction and then we have a path to implementation from that highest point."

Later in the discussion, Nikhil asserted that "C is just a lousy language for expressing many kinds of computations. It's a pipedream that you should not be thinking about parallelism. C is just the wrong answer to this question." Sanguinetti responded: "That's why SystemC was developed. C was not adequate for representing concurrency, and SystemC provides an abstraction layer. It works."

C/SystemC advocates also talked about the need to model at different levels of abstraction. The SystemC transaction-level modeling (TLM) standard allows that. One point I did not hear mentioned is that the SystemC TLM standard opens the possibility of linking the virtual platform environment with implementation through HLS. Separately from DAC, Cadence and Wind River recently published a whitepaper that notes this connection.

What Do You Want From HLS?

In my view the panel did not really define HLS. But there was a discussion about what users really want from HLS. Gajski said he wants a tool that can go from a C language description to an architecture with, for example, a 3-stage pipeline. "We can do that," Mac said, "but we wouldn't invent an instruction set or instruction store, fetch and decode."

Nikhil's view: "At the high level, architectures should be left in the hands of the designer and the language should let the designer fully express it. C does not." Sanguinetti's response: "You don't take a C algorithm, stick it into an HLS tool, and say I'm done. The job of the hardware designer is not being replaced by the HLS tool. You start with an initial C algorithm and refine it as you do architectural exploration. That's why we need something like SystemC."

Are HLS algorithms "good enough?" Yes, panelists said. But Varma noted that HLS is "not pushbutton." Takach said "you do have to put in some hardware intent at times." Mac said that hardware features should be extracted "automatically, with light user guidance."

Are Users Good Enough for HLS?

As I was rushing out to catch a plane, Grant Martin asked a very pointed question from the audience. He noted that a lot of HLS code is badly written. "The fact is that many users can't write well in any language," he said. How do we overcome that barrier, he asked?

This is a good point. To get good results, users need to understand how to write good code for HLS and how to best use the tool. It's important to choose a provider that offers good training and support. Otherwise, the choice of input language won't matter very much.

Richard Goering


By HLS_AE on June 30, 2010
Varma noted that HLS is "not pushbutton."
Takach said "you do have to put in some hardware intent at times."
this two comment is absolutely important for you to get good QoR, C is very flexible, you need to know what architecture will be generated. just like RTL designer need to know circuit.

By A. Observer on July 1, 2010
I would tend to agree with the audience member: we need to move beyond C.  A lot of developers in the software world have moved beyond C/C++ to higher level languages to get higher productivity.  And SystemC seems, at best, to be a clever hack - macros and a runtime on top of C++.  Ever tried to figure out the error messages that come out of the compiler when you feed it some SystemC?
I'm not sure what the answer is, but I have some suspicion that something more declarative and less imperative could be better.  It's interesting that BluSpec started out with a more functional and declarative direction (their own BluSpec language) but now they seem to be pushing SystemVerilog synthesis.  Maybe they were onto something before?

By Raj S. Mitra on July 1, 2010
The last para of the blog sums up the debate: “To get good results … the choice of input language won't matter very much”. And the statement that “you do have to put in some hardware intent at times” is very much an under-statement – you have to think about the architecture right from the beginning if you want to get a good implementation.
And yet the world is moving towards HLS and SystemC (which is nothing more than a concurrent version of C, to help in placing the architecture hooks), and there are two very good reasons for that – which are not at all related to efficient implementations. And those reasons come from the unanswered question – “What Do You Want From HLS?”. A good implementation is only one of the outcomes of HLS, and time and again we have observed that expert designers implement much better than HLS tools do (see our “Design and Test” paper as an example). So an efficient implementation is not the main reason designers want to move to HLS, it is just the gating condition.
The main advantage of using HLS is to easily get models for virtual prototyping. Without HLS, we have to maintain 2 separate models – one for VP and another for implementation, and it is a perennial nightmare to keep the 3 models in sync (the third model being the architects’ reference model, which stays separate anyway). It costs manpower, it consumes time, it delays software integration, and it makes the project way too late. These VP models closely reflect the architecture, and are thus usually very close to the HLS model, so the same model can suffice (with some additional features for debug and simulation hooks) as both an HLS model as well as a VP model. So, if we use an HLS tool, we can reduce the model-count by 1 without degrading the implementation (i.e, if the HLS tool can generate an efficient implementation, which is why I called it a gating condition), and this is a very significant gain. And since most architectural simulators are based on SystemC, we need a SystemC model so as not to further complicate the debugging process. (If we use another language for HLS, we would have to generate the SystemC model also from it for VP simulation purpose, and debugging an auto-generated code is another nightmare we would like to avoid. So, it is best that the VP model has been hand-written.)
The other reason for choosing SystemC as the HLS language is that the architects’ reference models are usually in C/C++, and it is far easier to edit and change this C-reference-model to a SystemC-implementation model than to any other language.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.