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.
JL's main argument is that the virtues of a standard methodology (UVM =
Universal Verification Methodology) built in a standard language
(SystemVerilog) are being compromised because both are hard to learn. I can't really
argue but I think it's worth separating two aspects of that difficulty.
SystemVerilog is, in truth, a bit of a "Frankensteinian" language. Its many new
constructs on top of Verilog came from several different sources. Further, it
is a dual-purpose language meant to both describe designs and verify them. It lacks
some of the elegance of certain other languages but it does the job, as
evidenced by its wide usage and overall success. It is most surely not dying.
The second difficulty in learning the UVM and SystemVerilog is the leap in
thinking required to embrace object-oriented programming (OOP) and other
advanced concepts. This same challenge exists for just about every "modern"
language as well as alternative verification and modeling languages such as e
and SystemC. JL calls out for the industry to start looking at "other languages
and development frameworks." I frankly find it hard to imagine that any other
approach would not entail the use of OOP and therefore require a solid
understanding of this programming discipline.
JL concludes by contending that EDA vendors will not, or perhaps cannot,
produce the level of innovative thinking to define such a new language. His
implication seems to be that both SystemVerilog and the UVM were foisted on the
industry by EDA vendors and that's the best we can
do. In fact, both of these were produced by standards bodies comprising a mix
of EDA vendors, consulting companies, semiconductor suppliers, and systems
houses. All can claim credit for the wide success of the UVM and SystemVerilog,
while sharing a bit of blame for the less elegant aspects of the language.
I believe that UVM does represent innovation on the part of the industry as
a whole, with EDA vendors playing a key role. The UVM has done more than any
other single technology to move countless thousands of users to advanced
verification. The upcoming Unified Coverage Interoperability Standard (UCIS) is
another innovative industry-wide effort likely to have great benefit for users.
There are many additional examples of ongoing EDA innovation in functional verification:
low-power flows, much faster mixed-signal simulation, multi-core support,
unique blends of simulation and formal techniques, and more.
But innovation does not imply that we need to rush off and define yet
another language. Sure, someday there will a better verification language than
SystemVerilog and a better methodology than the UVM. However, the reality is
that every new language and methodology requires a huge investment. It takes
EDA vendors three or four years to implement a new standard and by that time
there's probably a new version ready to be implemented. Users invest billions
of dollars in training and building reusable verification components. Let's
leverage this investment; there's a lot of headroom for improved verification
productivity and quality with what we have in hand today: SystemVerilog, e,
SystemC models, and multi-language UVM. Let's run with it!
The truth is out there...sometimes
it's in a blog.
I agree 100% that multi-language UVM is interesting and useful. As you know, Cadence has contributed e and SystemC UVM libraries to UVM World, and we are encouraging Accellera to extend the standard to include full multi-language support.
IMO, multi-language support in UVM probably would be more interesting & useful. I believe it is the language that makes UVM look tedious. Maybe if it was tried on 'e' first and then extended to SV, the blog post title would have eliminated "UVM" probably.
I did see that blog post; kudos to Mentor for commissioning the survey and to Harry for offering some very interesting analysis. Specific to Specman/e, your survey reports a slight dip in usage from 2007 to 2010. I just ran the numbers from our internal sales system, and have the hard data that the number of Specman licenses in active use by our customers grew significantly over this same period. No matter how carefully a survey is done, it is after all only a sample.
Your survey also suggests a drop-off in Specman/e usage over the next 12 months. I've commissioned and analyzed surveys too, and one very common result is that respondents over-estimate how quickly their environment will change. I'm sure that some Specman/e users feel that they will be forced to switch to SystemVerilog but I predict that far fewer will actually do so. Further, we've seen several projects try SystemVerilog and then switch back to e because they lost 30-40% efficiency:
On the other hand, I do believe that usage of eRM and URM is declining. UVM is the standard, and with Cadence's contributed e and SystemC extensions paving the way it's natural for users of all older methodologies to switch to multi-language UVM regardless of their language or mix of languages. UVM is the way forward; surely we agree on that!
Looks like "rumors of SystemVerilog's death" aren't the only thing being greatly exaggerated. If you look at blogs.mentor.com/.../part-8-the-2010-wilson-research-group-functional-verification-study you'll see the results of a blind study by Wilson Research Group showing that usage of 'e' is actually shrinking (Figure 4), as is usage of eRM (Figure 5).
Many engineers consider e a more elegant and focused language than SystemVerilog for verification. I agree that public statements of support from other vendors would be beneficial to e's large and growing user community. We can't make that happen ourselves but perhaps the users can if they keep pushing!
We don't need a new verification language, there is Specman e
We only need need the other two EDA companies admit they also support IEEE1647.