VHDL simulation
8.1 Event-driven simulation
8.2 Simulation of VHDL models 182
8.3 Simulation modelling issues 185
8.4 File operations 186
VHDL is a language for describing digital systems. To verify that a model is correct, a simulator may be used to animate the model. In the first section of this chapter, the principles of digital simulation are described. The specifics of VHDL simulation and techniques to improve simulation efficiency are then discussed. Finally, file handling is described.
8.1 Event-driven simulation
VHDL is a language for describing digital systems; therefore it should be no surprise that standard event-driven logic simulation algorithms are used. Such algorithms are most easily described in terms of the simulation of structural models. Behavioural models are evaluated in much the same way, where a process can be thought of as an element.
The objective of event-driven simulation is to minimize the work done by the simulator. Therefore the state of the circuit is evaluated only when a change occurs in the circuit. It is possible to predict when the output of an element might change because we know that such a change can occur only after an input changes. If we monitor only the inputs to elements, we can know only that an output might change;
the logic function of the element determines whether or not a change actually occurs. As we also know the delays through the element, we know when the output might change. Thus an element needs to be evaluated only when it is known that its output might change but not otherwise. Nevertheless, even by predicting a possible change, it is necessary to re-evaluate elements only when the possible changes
178
Event-driven simulation 179
Current time tn
Events
tn+1
tn+2
tn+3
Figure 8.1 Event list.
occur. By following the possible events through the circuit we can minimize the computation done by the simulator. Only elements that change need to be evaluated;
anything that is not changing is ignored.
The delays through elements are defined in terms of integer times. The units of time might be nanoseconds or picoseconds. As the time is incremented in discrete intervals, it is likely that, for any reasonably large circuit, more than one element will be evaluated at any one time. Equally, there may be times at which no elements are due for evaluation.
This implies a form of time step control. As each element is evaluated, any change in its output will cause inputs to further elements to change, and hence the outputs of those elements may subsequently change. Clearly it is necessary to maintain a list of which signals change and when. An event is therefore a new value of a signal, together with the time at which the signal changes. If the event list is ordered in time, it should be easy to add new events at the correct place in the future.
A suitable data structure for the event list is shown in Figure 8.1. When an event is predicted, it is added to the list of events at the predicted time. When an event is processed it is removed from the list. When all the events at a particular time have been processed, that time can be removed.
This list manipulation is relatively easy to do in a block-structured programming language, such as C, although adding new times to the middle of a list can be awkward.
An element can be scheduled for processing when its inputs are known to change.
For example, consider an AND gate with a 4 ns delay. When the signal at one input changes it can be predicted whether the signal at the output changes depending on the state of the other inputs of the gate. If the output does change, the output event can be scheduled 4 ns later. The algorithm can be written as shown in pseudo-C in Figure 8.2.
An event is scheduled only if the new value is different from the value that has pre-viously been scheduled for that signal. If two or more events occur on input signals to
180 VHDL simulation
Figure 8.2 Single-pass event scheduler.
an element, more than one event may be scheduled for an output signal. It is thus important to know that the new value is different not merely from the present value but also from a value that might already be scheduled to be set in the future. This algorithm therefore has a disadvantage as it stands, because an element is evaluated whenever an event occurs at an input. It is quite possible that two events might be scheduled for the same gate at the same time. This could lead to a zero-width spike being scheduled one delay later. Even worse, if the delays for rising and falling output differ, the presence or absence of an output pulse would depend on the order in which the input events were processed.
In VHDL terminology, an input change that might lead to an output change is known as a transaction. Only if an output changes is this transaction scheduled as an event.
If zero-width pulses are to be suppressed, they can be considered as a special case of the inertial delay model. The previous algorithm can be extended to include pulse can-cellation if a pulse is less than the permitted minimum width, as shown in Figure 8.3.
This model assumes two-state logic. If an event is predicted at a time less than the inertial delay after the previous event for that node, this new event is not set and the previous event is also removed. If more than two-state logic is used, the meaning of an inertial delay and hence of a cancelled event must be thought about carefully. In order to cancel an event, it is necessary to search through the event lists. Event cancellation is therefore best avoided, if possible.
One further problem exists with the selective trace algorithm. A gate with a zero delay would cause an event to be scheduled at the current simulation time if an input changes.
Thus, while events are being processed at the current time, new events are being added to the end of the event list. There is clearly the potential here for an infinite loop to be generated, where the simulation never advances beyond the current simulation time. In practice, the only way to avoid this problem is to count the number of events at a time point, and if they exceed some arbitrary limit to terminate the simulation.
We have already noted that the presence or absence of zero-width pulses can be dependent upon the order of evaluation of events at a time point. Consider the circuit of Figure 8.4. If both gates have a zero delay and the input changes from 0 to 1 as shown, a zero-width pulse may be generated.
for (i = each event at current_time) {
update_node(i);
for (j = each gate on the fanout list of i) {
update input values of j;
evaluate(j);
if (new_value(j) ≠ last_scheduled_value(j) ) { schedule new_value(j) at
(current_time + delay(j) );
last_scheduled_value(j) = new_value(j);
} } }
Event-driven simulation 181
0 1
1 0
0 1 0
Figure 8.4 Circuit with zero delays.
Figure 8.3 Single-pass event scheduler with inertial delay cancellation.
If the AND gate is evaluated first, both inputs will appear to be at logic 1, so the out-put will become 1. The inverter is evaluated next, causing the other AND inout-put to change. The AND gate is evaluated again and the output changes back to 0. On the other hand, if the inverter is evaluated first, both inputs to the AND gate will appear to change simultaneously when it is evaluated, and no pulse is generated. Although it is obvious here that the inverter should be evaluated first, this is not always the case and we must assume that the order of evaluation of gates is effectively arbitrary.
This arbitrariness can be avoided by using delta delays. A delta delay can be thought of an infinitesimal unit of time, as shown in Figure 8.5. Zero delays are modelled as delta delays, so that any events generated at the current time with zero delays are scheduled to occur one delta delay later. In the above example, both gates would be evaluated at the current time, and their outputs would be scheduled one delta delay later. The AND gate would then be evaluated again at the current time plus one delta.
Thus a circuit is always evaluated in exactly the same way; in this case we always get
for (i = each event at current_time) {
update_node(i);
for (j = each gate on the fanout list of i) {
update input values of j;
evaluate(j);
if (new_value(j) ≠ last_scheduled_value(j) ) {
schedule_time = current_time + delay(j);
if (schedule_time ≤ last_scheduled_time(j) + inertial_delay(j)) {
cancel_event at last_scheduled_time(j);
} else {
schedule new_value(j) at schedule_time;
}
last_scheduled_value(j) = new_value(j);
last_scheduled_time(j) = schedule_time;
} } }
182 VHDL simulation
Current time tn
Events
tn+δ
tn+2δ
tn+1
Delta times
Next time
Figure 8.5 Event list with delta delays.
a zero-width pulse generated. Moreover, any simulator that implements delta delays will evaluate the same circuit in the same way, so we can directly compare simulators.
It should be noted, of course, that the use of delta delays causes new delta times to be inserted into the event list, but it is not possible for a series of delta times to add up to a real simulation time step.