It’s all about communication. When I talk to people in the EDA community, we often bandy words around in the comfort that we all know what they mean — and that they mean the same thing to each of us. But do they? You know — what’s a model? A system? Tomato? Tomahto?
I have been thinking a lot lately about hardware description languages — VHDL, VHDL-AMS, Verilog-AMS, SystemVerilog — and how we use words to describe concepts about AMS designs. Today, I want to write about my favorite multi-meaning word, signal, and I want to share how thinking about it in very precise ways led me to an unexpected (well, to me) realization. This all came about while discussing with my colleagues the idea of “connecting analog to digital.” We stumbled over the nuance of “signal” when grappling over such questions as, when are connect modules (in the Verilog-AMS sense) required in mixed-signal simulation, how do event driven mixed signal (EDMS) models of AMS hardware enter into the mix, and what do “analog” and “digital” mean — to the IC designer community, and to the AMS simulation community.
Let me outline some terminology that I am advocating:
Signal (Meaning 1): as used when talking about HDL concepts: an informal term, usually meaning a variable (SystemVerilog), net (SystemVerilog), or terminal (VHDL-AMS). The context where it is used may imply further restrictions on allowed types [Adapted from IEEE 1800 SystemVerilog Standard].
Signal (Meaning 2): as used when talking about electric circuits: transmitted energy that can carry information [Wikipedia article on clock signal]. To disambiguate, the phrase real-world signal will be used in this article.
Analog abstraction: a representation of a real-world signal that retains the sense of the continuous range of the signal level [Wikipedia]. Many different representations are possible, including conservative, signal-flow, and event-driven. Event-driven signals may be represented by a single value of type real (often referred to as Real Number Modeling, especially when using the Verilog-AMS concept of wreal) or by a structure (record) that may contain many pieces of information (including real, integer, and enums). Event-driven signals are often thought of as piecewise constant, but this is not a fundamental requirement. A piecewise linear event-driven signal may, for example, be represented by a pair of real numbers (e.g. value and slope). Analog abstraction is applicable to all forms of energy (including electrical, mechanical, and thermal).
Digital abstraction: an abstraction of a real-world signal described as discrete bands of analog levels, rather than by a continuous range. All levels within a band represent the same signal state. In most cases the number of these states is two, and they are represented by two voltage bands: one near a reference value (typically termed as ground or zero volts) and a value near the supply voltage, corresponding to the false (“0″) and true (“1″) values of the Boolean domain respectively [Adapted from Wikipedia]. Waveforms of signals in the digital abstraction are always of necessity discontinuous — they are in fact piecewise constant. For practical purposes, digital abstraction is only applied to the electrical form of energy in EDA software.
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 meaningful information.
Functionally digital signal: a real-world 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.
As an example of a functionally analog signal, think of the output signal of a microphone. An example of a functionally digital signal could be the control of a digitally controlled microphone preamplifier. Real designers of course do not say “functionally analog input,” they will simply say “analog input”.
But let’s now imagine an AMS IP block of that preamplifier that has both a SPICE implementation and an event-driven verification model written for it. If you talk to many people from the AMS simulation community, they will tend to say that the SPICE model uses analog signals and that the event-driven model (to be simulated in a digital simulator) uses digital signals. Ooops. Very different meanings.
Let’s look at an example. In the following figure, “A” and “D” are, respectively, functionally analog and functionally digital signals (what a designer would call analog and digital). It seems pretty obvious that you would not want to connect a functionally analog to a functionally digital signal, or vice versa, as indicated by the green check mark and the red cross.
Now if we use the SPICE implementation for the component on the left, and an Event-Driven (often Real Number) model on the right, we’ll have to insert what are known as connect modules to make the SPICE and the digital simulator understand each other (the green boxes).
Notice that the connect modules are arranged to create a connection between a signal represented by an electrical terminal on the left (with voltage and current both represented) and either a SystemVerilog net of type real (or wreal in Verilog-AMS) or a net of type logic on the right (depending on whether the signal is functionally analog or functionally digital).
In the model on the left, written using event-driven modeling style, the type of signal is chosen according to whether it functions as an analog or a digital signal (functionally analog or functionally digital). We should not blindly convert a SPICE electrical signal to an event-driven equivalent of real (or wreal), since such a modeling style makes no sense.
So, if you ever catch yourself trying to connect a net of type real to a net of type logic, re-examine your model, or your design. One or the other does not make sense.