Archive for the 'verification' Category

While at SNUG, I attended our AMS technical track session. One of the presentations described an innovative flow using UVM with Verilog-AMS. Synopsys CustomSim-VCS was successfully used on AMS designs to demonstrate the performance advantages of this methodology. The title was:

“Universal Verification Methodology (UVM)-based Random Verification through VCS and CustomSim in Analog Mixed-signal Designs for Faster Coverage Closure” by Warren Anderson and Ravi Ram from AMD, and Vijay Akkaraju, from Synopsys.

To give you a little more insight (don’t thank me ), this paper describes specific application of RTL verification methodology for AMS designs. Given the increasing complexity of mixed-signal circuits, a larger and larger number of stimulus need to be ran  to ensure functional correctness.  Because of lengthy run times of SPICE-based simulations and limitations of Verilog only models, more sophisticated approaches are needed.  AMD presented their approach, where low-level analog blocks were modeled using Verilog-AMS, and instantiated in a System Verilog top-level testbench for mixed-signal simulations. This flow was successfully implemented using Synopsys CustomSim-VCS.

Because I am a really nice person , I have included the presentation at the end of this post.

In this interview, Warren and Vijay share their insights about this approach and their overall experience at SNUG.

Warren Anderson

Warren Anderson is currently a Fellow at AMD’s Boston Design Center, where he works on high-speed I/O and electrostatic discharge (ESD) protection design.  Warren leads a team designing I/O and ESD circuits and developing solutions for high-speed off-chip signaling on AMD’s microprocessors.  Prior to joining AMD, he worked for Intel, Hewlett Packard and Digital Equipment Corporation. Warren’s areas of expertise include I/O circuit design, I/O jitter modeling and performance prediction, ESD protection, and signal integrity.  His publications include numerous papers on ESD protection design as well as contributions to three books. Warren currently holds 11 patents on ESD protection devices, circuits, and I/O design techniques.

Vijay is an Staff Application Consultant for Synopsys’s Simulation products, supporting key strategic accounts in Silicon Valley. He has been in the semi-conductor industry for 13 years including multiple roles in Design Engineering and has been part of 17 Silicon tape-outs. Before his current role he had stints in Analog Devices, AMCC and a start up.

Q- Warren, what was your overall experience at SNUG as a speaker? Which feedback did you receive after your presentation?

A- It was a very good experience.  I particularly enjoyed the Q&A discussion after the talk.  We received many thoughtful questions, showing that the audience was highly engaged during the talk (and it’s always nice for a speaker to know that the audience stayed awake!).  The amount of time allotted for the talk and questions was just right, making for a comfortable setting and pace.  The publication submission process was well organized and easy to follow.

Q- Could you please describe your job responsibilities within AMD ? What types of circuits do you simulate and which specific  Synopsys tools/simulator do you use ?

A- I manage a design team working on custom circuits for memory I/O.  My team is responsible for the transistor-level design of the circuits discussed in the paper: drivers, receivers, amplifiers, comparators, biasing, clocking, etc.  Most of our work involves creating and tuning the transistor-level design through HSPICE.  For the Verilog-AMS modeling, we run VCS+CustomSim/XA.

Q- Can you give us some background on this paper and using Verilog-AMS in conjunction with UVM? What were you trying to achieve?

A- High-speed I/O designs use a large amount of digital logic to control analog circuits.  The increasing mixed-signal nature means more digital-analog interactions, where sequences have to be performed in the right order, control bits need to be set properly, and missing a flop on an analog control wire could completely break the design.  In fact, in our prior project, we had a couple of near misses where we caught a few such bugs late in the project by manual inspection or transistor-level co-simulation with XA.  I didn’t want to repeat that scenario.

Verilog-AMS models run faster and follow a top-down design approach, enabling earlier verification of the mixed-signal interactions.  UVM increases our coverage of mixed-signal interactions by allowing us to randomize variables, such as offsets, device-related variations, and delays, in the Verilog-AMS models.

Q-   What are the main advantages (besides performance) in using this flow? Which challenges did you encounter during implementation?

A- As I mentioned, transistor-level co-simulation with VCS+XA has to wait for the transistor design to complete before it can be run.  Verilog-AMS models enable mixed-signal verification earlier in the design process, before the transistor-level design is finished or sometimes before it even starts, catching bugs earlier when they are easier to fix.  I think of it as RTL for analog designs.

In our implementation, automatic converter insertion caused some challenges.  It took a bit for us to become educated on the converter insertion algorithm, but it made sense in the end.  In order to configure the simulation to propagate analog signals through the top-level I/O block the way we wanted, we had to edit a few models once we saw where the converters were placed.  We did find a few bugs in the simulator, but those have been fixed.  Synopsys was responsive and committed to help us meet our design completion targets.

Q- What do you see moving forward in advanced Mixed-Signal/SoC verification?

A- We want to unleash more of the power behind the mixed-signal verification models and tools.  We will add more variables to our Verilog-AMS models and tie these into UVM constraints and randomization so deeper aspects of mixed-signal interaction can be covered.  In addition, I expect to propagate the AMS methodology to other I/O interfaces within AMD.

Q- Vijay, from a Synopsys point of view, we have a very robust and highly competitive mixed –signal solution using our leading edge fast-spice solver CustomSim in conjunction with VCS. Which design/customers would benefit the most from using this flow?

Vijay Akkaraju

A- I feel most AMS designs where Mixed-signal simulations are more than just “sign-off” can benefit from this methodology. The environments  likely to get the most are the ones with a mature UVM flow with large number of constrained random testcases. Also, designs where some rtl (digital) code can only be reached in a mixed-signal context for purposes of coverage (both functional and code) can immensely benefit from adapting this. I say that since for them, waiting for availability of a finished spice netlist comes in the way of speedy coverage closure. Also, designs with a complex Analog-Digital interface where constraint randomization of stimulus can expose bugs not likely to be exposed using directed testcases only.

You can find the presentation and paper clicking on the link below. Enjoy and see you soon!

SNUG presentation:

SNUG_AMS_v6_final_presentation

SNUG Paper:

SNUG_2012_AMS13

Hello!

Do you ever

• wonder what the latest news is for Synopsys Custom and AMS solution? how others are using Synopsys solutions?
• wish you had insight into the latest advances in Synopsys solutions?
• have the urge to send comments to Synopsys team, via your smart phone?

The day you all have been waiting for has finally arrived; our Analog Insights blog is Back! Our mission is to create an interactive place where information can be shared and discussed among our design community, from a pure Analog spice-level circuit to an advanced SOC design.

Because Synopsys Custom and AMS tools portfolio is extremely diverse and comprehensive, our range of topics will vary from analog, RF, to mixed signal from a simulation and design angle. The goal of Analog Insights is to also provide accurate information about the flows or solutions that would benefit our end-users and improve performance and productivity.

For example, you will be able to find:

• List blogs where we would provide tricks and tips to improve simulator performance and convergence (for example “5 tips to spice up
your PLL design :^), I know you are all disappointed..)
• Interview blogs with CAD, design, verification, and modeling engineers to get more insight on their work and their best practices using Synopsys AMS tools
• Technical blogs, where we would go deeper on specific Custom design and AMS subjects
• Industry analysis blogs, where we would capture incoming hot trends in technologies and describe Synopsys solutions
• Webinars, Videos showcasing advanced features and/or flows

We of course welcome your inputs and suggestions on how to improve our blog, as we want it to be innovative, instructive and interactive. I hope you would appreciate and use this blog. See you at our next blog!

Today’s Guest Blogger is Dwayne Holst, Corporate Applications Engineer for CustomExplorer and Custom WaveView at Synopsys.

Running analog regressions in a production chip design flow is hard enough without having to sort through the results by hand. While the majority of the thousands of simulations are probably good, the risk of missing a problem is the risk of a bad tape out (and then you have to fill out a lot of paperwork, there are more questions and it’s generally not a good thing).

Last year, we introduced a new feature in CustomExplorer to help out with this tedious manual process.

Called “Batch Waveform Compare”, this feature automates the comparison of simulations runs in batch and alerts the user to the problems.

Waveform Compare can be used early on in the design phase. Designers can compare waveforms from RTL, down through to the device level and make sure that your design is converging on the spec. The final use of Waveform Compare tests the results of extracted parasitic simulations to help quickly isolate problems.

And it’s fast
 One of our early adopters of Batch Waveform Compare saw their week of manual time required to “eyeball” 100 analog waveforms drop to just 15 minutes of Waveform Compare run time.

The user has complete control over the comparison algorithms. Tolerances for the x-axis (be it time, frequency
) can be set independently from the y-axis (be it voltage, current
) and Waveform Compare does the rest.

Here is a partial example of a rules file for waveform compare:

; Global Parameters
v_tolerance 5mv
i_tolerance 1ma
a2d_threshold 2.5v

; Aliases
Alias stable_period “start=5ns, stop=16ns”

; Rules
Rule v_check begin
   Master gold2.dat
   Step 0.1ns
   v_tolerance 1mv
   v_reltol -0.01
end

rule mono_chk begin
   monotonicity_check
end




; Checks
Check begin
   target “t1.dat t2.dat”
   signal “*”
   time_range “0ns, 6ns”
   rule “initial_v_check”

   target “t1.dat t2.dat t3.dat”
   signal “s1, s2, s3”
   time_range stable_period
   rule “v_check”
end

The result of this rule file applied against the simulation results
$> sx –compare compare.rules
   *** loading waveform file gold2.dat 
 ***
   *** loading waveform file t1.dat    
 ***
   *** loading waveform file t2.dat    
 ***
[COMPARE] master file    : ‘gold2.dat’
[COMPARE] master file    : ‘t1.dat’

# comparing signal ‘v(in1’

x-axis			master	0|test/IN1
1.0500E-08	1.650000	[1]		[0]
1.1000E-08	3.300000	[1]		[0]
# end of difference list



Waveform compare is a powerful tool in CustomExplorer and can be used to significantly improve design regression productivity. Have fun with it.

Dwayne

About Dwayne

Dwayne strives to be a cool dad and he’s an EDA geek. He also pretends to be a Southerner although he’s really a California Yankee living in North Carolina.

High accuracy analog simulations face the classic problem of scalability. Doubling the size of a design roughly quadruples the size of the matrix and dramatically increases a simulation’s run time to the point where a design team simply cannot wait for it to finish. Conversely, the team cannot proceed without knowing that the design is functioning. Conundrum!

Happily, improvements in processor technology have provided new machines with multiple processing cores on the same chip. Although HSPICE has had the ability to use these cores for several years now that hasn’t stopped us from making improvements in our multi-core processing capabilities.

Synopsys recently released a new capability in HSPICE that improves the scalability of simulations on machines with four or more cores. This new high-performance multi-processing capability is seeing great scalability on multiple core machines:

These are average speedups on top of the over 5x speed improvements on single-core HSPICE that our team has already achieved over the past few years. Many of our simulation tests on four cores are reaching even higher performance while maintaining the golden accuracy you demand from HSPICE.

I’d like to go into more detail about how this great new technology works but given that it is patent-pending, I will save that discussion for another blog entry.

Kishore

If you are reading this, you may have had thoughts on blogging yourself, or perhaps you already are a blogger. One of the most valuable lessons that I have learned from writing a blog is how it can be be used for creating and publicizing my personal “brand”. Personal branding is a way to demonstrate the unique expertise and value that you can provide, to potential employers as well as to colleagues in your profession.

I was first introduced to the topic of personal branding in an article for which I was interviewed by EDN magazine; Life after layoffs: How to move forward after a job loss. Since then I have been asked to share my experience as a blogger with others, most recently at a career networking group hosted by Right Management here in Silicon Valley. My “Top 10 ways to attract subscribers to your blog” may be helpful to you in developing your own personal brand through blogging. You can view the slide show of my presentation here: Developing Your Personal Brand Through Blogging.

-Mike

Hello Everyone,

The Design Automation Conference will take place this year in Anaheim-CA, on June 8-13. (OK… insert your own Mickey Mouse jokes here ________ )

I hope to see many of you at DAC, but if you were not planning to attend perhaps I can attract you with the Synopsys AMS Verification Breakfast that will take place on Tuesday morning, June 10th. The theme for this year’s panel discussion is “AMS Verification and Moore’s Law
 solutions for 45nm and beyond“. If you have attended the AMS breakfast panels in the past, you know that they have been very interesting and entertaining affairs. This year we will explore the topic of AMS verification challenges, and how to address the issues that occur when “analog meets digital“. You need to go to this AMS Breakfast link to register, and those in attendance will have a chance to win a free Apple iPod Touch.

Our panelists this year:

Thomas J. Sheffler, PhD.
Sr. Principal Engineer
Rambus, Inc.

Jess Chen
Senior Staff Engineer
Qualcomm CDMA Technologies

Jeff McNeal
R&D Engineer
Synopsys IP Solutions Group

Henry Chang
Vice President
Designer’s Guide Consulting, Inc.

Following presentations by our panel of experts, you will have the opportunity for Q&A as well. It will be a great opportunity to network with colleagues who are active in the growing field of AMS verification, so I invite you to sign up today!

-Mike
Design Automation Conference AMS Verification analog digital

Hi All,

Are you planning to come to the Synopsys User’s Group meeting in Santa Clara next week? This year’s SNUG program offers several sessions on AMS topics that I recommend for you to check out:

First, to get a good overview of Synopsys’ roadmap including the latest in AMS, don’t miss Aart’s keynote address:

Monday, March 31, 2008

9:15 – 10:30 Keynote Address: Aart de Geus, Chairman of the Board and CEO – Synopsys, Inc.

Also on Monday, in the AMS track, there are these two sessions on AMS simulation methodologies:

11:00 – 12:30 MA7, Tutorial: Post-Layout Simulation Methodologies
3:45 – 5:15 MC7, User Session: AMS Simulation

On Tuesday, April 1, 2008, you won’t want to miss the tutorial and panel session on AMS verification:

10:15 – 12:15 TA7, Tutorial: What’s New in Analog/ Transistor Simulation Products
1:15 – 2:45 TB7, Panel: Mastering the Demands of Analog Mixed Signal at 45nm

But… you know.. all work & no play is not good, so don’t miss the fun, free food & refreshments… and entertainment of the “R&D night on Monday”.

Monday, March 31, 2008

5:00 – 8:15 Synopsys R&D Night
Always popular and informative, Synopsys R&D Night gives you an opportunity to relax, mingle, talk shop with Synopsys R&D and executives and hear about Synopsys’ hot new technology. Stick around! The evening concludes with a performance by ‘Blues Compiler’…SNUG’s own version of the blues, featuring Aart de Geus delivering a presentation on guitar you won’t want to miss!

Best of all, I personally invite you to come visit the “Meet the Bloggers” booth during R&D night to say hi to me and my fellow Synopsys bloggers. It should be almost as much fun as “Meet the Fockers” but even better… because you are already in the “Circle of Trust”. Be sure to pick up a rare, collectible trading card with your favorite Synopsys OC blogger on it, preferably autographed!

On the back of each blogger card you will find instructions on how to enter a drawing for a MacBook Air. But, you need to come by our booth to get one, so don’t miss it!

And… as a special incentive… I have a prize for the 1st ten SNUG attendees who can share with me something that you read here on my blog. I am looking forward to meeting many of you at SNUG next Monday night.

-Mike

Location: Santa Clara Convention Center
5001 Great America Parkway
Santa Clara, CA 95054

Synopsys
AMS simulation
AMS verification
Circle of Trust
Meet the Fockers

To complete my review of the Analog/Mixed-Signal Verification session at DVCon-08; the last paper presented was by Walter Hartong and John Pierce of Cadence Design Systems.

7.3 Analog Mixed-Signal Verification: Can Modern Approach Replace the Traditional Way?

This presentation explored AMS verification from both the Analog and the Digital sides, as well as how the two can meet (reminiscent of one of my most popular posts here: Design Verification. Analog… meet digital. Digital… meet analog). As in the first two papers in this session (see Part I and Part II), the authors discussed how event-driven techniques are preferred at the SoC level for integration of analog block behavior. Also, as in the preceding paper from Chris Jones and Jeff McNeal of Synopsys, a hierarchical verification methodology was described.

When one looks at the relative performance figures in the author’s proposed hierarchical AMS methodology, one can readily see why big-D/little-a verification engineers might prefer the event-driven approach:

1. Extracted transistor netlist including parasitic elements (0.5-0.1 X)
2. Transistor level ideal circuit (1.0 X)
3. FastSPICE simulation (5-20 X)
4. Analog behavioral modeling (5-100 X)
5. Real number modeling (50-500 X)
6. Pure digital model (500-10,000 X)

There is a trade-off in performance versus accuracy that must be made in applying any hierarchical verification (and modeling) methodology. In this list it is assumed that the most accurate modeling approach, the extracted post-layout netlist, is also the slowest. The authors were probably referring to a flat post-layout netlist, accompanied by standard SPICE simulation. However, in my experience the combination of a hierarchical FastSPICE engine with hierarchical back-annotation of parasitics can actually deliver a large speedup over SPICE while simultaneously increasing the accuracy of results. What – you say? Increased performance and accuracy at the same time? That’s impossible!

Let’s look at this more closely. When you first consider that pre-layout simulation, which designers tend to do more of than anything else, is really a very unrealistic abstraction in and of itself, this may make more sense. It is a mistake to treat the pre-layout simulations as somehow “golden”. It’s the silicon that matters, and to get closer to the silicon you must do post-layout simulation. So, no argument so far on which model is most accurate.

Looking next at simulation performance, of course a FastSPICE simulator will provide higher speed over standard SPICE. But a total solution for post-layout verification, such as in Synopsys’ HSIM^plus , also provides a great increase in capacity as well. This is a critical 3rd dimension in a hierarchical methodology trade-off that is sometimes overlooked while focusing only on performance vs. accuracy. By having the increased capacity to accurately simulate post-layout effects that no standard SPICE simulator could handle, you simultaneously increase accuracy as well. More capacity = more accuracy. I sometimes see designers getting hung up on matching FastSPICE results to pre-layout SPICE, when they should really be looking at the overall accuracy in terms of how closely it models the eventual silicon. The effects of modeling the parasitics in the power and signal nets, the coupling of sensitive nodes, and the layout proximity effects on transistors more than makes up for any loss of accuracy in FastSPICE from exchanging analytic device models for table models – for example.

So my hierarchical flow would look like this, in order of highest to lowest accuracy:

1. FastSPICE post-layout simulation (5-20 X)
2. Transistor level pre-layout SPICE simulation (1.0 X)
3. FastSPICE simulation pre-layout simulation (10-100 x)
4. Analog behavioral modeling in SPICE or Fast-SPICE (1-100 X)
5. Real number modeling with event-driven simulation (50-500 X)
6. Pure digital model (500-10,000 X)

These are approximate rules-of-thumb, as you can’t compare a FastSPICE simulation to SPICE when SPICE never even gets started because it chokes on the size of the post-layout netlist. Another point to be aware of, as the first two authors in this session at DVCon pointed out, is that there is no guarantee that an analog behavioral model will actually speed up simulation. Again, it’s a speed versus accuracy tradeoff in the model – but that’s a subject for another time.

With all these options and trade-offs to make in order to complete verification of an AMS SoC, it is important to start out with a documented verification plan – as the authors point out in their paper. Tools for developing verification plans are more prevalent in digital verification, but it is now becoming more critical that analog meet digital early in the design project. One master verification plan should be created which describes the objectives at each step, and the level of abstraction to be used.

Looking at other methods that are used in digital verification; the authors discussed how the concepts of random stimulus, automated self-checking, and coverage can be applied to AMS verification. My friends at Designer’s Guide Consulting have also proposed a method for applying some of these digital techniques to analog by using Verilog-AMS and scripting techniques, in their paper on Verification of Complex Analog and RF IC Designs. Do these digital verification concepts apply to analog and mixed-signal?

1. Random Stimulus

Random stimulus or constrained random testing is (excuse the expression) a much more logical concept when applied to digital designs. The concept is that you can catch unexpected errors that a directed test (i.e. one that a designer has specified) may not catch. For AMS verification, random stimulus of a digitally-controlled mixed-signal circuit would also seem to be straightforward. You can randomly generate digital vectors that are defined within a boolean space. But how do you define the space for all possible analog stimuli that would include “illegal” operating conditions? How far do you extend into the “illegal” input range? It is up to the designer/verification engineer to define the constraints because there is nothing as simple as a boolean space to search. Additional work is required if one wants to automatically flag illegal output conditions as well. It seems to me that for AMS this concept essentially reverts, for practical reasons, to a set of directed tests – possibly extended manually to “what-if?” something “bad” happens.

2. Automated self-checking

Automated self-checking in digital verification refers to the use of techniques such as assertions. Assertions generally are used to specify temporal conditions that must hold, and are specified by a designer as part of a functional specification; such as “this signal must stay high for 3 clock cycles after reset“. Again – not so directly applicable to analog because our circuits are not necessarily event-driven or temporal. However, in AMS designs there are states or conditions that we want to monitor to make sure they do/do-not occur. Maintaining a transistor within a safe operating area of terminal voltage is an example. Functions are sometimes built in to simulators to allow such conditions to be monitored. Synopsys’ HSIM^plus CircuitCheck provides a sophisticated set of assertion-like checks that can be run either as part of the transient simulation, or as a pre-simulation test after the netlist is read-in and the circuit can be examined quasi-statically. The pre-simulation tests have the benefit of being vector-less, so they don’t require a directed test to be exercised.

3. Functional coverage

For digital verification, coverage can refer to “code-coverage” since one may want to know how much of the synthesized design has actually been exercised. That concept doesn’t apply to AMS, but it can be useful to have a figure of merit for how many of the designer-defined tests have been completed or how much of the operating range has been tested. For AMS verification some coverage items might be: a measure of simulations completed versus plan, completeness of the dynamic range covered, percentage environment & operating conditions and process corners verified.

In the end, a conclusion by the authors of “Analog Mixed-Signal Verification: Can Modern Approach Replace the Traditional Way?” was that “pure” analog and digital methods are essential for each designs within their respective domains, but that a common/integrated mixed-signal methodology does not yet exist.

What do you think? How does your project team integrate analog and digital verification strategies? How should “Analog Meet Digital“? I heard from a few people at DVCon who said they were looking for a place to discuss how to bring these two worlds together, and that while an AMS session at DVCon was good it tends to get lost amongst the main focus on digital methodology. Until AMS Verification has its own conference, I invite you all to use this space to participate, share, reply and comment on issues such as those discussed at DVCon.

-Mike

AMS verification assertions functional coverage constrained random testing FastSPICE Verilog-AMS DVCon

The second paper from the Analog/Mixed-Signal Verification session at DVCon-08 was presented by Jeff McNeal of Synopsys’ Intellectual Property Solutions Group:

7.2 Methodology for Modeling Analog Circuits Using Behavioral Verilog

Chris Jones, Jeff McNeal – Synopsys, Inc.

The work that was described in this presentation also addressed the problem of verifying the interaction between digital and analog circuits in mixed-signal designs (as in the 1^st paper: Thomas J. Sheffler Functional Verification in the Presence of Linear Analog Circuits), but went further by describing a comprehensive methodology to integrate synthesized and custom digital blocks as well as the interaction between analog modules that communicate across different levels of a chip’s hierarchy.

The verification methodology described here can itself be thought of as hierarchical, since it employs progressive refinement from higher level behavioral models all the way to transistor-level circuit models (for analog blocks) as a design proceeds from the top-level architectural definition through implementation and signoff. The Verilog PLI is also used extensively in this verification flow, with analog behavior represented by a small library of primitive functions that convert (to or from) real-number variables that are assigned to represent voltage or current values on digital wires. Here is an example from the author’s paper at last year’s DVCon (ref: C. S. Jones, J. McNeal, and R. Segelken, “Sending Analog Values Along Digital Wires”, DVCon 2007) of a PLI function to convert a real-number variable to a value on an output net:

$ana_voltage_source(wire_out, real_val)

In the earlier paper by Sheffler, the objectives for the analog behavior to be modeled were simpler – representing the conversion of a digital control word to an analog voltage. There is a requirement to model higher level analog/mixed-signal functions in the methodology described in this paper, so rather than solve for DC voltages and currents Verilog behavioral models are used to directly calculate analog values, such as in this example of a DAC (also from the same author’s paper at DVCon 2007):

The paper provides a comprehensive set of rules for applying this verification methodology, which I won’t go into here, but I highly recommend getting a copy if you are interested in more details.

My thoughts:

Once again; this paper provides another alternative for modeling the type of mixed-signal behavior that Verilog-AMS was developed for. To be fair; the Verilog-AMS language provides the capability to model much more elaborate analog and mixed-signal behavior, but that analog behavior must be calculated by a SPICE engine. Developing Verilog-AMS models is a difficult skill to master, and it is easy to create a model that is functionally correct but is bad in terms of how it affects simulation performance.

It is also apparent that for purposes of functional verification, at least in these examples of D/a designs, the event-driven approach controlled by a digital simulator is sufficient. It is also clear that the simulation performance during verification is of utmost importance when Analog meets Digital. Of course, much verification time is still consumed outside of this flow, by the analog block designers running SPICE and Fast-SPICE.

One obvious problem with any hierarchical verification methodology is how to check the behavioral models against the actual circuitry. In many cases the models are checked manually, and the assumption is that the analog designers have sufficiently verified their transistor-level blocks. I like that the methodology presented in this paper is more robust, because co-simulation of Verilog with Fast-SPICE is used as the final sign-off verification. The authors point out that judicious use of co-simulation is a requirement for catching subtle model mismatches, and is considered a necessity to increase confidence before tapeout.

Have you used SPICE or Fast-SPICE co-simulation with Verilog or VHDL?  What about Verilog or VHDL AMS extensions?  Are AMS behavioral modeling languages useful, or do they just slow down digital simulations?

I’m looking forward to your comments.

-Mike
DVCon AMS Verification Verilog Co-simulation Behavioral Modeling