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
Richard Goering wrote an excellent summary of the DAC panel "High Level Synthesis Deployment: Are We Ready?," which can be found here.
His conclusion is that we are getting close, and one of the biggest hurdles still to overcome is the skill set -- the combination of hardware design expertise and C++ -- which represents an opportunity for engineers seeking a new or better career.
That is a very insightful conclusion, given what we see in terms of drivers. Both Eli Singerman of Intel and Mark Johnstone of Freescale pointed out that they cannot accomplish what they need to in terms of design productivity and complexity utilizing RTL-based flows. Referring back to Clem Meas' introduction slide, we are still designing chips using the methodology that came into vogue with Netscape Navigator and Forrest Gump.
We are long overdue for a better way, and it should have become available roughly at the same time as Harry Potter: Prisoner of Azkaban. Instead, in order to get chips out the door, companies have come to rely on buying off-the-shelf IP, often from low-cost design houses since the IP offers them no differentiation. Some of our C-to-Silicon Compiler customers tell us that they adopted HLS in order to be able to again differentiate via hardware. But if they cannot find engineers capable of using this methodology, the tools have little value.
There were other obstacles noted by panelists, some of which are solved by tools like C-to-Silicon Compiler. These include QoR comparable to hand-written RTL, an ECO flow,and use of a standard language input. But Eli Singerman pointed out that verification techniques are still behind. Yet verification is one of the biggest benefits of moving up in abstraction. Mark Johnstone described a recent project where he had to design a transcendental function with 7 cycles of latency. He designed it with SystemC and was able to run 10M inputs in 15s. So that's 70M cycles in 15 seconds. He was then able to run 4 billion patterns of random stimulus in 30 minutes. "I simply could not have done this much verification and found this many bugs as fast with RTL simulation," he said.
So the potential is there, but we need to extend today's mature metric-driven methodologies up to take advantage of the benefits of higher abstraction. Fortunately this effort is in progress, but it is vital to mature it so it can be adopted broadly.
The other big impediment to faster adoption of HLS is the amount of legacy RTL. Blocks that are designed using SystemC/TLM will see the productivity and runtime improvements, but they must be integrated with all the RTL IP in a SoC so full-chip verification is still time-consuming. And the RTL IP is already proven and verified at the unit level, so creating a SystemC/TLM version creates overhead and risk. Most companies are taking the evolutionary approach of only targeting new IP for SystemC/TLM. This makes sense, but given the amount of hardware that is re-used, it slows the overall adoption of HLS.
This last issue is systemic -- there may not be a solution other than time. Of course if the first issue is solved, and we can create more designers that are proficient in this methodology, we may find that there is actually a larger demand for new IP than what we think. Today we only see companies design new IP when they absolutely have to. Perhaps when the supply of HLS-capable designers is sufficient, companies will be more willing to fund new IP development.
So the challenge comes back to developing C++/SystemC/HLS expertise amongst hardware designers. There are training courses offered by companies like Duolos, which do a good job of education. But these courses have been available for a while. The tools are available, and the methodologies are beginning to mature.
The conclusions drawn by Johnstone and Singerman were that we are capable of being ready for deployment, but right now we are really ready for pilot projects first. So I ask -- what else is needed in order to help this take off? I'd love to see ideas in the comments!