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
Emulation and FPGA-based prototyping are becoming increasingly necessary for complex systems-on-chip, but where are these hardware-assisted tools going to come from? Should you invest the resources to build and maintain your own, or purchase a commercially available solution? In either case, what do users need most in their prototyping systems? Panelists at the DVCon conference Feb. 29 tackled these questions from both user and vendor perspectives.
The panel was titled "Build or Buy: Which is the Best Practice for Hardware-Assisted Verification?" It was moderated by Brian Bailey, consultant and editor of the EDA DesignLine. Panelists included:
Bailey opened the discussion by noting that emulation and prototyping have gone from "luxuries that only a few people could afford" to necessities, with an increasing demand to provide such platforms to significant portions of the software development group. He then asked each panelist to comment on the question raised by the panel's title.
A Continuum of Platforms
Schirrmeister provided some initial context by noting that different platforms are needed at different stages of the design flow. "A continuum of engines is needed - there is no one size that fits all," he said. He showed the slide depicted below, and pointed out the pros and cons of TLM (transaction-level modeling) virtual platforms, RTL simulation, emulation/acceleration, and FPGA-based prototyping. (In the diagram, dark green indicates "very good," light green is "good," yellow is "neutral," and red is, well, not so good.)
The build vs. buy decision, Schirrmeister said, hinges on "the cost of ownership, not just the box and not just the FPGA. It's also the tools around it, the time it takes to get designs up and running, and how much power you consume. Tooling is a big question - do you use the same tooling as in the ASIC world or do you have to learn FPGA tools?"
Schirrmeister concluded: "You have so many other things to worry about, including embedded software, why add another risk factor in your design to build a board? You need to make that decision very carefully."
Other panelists had other views. Hsu said that his company, SpringSoft, is providing debugging and visibility software that will help people build their own FPGA prototyping platforms. Ryser said that "for us, it is really essential to use our own FPGA products to help verify our silicon products. We need the speed and the lower cost per bug."
Goodenough said that hardware acceleration is "one of the tools in our armory," but said that ARM generally builds its own emulation and prototyping systems. Why? One reason is the difficulty of compiling designs into FPGA-based prototypes, given that, as Goodenough said, "we are operating on the edge of reality with multi-core coherent systems." Another reason is that "most of the problem is not doing validation, it's integrating the validation environment into our workflow metrics reporting environment. We've found over the years that the only way to do that is to make it, rather than buy somebody else's solution and shimmy it into our system."
User Sets the Requirements
Qualcomm's Camilleri said he did not have a straightforward answer to the "build vs. buy" question. "I've done both, I've had good results with both. The answer is, it depends - on what you can do as a company and what you want to get out of your platforms."
If you "build," he noted, it take expertise in high-speed board design and layout, FPGAs, and a software infrastructure. Scale it up to volume production and "one could quickly find oneself in a support nightmare." On the other hand, Camilleri has some very demanding needs when it comes to buying prototyping platforms. In addition to very high speeds, here's what he wants to see from vendors of prototyping platforms:
"It's very unlikely that I can find a single vendor that can make the whole product line, starting with virtual platforms all the way to emulators," he said.
Schirrmeister's response: "I hear you." He agreed that "interworking with other platforms is very important. Standards are important. We are active in things like the [Accellera] SCE-MI committee to allow interworking between vendors." Schirrmeister also said that "I fully agree with time to stability. That goes together with making sure the connections work."
(Note: At Cadence, Schirrmeister is responsible for the System Development Suite, which emphasizes connectivity between virtual platforms, simulation, emulation, and FPGA-based prototyping).
So What Does It Take to Build Your Own?
Another interesting point in the discussion came when an audience member asked Camilleri and Goodenough what kind of investment it takes before getting a return on prototyping. Camilleri responded that it depends on whether Qualcomm is building or buying. "If we're building it's a strategic investment," he said. "We have a group of experts building boards, building systems around them, porting, making builds for things - it's a substantial team." He said the team will be in the "tens of people."
For buying, he said, "it depends on the expertise of the teams. When we buy we try to go with a more distributed model where experts are basically part of the verification team. That means less support from a central team."
If you buy an emulator, Goodenough said, "you typically have one guy who is Mr. Emulator. He knows everything about it and he interfaces with the EDA company. If you're building your own resource, you need board designers, experts in FPGA mapping, and probably production engineering people to effectively manage your infrastructure."
Camilleri noted that introducing a new technology such as emulation or prototyping may not show returns for two or three years. So why do it? "Returns come in many ways," he said. "It's the efficiency of the people and the ability to verify and do more. We're doing things in pre-silicon today that we never dreamed we could do with simulation. We're running so many frames and so many cycles. It's not just about correctness, it's a confidence that we get in our architecture. And now we're doing software development and bringing up software drivers."
I think this last comment shows that the return on investment for hardware-based verification is real, and that emulation and FPGA-based prototyping are here to stay.
Other DVCon 2012 Coverage
DVCon 2012: Accellera "Town Hall" Meeting Explores Future of EDA Standards
Hardware/Software Codesign: Pink Elephants on Parade?
DVCon User Panelists: Is Low Power Design Worth the Costs?
DVCon Panel: Will Differentiation Through Software Kill Chip Design?