Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
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
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:
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
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
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.
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.
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?
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.