Sable CPU Module Specification

Sable CPU Module Specification Sable CPU Module Specification

people.freebsd.org
from people.freebsd.org More from this publisher
20.02.2013 Views

Copyright © 1993 Digital Equipment Corporation. As the System-bus is based on a ‘‘snooping’’ protocol, every System-bus transaction is monitored by all System-bus participants. The memory modules can only act as responders or bystanders, and as such only respond to requests from bus commanders. The Processor and I/O subsystems can act as either commanders, responders, or bystanders. Table 63: System-bus Initiated Transactions Transaction Abbrv Systembus cycles Activity Write WR 6 B-Cache probe; 9 IF HIT update/invalidate IF update pull System-bus SHARED, cache block SHARED = prev SHARED Read RD 7 B-Cache probe; Provide data if HIT dirty Exchange XD 7 B-Cache probe (READ); Provide data if HIT dirty No-op Transaction NUT 7 No operation Refer to Table 65 for a detailed description of the control flows for System-bus initiated cycles. 5.2.1 CPU as Commander When one of the CPU module’s processors requests data that isn’t resident on the CPU module, a request is passed to the System-bus interface controller, and a System-bus transaction is initiated. 5.2.2 CPU as Bystander The CPU module is a Bystander when some other System-bus commander has requested data from a resource on the System-bus that doesn’t reside exclusively on the CPU module. As a Bystander, each B-Cache controller may have to update or invalidate a stale datum, or provide dirty data to the System-bus thereby pre-empting a memory module from returning stale data (for that transaction only). 5.2.3 CPU as Responder The CPU module is a Responder when some other System-bus commander has requested data from a System-bus visible CPU module register. CPU Module Transactions 157

Copyright © 1993 Digital Equipment Corporation. 5.3 Control Flow of CPU Module Transactions 5.3.1 Processor Initiated The CPU module B-Cache controller provides B-Cache control under the following circumstances. A B-Cache miss occurs, a LDxC, STxC, FETCH/FETCHM, or a MB is executed, or when a write to a shared cache block is detected. The behavior of the B-Cache controller is based on the current processor cycle type, the state of the B-Cache control bits, and the state of the System-bus. The following table illustrates the control flows for these cycles. Table 64: Processor Initiated Transactions - Control Flow Datum/Cache Cycle Status Size Activity Read HIT† X‡ X Write HIT NOT Shared† X Shared 32 bytes 1Refer to Section 4.2 for details. 2Processor Checks Data EDC. 3Processor Checks Tag Store and Control Store Parity. 4 B-Cache Controller Checks Tag Store and Control Store Parity. 5B-Cache Controller Checks Data EDC. †‘‘Fast Cache’’ cycles, external logic does not intervene ‡X - don’t care 158 CPU Module Transactions • Block read - Processor managed 32 • Update duplicate tag store • Block written (DIRTY = TRUE) - Processor managed 3 • Request System-bus 345 • System-bus WRITE cycle 15 • Update Cache block (DIRTY = FALSE, SHARED = System-bus shared during write) • Relinquish System-bus • ACK write

Copyright © 1993 Digital Equipment Corporation.<br />

As the System-bus is based on a ‘‘snooping’’ protocol, every System-bus transaction<br />

is monitored by all System-bus participants. The memory modules can only act as<br />

responders or bystanders, and as such only respond to requests from bus commanders.<br />

The Processor and I/O subsystems can act as either commanders, responders,<br />

or bystanders.<br />

Table 63: System-bus Initiated Transactions<br />

Transaction Abbrv<br />

Systembus<br />

cycles Activity<br />

Write WR 6 B-Cache probe;<br />

9 IF HIT update/invalidate<br />

IF update pull System-bus SHARED, cache block<br />

SHARED = prev SHARED<br />

Read RD 7 B-Cache probe; Provide data if HIT dirty<br />

Exchange XD 7 B-Cache probe (READ); Provide data if HIT dirty<br />

No-op Transaction NUT 7 No operation<br />

Refer to Table 65 for a detailed description of the control flows for System-bus initiated<br />

cycles.<br />

5.2.1 <strong>CPU</strong> as Commander<br />

When one of the <strong>CPU</strong> module’s processors requests data that isn’t resident on the<br />

<strong>CPU</strong> module, a request is passed to the System-bus interface controller, and a<br />

System-bus transaction is initiated.<br />

5.2.2 <strong>CPU</strong> as Bystander<br />

The <strong>CPU</strong> module is a Bystander when some other System-bus commander has requested<br />

data from a resource on the System-bus that doesn’t reside exclusively on<br />

the <strong>CPU</strong> module.<br />

As a Bystander, each B-Cache controller may have to update or invalidate a stale datum,<br />

or provide dirty data to the System-bus thereby pre-empting a memory module<br />

from returning stale data (for that transaction only).<br />

5.2.3 <strong>CPU</strong> as Responder<br />

The <strong>CPU</strong> module is a Responder when some other System-bus commander has requested<br />

data from a System-bus visible <strong>CPU</strong> module register.<br />

<strong>CPU</strong> <strong>Module</strong> Transactions 157

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!