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
As manager of hardware development for the Graphics Competence Center at Fujitsu Semiconductor Europe, Raimund Soenning faces some tough challenges. He's responsible for the design and verification of complex graphics controller SoCs for automotive applications. His group develops graphics and video processing IP that can be used in many different configurations.
"With any graphic or data or video processing IP, you have a number of combinations of ways you can use the IP," Soenning said. "Verifying all these configurations together, along with timing on the interfaces, makes it hard for us." Even with the purchase of third-party IP, he said, there's still a need to do "integration verification."
Directed testing is not an efficient way to test many possible IP configurations. In a recent interview Soenning talked about how his group is transitioning to constrained-random test generation, what advantages it offers, and what the challenges are in adopting it.
Introducing a New Approach
It turns out Soenning is a ten-year Specman user, and after he joined Fujitsu in 2006, he introduced it there. Constrained-random test generation is one of the key features of Specman, which is now part of the Cadence Incisive verification suite. Soenning noted that Fujitsu uses random test generation primarily at the IP and subsystem level, while generally retaining a directed-test approach at the full-chip level.
What's the advantage of constrained-random verification? "You can get to interesting scenarios and find bugs in your design much more quickly. If the environment is ready, you can generate thousands of tests in a very short time, testing your designs in ways you would not have thought of." Also, maintenance expenses are lower. "In Specman I need to maintain maybe 5 or 10 tests for one IP. In directed testing I need to maintain hundreds of files," Soenning said.
Metric-driven verification provides another advantage. "Instead of thinking you have tested something, you really measure it," Soenning said. His group uses both code coverage and functional coverage metrics. He noted, however, that it takes a lot of experience for engineers to write a good functional coverage model.
Soenning also said his group has experienced a "tremendous productivity gain" with Specman verification IP for such protocols as AHB, AXI, and PCI Express. "All of the advantages of standard interfaces would go away if there was no verification IP," he said.
Making the Change
Since constrained-random test generation is now available with SystemVerilog, why use the Specman e language? Because e has been around for 10 years and is a much more mature language, and in an earlier comparison it appeared to use fewer lines of code than SystemVerilog, Soenning said. "Why go for, in our view, the second best solution, when we can go for the best solution?" he answered.
However, Soenning noted, there's a learning curve for traditional Verilog RTL designers or verification engineers. The aspect-oriented nature of e is often unfamiliar to them. He found he needed to bring in specialists to set up the test environment. Once that was done, however, engineers without a prior knowledge of Specman or the constrained-random methodology were easily up to speed and were successful. "e is a verification language that is targeted specifically for the task of verification. So, it is quite easy to use for verification," Soenning said.
The biggest challenge in moving to constrained-random testing, it appears, is convincing engineering teams that it's worth investing some time to learn the methodology and set up the initial verification environment. But once that's done and the automated tests are running, verification engineers end up catching bugs that they would not have caught with directed random tests. One result is a quality improvement in the final product - even for IP with many configurations.