Donald E. Thomas - The Verilog Hardware Description Language, Fifth Edition (798541), страница 42
Текст из файла (страница 42)
Assume each gate has d units of delay. At the initial point of ourexample, the logic gates have the stable values shown in Figure 8.1a. An event occurson line A at time t, changing it to logic 1 as shown by the arrow in Figure 8.1b. Attime t, gate g1 is evaluated to see if there is a change on its output B. Since B willchange to a 0, this event is scheduled for a gate delay of d time units in the future.At time t+d, gate g1’s output (B) will be set to 0 as indicated by the arrow inFigure 8.1c and this new value will be propagated to the gates on g1’s fanout.
Sinceg1’s output is connected to gates g2 and g3, each of these gate models are evaluated tosee if there will be an event on their outputs due to the event on B. As can be seen,only gate g2 (output C) will change. This event (C = 1) will be scheduled to change dmore time units in the future. Figure 8.1d shows the results after this event at timet+2d.
At this point, the new value on C will be propagated to the gates on the fanoutof gate g2. These gates will be evaluated and new events will be scheduled, and so on.8.2.2 Towards a More General ModelClearly, a gate level event-driven simulator needs to keep track of the output values ofall the gate instances, the future times at which new events will occur, and a fanout listfor each of the gate instances in the simulation model. The events are stored in a listof event lists. The first list is ordered by times in the future. For each future time, there216The Verilog Hardware Description Languageis a list of events; all events for a specific time are kept together.
A simulator schedulerkeeps track of the new events occurring and maintains the event list. The schedulercan schedule an event at a future time by inserting the event into the event list. Thescheduler can also unschedule an event by removing it from the list.To this point, we have defined an event to be a change of a value at a specified time.From here on, we will distinguish between two types of events: update events, andevaluation events. An update event causes a value to be updated at a specified time. Anevaluation event causes a gate (or as we will see later, a behavioral model) to be evaluated, possibly producing a new output.
Indeed, update events cause evaluation events,and evaluation events may cause update events.Figure 8.2 illustrates the interconnection of the major elements of an event-drivensimulator. The simulation scheduler is shown here as being the major actor in the system. Each of the arrows connecting to it has a label attached describing the actionstaken by the scheduler. From the last section, we remember that current update events(new values) are removed from the event list and gate output values are updated.These update events cause the scheduler to look at the fanout list and determinewhich gates need to be evaluated.
These gates are evaluated and any resulting outputchanges will cause an update event to be scheduled, possibly for a future time.Figure 8.3 shows an algorithm specification for a simulator scheduler. Here we seethe typical flow of an event-driven simulator. Each iteration around the outer (while)loop is called a simulation cycle.
Since the event lists are maintained in time order, it iseasy to find the next time and the events to execute at that time; they are first in thelist. If there are no more events for the current time, currentTime is updated to thatof the next chronological event. All the events for the currentTime are removed fromthe event list.
These are then selected for processing in an arbitrary order by the “Foreach” statement.Advanced Timing217If the event selected is an update event, the assignment is made and the fanout listis followed, building a list of gates to evaluate. These gates are evaluated and anyresulting output changes are scheduled as update events. If there are behaviors on thefanout, evaluation events is scheduled for them. If the event selected is an evaluationevent, the gate or behavioral model is executed. Any output change causes an updateevent for the output. Note that the new update event may be for the current time(e.g., a gate of zero delay was executed).
This event is still inserted into the event listand will be removed at the next cycle of the outer loop. Thus, there may be severalsimulation cycles at the current time.Let’s follow this simulation algorithm, seeing how the event list develops over time.Figure 8.4a shows the initial event list for the example of Figure 8.1. The unprocessedentries in the list are shown in bold, and the processed (old) entries are shown in grayto illustrate the progression of time.
(In a simulator, the processed entries would beremoved from the list.) Specifically, when update event A = 1 is removed from the list,gate g1 evaluated. Since its output changes, an update for B = 0 is scheduled for t+d.This event is inserted into the event list as shown in Figure 8.4b. The next iteration ofthe simulation cycle is started and time is updated to t+d. At that time, update eventB = 0 is executed causing gates g2 and g3 to be evaluated. Only gate g2 changes, so anupdate event is scheduled for C = 1 at time t+2d as shown in Figure 8.4c. In the nextsimulation cycle update event C = 1 is executed.The discussion so far has centered around simulating gate level simulation modelsexhibiting the gate level timing model.
That is, when an event occurs on a gate output, all other gates on the fanout of that gate are evaluated to see if their outputs218The Verilog Hardware Description Languagechange. The next section will extend our understanding of a simulator to be able tohandle behavioral models.8.2.3 Scheduling Behavioral ModelsBehavioral models in Verilog follow the procedural timing model. Thus, these simulation models are sensitive only to a subset of their inputs, and these sensitivities maychange over the execution of the model. In this section we will consider the variousaspects of simulating behavior models, including handling fanout lists, and registerupdates.Consider Example 8.4, a behavioral modelof a master-slave latch.
The operation of thelatch is dependent on the two clock phasesphi1 and phi2. First the latch waits for thepositive edge of phi1. When this occurs, thevalue of d is saved internally and then thealways waits for the positive edge of phi2.When it occurs, the output q is set to the qInternal value and the always loop repeats.module twoPhiLatch(inputphi1, phi2,output reg q,inputd);regqInternal;always begin@ (posedge phi1)qInternal = d;@ (posedge phi2)q = qInternal;endendmoduleThe important point to realize is that overthe execution of this behavioral model, it isalternately sensitive to the positive edges ofphi1 and phi2, and is never sensitive to inputd. A behavioral model has a sensitivity list — alist that specifies which of its inputs the always Example 8.4 A Master-Slave Latchor initial statement is currently sensitive to.Thus, we can examine any always or initial statement and determine, as a function oftime, what update events can cause it to be evaluated.Advanced Timing219To simulate elements using the procedural timing model within the framework ofSection 8.2.2, we need to be able to alter the fanout lists as the execution of the simulation models proceed.
That is, because the sensitivity lists change, the fanout listsneed to change. For instance, at the start of simulation in Example 8.4, the controlevent (“@”) is executed and the process statement (i.e., the always) containing thecontrol event is put on the fanout list of phi1. When there is an update event on phi1,an evaluation event for the process is scheduled.
When this evaluation event is executed, the process determines if there is a positive edge. If there isn’t, then the alwaysblock continues waiting — the fanout lists are not changed. If there is, the process isremoved from the fanout list of phi1, and the behavioral statements resume their execution (in this case with “qInternal = d;”). When the next control event is executed,the process is placed on the fanout list of phi2.
Now, any change on phi2 will cause anevaluation event to be scheduled for the process. When the evaluation event is executed and the positive edge found to have occurred, the process is removed from thefanout list of phi2, execution of the behavioral statements proceeds, and at the nextcontrol event the process is placed on the fanout list of phi1.In general, execution of a control event or a wait statement with a FALSE conditionwill cause the current process statement (an always or an initial) to be suspended andplaced on the fanout lists of the elements in the event or conditional expression.When an event occurs on one of the elements, an evaluation event is scheduled for theprocess to determines whether the event or wait condition has been satisfied.
Whenthe condition has been satisfied, the process statement is removed from the fanoutlists.Not only is the process statement placed on the fanout list, but also an indicator asto where to resume executing the process is maintained. This is analogous to a software program trying to read from an input device. The operating system will suspendexecution of the program until the input has arrived. Once input has arrived, the program continues executing from the point where it was suspended. In like manner, asuspended Verilog process resumes executing from where it was suspended.220The Verilog Hardware Description LanguageNow consider an altered version ofmodule twoPhiLatchWithDelayExample 8.4 shown in Example 8.5. The(input phi1, phi2, d,only difference here is that there is a delay ofoutput reg q);two time units before each of the proceduralassignments.
The action taken by the simuregqInternal;lator when a delay is executed is to suspendthe process statement and schedule an evalalways beginuation event for its resumption at the appro@ (posedge phi1)priate time in the future. The process’#2 qInternal = d;sensitivity list is not changed.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
