12.4 Processor and External Requests
Figure 12-7 Processor Requests
Read request asks for a block, doubleword, partial doubleword, word, or partial word of data either from main memory or from another system resource.
Write request provides a block, doubleword, partial doubleword, word, or partial word of data to be written either to main memory or to another system resource.
Null write request indicates that an expected write has been cancelled as a result of an external request.
Invalidate request specifies a line in every other cache in the system that must be marked invalid.
Update request provides a block, doubleword, partial doubleword, word, or partial word of data that must be transferred to every other cache in the system.
Table 12-1 lists the processor requests that each type of R4000 can issue.
Table 12-1 Supported Processor Requests 
Processor requests are managed by the processor in two distinct modes: secondary-cache mode and no-secondary-cache mode (see Chapter 11 for a description of these two modes), which are programmable through the boot-time mode control interface described in Chapter 9.
The permissible modes of operation are dependent on the following processor package configurations; if not programmed correctly, the behavior of the processor is undefined.
The processor has the input signals RdRdy* and WrRdy* to allow an external agent to manage the flow of processor requests. RdRdy* controls the flow of processor read, invalidate, and update requests, while WrRdy* controls the flow of processor write requests. Processor null write requests must always be accepted and cannot be delayed by either RdRdy* or WrRdy*. The processor request cycle sequence is shown in Figure 12-8.
Figure 12-8 Processor Request
A processor read request can be split from the external agent's return of the requested data; in other words, the external agent can initiate an unrelated external request before it returns the response data for a processor read. A processor read request is completed after the last word of response data has been received from the external agent.
Note that the data identifier (see System Interface Commands and Data Identifiers, in this chapter) associated with the response data can signal that the returned data is erroneous, causing the processor to take a bus error.
Processor read requests that have been issued, but for which data has not yet been returned, are said to be pending. A read remains pending until the requested read data is returned.
In secondary-cache mode, the external agent must be capable of accepting a processor read request followed by a potential update request any time all three of the following conditions are met:
Processor Read Request
When a processor issues a read request, the external agent must access the specified resource and return the requested data. (Processor read requests are described in this section; external read requests are described in External Requests, later on in this chapter.)
In no-secondary-cache mode, the external agent must be capable of accepting a processor read request any time the following two conditions are met:
Processor Write Request
When a processor issues a write request, the specified resource is accessed and the data is written to it. (Processor write requests are described in this section; external write requests are described in External Requests, later on in this chapter.)
A processor write request is complete after the last word of data has been transmitted to the external agent.
In secondary-cache mode, the external agent must be capable of accepting a processor write request any time all three of the following conditions are met:
When a processor issues an invalidate request, the specified resource is accessed and the line is marked invalid. (Processor invalidate requests are described in this section; external invalidate requests are described in External Requests, later on in this chapter.)
A processor invalidate request requires a completion acknowledge by either the invalidate acknowledge signal IvdAck* or the invalidate error signal IvdErr*, unless the invalidate is canceled by the external agent. A processor invalidate request that has been submitted, but for which the processor has not yet received an acknowledge or a cancellation, is said to be unacknowledged. When the processor invalidate request fails (IvdErr* is asserted), the issuing processor takes a bus error on the store instruction that generated the failed request. Figure 12-10 shows a sample processor invalidate/update request cycle.
Invalidate cancellation is signaled to the processor during external invalidate, update, snoop, and intervention requests; IvdErr* signals a processor invalidate request has failed.
A completion acknowledge for processor invalidate requests is signaled through the System interface on dedicated pins, and this acknowledgment can occur in parallel with processor and external requests.
State changes in the external system are not instantaneously reflected in the caches of every processor, which means an external agent can discover that a processor request for an invalidate cannot be completed. For example, a processor store can hit on a shared cache line and issue an invalidate to the external agent. However, before the external agent can transmit the invalidate to the rest of the system another invalidate for the same cache line can be received by the external agent. If this occurs, the processor cache does not reflect the current state of the system and the processor invalidate must not be transmitted to the system; instead, the external agent must cancel the processor unacknowledged invalidate. Figure 12-9 shows this cancellation cycle.
Figure 12-9 Cancelling an Invalidate Request
The steps shown in Figure 12-9 are described below:
1. The processor issues an invalidate on a store hit to a shared line in its cache.
2. An invalidate request, coming from the system bus, is received by the processor's external agent targeting the same cache line.
3. The external invalidate invalidates the cache line, and the processor invalidate request is cancelled.
4. The processor re-examines the state of the cache line and discovers the cache line which was target of the store is now invalid. The processor issues a processor read request to service the store miss.
When a processor issues an update request, the specified resource is accessed and the line is updated. (Processor update requests are described in this section; external update requests are described in External Requests, later on in this chapter.)
A processor update request requires a completion acknowledge by either the invalidate acknowledge signal IvdAck* or the invalidate error signal IvdErr* (shown in Figure 12-10), unless the update is canceled by the external agent. A processor update request that has been submitted, but for which the processor has not yet received an acknowledge or a cancellation, is said to be unacknowledged. When the processor update request fails (IvdErr* is asserted), the issuing processor takes a bus error on the store instruction that generated the failed request. Figure 12-10 shows a sample processor invalidate/update request cycle.
Figure 12-10 Processor Update/Invalidate Acknowledge Cycle
Update cancellation is signaled to the processor during external invalidate, update, snoop, and intervention requests; IvdErr* signals a processor update request has failed.
Since a completion acknowledge for processor update requests is signaled through the System interface on dedicated pins, this acknowledgment can occur in parallel with processor and external requests.
The processor supports three types of clusters:
Potential update requests within a cluster can be disabled through the boot-time mode control interface.
The external agent must accept all requests that form the cluster before it can respond to the read request that began the cluster. The behavior of the processor is undefined if the external agent returns a response to a processor read request before accepting all of the requests of the cluster.
Once the processor issues a read request, a potential update request follows, regardless of the state of RdRdy*. Potential update requests do not obey the RdRdy* flow control rules for issuance, but rather issue with a single address cycle regardless of the state of RdRdy*.
A processor potential update request remains potential until the read response to the pending processor read request which began the cluster is received by the external agent.
Generated with CERN WebMaker
Processor Update Request
An update request notifies all processors that a specified cache line in all caches throughout a multiprocessor system must be replaced with modified data. An update request can only be used in a multiprocessing system.
Clusters
A cluster consists of a single processor read request, followed by one or two additional processor requests that are issued while the initial read request is pending.
In secondary-cache mode, the processor issues individual requests (as in no-secondary-cache mode), or cluster requests. All requests in the cluster must be accepted before the response to the read request that began the cluster can be returned to the processor. Read With Write Forthcoming Request as Part of a Cluster
The processor signals that it is issuing a cluster containing a processor write request by issuing a read-with-write-forthcoming request, instead of starting the cluster with an ordinary read request. The read-with-write-forthcoming request is identified by a bit in the command for processor read requests. Potential Update as Part of a Cluster
Potential updates are identified by setting a bit in the processor update command. A processor potential update request is any update request that is issued while a processor read request is pending.
Write Request as Part of a Cluster
A write request that is part of a cluster obeys the WrRdy* timing rules for issuing, as shown earlier in Figure 12-3.
Copyright 1996, MIPS Technologies, Inc. -- 21 MAR 96
