We represent a model using an event graph. Event graphs provide a representation for the static simulation algorithm to work on, and transformations on event graphs can be used to improve simulation performance.
An event graph partitions the model into events, represented by vertices, and uses directed edges to represent relationships between events. We define an event to be the largest unit of a program that will execute atomically during simulation, which corresponds to the code that would be executed during one step of an event-driven simulation. The semantics of the original language determines precisely how the boundaries between events are determined from the original source. In Verilog, events have boundaries at the start and finish of always and initial blocks, at explicit delays, and at statements that wait on signals (such as @ and wait). Each vertex has associated with it executable code from the Verilog program.
An edge represents a causal relationship between one event and
another. Edges can take two forms: sensitizing and triggering. Event sensitizes a following event
whenever
they are separated by an @ or wait statement. The
execution of event
makes
sensitive;
can then be
triggered by other events.
Triggering actions cause events to be scheduled for execution. There
are three kinds of trigger actions: control flow, data flow, and
delays. can trigger
:
Note that not all control flow is represented by control flow edges. Only control flow that crosses an event boundary is represented in this way. All other control flow is contained within a single event.
A Verilog program is represented by
an event graph , where
An example of an event graph for a small Verilog program is shown in Figure 1.
