Archive for 2008

In his comments on AMS Verification at ICCAD, responding to my remarks on the challenge of post-layout transistor-level verification, Martin asked:

1. Is it really required to combine the top-level architecture modeling with a full-blown extracted netlist with parasitics of the entire chip?
2. … The system-level guy is probably interested whether his “Quality of Service” is ok (Bit-error-rate is already to “low-level”), and if not, is the analog guy able to dig-down to the parasitic-level to find out whether it’s an parasitic-related problem?
3. Should we not propagate a cascaded approach: validate & replace physical implementation with schematic with the dominant parasitics only validate & replace schematics with a behavioral model validate & replace combination of behavioral models with system-level model, etc (note in top-down or bottom-up direction or both). But this requires a rather strict design methodology and modeling philosophy, which is again not always fully supported by today’s flow/tools.

Martin, it looks to me like you are describing a hierarchical verification methodology; i.e. one where different levels of abstraction (and the associated tools) are applied throughout the flow from circuit to block to full-chip . That is exactly what is required, which is why no single language or tool can ever completely cover the range of abstraction levels required to complete design and verification of an AMS SoC. Only an integrated and seamless (as possible) flow will suffice.

To answer your first question, no – it is not required to use the “full-blown” post-layout netlist with extracted parasitics of the entire chip at the architectural level. The first question to answer is “what are you trying to verify”? It’s critical to apply judgment in choosing the right model and abstraction level for each problem, rather than throwing all the data at it with the hope that this will provide the best insurance. My 1st post on this thread addressed this problem of “extraction overload”, as John Croix of Nascentric described it at ICCAD.

As a starting point for post-layout analysis, there are automated methods of applying only the dominant parasitics to a schematic-level simulation. For more details on how to optimize post-layout transistor-level analysis; you should review a webinar that I put together in 2006 (it is archived on the Synopsys website) – see Verifying Performance and Reliability in Nanometer Designs.

At the top-level, nobody would use a “full-blown” netlist. First of all, most AMS SoCs are “big-D/little-a” so analog-digital co-simulation is the way to go here. The parasitics in the digital blocks are back annotated into Verilog or VHDL models, and Fast-SPICE is used to accelerate the post-layout transistor-level blocks.

If you are verifying the power/ground buses for IR drop in the presence of parasitics, a similar hierarchical approach is the answer. There is no need, and it is totally impractical, to verify the entire chip at the transistor-level. As in the case of full-chip functional verification, different levels of abstraction are used for analog and digital blocks. A tool like Synopsys’ PrimeRail integrates the flow from transistor to gate-level, so that a unified view of the dynamic power grid IR drop can be performed.

What issues have you seen where the flow you want to employ is not supported by today’s tools?

-Mike

AMS verification
Fast-SPICE
Verilog
co-simulation
parasitic back annotation

Hello Everyone,

My recent post on AMS Verification at ICCAD has generated some detailed comments, which provide great opportunities for continuing the discussion. My response is somewhat overdue, so let’s begin with this 1st comment from Martin, who is associated with the System-C AMS initiative.

In response to my statement that “A hierarchical verification methodology is the only way to go for complex, high-performance mixed-signal SoCs” Martin said:

Gluing tools together (hierarchically or not) is probably not the solution for this problem, as this will introduce fuzzy inter-tool communication (example: co-simulation between tool ‘A’ and ‘B’). What we need is a transparent design flow to support a (top-down) design refinement methodology, complemented with bottom-up verification elements. As soon as the methodology becomes clear, we should _not_ start a discussion on tools, but first look at the modeling language: which language is most suitable to do the job? Is there any? Today’s complex AMS systems are not just a bit of analog transistors and some RTL; it’s about having digital HW/SW and AMS subsystems that interact. This is one of the main reasons why the SystemC AMS extensions are being standardized.

Martin, I hope you did not think I was suggesting “gluing” together tools. In fact, I said quite the opposite in my 2nd statement that “EDA vendors need to focus more attention on flows, not just point tools“. I’m not exactly sure what you mean by a “transparent” design flow, but I absolutely agree that the challenges of AMS design and verification (the two activities being more inseparable than in digital) must be addressed from a complete top-to-bottom flow perspective and not just as a pursuit for better point tools.

The first problem though, is in the definition of any “one-size-fits all” methodology. Are you suggesting that one methodology could be developed across the EDA and semiconductor industries, that would cover all types of AMS/RF SoCs? I think that it would be unrealistic to expect that such a methodology could be created, and/or that customers would ever give up on their internal processes and proprietary methods. However, I believe that a set of best practices for a comprehensive set of relevant prototype circuits is sorely needed. What a waste it is for each company that designs ΣΔ ADCs, for example, to develop a verification methodology from scratch.

But this begs a lot of questions. EDA vendors generally do not possess the design domain expertise to develop such methodologies, and those EDA vendors that have invested in AMS methodology services and packaging of AMS verification IP have struggled to get customers to pay for them. I think that the only practical answer is to elevate the practice of AMS verification through collaborative industry efforts, so that we can develop and publish more best practices. Digital verification has been elevated to this level, but AMS is lagging.

You then propose that we should not “start a discussion on tools, but first look at the modeling language“. I have been active in the current Accellera discussions on defining a language for assertion-based AMS verification, and going further back I was involved in the early development of Verilog-AMS. There is a very significant difference in how these two efforts originated. In the case of Verilog-AMS, it started with efforts to standardize Verilog-A, which was based on commercial development of a tool and language for analog behavioral modeling by Cadence. In the case of AMS assertions there is no commercial implementation of even a first prototype, just a general consensus on the need to merge some functionality of System Verilog with Verilog-AMS.

Even if the EDA industry was not under such severe economic stress as it is today, the notion of developing a standardized language before there are tools upon which to run it is naive. It is unavoidable – a language is just the user interface for driving the tools. Academic exercises belong in academia. EDA and semiconductor companies are in business to make money. What is the point of developing a language without considering implementation requirements at the same time?

However, I am personally not very familiar with the System-C/AMS effort, as it is mostly a European initiative. How are users and vendors collaborating on that project?

-Mike

System-C
AMS verification
Verilog-AMS
assertions

I wasn’t able to attend myself, but there was an interesting session on AMS verification at the most recent ICCAD in San Jose: DESIGNERS’ PANEL: Mixed-signal Simulation Challenges and Solutions. Richard Goering has a report on the panel discussion at SCD Source – Designers cite mixed-signal challenges and solutions.

There are some important lessons to be drawn from the panelist’s presentations in Richard’s report:

1. A hierarchical verification methodology is the only way to go for complex, high-performance mixed-signal SoCs.

The challenges of verifying a 40 Gbit/second CMOS deserializer IC, presented by William Walker of Fujitsu Labs, makes this abundantly clear. While this problem was described as “outside the envelope of what CAD tools are capable of verifying today“, I think it would be more accurate to say there is no SINGLE CAD tool – it takes a hierarchical methodology built from several tools that are best-suited for various aspects of the problem.

Think about this… when you go for your next annual physical checkup, would you want your doctor to use just one instrument to verify your health? That could be painful, not to mention totally ineffective!

The hierarchical methodology described in this example includes:

• SPICE for highest accuracy at the block level
• FastSPICE to accelerate verification of difficult multi-rate circuits, such as PLLs
• Verilog-AMS for chip-level functional verification
• Matlab Simulink for top level architectural modeling

2. EDA vendors need to focus more attention on flows, not just point tools.

So, even if you agree that a hierarchical methodology is required, you may ask “how do I put one together”? While there are certainly some gaps that still call for better point-tool solutions; such as time-domain noise and jitter analysis, I believe that the bigger issue is that EDA vendors don’t give enough attention to the integration of their tools into seamless verification flows.

Now, to defend EDA vendors somewhat, while this is a big problem for users it is an even bigger problem for tool developers. They just don’t have the knowledge and expertise to take a design through a complete flow. Developing a flow requires a closer working partnership between vendors and customers, and all too often the customer can’t share their most difficult designs outside their company. The result is a lot of reactive bug reports and enhancement requests, rather than proactive joint development.

Another problem is that the best tool for each task may come from a different vendor. This is why it is worrisome to hear that some vendors are pulling back on their interoperability programs. I would like to call for an initiative to create a verification equivalent to the OpenAccess Interoperable PDK Library industry alliance. This is a critical industry need.

3. You can’t just just throw as much data as you can create at a tool and expect it to spit out an answer.

I’m not referring to garbage-in/garbage-out here. This is in some ways even worse, the case of too much data in… and nothing out! I have also seen many examples of “extraction overload”, as was described in the ICCAD discussion by John Croix of Nascentric. This is the challenge of post-layout transistor-level verification. Designers and verification engineers sometimes fear missing some minute detail in the extracted parasitics from their layouts, so you see netlists bogged down by milli-ohm resistors and atto-farad capacitors that have no meaningful effect on circuit performance. Post-layout analysis is a critical part of a hierarchical verification methodology, which requires close integration between extraction tools and simulators. These tools tend to live in separate worlds, both at EDA vendors and with users; the physical/geometric view of the design database and the electrical/schematic view of the circuit that the layout implements. Accurate parasitic reduction is required, along with intelligent back-annotation heuristics. From experience, I suggest looking into tools such as HSIM^plus if you are choking simulations with flat, multi-gigabyte parasitic files.

-Mike

p.s. I have been informed that this blog, and the other Synopsys Open Community blogs, will be moving by Dec-6 to a new location on the new Synopsys.com website. The RSS feeds should still work, and the URLs will get forwarded, so you should not lose contact with your subscriptions. A new look & feel should make the entire site easier to use and navigate.

p.p.s. If you have been using Yahoo readers for your blog subscription… well you might not be seeing this at all. Nevertheless, for some reason Yahoo is not refreshing the feeds for Synopsys blogs, so that it appears nothing new has been posted in a long time. I don’t know if the new web site will fix that, but for now I can no longer recommend using Yahoo for blog subscriptions. Please see the new link to subscribe by email through Feed Burner. I know that one still works.

mixed-signal verification
OpenAccess
analog simulation
verification methodology

This is a follow up to comments on my post AMS assertions… a violation of “the 10 commandments”?

---

I think that defining an interface between Verilog-AMS and SV is exactly what is needed. But, instead of doing that, the Accellera committee is trying to define a new “merged” language that can translate analog signal properties into the digital property syntax of SV. This effort fails to understand that what may be an interesting exercise academically does not necessarily equate to the best (or even a viable) solution for the real world.

• More importantly, are we losing sight of “What is the problem that we are trying to solve”?

There are two simple facts that frame this problem.

1. SV only understands boolean values for property checks. That is not going to change.
2. Analog instrumentation is required to perform property checks of an analog circuit or signal. That is not going to change either.

So how should analog meet digital here? If you try to (syntactically) put analog instrumentation in the digital checker it’s pointless, because the execution still must be performed by an analog engine. (Hence all the examples with “special functions”).

In a real-world solution, it makes much more sense to utilize whatever instrumentation fits in the analog engine to test analog properties, rather than obscure that reality in a new language that must be parsed and elaborated for execution in the analog engine anyway.

We can easily communicate boolean values from analog property checkers to SV through a co-simulation interface. A rough implementation of that has already been demonstrated by IIT Kharagpur in their research project “Instrumenting AMS Assertion Verification on Commercial Platforms”.

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);

The property types would match those in a taxonomy of analog properties. I firmly believe that my taxonomy is a more viable starting point than where this activity sits today, but I would be more than thrilled to see one that represents a consensus of a cross-functional industry committee.

In an integration of analog engines (SPICE, FastSPICE, whatever… with or without Verilog-AMS) with SV, as in the IIT example, parsing of a netlist with an AMSproperty would immediately invoke functions that the analog engine understands. No new language required!

Furthermore, this solution would enable complete coverage of all the property types in the analog taxonomy, which the current SV-constrained discussion does not address. EDA vendors could then build interfaces to whatever analog tool best fits with the properties being checked, and not be limited to time-domain simulation.

Let’s develop a solution that fits the problem, rather than the other way around!

-Mike

The World is Analog

AMS assertions

System Verilog

Verilog-AMS

Accellera

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 opinon.

I have not been entirely alone on making this point. Another participant in the Nov-4th Accelllera 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.

analog
AMS verification
System Verilog
Accellera
Verilog-AMS
assertion-based verification

Hello Everyone,

Are you attending ICCAD in San Jose this week? Even if you’re not, but you are in Silicon Valley Wednesday afternoon Nov-12, here is your opportunity to see what EDA bloggers look like in real life. (Here’s a secret… we wonder what you look like all the time). And best of all… it’s FREE and you don’t need to be registered for ICCAD to attend.

Ed Lee (of Lee Public Relations) and Sean Murphy (of SKMurphy, Inc.) have organized a EDA Bloggers’ “Birds-of-a-Feather” meeting, to be held at 4:00 PM in the Fir Ballroom at the San Jose DoubeTree Hotel. If you are thinking of starting your own blog, this will be a great place to start by meeting a group of the EDA industry’s most experienced bloggers. The event will feature a mix of bloggers from EDA companies, journalists, users and EDA consultants. I will be joining this group of my fellow bloggers for a 3-minute “Lightning Talk” on the topic of how to develop an audience for your blog.

Confirmed presenters:

• Karen Bartleson http://synopsysoc.org/thestandardsgame/
• John Blyler http://www.chipdesignmag.com/blyler/
• John Busco http://jab-semi.blogspot.com/
• Grant Martin http://www.chipdesignmag.com/martins/
• Rick Munden http://blog.freemodelfoundry.com/
• Sean Murphy http://www.skmurphy.com/blog/
• Warren Savage http://www.design-reuse.com/blogs/oncores

For more details, see Sean’s blog or the ICCAD website.

-Mike
blogging
ICCAD
EDA

Hi All,

There was another Accellera discussion this week on the topic of AMS assertions. To be more accurate, the discussion has actually focused more on how to define analog properties in System Verilog. Now this is a great example of the type of “analog meets digital” issue we explore here, but I have to say that I just can’t get this image of square pegs and round holes out of my head on this. You know… you might be able to get them to fit together, but only if you make the peg small enough. And therein lies the issue, at least in regards to sizing a solution to fit a problem… and the problem here is how to improve AMS verification.

If you look at the IEEE 1800^TM Standard for SystemVerilog (which you can download from the link if you have an IEEE XploreÂź account), you will see that the spec defines seven types of (logical) properties:

1. sequence
2. negation (NOT a property)
3. disjunction (OR of two properties)
4. conjunction (AND of two properties)
5. if…else (IF A then property B)
6. implication (when A then property B)
7. instantiation (you’ll have to look that one up)

Now it’s no wonder I am an analog guy. Logical combinations (NOT, AND, OR) count as new properties???

In any case, look at my Taxonomy of analog properties and you will see that only categories #4 and #7 are a potential fit with the defined System Verilog digital properties.

1. Connectivity properties
2. Static electrical properties
3. Functional properties
4. Single-event temporal properties
5. Cumulative temporal properties
6. Frequency domain properties
   
7. Mixed-signal interface properties

So, how do we fit the round peg into the square hole? Or should we?

I found this statement from the IEEE 1800 spec to be extremely interesting (pg. 244):

“One of the goals of SystemVerilog assertions is to provide a common semantic meaning for assertions so that they can be used to drive various design and verification tools.”

The SV assertions are specifically designed to work with digital verification tools; digital simulators, formal verification tools, and coverage measurement tools. Should we not then be looking at how to best define analog assertions so that they work with analog verification tools? Looking at the little piece of analog that fits with a popular digital verification language certainly has its merits, but I also think that it leaves too much out when it comes to meeting the actual objective of improving AMS verification.

If we instead look at the problem from the point-of-view of what analog properties are, as the developers of the IEEE-1800 standard did for digital, we can get a much better solution. And, I think that it’s actually not so hard to do.

Each of the analog/electrical properties in my taxonomy can be verified by tools that are in use today. The definition of an analog property can refer to the type of analysis or tool required, just as the digital assertions do. And… just as the Verilog-AMS LRM does for models, with analysis-dependent functions.

In the end, the SV assertions come down to a simple true/false boolean value. If we let the analog tools do what they do best, i.e. analyze analog properties and set pass/fail flags, it would be much easier than trying to fit that round peg into a square hole. In fact, that is very similar to some experimental work done at IIT Kharagpur on verification of time domain mixed-signal properties. I believe that this concept, of using optimized analog property checkers, linked to SV where it fits, is the way to go for comprehensive “analog meets digital” verification.

I hope to hear more of your thoughts on the subject.

-Mike

AMS verification
Accellera
Verilog-AMS
System Verilog assertions
IEEE 1800
Assertion-based verification

Hello everyone,

It’s been a while since I went “off topic” into one of my favorite extracurricular activities. (Actually almost one year ago since I wrote Digital vs. Analog: never-ending myths of CDs vs. LPs). Because I spent so many years as an ADC designer, I get especially peeved when mythology is substituted for science in discussions of analog-digital conversion. But this type of lazy editorializing happens way too often, and not just in the never-ending debates over analog vs. digital audio. (For another example, see Analog design is NOT black magic… but it is VERY hard). Is it because science is so hard that, just like ancient cavemen discovering fire, writers find it easier to explain technology in some mystical pseudo-scientific way? Or has the Unstoppable commodization of information goods, as one of my professors at SJSU described it, caused writers to go for the provocative at the expense of the facts?

The stimulus for my rant is yet another case of a “golden-eared” audiophile trying to attribute flaws to analog-digital sampling that just don’t exist. I had an episode of dĂ©jĂ  vu yesterday when I picked up a copy of the November issue of Sound & Vision magazine, since I realized that I first wrote an article about this topic more than seventeen years ago! (“Un-debunking the truth about CD specs“, Components in Electronics, May 1991).

If you happen to come across Rob Fraboni’s “The Producer’s Ear” column you will see what I mean. Now, Mr. Fraboni may be an excellent record producer/engineer (after all… he claims to know Eric Clapton personally), but like many before him he just can’t understand how you could possibly sample an analog waveform without losing something. In comparing analog and digital he writes: “The samples, by their nature, leave finite gaps in the wave. These gaps are perceived subconsciously.”

Wow… “gaps in the wave“!

Would that be something like the clicks and pops from your precious vinyl LP?

-Mike
audiophile
analog-digital conversion
vinyl LPs
CD audio
Sound & Vision

The Verilog-AMS Technical Subcommittee of Accellera held another in a series of conference call discussions on Tuesday Oct-7, to further explore the topic of AMS Assertions. The meeting began with a review of some work that was published at the workshop on Formal Verification of Analog Circuits, which I wrote about here in June.

In the FAC paper, Analog Property Checkers: A DDR2 Case Study, authors from Verimag and Rambus described the use of analog extensions to the PSL Language for verification of DDR2 memory timing properties. Verimag developed the PSL extensions, which they call Signal Temporal Logic (STL), for the European government-funded project PROSYD: Property-Based System Design.

While setup and hold times may appear to have little to do with analog, in this case the DDR2 spec requires applying a variable correction factor that depends on the slew rate of the data and clock signals. (For more details on the slew derating for DDR2 memories, you can download the JEDEC spec here). This variability turns what might otherwise be a straightforward timing measurement into a more complicated case of analog waveform measurement.

Since the DDR2 setup & hold spec requires measuring two waveforms (data and clock) at multiple points, and under multiple conditions of slew rate, it would fit with category #5 from my Taxonomy of analog properties: Cumulative temporal properties.

Dejan Nickovic of Verimag, one of the authors of the FAC paper, also described an example of using STL to verify erase conditions in a Flash memory example from ST Microelectronics. The erase condition of the Flash memory cells was described in this way:

“… define the erasing condition that holds whenever the wordline signal wl is lower than -6 and p-well pw is above 5.

…whenever an erasing condition holds, the pointwise distance between the source s and p-well pw voltages has to be smaller than 0.1 and the value of pw should not be greater than 0.83 from the value of bitline bl.”

This is a DC property, so it fits with category #2 of my taxonomy: Static electrical properties.

I then briefly described three examples of analog properties that go beyond waveform characteristics:

1. Device-level properties to identify mismatched voltage domains (i.e. a thin-gate device switched to a higher voltage signal). This case could be static (category #2) or single-event temporal (category #4).

2. Situation where power-gating inadvertently creates a floating, high-impedance node. This is the case of “analog-X”, and can be destructive if (through leakage or noise) the node floats to a point that it turns on DC current paths. An author at SNUG Boston recently described how this problem has been addressed by Synopsys CircuitCheck. Again, this phenomenon could be considered to be static or temporal, but with a time constant that is much too long to dynamically simulate.

3. DC leakage paths. With the need to do complex on-chip power management, one of the most common needs for mixed-signal verification involves checking of digitally-controlled power modes. Since there is generally no concept of the power supplies in digital simulations, how would we assert an analog property for a supply in order to check leakage current? This would be a temporal property of a device when it is switched into a leaky state, but could also be checked statically with a tool like Synopsys CircuitCheck.

Following my presentation Ed Cerny, a Synopsys colleague and one of the co-authors of the Verification Methodology for System Verilog, described examples of how features of Verilog-AMS and System Verilog could be combined to implement temporal property checking, as in the initial proposal submitted to the Accellera committee. This is helpful for showing how to address problems that can be fit within the event-driven discrete time domain that is used in the digital world. However, to develop and drive adoption of ABV for AMS, I believe that the broader view of analog behavior will be critical. A proposal has also been made to the committee to broaden the scope of the proposed property specification language for AMS assertions such that it would be independent of any simulation/modeling language (i.e. Verilog/VHDL-AMS). I agree that is the way to go, and we should be exploring that more in future Accellera meetings.

-Mike
Accellera
assertion-based verification
AMS assertions
analog properties
System Verilog
Verilog-AMS

Hello Everyone,

Tomorrow, Sept-27, marks the one-year anniversary of Kicking off Analog Insights. I think it is very apropos that I should be observing that anniversary while attending the IEEE International Behavioral Modeling and Simulation Conference, which has had an excellent program this year.

The community of readers for this blog has grown tremendously over the last twelve months, and I want to thank all of you for coming by to read my posts, and an even bigger thanks to those of you who take the time to contribute your comments. I invite more of you to do so.

I thought it would be interesting to take a look at what have been the most popular topics so far. Here are the Top-5 posts from the 1st year of Analog Insights.

1.	Web seminar on multi-core simulation
2.	Raise your hand if “You’re an analog”
3.	Other AMS Verification Research Conferences
4.	things heard at DAC – day 3
5.	Formal Verification of Analog Circuits

-Mike