Home > Community > Blogs > Industry Insights > q amp a what cadence has learned about high level synthesis
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

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

Email

* 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: *

Q&A: What Cadence Has Learned About High Level Synthesis

Comments(2)Filed under: Industry Insights, SystemC, HLS, C-to-Silicon Compiler, System Design and verification, ECO

With the recent release of Cadence C-to-Silicon Compiler, Cadence has joined the rapidly growing high-level synthesis (HLS) marketplace. In this interview Mike "Mac" McNamara, vice president and general manager of the Cadence Systems Software Group, talks about what Cadence has discovered about HLS and its users.

Q: How long has Cadence been selling C-to-Silicon Compiler? What is its history?

A: We announced C-to-Silicon at the July 2008 CDN Live! in Tokyo. There were two customers who had used the product throughout its incubation, which started in 2006. These customers were Hitachi and Renesas, and they endorsed the product.

We developed the product based on a study done at Cadence Research Labs in Berkeley. The study asked the question "Why HLS hasn't saved the day, given that we've had it for ten years, and has so many things in its favor?" We identified what was great about [HLS] technology and what roadblocks were limiting the acceptance and wide deployment of the technology.

Q: So, why weren't earlier attempts at HLS more successful?

A: The early tools were based on the traditional RTL focused hardware description  languages, such as VHDL and Verilog. You could write behavioral descriptions in these languages , but there wasn't enough of an abstraction lift going from RTL to behavioral Verilog, nor could you engage people who had different expertise than the traditional RTL coder. Later tools tried to expand the user base by focusing on the C language as an input, but they encountered difficulties because C is a procedural language, with no notion of timing or concurrency. Vendors needed to introduce their own proprietary extensions, pragmas, comments and directives to enable users to guide a synthesis tool to produce concurrent hardware.

Many of these early tools went right from behavioral input to generating gates, so it was very difficult to apply RTL-level commercial tools for manufacturability, power optimization and the like because the tools bypassed that. Also, many of these tools just supported synthesizing the datapath portion of the design. Raising datapath synthesis to a higher abstraction level delivered some productivity, but customers were still left coding their control logic in RTL Verilog.

Q: C-to-Silicon was not the first high-level synthesis tool. What was unique about C-to-Silicon when it was announced?

A: We were the second tool to support synthesis from SystemC - Forte's [Cynthesizer] was the first. We chose the IEEE 1666 SystemC as it is a language based on the most commonly used programming language on the planet [C++], but then adds industry-standard synchronization primitives and a standard way to model concurrency. To our minds it was absolutely clear that this was the right language choice.

One unique capability we developed is the ECO mode. C-to-Silicon builds logic using a database, which is a unique feature compared to other HLS tools. The second time you run the tool, we can compare the original input to the new ideas you have, and implement the design so as to make the minimum number of necessary changes. If you give a traditional tool slightly different inputs, it is going to give you a newly optimized design that is perhaps radically different from the original.

Another capability unique to Cadence is that we embed digital synthesis in the tool, so when you get to complex control problems, we hand those over to RTL Compiler to generate logic. Leveraging the excellent logic optimization features in our commercial digital synthesis tool, we can quickly find the best way to implement your control logic. One thing we can do is take a function and generate a custom operation that implements that function. We hand it to RTL Compiler on the fly and ask it to make an optimized implementation of this operation. Now it's in our library and you can call this function many times from different parts of your logic.

Q: What kind of customer is interested in HLS? What types of applications?

A: We have both systems companies and semiconductor companies using the tool very successfully. They have different motivations. The systems companies are trying to build devices more effectively by operating at a higher level. The semiconductor companies are looking to provide more service to their system partners. They want to be able to accept descriptions from their systems customers at the C level, and they also want to develop an internal library of IP so they will be a more attractive partner for their potential systems customers, and use more effective means to build this library.

Digital TV is a big area that people look at [for HLS]. Communications is another area,  with routers and switches. Consumer products are a big application area. The Cadence web page includes a success story about Casio, which designed a camera chip with a fair amount of control logic using C-to-Silicon. And there are processor companies looking at C-to-Silicon as well. 

The bottom line is that nearly every application space and type of customer who generated RTL yesterday is a candidate for high level synthesis today.

Q: Japanese companies were the first to adopt HLS, and C-to-Silicon was announced in Japan. Why is HLS strong there?  What about the rest of the world?

A: Japan has had the highest density of folks doing consumer products, so they've been thinking at the system level for a long time. Japan has always been looking for more productivity and has been more open to adopting  new technologies. Japan has a relatively high cost for engineers, so increasing their productivity is a major focus. There's outsourcing to India or China, but there's also outsourcing to the CPU. You can apply automation to the tedious task of generating RTL instead of employing a team of people in China.

But we have customers around the world now, including North America and India. The rest of the world is just as engaged. As we come through the recovery, companies are not going to get back the budgets they had in 2005 or 2006. But they can employ some tooling that lets a limited staff generate chips quickly.

Q: Who uses HLS? Is it the architects or the RTL designers?

A: It's merging in the middle. A successful HLS engineer needs to have solid grounding in RTL concepts, but also needs to be good at C++ and have the ability to think about how to model your design. We will grow a new class of users that will be much more productive than we were at the RTL design abstraction, just as we stepped up productivity moving to the RTL level from the gate-level design capture abstraction.

We're seeing architects get closer to design, and we're seeing designers move up in abstraction and get close to architecture. The roles are going to blur, and it's going to change the way companies operate.

Q: What's the advantage of HLS? And what's the quality of the generated code?

A: Productivity is key. With C-to-Silicon, we've seen that two or three people can generate 20 million gates in two months. That's something that used to take a team of 10 to 15 people six months or a year.

People are seeing results that are quite competitive with hand-coded RTL - sometimes greatly exceeding it, sometimes matching it, in timing, area and power.

Q: Is there a learning curve with HLS?

A: There's a little bit of a learning curve. It basically makes your first project on the order of what you would have experienced before, but after that the learning is encoded in the team. And they get the immediate 3-5X code size reduction, which is an immediate productivity gain. Verification throughput productivity increases by as much as 10X.

Q: Are customers using HLS for whole chips, or for selected blocks? How large?

A: By and large, people don't synthesize whole chips these days - at RTL or HLS. We are in a SoC platform-based world where people aggregate lots of existing RTL with a few new functions, in order to address an expanded market. We designed C-to-Silicon to work really well for large blocks that will be components of SoCs. That said, we do have an example from Japan in which three companies each synthesized 20 million gate blocks for a 4G switch IC. They thus constructed an entire 60 million gate chip using C-to-Silicon.

Q: What's been surprising about bringing C-to-Silicon to market?

A: I'm continually amazed - I had a sense the U.S. market would take a lot longer, but now we have both small and large U.S. customers. Current wisdom was that it Japanese and European customers would adopt it, and Americans would stick with Verilog. But we've had some real success in the U.S.

The hardest thing has been getting people to appreciate the verification value of high level synthesis. I joined Cadence as a part of the Verisity acquisition, where we greatly improved the efficiency of verification.  A lot of customers are divided into verification teams and architectural or design teams, and C-to-Silicon is somewhat disruptive in that it has features for both. People are evaluating us compared to existing tools that don't have verification -- therefore they don't have test cases for it.

Q: There's no standard SystemC synthesis subset yet. Is Cadence working towards that?

A: We are involved in the [Open SystemC Initiative] synthesis working group, and quite a few customers are participating there as well. We're working to craft a standard in a way that both represents what all tools support, and additionally drives the tools to add support for things they don't yet support in a way that is consistent with the SystemC standard.

Q: What are you working to improve with C-to-Silicon?

A: Quality of results is always something that can be made better. You need to be able to generate RTL that's as good as what you can get by directly writing Verilog for this flow to be worthwhile.

Number two is ease of adoption. To use high-level synthesis, you need to be pretty good at C++ and have design constraints in mind, and there aren't all that many people who can bring that to the table. So we're putting in lots of features that make it easier to understand what the tool did, what the implications are, and how you could alter things to get different results.

For verification, we're developing technology that lets you run your RTL and see which bits of C code are executing. You can set breakpoints in C code and see where you end up in RTL, or set breakpoints in RTL and see where C code is executing. We think this will be very valuable for verification debugging.

Q: Finally, what's the message to prospective C-to-Silicon customers?

A: This is real! Real companies are using it to design real chips. They're getting a huge leap in productivity. You can't afford to ignore that, especially since we're coming into a recovery where we all need to do more with less. C-to-Silicon is a productivity tool that lets you build designs more quickly. You should take a look.

 

Richard Goering

 

Comments(2)

By Andries Hekstra on May 20, 2010
I underwrite the testimony above about the high value of HLS for generating complex IP, such as, in my case, configurable accelerators as components of a flexible baseband of a digital receivers. Indeed, the full potential of HLS is only realized by people with multiple skill sets. Even without doing inventions, but just to have the algorithmic knowledge and creativity to think of many possible ways to do the same (DSP) thing and explore that in record time with HLS more than compensates the slight increase in area which one would have if one would code something in the (single) exact same way an RTL design would do it.  
Despite that such people with multiple skill sets are hard to find and have this high leverage though HLS tools, I wonder why virtually almost all job openings one finds on the internet e.g. on "SystemC" seem to address its application to virtual platforms and the like rather than HLS.

By sowmya on November 3, 2010
how to write a C program for standard specification of basic logic gates and how to simulate them as part of EDA tool. what i mean to say is how to develop a basic gate model using C language? please mail me the answer


Leave a Comment


Name
E-mail (will not be published)
Comment
 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.