Donald E. Thomas - The Verilog Hardware Description Language, Fifth Edition (798541), страница 25
Текст из файла (страница 25)
The ready signal is a syn//…consumedataInchronization signal that tells the conendsumer process that the producer processendmodulehas passed the state where dataIn is generated. In this way, the two processesbecome synchronized by the ready signal. Example 4.5 The Consumer ModuleThe general form of the wait statement isConcurrent Processes117statement|wait_statement…wait_statementwait ( expression ) statement_or_nullstatement _or_nullstatement|;The expression is evaluated and if it is TRUE, the process proceeds to execute the statement.
If it is FALSE, the process stops until it becomes TRUE. At that time, the processwill proceed with the statement. Note that the wait statement does not, itself, have asemicolon at its end; the statement_or_null contains the semicolon. Again, thechange in the expression must come about from the actions of another concurrentprocess.It is interesting to note that there would be a problem simulating Example 4.5 ifthere were no other event control or delay operations in the always statement. If thiswere true, then once the wait condition becomes TRUE , the loop would continue to beexecuted forever as the wait will never be FALSE .
In one sense, this problem comesabout because the simulator is simulating concurrent processes in a sequential mannerand only switching between simulating the concurrent processes when a wait for aFALSE condition, delay, or event control is encountered. Since none of these areencountered in this loop, a simulation would loop forever in this always statement.Actually, this is a more general problem in describing concurrent systems. In general, we cannot assume much about the speed of the processes in relation to eachother, and thus, we need to introduce more synchronization signals to insure theircorrect execution. If Example 4.5 had another synchronization point, say await (-ready), then the producer and consumer in the example would be more tightlysynchronized to each other’s operating rate.
Further, the simulation would also runcorrectly! The next section illustrates this with further examples.References: compare to while 4.3.24.3.1 A Complete Producer-Consumer HandshakeExample 4.5 could exhibit some synchronization errors. Specifically, the consumernever signals to the producer that the dataIn has been consumed. Two possible errorscould occur because of this incomplete handshake:The producer may operate too fast and change dataIn to a new value before theconsumer has a chance to read the previous value.
Thus the consumer would missa value.118The Verilog Hardware Description LanguageThe consumer may operate too fast and get around its always statement and seeready still TRUE. Thus it would read the same data twice.We need to synchronize the processes so that regardless of the speed of theirimplementation they function correctly.
One method of synchronizing two processesis with a fully-interlocked handshake as shown in Figure 4.1.The handshake illustrated above is described in Example 4.6 and the followingparagraphs. The description consists of two always blocks, the first modeling the consumer and the second modeling the producer. At the start of time, both of theseblocks can run. Of course one of them will go first, as chosen arbitrarily by the simulator. Initially all registers and wires have unknown value.
Thus, when producerreaches “wait (consReady)” or the consumer reaches “wait (prodReady)”, that alwaysblock will stop and wait because consReady and prodReady are unknown. If the consumer starts first, it will wait for prodReady after setting consReady to 1. The producer will then run, setting prodReady to 0 and continue through the wait forconsReady. If the producer starts first, it will set prodReady to zero, produce somedata, and wait for consReady. Then the consumer will execute, setting consReady to 1and wait for prodReady. Since consReady was just set to 1, the producer will continueagain.Assume we are at the point where the producer has set producer-ready (prodReady) to FALSE (or zero) indicating that it is not ready to send any information, andthe consumer has set consumer-ready (consReady) to TRUE (or one) indicating that itis ready to receive information.
When producer has generated a value, and it sees thatconsReady is one (arrow A in Figure 4.1), it loads the value into the output registerdataOut and sets prodReady to one. It then waits for the consumer to receive thevalue and set consReady to zero. The consumer, seeing prodReady at level one, makesa copy of the input and sets consReady to zero (arrow B in Figure 4.1).The producer now knows that the consumer has received the data so it sets prodReady back to zero, signalling the end of its half of the transfer (arrow C inFigure 4.1).
The producer proceeds with its business and the consumer consumes thedata. Then, seeing that the producer has finished its transfer, the consumer indicatesConcurrent Processes119module ProducerConsumer;regconsReady, prodReady;reg[7:0] dataInCopy, dataOut;alwaysbegin// The consumer processconsReady = 1;// indicate consumer readyforeverbeginwait (prodReady)dataInCopy = dataOut;consReady = 0;// indicate value consumed//…munch on datawait (!prodReady)// complete handshakeconsReady = 1;endendalwaysbegin// The producer processprodReady = 0;// indicate nothing to transferforeverbegin// …produce data and put into “dataOut”wait (consReady)// wait for consumer readydataOut =prodReady = 1;//indicate ready to transferwait (!consReady)//finish handshakeprodReady = 0;endendendmoduleExample 4.6 The Consumer With Fully Interlocked Handshakethat it is ready for another transfer by setting consReady (arrow D in Figure 4.1).
Theconsumer then watches for the next transfer. At this point, the transfer is complete.Note that we have introduced the random system function in the producer. Thisfunction returns a new random number each time it is called.This method of transferring data between two concurrent processes will work correctly regardless of the timing delays between the processes and regardless of their relative speeds of execution. That is, because each process waits on each level of theother process’ synchronization signal (i.e.
the producer waits for both consReady and120The Verilog Hardware Description Language!consReady), the processes are guaranteed to remain in lockstep. Thus, the consumercannot get around its always loop and quickly reread the previously transferred data.Nor, can the producer work so quickly to make the consumer miss some data.
Rather,the producer waits for the consumer to indicate that it has received the data. Systemssynchronized in this way are called self-timed systems because the two interacting processes keep themselves synchronized; no external synchronization signal, such as aclock, is needed.References:F; comparison of event and wait 4.3.34.3.2 Comparison of the Wait and While StatementsIt is incorrect to use the while statement to watch for an externally generated condition.
Even though the final implementation of the state machine that waits for thecondition generated by another concurrent process may be a “while” (i.e. stay in stateready is FALSE), conceptually we are synchronizing separate processes and weshould use the appropriate wait construct.A further explanation of the differences between the wait and while involves theuse of the simulator. Assuming a uniprocessor running a simulator, each always andinitial statement is simulated as a separate process, one at a time. Once started, thesimulator continues executing a process until either a delay control (#), a wait with aFALSE condition, or an event (@) statement is encountered.
In the case of the delaycontrol, event, or a wait with a FALSE condition, the simulator stops executing theprocess and finds the next item in the time queue to simulate. In the case of the waitwith a TRUE expression, simulation continues with the same process. A while statement will never stop the simulator from executing the process.Therefore, since the while statement shown in Example 4.7 waits for an externalvariable to change, it will cause the simulator to go into an endless loop.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
