Performance Modeling and Analysis Using VHDL and System:ADEPT Handshaking and Token Passing Mechanism.

ADEPT Handshaking and Token Passing Mechanism

Recall that the ADEPT standard token has a status field which can take on four values: PRESENT, ACKED, RELEASED, and REMOVED. These values reflect which stage of the token passing protocol is currently in progress. Several examples will now be presented to show how the handshaking and token passing occurs between ADEPT modules. Figure 77.8 illustrates the handshaking process between a Source module connected to a Sink module.

Figure 77.8(A) describes the “simplified” event sequence. Here, we can think of the four-step hand- shaking as consisting of simply a forward propagation of the token and a backward propagation of the token acknowledgment. Thinking of the handshaking in this simplified manner, Table A in Figure 77.8 shows the simplified event sequence and times. At time 0 ns, the Source module places a token on A, corresponding to Event 1. The token is immediately acknowledged by the Sink module, corresponding to Event 2. Since the Source module has a step generic of 5 ns, and there is no other delay along the path to the Sink, the next token will be output by the Source module at time 5 ns.

Figure 77.8(B) details the entire handshaking process. Table B in Figure 8 lists the detailed event sequence for this example. Since handshaking occurs in zero simulation time, the events are listed by delta cycles within each simulation time. The function of delta cycles in VHDL is to provide a means for

ordering and synchronizing events (such as handshaking) which occur in zero time. The actual event sequence for this example consists of four steps, as shown in Figure 77.8(B). Event 1 is repeated at time 5 ns, which starts the handshaking process over again.

A Three Module Example

To illustrate how tokens are passed through intermediate modules, a three module example will now be examined. Consider the case where a Fixed Delay module is placed between a Source and Sink. This situation is illustrated in Figure 77.9.

Figure 77.9(A) shows the simplified event sequence, where we can think of the four-step handshaking as consisting of simply a forward propagation of the token and a backward propagation of the token acknowledgment. Table A in Figure 77.9 lists this simplified event sequence. Notice that since now there is a path delay from the Source to the Sink, the time between new tokens from the Source is step + path_delay = 5 + 5 = 10 ns. At time 0 ns, the Source module places the first token on Signal A (Event 1). This token is read by the Delay module and placed on Signal B after a delay of 5 ns (Event 2). The Sink module then immediately acknowledges the token on Signal B (Event 3). The Delay module then passes this acknowledgment back through to Signal A (Event 4). At time 10 ns, the Source module places the next token on Signal A, starting the process over again.

Figure 77.9(B) shows the detailed event sequence for this example. Since there are two signals, there are a total of eight detailed events. Table B in Figure 77.9 lists the detailed event sequence for this example. Again since the handshaking occurs in zero simulation time, the events are listed by delta cycles within

each simulation time. Table B lists the resolved values on both Signal A and Signal B, where a value of “----” indicates no change in value. Notice that the sequence of events on each signal proceeds in this order: place the token (present) by the “source side,” acknowledge the token (acked) by the “sink side,” release the token (released) by the “source side,” and finally remove the token (removed) by the “sink side.” The important concept to note in this example is the ordering of events. Notice that the Delay module releases the token on its output (Event 4) before it acknowledges the token on its input (Event 5), even though the two events occur in the same simulation time. These actions trigger the Sink module to then remove the token on Signal B (Event 6) and the Source module to release the token on Signal A (Event 7), both in the next delta cycle. Thus Signal B is ready for another token (removed) a full delta cycle before Signal A is ready.

Token Passing Example

To illustrate how tokens propagate in a larger system, consider the model shown in Figure 77.10. This figure shows the simplified event sequence, where again we can think of the four-step handshaking as consisting of simply a forward propagation of the token and a backward propagation of the token acknowledgment. In this system, the Source module provides tokens to the Sequence A (SA) module (Event 1), who first passes them to the Sequence B (SB) module (Event 2). The Sequence B (SB) module first passes the token to the Fixed Delay A (FDA) module (Event 3), who passes it to the Sink A (SIA) module after a delay of 5 ns (Event 4). The SIA module then immediately acknowledges the token (Event 5), which causes the FDA module to pass the acknowledgment back to the SB module (Event 6). At this point the Sequence B (SB) module places a copy of the token on its second output (Event 7), where it is passed through the Union A and onto its output (Event 8). The Read Color A module then places the token on its out_1 output (Event 9) and simultaneously places the token on its independent output. The Sink B module then acknowledges the token on Signal H (Event 10). Upon seeing this acknowledgment, the Read Color A module releases the token on its independent output since the Read Color module has no “memory” (the release ? generic equals true). The acknowledgment is then propa- gated back to the Sequence B module (Events 11 and 12). At this point, the Sequence B module

acknowledges its input token (Event 13), freeing the Sequence A module to place a token on its second output (Event 14). This token is then passed through the Union A, Read Color A, and Sink module (Events 15 and 16) and the acknowledgment is returned (Events 17–19). The Sequence A module can then acknowledge the token on its input (Event 20), allowing the Source module to generate the next token 5 ns (step) later. If we examine the activity on Signal I (the independent output of the Read Color A module), we see that it goes present after Event 8, released after Event 10, present after Event 15, and released again after Event 17. Consider the operation of the Terminator module attached to this signal. Since the Terminator module halts simulation after the number of active events specified by the stop_after generic, if we were to simulate this example, the simulation would halt after Event 15 (the second active event).