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.
Don't expect Michael Blech, a verification manager at PMC-Sierra's Fiber to the Home (FTTH) division, to switch from the Specman e verification language any time soon. A 10-year user of e, he has some strong views about the advantages of e over SystemVerilog, including language features that he says are often overlooked.
First, he'd like to make a clarification - SystemVerilog is not just an extended version of Verilog. While the naming was successful, it's actually a new object-oriented language. "More than two-thirds of the [SystemVerilog] language is actually something new," he said. "Designers have to learn what object-oriented is all about."
While e is a language specifically developed for verification, the role of SystemVerilog is "not defined yet," Michael said. When it comes to verification, his view is that SystemVerilog is "about where e was 7 or 8 years ago in terms of maturity and functionality."
AOP - A Different "Aspect" to Verification
One key difference between e and SystemVerilog is that e is aspect-oriented, whereas SystemVerilog is object-oriented. What does this mean in a verification context? Aspect-oriented programming (AOP), said Michael, "gives you the flexibility to change things as you go, without the need to rewrite a lot of your environment or your test data base."
A case in point: several years ago he was verifying a network processor when engineers suddenly discovered that the processor could not support full wire speeds and calculate a cyclic redundancy check (CRC) on Ethernet packets on some of its interfaces. By default, packets have CRC. AOP allowed an easy fix - creating a new "aspect" of a packet that does not have CRC. It wasn't necessary to modify tests or change the verification environment.
"Without AOP, you would need to create a new class or subclass that does not have CRC as a member," Michael said. "You would need to change your environment and modify all relevant tests." Moreover, it would probably be necessary to maintain two environments, one for packets with CRC and one for packets without it, potentially doubling the number of lines of code.
Random Stability, Coverage, and Debug
An often-overlooked advantage of e, Michael believes, is random stability. Long part of the e language, random stability ensures that tests will maintain the same pseudo-random values over multiple runs with a given seed, even if the test environment changes. Without random stability, he noted, it is possible to miss bugs when designs are modified or scenarios are changed. An engineer might think he's fixed a bug when all he's done is changed the scenario.
SystemVerilog has random stability up to a thread resolution (but is missing stability within a thread). Michael said the e language is more mature in this respect because "e is completely stable. If you find in e a scenario for the same thing, and you get different results, that means there's a bug that should be fixed, as stability is assured within a major version."
SystemVerilog has coverage, but Michael believes e language coverage is more mature. What's missing in SystemVerilog, he said, is scalability. The e language, he said, "allows you to have true coverage metrics for real life, and not just for several hundred simple items. In the last ASIC we verified, just on the top level, we covered more than 10,000 items and cross items, and lower level verification environments (cluster or unit) sometimes can hold a magnitude more than that."
When it comes to debug, one advantage of the e language is its ability to run in both interpreted and compiled modes. When it runs as an interpreter, Michael noted, e will not cause segmentation faults, but rather the simulation will stop, indicating that some coding violation or memory access violation has occurred. Also, when e is interpreted, you can easily make changes. "When you're debugging your code, and you want to try a new method, no problem - just execute it from the command line. There is no way to do that in SystemVerilog."
SystemVerilog runs only as a compiled language. "That means every time I fix something, I need to elaborate again. On large designs that is costly," he said.
Michael has not done direct comparisons of the language by applying both to the same verification problem. However, he's done evaluations of SystemVerilog and worked with many contractors that use both languages. He estimates that switching from e to SystemVerilog (assuming one is a proficient user of e) will cause a 30-40% productivity loss. (A similar conclusion was reached by an STMicroelectronics engineer featured in a previous Industry Insights blog interview).
SystemVerilog does have a few advantages. One is that, thanks to its name, "designers are less afraid of it and are willing to try it." Also, it is easier to accomplish zero time accesses to DUT structures for simulation performance (for example: read-modify-write to behavioral RTL memory models).
His advice to verification teams considering a language choice: "It depends on what you need to verify. If it's simple and you don't need to do a lot of generation, and you feel SystemVerilog is more natural for some reason, you can go for SystemVerilog. On the other hand, if the environment is heavy on generation, and complex in the way it manipulates information, you should go to e."
As for Michael himself, will he be switching away from e today? "Why would we take a step backwards in verification capabilities when we are faced with challenges of verifying even more complex chips?"
Cadence verification tools fully support both e and SystemVerilog, and both are IEEE standards. From a Cadence perspective, either language can be a good choice. The important takeaway is that there is a choice. With thousands of loyal users such as Michael, a great deal of legacy code, an ongoing IEEE standards effort, and a much longer history than SystemVerilog, you can count on e to be around for a very long time.