|
Design FeaturesFebruary 3, 1997 |
In addition
to representing logical values, simulators need to represent the strengths of
those values.
The problem lies in how a simulator can accomplish this task.
Most of today's digital systems are based on binary logic; that is, logic gates based on two voltage levels and, therefore, two logical values. Some experiments have been performed on tertiary logic, which is based on three voltage levels/logical values and whose tertiary digits are referred to as "trits," but thus far these experiments haven't made any inroads into commercial applications.
The minimum set of logic values required to represent the operation of basic logic functions is 0 and 1, and you can implement a functional logic simulator using only these two values; for example, consider the home-brewed simulator described in an earlier article (Reference 1). However, simulators that support only 0 and 1 values are somewhat limited, and the next step up the ladder is the ability to represent unknown X values (Reference 2). These X values can represent a variety of conditions, such as an uninitialized register or a clash between two devices driving the same wire with opposing values (Figure 1a).
The simulator automatically derives the delays to and from X values from the LH (0 to 1) and HL (1 to 0) delays specified within the component models (Figure 1b). For example, a transition from a 0 to an X at a gate's output assumes that gate's LH delay. The reason for this assumption is that an X in this context is assumed to represent an unknown between a 0 and a 1, so a transition from a 0 to an X actually represents either a 0-to-0 transition or a 0-to-1 transition; only the 0-to-1 transition is of interest in the context of timing relationships. Similarly, an X-to-0 transition assumes the HL delay, a 1-to-X transition assumes the HL delay, and an X-to-1 transition assumes the LH delay.
It's also useful for the simulator to be able to represent high-impedance Z values so that it can simulate tristate devices. Thus, designers of logic simulators tend to regard 0, 1, X, and Z as the minimum logic set required to verify the basic functionality of most digital circuits. You also need some technique to resolve the final value on a wire that is driven by multiple sources. Consider a portion of a circuit that contains a capacitive element combined with a resistive driving element and a strongly driving element (Figure 2).
First, assume that the resistive FET is enabled and the Normal FET is disabled, which means that the node (wire) under consideration will drive to a weak logic 1. Next, assume that the resistive FET is subsequently disabled, which results in the wire's being maintained at an extremely weak logic 1 by the charge on the capacitive element. Now, assume that the normal FET is enabled; it then overpowers the capacitive element and drives the wire with a strong logic zero. Finally, assume that both the resistive and normal FETs are enabled, which means that the normal FET becomes the dominant player and continues to drive the wire with a strong logic 0.
Thus, a simulator needs to represent not only logical values, but also the strengths of those values. The problem lies in how the simulator can accomplish this task.
Cross-product value sets
One approach to choosing a set of logic values is to consider each value as having a number of attributes chosen from independent categories. For example, you may characterize a node's logic state and the "strength" of that state independently. Many logic simulators use the values formed by the cross product of the various value attributes; for example, consider the cross-product value set in Figure 3.
In this example, the forced strength refers to the value of a power-supply terminal, with the underlying assumption that forced signals provide enough sink or source capability to be unaffected by the contributions of any transistors or gates. Assume that the driven strength refers to the output from normal transistor switches and that the weak strength comes from a resistive source, such as a depletion-mode transistor. Finally, the charged strength refers to the charge stored on a capacitive element and is generally assumed to remain unchanged until some other part of the network overrides the charge, although some simulators allow the user to specify decay times on these values.
Unfortunately, there's a significant amount of confusion in this area in that there are few if any standards with regard to the terminology. Thus, some simulators refer to states as "levels," or "values"; some refer to the forced strength as supply; some refer to the driven strength as strong, forced, or active; and some refer to the weak strength as resistive or passive. Adding to the confusion, some simulators regard the high-impedance Z value as a state (or level), and others regard it as a strength. Finally, some simulators include the concept of an undefined U state that differentiates between cases such as uninitialized registers and the X values generated by clashes between opposing values.
However, the main problem with simulators based on the cross-product technique is that they can be pessimistic in certain cases, because they tend to regard the various cross-product values as forming a regimented hierarchy (Figure 4).
At first glance, this hierarchy may appear perfectly reasonable. You would certainly expect a DH (driving high) to override a WL (weak low). However, the situation may be less than straightforward when you start to consider cases such as transistors whose control inputs are presented with X values (Figure 5).
When analyzing this node, the simulator incrementally analyzes each of the driving terminals. Assume that both transistors are initially disabled and that the capacitive element is originally presenting the node with a CL value from a previous evaluation. Assume also that the current evaluation cycle is triggered by a 0 presented to the control input of the resistive FET at the same time that an X is presented to the control input of the normal FET. Finally, assume that the simulator evaluates the driving terminals starting with the capacitive element, followed by the normal FET, followed by the resistive FET.
The evaluation cycle commences when the simulator looks at the capacitive element and tentatively assigns a value of CL (charged low) to the node. Next, the simulator considers the normal FET, which, due to the X on the FET's control input, either drives a high-impedance or a DH (driving high) onto the node. In this case, the simulator determines that the state of the normal FET's output terminal is some flavor of an X, but the strength of this signal is somewhat uncertain. However, assigning a weak or charged strength to the signal is inappropriate, because these strengths understate the case in which the output from this transistor could be a strong logic 1. The only reasonable course of action, therefore, is for the simulator to assign a DX (driving-unknown) value to the node. Finally, the simulator considers the resistive FET, which clearly presents a WH (weak-high) value to the node, but the simulator doesn't remember that the DX value is the result of the ambiguity between a Z and a DH, so its only course of action is to leave the node set to a DX value.
Although this final DX value is not wrong per se, it is certainly more pessimistic than necessary. Of greater concern is that, depending on the strength of the simulator's algorithms, varying the order of the terminal evaluations may return a different result. That is, if the simulator evaluates the resistive FET before the normal FET, the simulator would assign a tentative value of WH (weak high) to the node. Then, when the simulator subsequently evaluates the normal FET, its algorithms may be sufficiently powerful to recognize the fact that combining a definite WH with either a Z or a DH means that the final value assigned to the node should be some flavor of a logic 1.
In fact, simulators that use cross-product sets usually attempt to perform their incremental analysis in an order that would yield a reasonable answer on the example circuit in Figure 5, but it is possible to confound this type of simulator with more complex circuits containing X values. It is certainly possible to tweak the algorithms to build effective simulators using cross-product value sets, but such simulators are prone to make pessimistic evaluations on circuits containing X values, which can cause difficulty in initializing the circuits and can lead to the overpropagation (flooding) of X values through the circuit.
Interval-value sets
The separation of the notions of strength and state causes the difficulties with the cross-product concept. Once a node is set to an unknown X value of some strength, it cannot return to a "normal" value unless a stronger signal overpowers it. Thus, if a node is tentatively set to the strongest X value, it remains at that value for the rest of the computation. As illustrated in the previous example, this approach leads to conservative predictions due to the lack of suitable alternatives. Specifically, our "virtual simulator" was obliged to pick the highest strength to be on the safe side, because there was no value available to reflect the fact that the Z component that contributed to the intermediate X value was of very low strength and, hence, that later network components might override this component.
The concept of intervals provides the basis for an alternative approach to constructing a set of possible node values. First, define a set of prime values representing a range of strengths and 0 or 1 states in which each prime value encapsulates both strength and state information. For example, you might begin with the eight non-X values derived in Figure 3, along with a Z value (Figure 6).
In this case, derived interval values that do not cross or touch the Z centerline correspond to a valid logic state, and intervals above and below the line represent some flavor of a logic 1 or logic 0, respectively. By comparison, intervals that do cross the centerline represent X values, where the X values in the cross-product set discussed earlier correspond to intervals with equal strengths at their end points. The end result is that X values in the interval-value set represent the ambiguity about which base values best represent the true node value. As you will see, this approach is far more satisfactory than thinking of X as an independent logic state.
When an interval-value simulator merges two node values, it takes into account that some prime values overpower other prime values, and then it chooses the smallest interval that covers all of the possible remaining node values. However, unlike the cross-product technique, the interval-value set can represent X values without losing track of the strengths of the signals that lead to those values. To illustrate this point, consider again the problem in Figure 5.When the interval-value simulator compares the CL from the capacitive element with the ambiguity between the Z and DH values arising from the normal FET, the resulting intermediate value is the interval encompassing the range between CL and DH. When the WH contribution from the resistive FET is subsequently discovered, the simulator understands that the prime WH value from the resistive FET overpowers the weaker CL component from the capacitive element, so the simulator can narrow this range to the interval encompassing WH and DH. This approach corresponds to a logic-high signal, which is a sensible answer. Furthermore, merging the contributions from the individual terminals driving the node is both commutative and associative, which means that the simulator can process the network in any order without affecting the final value that is assigned to the node. Finally, take note that the interval-value set is not particularly CPU-intensive, because you can perform the intermediate evaluations using a look-up-table approach.
Cosimulation between logic-value sets
Designers of digital simulators face disparate considerations when it comes to specifying the logic value set they intend to implement. If the set is too small, it may not be possible to describe precisely the actual node value using one of the available values, which means that the simulator has to choose an approximation. If this approximation involves some variant of an unknown X, then the approximation may cause effects beyond those imposed by the network under consideration, thereby resulting in conservative or pessimistic evaluations. By comparison, if the logic value set is too large, it becomes difficult to determine whether the simulator's predictions are correct, and there may also be problems in displaying the results in a form that is meaningful to the user. The cosimulation of two or more simulators, each of which has its own way of representing the world in the form of its logic-value set, exacerbates these problems.
The two most popular hardware-description languages (HDLs) in use are VHDL and Verilog. VHDL lets you create your own data types and logic sets, and you can also define the resolution function to be used. A resolution function controls how conflicts between signals of different values are to be resolved. By comparison, Verilog users must choose between a compact signal set comprising 0, 1, X, and Z or an expanded set in which signals include both the logic value and associated strength information. This expanded interval-value set comprises 15 prime states. In addition to the Z state, there are seven flavors each of logic high and low, which, in descending order of strength are: supply drive, strong drive, pull drive, large capacitive, medium capacitive, weak drive, and small capacitive.
In the not-so-distant past, designers tended to purchase and stick to a simulator based on the HDL of their choice. However, there is an increasing trend toward the codevelopment of products across different companies, and projects spanning multiple sites and multiple companies must be able to accommodate existing investments in, and individual preferences for, multiple languages. Thus, there is an increasing requirement for simulation environments that can support the cosimulation of VHDL and Verilog, which means that you must define the way in which signals from a module in one domain will be coerced, or mapped, into signals that the other domain understands.
Although VHDL allows users to define their own data types, most cosimulation environments support mapping only at the VHDL side of the simulator-to-simulator interface using signals based on the "std_logic" data types as referenced in the IEEE-1164 standard. This standard defines "std_logic" as having nine values comprising "U," "X," "0," "1," "Z," "W," "L," "H," and "-," where "U" represents an uninitialized unknown, "W" represents a weak unknown, "L" represents a weak "0," "H" represents a weak "1," and "-" represents "don't care." The unknown U value is particularly useful for distinguishing cases such as uninitialized registers from X values caused by clashes between multiple devices driving opposing signals onto a common wire. Also note that the "don't-care" value is of little interest to a simulator but is instead predominantly intended for use by synthesis utilities. But the problem remains that you have to define some technique for mapping between the extended Verilog and the VHDL "std_logic" value sets (Figure 7).
As you can see, there is more to digital simulation than meets the eye, especially when it comes to representing both logic values and strengths of signals. (Note that the mapping shown in Figure 7 was proposed in the paper entitled "Standard Verilog-VHDL Interoperability," which was presented at the Spring 1994 VHDL International Users Forum (VIUF) conference by Victor Berman of Cadence Design Systems Inc and which was subsequently passed to the IEEE-PAR-1076.5 committee for its consideration for a VHDL-Verilog interoperability standard.)
Author's note
Following my articles relating to logic simulation, a number of readers e-mailed me asking where they can acquire a simulator (preferably free) to play with, so here are a few suggestions:
Author's biography
Clive "Max" Maxfield is a member of the
technical staff at Intergraph Computer Systems (Huntsville, AL), (800) 763-0242,
where he gets to play with the company's high-performance graphics workstations.
In addition to numerous technical articles and papers, Maxfield is also the
author of Bebop to the Boolean Boogie: An Unconventional Guide to Electronics
(ISBN 1-878707-22-1). To order, phone (800) 247-6553. You can reach Maxfield via
e-mail at crmaxfie@ingr.com.
| EDN Access | Feedback | Subscribe to EDN | Table of Contents |