Analog Simulation Insights

 

AMS assertions… a violation of “the 10 commandments”?

Now… before any religious zealots come after me, “the 10 commandments” that I refer to are in my friend Karen Bartleson’s list of Commandments for Effective Standards. If you have been reading here in recent months, you know that I have been participating in Accellera discussions on the topic of AMS assertions. After the last two meetings, I have grown more concerned that this activity is committing transgressions of Karen’s 3.1th commandment: Know when to start. I might modify that slightly to say “know WHERE to start“.

Karen captured the issue well when she wrote There is a proper time to start a standardization effort for a technology (or format, API, database, …). Before standardizing, it has to have reached a certain level of maturity.”

The problem as I see it is that there is no existing tool, and neither are there any agreed upon best practices, for the realization of Assertion-Based Verification of AMS designs (AMS-ABV). Yes, as I have written here before, there have been some research activities in this area. There are also some who are actively employing existing Verilog-AMS capabilities to implement AMS-ABV. And yes, I am pretty sure that we all agree there is a critical need for improving the productivity of AMS verification by adopting automated checking techniques like ABV. I wouldn’t be here (virtually) if there wasn’t. But advocating a solution (i.e. a merger of SystemVerilog with Verilog-AMS), before reaching agreement on the problem to be solved, seems to be a sign of premature standardization – in my opinion.

I have not been entirely alone on making this point. Another participant in the Nov-4th Accellera committee meeting asked if we should define requirements before we define syntax. I attempted to define requirements in my Taxonomy of analog properties. This is a classic example of the problems that can arise when “analog meets digital”. Language standardization efforts, by their very nature, are not likely to attract active involvement from those of us who would say “I’m an analog“. We just aren’t very interested in designing languages. Where we focus on transistors and circuits, the digital types focus on syntax; regular expressions, special functions and my favorite… syntactic sugar. Special functions are required because SystemVerilog is a digital verification language (doh!). More than once, in the last two meetings, someone has pointed out that Verilog-AMS can already do what the language definers are trying to re-invent. Why force a round peg into a square hole? Is this going to make AMS verification any easier?

I have nothing against language definition per se, if that’s what you’re into. But, at some point, reality has to settle in and the language needs to be implemented in a simulator(s). I found this quote from Karen’s 3rd commandment to be especially apropos:

“There are dozens of EDA standards sitting on the shelf unused. (Remember VHDL Waves?) Resources consumed by these standards could certainly have been better spent. Working on a standard that isn’t going anywhere is a senseless waste.”

Several examples of AMS SystemVerilog assertion prototypes are now being discussed in the Accellera meetings. You can go to the Accellera Verilog Analog Mixed-Signal Group repository to download the documents. If you have used Verilog-A/AMS, you probably have learned that one of the best practices is minimal use of analog event statements like @cross. Well folks… forcing the “round peg” of analog (continuous time) properties into the “square hole” of digital (discrete time) checkers requires creating and monitoring a ton of analog events! The problem expands many times over when you play tolerances into the equation, as you will see in the example prototypes. We are in danger of defining a language that is completely impractical to implement and apply. As it currently stands, the examples could only be implemented in a post-simulation waveform calculator… not exactly a novel concept.

Finally – even with the most brilliant definition of how to do AMS-ABV, it would be meaningless if no EDA vendor signs up to create an implementation. This Accellera activity is very different than the Verilog-AMS effort that I participated in ten years ago. At that time Verilog-A had already been introduced, in Cadence’s Spectre-a as well as in Meta-Software’s HSPICE. The leaders of this project are a semiconductor vendor (Freescale) and a research institute (Verimag). There are a few participants from Synopsys and Mentor, with little or no participation from Cadence. Clearly, to achieve a meaningful consensus on advancing AMS verification with assertion techniques more participation is needed. The discussions take place every other Tuesday morning, moving to 10AM central U.S. time on Dec-2. I believe that you can mailto:verilog-ams@eda.org if you would like to join the discussion.

-Mike

p.s.

You may notice some slight changes to the Analog Insights page. First – you will note that my introduction in the “About” right sidebar has changed. I think that an update was long overdue, but this also will now reflect the fact that I am no longer employed by Synopsys. However, Analog Insights lives on, and Synopsys has encouraged me to continue posting here. I am very gratified at the tremendous growth in subscribers over the last year, so I am glad that I won’t be losing that audience.

At the same time, I now have an opportunity to revive my personal blog; The World is Analog. You will note that link is now on my blogroll in the left sidebar as well. I had started blogging on my own site a few months before the launch of Analog Insights, but decided to shut it down for reasons that you can read about there. The World is Analog will reflect my broader interests in topics beyond AMS verification. I hope that you come by to check it out, and subscribe there as well.






  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • RSS
  • Twitter