Home > Community > Blogs > Custom IC Design > analog assertion based verification methodology reality or a dream part 2
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Custom IC Design blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Analog Assertion Based Verification Methodology – Reality or a Dream? (Part 2)

Comments(1)Filed under: Custom IC Design, AMS Simulation, analog, mixed-signal, mixed signal, Analog simulation, ABV, SVA, PSL, assertions, assertion-based, wreal, SoC, verification

The design and verification methodology for analog circuits has not changed much over the past decade. But the complexity of analog designs has grown exponentially. Analog parts are not just on the peripherals of SoCs any more. It is very common to have complex analog IP in applications such as communications, transportation and bio-medical devices. So it is not enough to just verify analog designs in isolation.

There is an added emphasis on two major concepts:

1) Verify the analog design in isolation thoroughly for functional correctness. This is very similar to having a thorough block-level verification methodology in the digital world. The block handed over to the SoC integration team needs to be bug free. The statement that "debugging issues at the block level is much easier than debugging them at the SoC level" applies to all the analog blocks that become part of the mixed-signal SoC. This process demands an advanced methodology that can build significant automation into the verification of analog designs.

2) The advanced methodology needs to align itself with the SoC verification methodology. What this means is that the pre-verified analog blocks should be delivered to the SoC integration team in an easily consumable manner. At the simplest level it could mean delivering a high performance behavioral model that is functionally equivalent to the analog design. At the next level it could mean a set of assertions (that goes with the behavioral model) that the SoC verification engineer could turn on for the analog blocks to get visibility into the functionality for debugging purposes or metric collection purposes.

There are three important ideas that resonate with assertions: Observability, Controllability and Reuse. Put them all together and it simply means increased productivity. Assertions can describe design functionality in succinct statements. Some common properties could be

  • Looking for a certain value on a signal under given conditions at a given time
  • Looking for a logical combination of values on certain signals under given conditions at a given time
  • Looking for a sequential relationship between multiple signals over a period of time

One of the key value-adds of assertions is the ease of debugging. The visual inspection of waveforms (a very common practice still in the analog world) to make sure that a design is behaving correctly is very inefficient. It is extremely time consuming and error-prone, not to mention the length of analog simulations adding to the burden of analysis. Also the engineer has to wait for the end of simulation to find out about real design issues, or many times, just simple user setup issues.

By capturing the main design functionality and the input assumptions as part of assertions, the verification environment becomes extremely interactive. Assertions fire error messages as soon as a property is violated, and the user can stop the simulation right away. Once the simulation is stopped, the user is taken to the time stamp at which the error was fired. Our friends in the digital world have perfected the debugging of assertions and we can leverage it right away.

There are multiple standard assertion languages that digital verification engineers use extensively. Property Specification Language (PSL) and SystemVerilog Assertions (SVA) are the most popular ones. Cadence has worked vigorously in extending these languages to support assertion based verification for analog designs. These techniques are discussed in an excellent paper presented by my colleagues recently at ARM Technology Conference 2010 (click on Day 1 and scroll down to ATC-122).

In general the standard assertion languages depend on discrete events that are clocked to build meaningful sequences. Since analog values are continuous, the standard languages need to find a way to handle these. While several ad-hoc methodologies exist today, it is important to standardize this flow. I sincerely urge the analog design community to participate in the Accellera standardization process to find a solution that is practical and portable across all phases of design and verification cycle.

In conclusion, when I try to compare the evolution of assertion-based verification on the digital side to what is happening now on the analog side, I see the exact same problems. The lack of standard languages and methodology, the lack of consistent tool support, the lack of training and use cases and the lack of availability of IP are all not new to the design community. But the demand for all the above has been clearly established by the complexity of mixed signal SoC realization, and Cadence has taken a leadership role on delivering these solutions to our customers.

Srikanth V Raghavan

Previous post:

Analog Assertion Based Verification Methodology – Reality or a Dream? (Part 1)


By Ramya on October 4, 2012
Hi Srikanth, I liked the article. One question though.. How will assertion based verification beat the bottlenecks such as the very characteristic of analog signals,i.e, continuity ? I dont know if its a stupid question but I am still learning SVA as I am trying to use it for analog assertion. Thanks in advance.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.