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.