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
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
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
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
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
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.
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
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.