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
Last week over in the LinkedIn Design Verification Professionals group, a thread came up in the discussion area regarding support for AOP in VERA. The discussion quickly changed to the benefits of AOP for Verification. Unfortunately, for the user who kicked off the thread, most of the other respondents seemed to only have experience with VERA's limited AOP capabilities and not with the more complete implementation of AOP in e. In case this question comes up at your company (and in case you not already a LinkedIn subscriber), allow me to repeat my reply on the value of AOP in e/Specman below.
Enjoy! Brett Lammers
************************ Post to LinkedIn discussion *************************
I just could not resist putting my 2 cents in on this discussion. Not being a Vera user myself, I cannot comment on AOP support in Vera, but I am getting the feeling from the other posts that there may be some limitations especially if it can only be used to layer testcases on top of an existing tesbench.
I would agree with Dean and Igor that a very powerful usage of AOP is to manage testcases layered over an existing testbench. However, at least when using e, I would argue that AOP plays an important role in testbench design also. As a reminder, (you all probably already know this): AOP (at least as implemented in e) goes beyond OOP in providing the user more flexibility to organize their code modules not only by objects, but also by cross-cutting-concerns (functionality that touches multiple objects in the code set). In verification, these cross cutting concerns can include DUT related functionality such as operation modes as well as verification related functionality like coverage collection or checking. Of course, as Dean and Igor already mentioned, the test itself is a cross-cutting-concern as it configures and constrains many objects within the testbench. However, using AOP in designing the testbench is extremely useful encapsulating object functionality, safely maintaining existing code, and reusing existing code.
In the context of encapsulating object functionality, just like in OOP, it is good practice to go through some planning to organize both objects and their associated concerns into the appropriate modules. This will prevent code that is difficult to read and maintain. In fact, it may even make it easier to read and maintain since there will be additional modularity and encapsulation. If we think about it modularity and encapsulation are really the motivation behind OOP in the first place. AOP just gives you yet another dimension in which to manage your code.
As Igor mentioned, since AOP gives you more freedom to split object functionality across multiple modules it is possible for you to create some incredibly messy code. However, back in the day (over 7 years ago), the Specman team understood this risk, and in partnership with lighthouse customers created what was called the e Reuse Methodology ("eRM"). Today the same eRM concepts for building reusable testbenches in a methodical and organized manner can be found under the OVM umbrella as OVM e. The success of eRM (it's been adopted by 98% of e/Specman customers), and the ongoing growth of Specman usage itself, shows that "structured AOP" is effective for block, chip, and system level verification challenges.
Brief digression: For additional information on OVM and how it applies to Specman/e check out this article and the related discussions:
What about code maintenance and reusing existing code? Here again, AOP is almost indispensable. By using AOP extensions, users can methodically update an existing environment with concerns that were missed in the initial planning, or are the result of changes that occur later on in the project. This sort of "after-the-fact" manipulation can be difficult in a standard OOP environment and/or if you only hold yourself to strict OOP practices. In the context of reusing existing Verification IP, AOP allows you to configure, control and add functionality to the existing VIP without touching the base code set - hence the reference to "safety" above since you don't have to muck with proven code. This can become critical when sharing IP across multiple projects or groups.
I would also invite you all to check out additional discussions on this subject as well as other related topics here: www.cadence.com/community/posts/teamspecman.aspx
********************************** End Post **************************************
Quite a comprehensive summary Brett!