Stories of an AMS Verification Dude: Putting Stuff Together
by Martin Vlach, Mentor Graphics
I don’t know how this came about, but the other day I got hired to do something called AMS Verification. It seems that there is this chip design that combines digital and analog stuff, and I was asked to make sure that all of it works when it’s put together and that it does what it was meant to do when they got going in the first place.
Not knowing any better, I guess I’ll start by hoping that all of the pieces they handed to me were done just right as far as those designer dudes understood when they got handed their jobs. So here’s what I’m thinking: The dudes may be real good in designing, but they are humans too and so they probably missed some points, and misunderstood some others, and when it’s all put together, Murphy says that things will go wrong. Besides, those analog and digital dudes don’t talk to each other anyway.
I think about it some, and come to the conclusion that I have two problems to worry about: Did they hook it up right? Do the pieces play well together?
Not knowing anything, I first go to the digital folks, and ask them how I should verify this.
No problem: Do some formal, set up a testbench with some constrained random, slap in a few assertions, simulate it, if it’s too big put it on an emulator, and check your coverage. You’ll be done in no time. Easy peasy. I find out pretty soon though that this ain’t gonna work so good with those SPICE netlists that I got handed by the analog people.
OK, I’ll go ask them then.
No problem: In your schematic, rustle up some power supplies and ground, toss in a few sine sources here and there to make it wiggle, generate the SPICE netlist, do some transient and frequency runs, and look at the waveforms to see if they’re any good. Hmmm. I don’t think this will work with those RTL designs I got from the digital folks. Anyway, what does it mean when they say that “waveforms look good”? I mean, I know what I think of when I think of curves and models, but it doesn’t seem to fit this job.
But I guess I’m the mixed signal expert here, so I’ll have to figure it out on my own. And I did. I wrote a big tome about it and handed it to my boss. She muttered something about “better English,” but she said that since I done such a good job, she’ll fix it up for me. So here’s how Chapter 1 came out:
Mixed Abstraction—Mixed Signal Design Descriptions
There are many decisions to be made before embarking on an implementation of a verification environment for a mixed signal IC design project. This chapter focuses on issues in setting up mixed signal designs in preparation for simulation. Let’s assume that some decisions have already been made: The environment will use SystemVerilog for testbenches, and the preferred HDL language family is Verilog.
Before proceeding, let us recall some definitions from a previously published Verification Horizons article:
- Analog abstraction: a representation of a real-world signal that retains the sense of the continuous range of the signal level. In this article, only SPICE representations are considered.
- Digital abstraction: an abstraction of a real-world signal by discrete bands of analog levels, rather than by a continuous range, typically 0 and 1.
- Functionally analog signal: a real-world signal that must be represented by an analog abstraction to usefully reason about it. It cannot be represented using digital abstraction and still retain the information content.
- Functionally digital signal: a real-life signal that can usefully be represented by a digital abstraction. It can also be represented by an analog abstraction from which the digital abstraction can be derived based on the discrete bands of analog levels.
When it comes to mixed signal designs, the subsystems are typically described as:
- RTL for the digital portion.
- SPICE schematics for the analog portion.
The RTL is described in SystemVerilog (a proper superset of Verilog), and for simplicity let’s assume that the ports are scalar nets with type logic. At the RTL design level, the concepts of supplies and ground are not relevant – they are left for a later step in the process. All signals are functionally digital signals at the digital abstraction level.
For analog schematics, the situation is less straightforward. There are analog data pins of course, but the analog portion will already have some control logic that configures the analog data handling. This logic is described on the schematic at a transistor level, whether it was already synthesized, or designed “by hand” as custom IC designers often do. In analog, power and ground connections cannot be abstracted away, since they provide both the correct voltages and power (current) that form an integral part of the operation of the circuit. The schematic will thus show three different kinds of pins:
- Analog signal pins that carry the functionally analog signals that are being processed by the component.
- Digital control pins. Although they carry functionally digital signals, these signals are represented at the analog abstraction level.
- Power supply and ground pins.
At this point of the discussion, we are going to simplify further, ignoring issues related to the power supply and ground pins, and assume that some magic happens later in the IC design process to “get it right.”
Given this introduction, let’s state a simple design and verification problem: Connect the subsystems and verify that the right ports from the RTL have been connected to the right pins on the schematic.
Coming from the digital world, one might think that this would be a pretty good candidate for some kind of formal or static verification. While this sounds appealing in principle, there are no tools today that can be used, and so we are left with verification by simulation of the connected RTL and schematic (i.e., SPICE) designs.
Let’s examine how this can be done. Whether the design that we are working on is a full chip, a subsystem, or an IP block, let’s call the desired connectivity the top level netlist. The top level netlist must be specified somewhere, and depending on which team (digital or analog) is in charge, it is done in one of two ways:
- As a digital netlist, in a digital-centric design and verification flow.
- As an analog schematic, in an analog-centric flow.
As an aside, there are some design teams that use a proprietary format, for example JSON, for the top level connectivity from which other descriptions are derived, but this is an exception and not a common industry practice. The connectivity must accomplish the following tasks:
- Connect RTL ports together for shuttling around digital signals in the digital abstraction (logic).
- Connect schematic pins together, thus forming equipotential analog nodes in the analog abstraction (SPICE).
- Finally, connect RTL ports to the appropriate digital control pins of the schematic. Both of these are functionally digital signals (ports and pins), but from the RTL side they come in the digital abstraction, and on the analog side they are described in the analog abstraction.
It turns out that it is useful to consider all of this as two separate (but of course related) problems:
- How to convert from one abstraction to another (digital vs. analog).
- How to describe connectivity without focusing on the abstraction level.
The following two sections describe these two problems and their accepted industry solutions.
The problem of converting between two different types of abstraction has been solved by adding a special class of model to the design description. Unlike most models that represent an actual physical “thing” that will eventually be manufactured, these models only perform abstraction conversion and so are meaningful only during mixed abstraction simulation.
To be absolutely clear: a conversion between a digital abstraction of a signal and the analog abstraction of the same signal is not a model of an actual physical analogto- digital converter (ADC) or a digital-to-analog converter (DAC).
These nonphysical abstraction conversion models have been variously called by names such as hypermodels (the Saber simulator), connect modules (Verilog-AMS), boundary elements (Questa ADMS), just plain “converters”, and surely many other terms. In this article, the term boundary element will be used.
Boundary elements convert between the logic value on the one hand (0/1/X/Z) and the appropriate voltage/current levels on the other. Because (in this example) they are used to convert between signals modeled in discrete time (digital simulators) and continuous time (analog, SPICE simulators), they also have to take into account that SPICE algorithms do not usually like discontinuous changes. Therefore, they must convert the discrete time discontinuous signal transition (e.g. 0 -> 1) into a continuous signal that changes over a period of time. In the other direction, when converting from the continuous time analog abstraction to discrete time digital, they must detect a gradual change on the analog side and create an event for the digital event-driven engine.
At its most basic conceptual level, a boundary element has two connections: one for a port from the RTL description and one for a pin on the schematic. In real-life implementations, things of course are never so simple, and boundary elements also usually connect to the supply and ground on the analog side as a way to accurately model voltage levels.
Of all the standard languages, only Verilog-AMS has approached the problem of automatically inserting boundary elements (called connect modules in that standard). However, all modern simulators insert boundary elements automatically at appropriate places, based on rules that are specified as part of the design, often using vendor-specific methods.
Now that we know we can use boundary elements to convert abstraction, let’s turn our attention to specifying connectivity.
In the analog-centric case, schematic capture systems represent connectivity using lines on a drawing surface, and do not pay much attention to what those lines represent. At the level of the schematic, those details are abstracted away. It all depends on what happens next. Sometimes those lines all become a single “node” in a “SPICE netlist” and represent an equipotential region, where all currents flowing into it must sum to zero (KCL/ KVL). Sometimes those lines (especially in the early days of electronics) represent a physical wire on a board. Sometimes they represent a complicated path that must be created on a chip. Sometimes they can be interpreted as a logic signal path from here to there.
But in the context of mixed-signal and mixed-abstraction verification, we want to consider how those lines are represented in a text file that will be used as input to a simulator. The conversion from the schematic (database) to the textual form is achieved by so-called netlisters, and the problem we have stated for ourselves is what should be the format of the resulting text file.
In the digital-centric case, the top level netlist is created manually, but the question of what should be the format of that netlist is the same as the question of what should be the format of the output of a netlister.
It turns out that the common schematic concept of “I need to connect pins, and I don’t know yet what abstraction will be used” has taken a long time to represent unambiguously in text form. Simulators have always considered connecting objects with a particular semantic: logic ports in digital simulators and electrical pins in SPICE, and the problem of connecting incompatible abstractions did not arise until mixed-signal and mixed-abstraction simulation appeared.
For a long time such abstraction-less connectivity has been approximated by using either the Verilog wire or a SPICE node—both of which, strictly speaking, have an abstraction attached to them, with resulting confusion in applying conversion rules. Using another perspective, the abstraction-less connectivity has been banned, particularly in VHDL and VHDL-AMS, which require top level netlists to be strongly typed.
Recently, the SystemVerilog IEEE 1800-2012 standard defined an abstraction-less connectivity concept, allowing it to be expressed in terms of interconnect objects. However, this standard does not yet allow mixing abstraction levels; all of the nets that are connected using interconnect must use the same abstraction.
Let’s return to the discussion of how to make the textual top level netlist, either manually (in digital-centric flows) or by a netlister from a schematic database (in analog-centric flows). What are the options?
- Use wire in Verilog.
- Use interconnect in SystemVerilog 2012.
- Use a node in a SPICE description.
- Use one of the mixed signal languages, such as Verilog-AMS, and explicitly pick whether digital (wire) or analog (electrical) pins/ports are being connected.
In all of these cases the problem of mixed abstraction is yet to be satisfactorily solved, although Verilog-AMS comes closest. The problem with Verilog-AMS is that it is based on Verilog-2005, and mixing it with SystemVerilog is nonstandard.
It appears that today, the best practice is to:
- Use Verilog wire to approximate abstraction-less connectivity because it has been used the longest and fits well with back-end flows.
- Keep an eye out on the status of the implementation of the SystemVerilog interconnect because that is the latest standard • Use vendor-specific means of inserting boundary elements for abstraction conversion.
It’s me again, the AMS Verification Dude. Well, that was fancy-schmancy. I don’t know how about you, but I don’t see why that is called “better English.” All I was trying to say is that it ain’t all that easy. I looked around a lot, but neither the digital nor the analog dudes got it quite right, even though they were able to put something together. There’s still a lot of details to worry about, and lots of people are doing things differently, so it looks like we need a better standard to really solve this problem so I don’t have to come up with my own way of doing things. This’ll make my life so much easier that I even signed up to work on this Accellera SystemVerilog-AMS committee, and I for one will tell them what I think. Why don’t you come and join us?