Update on requirements for AMS assertions

In today's Accellera Requirements Gathering Group meeting on AMS Assertions, Jim Lear of Zarlink shared his perspective from in the trenches of complex AMS verification. I think that it was very eye opening to move the discussion up from the details of language requirements (i.e. the proposed solution) to stop for a moment to examine a real-world example of the problem we are trying to solve.

Jim expressed a concern that a focus on assertions would not solve his problems, which may be better represented by referring to the concept of transactions. In his company's designs, verification is based on performing tests of AMS circuit properties such as THD, linearity, etc. Many of these properties require analysis through frequency-domain transformation on time-domain data.

In Taxonomy of analog properties, which I published in Sept-08 on Analog Insights, I described requirements for verifying this type of cumulative signal property in AMS circuits:

Signal properties II: cumulative temporal properties

This type of property includes behavior that requires many measurements of multiple signals, sweeping over time and-or voltage/current in order to test. Examples are dynamic differential and integral linearity in an analog-digital converter, jitter, eye-width in a SERDES bit stream, etc.

Signal properties III: frequency domain properties

This could perhaps be included in the type II signal properties, but I break out separately the type of AMS circuit properties that are derived through frequency domain transformations. Anything to do with harmonic distortion, signal-to-noise ratio, filter cutoff frequency, etc. falls into this category.

The taxonomy has now been integrated into the Working Draft of Requirements for Analog Assertions. In the current version of the draft document, Type II properties are included in our scope as "Required", while the Type III properties are currently listed as "Low Interest".

Keep in mind that, in the language of System Verilog, an assertion is nothing other than the test of some property of a circuit or system. Here is an excerpt of the semantics defined in SystemVerilog 3.1, Accellera’s Extensions to Verilog®:

assert property ( property_spec ) action_block

Jim emphasized that rather than being simulator-language centric (i.e. System Verilog assertions), what he really needs is a library of test functions that can be applied to a design, and then transferred for use in the lab or in production tests of real silicon. This reminded me of a proposal that I wrote in "Followup to Comments" on my Analog Insights post on AMS assertions… a violation of “the 10 commandments”? in November of last year.

In that article, I suggested that AMS assertion-based verification could better be developed by allowing analog simulator vendors to develop their own proprietary implementations of analog property checkers, which could then be instantiated (i.e. asserted) from within a System Verilog testbench. This would allow solutions to be built upon tools which analog engineers employ today; such as measurement description languages and waveform analyzers, rather than attempting to fit an analog problem into a digital framework. The problem then, from a language extension perspective, would be limited to defining the interface.

Here is an excerpt from my November 19th, 2008 post:

My proposal is this: create an “AMSproperty” command to complement the current digital “property” functions in SV. Consider this…

• Just as Verilog-AMS supports analysis-dependent functions: analysis (analysis_list)
• Similarly, we could have analysis-dependent assertions: AMSproperty (property type);

I believe that this approach could really move things along much faster towards achieving the objective of helping Analog Meet Digital in complex AMS verification.

Your thoughts?

-Mike