Donald E. Thomas - The Verilog Hardware Description Language, Fifth Edition (798541), страница 23
Текст из файла (страница 23)
From where the firstidentifier is found, each succeeding identifier specifies the named scope within whichto continue searching downward. The last identifier specifies the entity being searchfor.Consider Example 3.13. Within module b, register r is not known because registerand wire identifiers are not searched for across module instantiations; they are onlyknown in the local scope.
However, the hierarchical reference top.r in module b willaccess r in top. Similarly, from module b, t.c.q accesses register q in task t (which, bythe way is different than register q in named block y). Further, block c can be disabledfrom b through the hierarchical name t.c. Note that these last two did not start withtop (although they could have). When searching up the module hierarchy from b, thenext scope up includes forward referencing names top, y, and t. Any of these (andactually any forward referencing identifier — modules, tasks, functions, or namedblocks) can be used as the root of the hierarchical name.
Indeed, when using a hierarchical name to specify a register or wire, the first identifiers in the name must be forward referencing identifiers. The last is the register or wire. When specifying thename, you need not start from the top. top.t.c.q and t.c.q are, from module b’s perspective, the same.Although we can gain access to any named item in the description with this mechanism, it is more appropriate to stay within the local and upward scope rules whichenforce better style, readability, and maintainability.
Use hierarchical names sparinglybecause they violate the stylistic rules of localizing access to elements of the design,rather than allowing any statement in the whole design to access anything.Yes, anything can access anything else through hierarchical naming. However, itmay not be appropriate stylistically. Stick with the rules of local and upward scope asmuch as possible.The Verilog Hardware Description Language1063.7 SummaryThe behavioral modeling statements that we have covered so far are very similar tothose found in software programming languages. Probably the major difference seenso far is that the Verilog language has separate mechanisms for handling the structuralhierarchy and behavioral decomposition.
Functions and tasks are provided to allow forthe behavior of a module to be “software engineered.” That is, we can break long andsometimes repetitious descriptions into behavioral subcomponents. Separately, we canuse module definitions to describe the structural hierarchy of the design and to separate concurrently operating behaviors into different modules.
The examples ofSection 3.5 have shown how these two approaches to modeling allow us to represent adesign in a wide range of stages of completion. The next chapter continues with thetopic of describing concurrent behaviors.3.8 ExercisesChange the expressions containing the right shift operator in Example 3.9 touse bit and part selects and concatenations only.3.2 Does replacing the repeat loop in Example 3.2 with the register declaration andfor loop below achieve the same results?3.1reg [3:0]i;for (i = 0; i <= `DvLen; i = i+1)begin//shift and subtract statementsend3.3 Shown below is a case statement with two case items defined.
The items calldifferent tasks. If we want to enumerate all of the possible case items, how manywould there be in all?reg[3:0] f;case (f)4’b 0110:taskR;4’b 1010:taskS;endcase3.4 Write a for loop statement which is equivalent to the casez statement in the following function without introducing any new variables.Behavioral Modeling107function [7:0] getMask(input [7:0] halfVal);casez (halfVal)8'b???????l: getMask = 8'b11111111;8'b??????10: getMask = 8'b11111110;8'b?????100: getMask = 8'b11111100;8'b????1000: getMask = 8'b11111000;8'b???10000: getMask = 8'b11110000;8'b??100000: getMask = 8'b11100000;8'b?1000000: getMask = 8'b11000000;8'b10000000: getMask = 8'b10000000;8'b00000000: getMask = 8'b11111111;endcaseendfunctionSimulate the multiply task and show the value of mpy, mcnd, and prod initially,and at the end of each of the 6 iterations of the loop.
Add astatementto show these values.3.6 Write the hierarchical name of every task, function, and register inExamples 3.9 and 3.10.3.7 In Example 3.13, we saw that from module b, register q in task t could bereferred to either as top.t.c.q or t.c.q. Why is there only one way to refer to register r from module b?3.53.8Look ahead to Example 6.10 on page 180.A. How would a behavioral statement in module slave call task wiggleBusLines?B. If both modules master and slave needed to call task wiggleBusLines, wherewould be the appropriate place for the task to be defined?4ConcurrentProcessesMost of the behavioral modeling statements discussed to this point have been demonstrated using single process examples.
These statements are part of the body of analways statement and are repetitively executed in sequential order. They may operateon values that are inputs or outputs of the module or on the module’s internal registers. In this chapter we present behavioral modeling statements that by their definition interact with activities external to the enclosing always. For instance, the waitstatement waits for its expression to become TRUE as a result of a value being changedin another process. As in this case and the others to be presented here, the operationof the wait statement is dependent on the actions of concurrent processes in the system.4.1 Concurrent ProcessesWe have defined a process to be an abstraction of a controller, a thread of control thatevokes the change of values stored in the system’s registers.
We conceive of a digitalsystem as a set of communicating, concurrent processes or independent control activities that pass information among themselves. What is important is that each of theseprocesses contains state information and that this state is altered as a function of theprocess’ current inputs and present state.110The Verilog Hardware Description LanguageExample 4.1 shows an abstract description of a computer.
An implementation ofthe hardware controller for the process described in the always statement is a sequential state machine with output and next state logic. This state machine would controla data path that includes the registers, arithmetic-logic units, and steering logic suchas buses and multiplexors.module computer;alwaysbeginpowerOnInitializations;foreverbeginfetchAndExecuteInstructions;endendendmoduleExample 4.1 An Abstract Computer DescriptionConsider that this process may interact with another process in the system, possibly an input interface that receives bit-serial information from a modem.
The processabstraction is necessary in this case because there are two independent, but communicating, threads of control: the computer, and the input interface. The input interfaceprocess watches for new input bits from the modem and signals the computer when abyte of data has been received. The other process, the computer described inExample 4.1, would only interact with the input interface process when a full byte ofinformation has been received.These two processes could have been described as one, but it would have been quitemessy and hard to read.
Essentially, each statement of the computer process wouldhave to include a check for new input data from the interface and a description ofwhat to do if it is found. In the worst case, if we have two processes that have n and mstates respectively, then the combined process with equivalent functionality wouldhave n*m states — a description of far higher complexity. Indeed, it is necessary toconceive of the separate processes in a system and describe them separately.When, when several processes exists in a system and information is to be passedamong them, we must synchronize the processes to make sure that correct information is being passed.
The reason for this is that one process does not know what stateanother process is in unless there is some explicit signal from that process giving suchinformation. That is, each of the processes is asynchronous with respect to the others.For instance, they may be operating at their own clock rate, or they may be producingdata at intervals that are not synchronized with the intervals when another processcan consume the data. In such instances, we must synchronize the processes, provid-Concurrent Processes111ing explicit signals between them that indicate something about their internal stateand that of the data shared among them.In hardware, one approach to synchronization is implemented with “data-ready”handshakes — one process will not read the shared data until the other signals with a“data-ready” signal that new data is present. When the other signals that the data hasbeen read, the first unasserts the “data-ready” signal until new information is available.Alternately, a clock signal is used to synchronize multiple processes.
Values are guaranteed to be valid and actions are specified to occur on one or both of the clock edges.Synchronizing signals such as handshakes and clocks are necessary when informationis to be passed correctly among separate processes.The statements presented in this chapter pertain to describing behavior thatinvolves the interactions among concurrent processes.References: always, initial 3.1; procedural timing model 8.1; non-determinism 8.34.2 EventsEvent control statements provide a means of watching for a change in a value. The execution of the process containing the event control is suspended until the change occurs.Thus, the value must be changed by a separate process.It is important to note that the constructs described in this section trigger on achange in a value.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
