I use Cadence's AMS simulator (ncsim -ams), which can be run from the Cadence hierarchy editor (CHED), from the Cadence analog design environment (ADE) or by executing ncelab and ncsim commands standalone, or as part of a script such as the runCompileElabSim script which can be generated with the CHED.

Here's what I envision for a test bench:

TB, (Top level testbench) schematic instantiates two symbols: DM, and SOCKET.
 DM (driver and monitor) drives all signals and monitors all outputs, and is a Verilog-AMS model
 SOCKET is a schematic, which instantiates the DUT and symbols for periferal components.
   Depending on the configuration view, the periferal components may contain schematics of matching networks, etc. or behavioral models.
   DUT (Device Under Test) has multiple configurations of schematics and behavioral models, RTL or structural Verilog digital blocks etc.

The design team of course creates and maintains the DUT, including schematics of analog circuits, and RTL or structural Verilog code for digital circuits.  Behavioral model writers (possibly, but not necessarily the block designers) create and maintain the Verilog-AMS models for analog circuits within the DUT. One or more people create and maintain the TB, including the TB and SOCKET schematic, SOCKET-level periferal schematics and models, and the DM model "shell".

An individual TEST consists of a configuration and DM code.  The DM model includes the module declaration, I/O list, and code which is common to all tests.  Additionally, the DM model uses `include statements to pull in external code for each unique test: digital vectors, analog signal parameters, measurement comparison and pass/fail routines for monitored signals.

A larger number of verification engineers write the custom DM code, run and debug the simulations.

All of the above is similar to digital verification approaches.  I've seen such digital approaches adapted to use Verilog-AMS models and netlists generated from schematics.  But for every one of them, the first step is to take all the models and netlists out of the dfII structure and put them into a traditional digital design hierarchy.  This eliminates the dfII benefits, including multiple configurations from the CHED.  I would prefer to embrace the dfII structure, and keep everything aligned with standard Cadence procedures.

We're finally at the bottom line.

Has anyone created a mixed signal verification methodology like the one I described, which embraces dfII, and are you willing to share it?

Would anyone like to collaborate with me on such a verification methodology?  Collaboration is strictly voluntary, and maybe we can publish a BMAS or CICC paper from our work.

Thanks!

Bob P.

Bob,
   You might want to take a look at http://www.designers-guide.com/docs/cicc06-dgc.pdf, which was published at CICC. This is also what I do for a living now. Transitioning a design team to this methodology is a big job, if you feel you need some help, give us a call.

-Ken

Ken,

Thanks for the reference paper.  Reading it will be my starting point.

Luckily (I hope), I have a clean slate to work with in my design group.  I'm not transitioning them from an existing methodology, but building up from zero.  We don't have much baggage carried over from a digital methodology.  If stuck, I'll keep your professional services in mind.

Thanks,

Bob


Ken Kundert wrote on Dec 4^th, 2006, 7:42am: