LITERATURE
Intel Application Support Services
Pentium ® Pro Family Developer’s Manual Volume 1: Specifications
FIGURES
TABLES

Intel Pro 200 MHz User Manual

Displayed below is the user manual for Pro 200 MHz by Intel which is a product in the Processors category. This manual has pages.

Related Manuals

Intel Pro 200 MHz Manual

Intel Intel® Storage System JBOD2312S3SP Manual

Canon PRO-2000 Manual

MSI PRO DP130 11-200EU Manual

Candy CCHM 200/N Manual

Brother SC-2000USB Manual

Microsoft 2000 Manual

Candy CCV 200 GL Manual

Pentium® Pro Family

Developer’s Manual

Volume 1:

Specifications

NOTE: The Pentium® Pro Family Developer’s Manual consists of three

books: Specifications, Order Number 242690; Programmer’s Reference

Manual, Order Number 242691; and the Operati ng Syste m Writer’s Guide,

Order Number 242692.

Please refer to all three volumes when evaluating your design needs.

1996

3/26/97 1:28 PM PPRODIS2.DOC

Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or

otherwise, to any intellectual property rights is granted by this document. Except as provided in Intel's Terms and Conditions

of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating

to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability,

or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical,

life saving, or life sustaining applications.

Intel may make changes to specifications and product descriptions at any time, without notice.

Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined."

Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising

from future changes to them.

The Pentium® Pro processor may contain design defects or errors known as errata which may cause the product to deviate

from published specifications. Such errata are not covered by Intel’s warranty. Current characterized errata are available on

request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product

order.

Copies of documents which have an ordering number and are referenced in this document, or other Intel literature, may be

obtained from:

Intel Corporation

P.O. Box 7641

Mt. Prospect IL 60056-7641

or call 1-800-879-4683

or visit Intel’s website at http:\\www.intel.com

* Third-party brands and names are the property of their respective owners.

TABLE OF CONTENTS

PAGE

CHAPTER 1

COMPON ENT INTRODUCTION

1.1. BUS FEATURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

1.2. BUS DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

1.2.1. System Design Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

1.2.2. Efficient Bus Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

1.2.3. Multiprocessor Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

1.2.4. Data Integrity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 -5

1.3. SYSTEM OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

1.4. TERMINOLOGY CLARIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

1.5. COMPATIBILITY NOTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

CHAPTER 2

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

2.1. FULL CORE UTILIZATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.2. THE PENTIUM® PRO PROCESSOR PIPELINE . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

2.2.1. The Fetch/Decode Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4

2.2.2. The Dispatch/Execute Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5

2.2.3. The Retire Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7

2.2.4. The Bus Interface Unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7

2.3. ARCHITECTURE SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

CHAPTER 3

BUS OVERVIEW

3.1. SIGNAL AND DIAGRAM CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.2. SIGNALING ON THE PENTIUM® PRO PROCESSOR BUS. . . . . . . . . . . . . . . . . . 3-2

3.3. PENTIUM® PRO PROCESSOR BUS PROTOCOL OVERVIEW. . . . . . . . . . . . . . . 3-4

3.3.1. Transaction Phase Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4

3.3.2. Bus Transaction Pipelining and Transaction Tracking . . . . . . . . . . . . . . . . . . . . .3-6

3.3.3. Bus Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7

3.3.4. Data Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8

3.3.4.1. Line Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9

3.3.4.2. Part Line Aligned Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 -9

3.3.4.3. Partial Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9

3.4. SIGNAL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10

3.4.1. Execution Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10

3.4.2. Arbitration Phase Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12

3.4.3. Request Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13

3.4.4. Error Phase Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18

3.4.5. Snoop Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18

3.4.6. Response Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20

3.4.7. Data Phase Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21

3.4.8. Error Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22

3.4.9. Compatibility Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23

3.4.10. Diagnostic Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24

3.4.11. Power, Ground, and Reserved Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25

TABLE OF CONTENTS

PAGE

CHAPTER 4

BUS PROTOCOL

4.1. ARBITRATION PHASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

4.1.2. Bus Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

4.1.3. Internal Bus States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

4.1.3.1. Symmetric Arbitration States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

4.1.3.1.1. Agent ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

4.1.3.1.2. Rotating ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

4.1.3.1.3. Symmetric Ownership State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

4.1.3.2. Request Stall Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

4.1.3.2.1. Request Stall States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

4.1.3.2.2. BNR# Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

4.1.4. Arbitration Protocol Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

4.1.4.1. Symmetric Arbitration of a Single Agent After RESET# . . . . . . . . . . . . . . . . . .4-5

4.1.4.2. Signal Deassertion After Bus Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7

4.1.4.3. Delay of Transaction Generation After Reset. . . . . . . . . . . . . . . . . . . . . . . . . .4-8

4.1.4.4. Symmetric Arbitration with no LOCK# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9

4.1.4.5. Symmetric Bus Arbitration with no Transaction Generation. . . . . . . . . . . . . .4-10

4.1.4.6. Bus Exchange Among Symmetric and Priority Agents with no LOCK# . . . . .4-11

4.1.4.7. Symmetric and Priority Bus Exchange During LOCK#. . . . . . . . . . . . . . . . . .4-13

4.1.4.8. BNR# Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14

4.1.5. Symmetric Agent Arbitration Protocol Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16

4.1.5.1. Reset Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16

4.1.5.2. Bus Request Assertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16

4.1.5.3. Ownership from Idle State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16

4.1.5.4. Ownership from Busy State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17

4.1.5.4.1. Bus Parking and Release with a Single Bus Request . . . . . . . . . . . . . . . .4-17

4.1.5.4.2. Bus Exchange with Multiple Bus Requests . . . . . . . . . . . . . . . . . . . . . . . .4-17

4.1.6. Priority Agent Arbitration Protocol Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17

4.1.6.1. Reset Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17

4.1.6.2. Bus Request Assertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

4.1.6.3. Bus Exchange from an Unlocked Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

4.1.6.4. Bus Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

4.1.7. Bus Lock Protocol Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

4.1.7.1. Bus Ownership Exchange from a Locked Bus . . . . . . . . . . . . . . . . . . . . . . . .4-18

4.2. REQUEST PHASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

4.2.1. Bus Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19

4.2.2. Request Phase Protocol Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19

4.2.3. Request Phase Protocol Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20

4.2.3.1. Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20

4.2.3.2. Request Phase Qualifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20

4.3. ERROR PHASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

4.3.1. Bus Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-21

4.4. SNOOP PHASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21

4.4.1. Snoop Phase Bus Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-21

4.4.2. Snoop Phase Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22

4.4.2.1. Normal Snoop Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22

4.4.2.2. Stalled Snoop Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23

4.4.3. Snoop Phase Protocol Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24

4.4.3.1. Snoop Phase Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24

vii

TABLE OF CON TENTS

PAGE

4.4.3.2. Valid Snoop Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

4.4.3.3. Snoop Phase Stall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

4.4.3.4. Snoop Phase Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

4.4.3.5. Snoop Results Sampling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

4.5. RESPONSE PHASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

4.5.1. Response Phase Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

4.5.1.1. Bus Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26

4.5.2. Response Phase Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26

4.5.2.1. Response for a Transaction Without Write Data. . . . . . . . . . . . . . . . . . . . . . 4-26

4.5.2.2. Write Data Transaction Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28

4.5.2.3. Implicit Writeback on a Read Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29

4.5.2.4. Implicit Writeback with a Write Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 4-30

4.5.3. Response Phase Protocol Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

4.5.3.1. Request Initiated TRDY# Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

4.5.3.2. Snoop Initiated TRDY# protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

4.5.3.3. TRDY# Deassertion Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

4.5.3.4. RS[2:0]# Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

4.5.3.5. RS[2:0]#, RSP# protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

4.6. DATA PHASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

4.6.1. Data Phase Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

4.6.1.1. Bus Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

4.6.2. Data Phase Protocol Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

4.6.2.1. Simple Write Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

4.6.2.2. Simple Read Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34

4.6.2.3. Implicit Writeback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35

4.6.2.4. Full Speed Read Partial Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36

4.6.2.5. Relaxed DBSY# Deassertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37

4.6.2.6. Full Speed Read Line Transfers (Same Agent) . . . . . . . . . . . . . . . . . . . . . . 4-38

4.6.2.7. Full Speed Write Partial Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39

4.6.2.8. Full Speed Write Line Transactions (Same Agents). . . . . . . . . . . . . . . . . . . 4-40

4.6.3. Data Phase Protocol Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

4.6.3.1. Valid Data Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

4.6.3.2. Request Initiated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

4.6.3.3. Snoop Initiated Data Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

CHAPTER 5

BUS TRANSACTIONS AND OPERATIONS

5.1. BUS TRANSACTIONS SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.2. BUS TRANSACTION DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

5.2.1. Memory Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

5.2.1.1. Memory Read Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

5.2.1.2. Memory Write Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

5.2.1.3. Memory (Read) Invalidate Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

5.2.1.4. Reserved Memory Write Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

5.2.2. I/O Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

5.2.2.1. Request Initiator Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

5.2.2.2. Addressed Agent Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

5.2.3. Non-memory Central Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

5.2.3.1. Request Initiator Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

5.2.3.2. Central Agent Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

5.2.3.3. Observing Agent Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

5.2.3.4. Interrupt Acknowledge Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

TABLE OF CONTENTS

viii

PAGE

5.2.3.5. Branch Trace Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9

5.2.3.6. Special Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 -9

5.2.3.6.1. Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10

5.2.3.6.2. Flush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10

5.2.3.6.3. Halt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10

5.2.3.6.4. Sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11

5.2.3.6.5. Flush Acknowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11

5.2.3.6.6. Stop Grant Acknowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11

5.2.3.6.7. SMI Acknowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11

5.2.4. Deferred Reply Transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12

5.2.4.1. Request Initiator Responsibilities (Deferring Agent). . . . . . . . . . . . . . . . . . . .5-12

5.2.4.2. Addressed Agent Responsibilities (Original Requestor). . . . . . . . . . . . . . . . .5-13

5.2.5. Reserved Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13

5.3. BUS OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13

5.3.1. Implicit Writeback Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13

5.3.1.1. Memory Agent Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14

5.3.1.2. Requesting Agent Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14

5.3.2. Transferring Snoop Responsibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15

5.3.3. Deferred Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

5.3.3.1. Response Agent Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17

5.3.3.2. Requesting Agent Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18

5.3.4. Locked Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19

5.3.4.1. [Split] Bus Lock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20

CHAPTER 6

RANGE REGISTERS

6.1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.2. RANGE REGISTERS AND PENTIUM® PRO PROCESSOR INSTRUCTION

EXECUTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.3. MEMORY TYPE DESCRIPTIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

6.3.1. UC Memory Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3

6.3.2. WC Memory Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 -3

6.3.3. WT Memory Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3

6.3.4. WP Memory Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4

6.3.5. WB Memory Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4

CHAPTER 7

CACHE PROTOCOL

7.1. LINE STATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.2. MEMORY TYPES, AND TRANSACTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

7.2.1. Memory Types: WB, WT, WP, and UC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2

7.2.2. Bus Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2

7.2.3. Naming Convention for Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3

CHAPTER 8

DATA INTEGRITY

8.1. ERROR CLASSIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

8.2. PENTIUM® PRO PROCESSOR BUS DATA INTEGRITY ARCHITECTURE . . . . . 8-2

8.2.1. Bus Signals Protected Directly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2

8.2.2. Bus Signals Protected Indirectly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 -4

8.2.3. Unprotected Bus Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6

TABLE OF CON TENTS

PAGE

8.2.4. Time-out Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6

8.2.5. Hard-error Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.2.6. Bus Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.2.6.1. Parity Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.2.6.2. Pentium® Pro Processor Bus ECC Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.3. ERROR REPORTING MECHANISM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.3.1. MCA Hardware Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.3.2. MCA Software Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

8.3.3. IERR# Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

8.3.4. BERR# Signal and Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

8.3.5. BINIT# Signal and Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

8.4. PENTIUM® PRO PROCESSOR IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . 8-10

8.4.1. Speculative Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11

8.4.2. Fatal Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11

8.4.3. Pentium® Pro Processor Time-Out Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12

CHAPTER 9

CONFIGURATION

9.1. DESCRIPTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.1.1. Output Tristate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

9.1.2. Built-in Self Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.1.3. Data Bus Error Checking Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.1.4. Response Signal Parity Error Checking Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.1.5. AERR# Driving Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.1.6. AERR# Observation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.1.7. BERR# Driving Policy for Initiator Bus Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.1.8. BERR# Driving Policy for Target Bus Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.9. Bus Error Driving Policy for Initiator Internal Errors. . . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.10. BERR# Observation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.11. BINIT# Driving Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.12. BINIT# Observation Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.13. In-order Queue Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.14. Power-on Reset Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

9.1.15. FRC Mode Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

9.1.16. APIC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

9.1.17. APIC Cluster ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

9.1.18. Symmetric Agent Arbitration ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

9.1.19. Low Pow er Standby Enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

9.2. CLOCK FREQUENCIES AND RATIOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9

9.2.1. Clock Frequencies and Ratios at Product Introduction . . . . . . . . . . . . . . . . . . . 9-10

9.3. SOFTWARE-PROGRAMMABLE OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

CHAPTER 10

PENTIUM® PRO PROCESSOR TEST ACCESS PORT (TAP)

10.1. INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

10.2. ACCESSING THE TAP LOGIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

10.2.1. Accessing the Instruction Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

10.2.2. Accessing the Data Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

10.3. INSTRUCTION SET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

10.4. DATA REGISTER SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

10.4.1. Bypass Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

10.4.2. Device ID Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

TABLE OF CONTENTS

PAGE

10.4.3. BIST Result Boundary Scan Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9

10.4.4. Boundary Scan Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9

10.5. RESET BEHAVIOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

CHAPTER 11

ELECTRICAL SPECIFICATIONS

11.1. THE PENTIUM® PRO PROCESSOR BUS AND VREF. . . . . . . . . . . . . . . . . . . . . 11-1

11.2. POWER MANAGEMENT: STOP GRANT AND AUTO HALT . . . . . . . . . . . . . . . . 11-2

11.3. POWER AND GROUND PINS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

11.4. DECOUPLING RECOMMENDATIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

11.4.1. VccS Decoupling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4

11.4.2. GTL+ Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4

11.4.3. Phase Lock Loop (PLL) Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4

11.5. BCLK CLOCK INPUT GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

11.5.1. Setting the Core Clock to Bus Clock Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5

11.5.2. Mixing Processors of Different Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7

11.6. VOLTAGE IDENTIFICATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7

11.7. JTAG CONNECTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8

11.8. SIGNAL GROUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9

11.8.1. Asynchronous vs. Synchronous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9

11.9. PWRGOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11

11.10. THERMTRIP# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11

11.11. UNUSED PINS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

11.12. MAXIMUM RATINGS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

11.13. D.C. SPECIFICATIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14

11.14. GTL+ BUS SPECIFICATIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17

11.15. A.C. SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18

11.16. FLEXIBLE MOTHERBOARD RECOMMENDATIONS. . . . . . . . . . . . . . . . . . . . . 11-28

CHAPTER 12

GTL+ INTERFACE SPECIFICATION

12.1. SYSTEM SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

12.1.1. System DC Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2

12.1.2. Topological Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4

12.1.3. System AC Parameters: Signal Quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4

12.1.3.1. Ringback Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6

12.1.4. AC Parameters: Flight Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8

12.2. GENERAL GTL+ I/O BUFFER SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . . 12-12

12.2.1. I/O Buffer DC Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-12

12.2.2. I/O Buffer AC Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13

12.2.2.1. Output Driver Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-15

12.2.3. Determining Clock-To-Out, Setup and Hold . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17

12.2.3.1. Clock-to-Output Time, TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17

12.2.3.2. Minimum Setup and Hold Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19

12.2.3.3. Receiver Ringback Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-21

12.2.4. System-Based Calculation of Required Input and Output Timings . . . . . . . . . .12-22

12.2.4.1. Calculating Target TCO-max, and TSU-Min. . . . . . . . . . . . . . . . . . . . . . . . .12-22

12.2.5. Calculating Target THOLD-MIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-23

12.3. PACKAGE SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23

12.3.1. Package Trace Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-23

12.3.2. Package Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-24

12.4. REF8N NETWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24

12.4.1. Ref8N HSPICE Netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-26

TABLE OF CON TENTS

PAGE

CHAPTER 13

3.3V TOLERANT SIGNAL QUALITY SPECIFICATIONS

13.1. OVERSHOOT/UNDERSHOOT GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

13.2. RINGBACK SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

13.3. SETTLING LIMIT GUIDELINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3

CHAPTER 14

THERMAL SPECIFICATIONS

14.1. THERMAL PARAMETERS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

14.1.1. Ambient Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

14.1.2. Case Temperature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

14.1.3. Thermal Resistance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3

14.2. THERMAL ANALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4

CHAPTER 15

MECHANICAL SPECIFICATIONS

15.1. DIMENSIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

15.2. PINOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4

CHAPTER 16

TOOLS

16.1. ANALOG MODELING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

16.2. IN-TARGET PROBE FOR THE PENTIUM® PRO PROCESSOR (ITP) . . . . . . . . . 16-1

16.2.1. Primary Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2

16.2.2. Debug Port Connector Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2

16.2.3. Debug Port Signal Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2

16.2.4. Signal Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3

16.2.4.1. Signal Note 1: RESET#, PRDYx#. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4.2. Signal Note 2: DBRESET# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4.3. Signal Note 3: POWERON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4.4. Signal Note 4: DBINST#. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4.5. Signal Note 5: TDO and TDI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4.6. Signal Note 6: PREQ# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4.7. Signal Note 7: TRST#. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5

16.2.4.8. Signal Note 8: TCK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5

16.2.4.9. Signal Note 9: TMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6

16.2.5. Debug Port Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7

16.2.5.1. Signal Quality Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9

16.2.5.2. Debug Port Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9

16.2.6. Using Boun dary Scan to Communicate to the P entium® Pro Processor. . . . . 16-10

CHAPTER 17

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1

17.1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1

17.2. MECHANICAL SPECIFICATIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2

17.2.1. Vendor Contacts for Socket 8 and Header 8. . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3

17.2.2. Socket 8 Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3

17.2.2.1. Socket 8 Pinout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3

17.2.2.2. Socket 8 Space Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4

17.2.2.3. Socket 8 Clip Attachment Tabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7

TABLE OF CONTENTS

xii

PAGE

17.2.3. OverDrive® Voltage Regulator Module Definition . . . . . . . . . . . . . . . . . . . . . . . .17-8

17.2.3.1. OverDrive® VRM Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8

17.2.3.2. OverDrive® VRM Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8

17.2.3.3. OverDrive® VRM Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-8

17.2.3.4. OverDrive® VRM Space Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 7-10

17.3. FUNCTIONAL OPERATION OF OVERDRIVE® PROCESSOR SIGNALS . . . . . 17-11

17.3.1. Fan/Heatsink Power (VCC5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-11

17.3.2. Upgrade Present Signal (UP#) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-11

17.3.3. BIOS Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 7-13

17.3.3.1. OverDrive® processor CPUID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-14

17.3.3.2. Common Causes of Upgradability Problems due to BIOS. . . . . . . . . . . . . .17-14

17.4. OVERDRIVE® PROCESSOR ELECTRICAL SPECIFICATIONS . . . . . . . . . . . . 17-14

17.4.1. D.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-15

17.4.1.1. OverDrive® Processor D.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . .17-15

17.4.1.2. OverDrive® VRM D.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-16

17.4.2. OverDrive® Processor Decoupling Requirements. . . . . . . . . . . . . . . . . . . . . . .17-16

17.4.3. A.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-17

17.5. THERMAL SPECIFICATIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-17

17.5.1. OverDrive® Processor Cooling Requirements. . . . . . . . . . . . . . . . . . . . . . . . . .17-17

17.5.1.1. Fan/heatsink Cooling Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-17

17.5.2. OEM Processor Cooling Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-17

17.5.3. OverDrive® VRM Cooling Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-18

17.5.4. Thermal Equations and Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-18

17.6. CRITERIA FOR OVERDRIVE® PROCESSOR . . . . . . . . . . . . . . . . . . . . . . . . . . 17-19

17.6.1. Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-20

17.6.2. Electrical Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-20

17.6.2.1. OverDrive® Processor Electrical Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . .17-20

17.6.2.2. Pentium® Pro Processor Electrical Criteria. . . . . . . . . . . . . . . . . . . . . . . . . .17-22

17.6.3. Thermal Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-22

17.6.3.1. OverDrive® Processor Cooling Requirements (Systems Testing Only) . . . .17-22

17.6.3.2. Pentium® Pro Processor Cooling Requirements (Systems Testing Only) . .17-23

17.6.3.3. Voltage Regulator Modules (Systems Employing a Header 8 Only) . . . . . .17-23

17.6.4. Mechanical Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-23

17.6.4.1. OverDrive® Processor Clearance and Airspace Requirements . . . . . . . . . .17-23

17.6.4.2. OverDrive® VRM Clearance and Airspace Requirements . . . . . . . . . . . . . .1 7-24

17.6.5. Functional Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-24

17.6.5.1. Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-24

17.6.5.2. BIOS Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-24

17.6.6. End User Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25

17.6.6.1. Qualified OverDrive® Processor Components . . . . . . . . . . . . . . . . . . . . . . .17-25

17.6.6.2. Visibility and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25

17.6.6.3. Jumper Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25

17.6.6.4. BIOS Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25

17.6.6.5. Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25

17.6.6.6. Upgrade Removal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-25

APPENDIX A

SIGNALS REFERENCE

A.1. ALPHABETICAL SIGNALS REFERENCE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

A.1.1. A[35:3]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

A.1.2. A20M# (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

A.1.3. ADS# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

A.1.4. AERR# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

xiii

TABLE OF CON TENTS

PAGE

A.1.5. AP[1:0]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

A.1.6. ASZ[1:0]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

A.1.7. ATTR[7:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

A.1.8. BCLK (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5

A.1.9. BE[7:0]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5

A.1.10. BERR# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

A.1.11. BINIT# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

A.1.12. BNR# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

A.1.13. BP[3:2]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

A.1.14. BPM[1:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

A.1.15. BPRI# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

A.1.16. BR0#(I/O), BR[3:1]# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

A.1.17. BREQ[3:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

A.1.18. D[63:0]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

A.1.19. DBSY# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

A.1.20. DEFER# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

A.1.21. DEN# (I/0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

A.1.22. DEP[7:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

A.1.23. DID[7:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

A.1.24. DRDY# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12

A.1.25. DSZ[1:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12

A.1.26. EXF[4:0]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13

A.1.27. FERR# (O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13

A.1.28. FLUSH# (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13

A.1.29. FRCERR(I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14

A.1.30. HIT# (I/O), HITM#(I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14

A.1.31. IERR# (O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15

A.1.32. IGNNE# (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15

A.1.33. INIT# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15

A.1.34. INTR (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

A.1.35. LEN[1:0]# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

A.1.36. LINT[1:0] (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

A.1.37. LOCK# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

A.1.38. NMI (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

A.1.39. PICCLK (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

A.1.40. PICD[1:0] (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

A.1.41. PWR_GD (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18

A.1.42. REQ[4:0]# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18

A.1.43. RESET# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19

A.1.44. RP# (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19

A.1.45. RS[2:0]#(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20

A.1.46. RSP# (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21

A.1.47. SMI# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21

A.1.48. SMMEM# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21

A.1.49. SPLCK# (I/O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22

A.1.50. STPCLK# (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22

A.1.51. TCK (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22

A.1.52. TDI(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22

A.1.53. TDO (O). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22

A.1.54. TMS (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22

A.1.55. TRDY# (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23

A.1.56. TRST# (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23

A.2. SIGNAL SUMMARIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24

xiv

TABLE OF FIGURES

PAGE

Figure 1-1. The Pentium® Pro Processor In tegrating the CPU, L2 C ache,

APIC and Bus Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

Figure 1-2. Pentium® Pro Processor System Interface Block Diagram. . . . . . . . . . . . . . . .1-5

Figure 2-1. Three Engines Communicating Using an Instruction Pool . . . . . . . . . . . . . . . .2-1

Figure 2-2. A Typical Code Fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2

Figure 2-3. The Three Core Engines Interface with Memory via Unified Caches. . . . . . . .2-3

Figure 2-4. Inside the Fetch/Decode Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4

Figure 2-5. Inside the Dispatch/Execute Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6

Figure 2-6. Inside the Retire Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7

Figure 2-7. Inside the Bus Interface Unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8

Figure 3-1. Latched Bus Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

Figure 3-2. Pentium® Pro Processor Bus Transaction Phases. . . . . . . . . . . . . . . . . . . . . .3-5

Figure 4-1. BR[3:0]# Physical Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

Figure 4-2. Symmetric Arbitration of a Single Agent After RESET# . . . . . . . . . . . . . . . . . .4-6

Figure 4-3. Signal Deassertion After Bus Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7

Figure 4-4. Delay of Transaction Generation After Reset. . . . . . . . . . . . . . . . . . . . . . . . . .4-8

Figure 4-5. Symmetric Bus Arbitration with no LOCK#. . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9

Figure 4-6. Symmetric Arbitration with no Transaction Generation . . . . . . . . . . . . . . . . .4-11

Figure 4-7. Bus Exchange Among Symmetric and Priority Agent with no LOCK# . . . . . .4-12

Figure 4-8. Symmetric and Priority Bus Exchange During LOCK#. . . . . . . . . . . . . . . . . .4-13

Figure 4-9. BNR# Sampling After RESET#. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14

Figure 4-10. BNR# Sampling After ADS#. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15

Figure 4-11. Request Generation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19

Figure 4-12. Four-C lock Snoop Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22

Figure 4-13. Snoop Phase Stall Due to a Slower Agent. . . . . . . . . . . . . . . . . . . . . . . . . . .4-23

Figure 4-14. RS[2:0]# Activation with no TRDY# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-27

Figure 4-15. RS[2:0]# Activation with Request Initiated TRDY#. . . . . . . . . . . . . . . . . . . . .4-28

Figure 4-16. RS[2:0]# Activation with Snoop Initiated TRDY# . . . . . . . . . . . . . . . . . . . . . .4-29

Figure 4-17. RS[2:0]# Activation After Two TRDY# Assertions . . . . . . . . . . . . . . . . . . . . .4-30

Figure 4-18. Request Initiated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34

Figure 4-19. Response Initiated Data Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-35

Figure 4-20. Snoop Initiated Data Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-36

Figure 4-21. Full Speed Read Partial Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-37

Figure 4-22. Relaxed DBSY# Deassertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-38

Figure 4-23. Full Speed Read Line Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-39

Figure 4-24. Full Speed Write Partial Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-40

Figure 4-25. Full Speed Write Line Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-41

Figure 5-1. Bus Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Figure 5-2. Response Responsibility Pickup Effect on an Outstanding Invalidation

Transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15

Figure 5-3. Deferred Response Followed by a Deferred Reply to a Read Operation. . . .5-18

Figure 8-1. BERR# Protocol Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8

Figure 8-2. BINIT# Protocol Mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10

Figure 8-3. Pentium® Pro Processor Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11

Figure 9-1. Hardware Configuration Signal Sampling. . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

Figure 9-2. BR[3:0]# Physical Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7

Figure 10-1. Simplified Block Diagram of Pentium® Pro Processor TAP logic . . . . . . . . . .10-1

Figure 10-2. TAP Controller Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

Figure 10-3. Pentium® Pro Processor TAP instruction Register . . . . . . . . . . . . . . . . . . . . .10-4

TABLE OF FIGURES

PAGE

Figure 10-4. Operation of the Pentium® Pro Processor TAP Instruction Register. . . . . . . 10-5

Figure 10-5. TAP Instruction Register Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

Figure 11-1. GTL+ Bus Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Figure 11-2. Transient Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

Figure 11-3. Timing Diagram of Clock Ratio Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

Figure 11-4. Example Schematic for Clock Ratio Pin Sharing . . . . . . . . . . . . . . . . . . . . . 11-6

Figure 11-5. PWRGOOD Relationship at Power-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11

Figure 11-6. 3.3V Tolerant Group Derating Curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21

Figure 11-7. Generic Clock Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24

Figure 11-8. Valid Delay Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24

Figure 11-9. Setup and Hold Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25

Figure 11-10. Lo to Hi GTL+ Receiver Ringback Tolerance . . . . . . . . . . . . . . . . . . . . . . . 11-25

Figure 11-11. FRC Mode BCLK to PICCLK Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26

Figure 11-12. Reset and Configuration Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26

Figure 11-13. Power-On Reset and Configuration Timings . . . . . . . . . . . . . . . . . . . . . . . 11-27

Figure 11-14. Test Timings (Boundary Scan) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-27

Figure 11-15. Test Reset Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28

Figure 12-1. Example Terminated Bus with GTL+ Transceivers. . . . . . . . . . . . . . . . . . . . 12-2

Figure 12-2. Receiver Waveform Showing Signal Quality Parameters. . . . . . . . . . . . . . . 12-5

Figure 12-3. Standard Input Lo-to-Hi Waveform for Characterizing Receiver

Ringback Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

Figure 12-4. Standard Input Hi-to-Lo Waveform for Characterizing Receiver

Ringback Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

Figure 12-5. Measuring Nominal Flight Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9

Figure 12-6. Flight Time of a Rising Edge Slower Than 0.3V/ns . . . . . . . . . . . . . . . . . . 12-10

Figure 12-7. Extrapolated Flight Time of a Non-Monotonic Rising Edge . . . . . . . . . . . . 12-11

Figure 12-8. Extrapolated Flight Time of a Non-Monotonic Falling Edge . . . . . . . . . . . . 12-11

Figure 12-9. Acceptable Driver Signal Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16

Figure 12-10. Unacceptable Signal, Due to Excessively Slow Edge After

Crossing VREF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16

Figure 12-11. Test Load for Measuring Output AC Timings . . . . . . . . . . . . . . . . . . . . . . . 12-18

Figure 12-12. Clock to Output Data Timing (TCO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18

Figure 12-13. Standard Input Lo-to-Hi Waveform for Characterizing Receiver

Setup Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20

Figure 12-14. Standard Input Hi-to-Lo Waveform for Characterizing Receiver

Setup Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20

Figure 12-15. Ref8N Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-25

Figure 13-1. 3.3V Tolerant Signal Overshoot/Undershoot and Ringback. . . . . . . . . . . . . 13-2

Figure 14-1. Location of Case Temperature Measurement (Top-Side View) . . . . . . . . . . 14-2

Figure 14-2. Thermocouple Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2

Figure 14-3. Thermal Resistance Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3

Figure 14-4. Analysis Heat Sink Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4

Figure 15-1. Package Dimensions-Bottom View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2

Figure 15-2. Top View of Keep Out Zones and Heat Spreader . . . . . . . . . . . . . . . . . . . . 15-3

Figure 15-3. Pentium® Pro Processor Top View with Power Pin Locations . . . . . . . . . . . 15-4

Figure 16-1. GTL+ Signal Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3

Figure 16-2. TCK with Daisy Chain Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5

Figure 16-3. TCK with Star Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6

Figure 16-4. Generic MP System Layout for Debug Port Connection. . . . . . . . . . . . . . . . 16-8

Figure 16-5. Debug Port Connector on Primary Side of Circuit Board . . . . . . . . . . . . . . . 16-9

Figure 16-6. Hole Layout for Connector on Primary Side of Circuit Board . . . . . . . . . . . 16-10

TABLE OF FIGURES

xvi

PAGE

Figure 16-7. Pentium® Pro Processor-Based System Where Boundary Scan is

Not Used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10

Figure 16-8. Pentium® Pro Processor-Based System Where Boundary Scan is Used. . .16-11

Figure 17-1. Socket 8 Shown with the Fan/heatsink Cooling Solution,

Clip Attachment Features and Adjacent Voltage Regulator Module. . . . . . . .17-2

Figure 17-2. OverDrive® Processor Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-3

Figure 17-3. OverDrive® Processor Envelope Dimensions. . . . . . . . . . . . . . . . . . . . . . . . .17-5

Figure 17-4. Space Requirements for the OverDrive® Processor. . . . . . . . . . . . . . . . . . . .17-7

Figure 17-5. Header 8 Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-9

Figure 17-6. OverDrive® Voltage Regulator Module Envelope . . . . . . . . . . . . . . . . . . . . .17-11

Figure 17-7. Upgrade Presence Detect Schematic - Case 1 . . . . . . . . . . . . . . . . . . . . . .17-12

Figure 17-8. Upgrade Presence Detect Schematic - Case 2 . . . . . . . . . . . . . . . . . . . . . .17-12

Figure 17-9. Upgrade Presence Detect Schematic - Case 3 . . . . . . . . . . . . . . . . . . . . . .17-13

xvii

TABLE OF TABLES

Table 3-1. Burst Order Used For Pentium® Pro Processor Bus Line Transfers. . . . . . . . .3-9

Table 3-2. Execution Control Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10

Table 3-3. Arbitration Phase Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12

Table 3-4. Request Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13

Table 3-5. Transaction Types Defined by REQa#/REQb# Signals . . . . . . . . . . . . . . . . .3-14

Table 3-6. Address Space Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15

Table 3-7. Length of Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15

Table 3-8. Memory Range Register Signal Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16

Table 3-9. DID[7:0]# Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16

Table 3-10. Special Transaction Encoding on Byte Enables. . . . . . . . . . . . . . . . . . . . . . .3-17

Table 3-11. Extended Function Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-17

Table 3-12. Error Phase Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18

Table 3-13. Snoop Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19

Table 3-14. Response Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20

Table 3-15. Transaction Response Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21

Table 3-16. Data Phase Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21

Table 3-17. Error Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22

Table 3-18. PC Compatibility Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23

Table 3-19. Diagnostic Support Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24

Table 4-1. HIT# and HITM# During Snoop Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-21

Table 4-2. Response Phase Encodings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26

Table 6-1. Pentium® Pro Processor Architecture Memory Types . . . . . . . . . . . . . . . . . . .6-2

Table 8-1. Direct Bus Signal Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3

Table 9-1. APIC Cluster ID Configuration for the Pentium® Pro Processor. . . . . . . . . . . .9-5

Table 9-2. BREQ[3:0]# Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6

Table 9-3. Arbitration ID Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8

Table 9-4. Bus Frequency to Core Frequency Ratio Configuration1. . . . . . . . . . . . . . . . .9-9

Table 9-5. Pentium® Pro Processor Power-on Configuration Register . . . . . . . . . . . . . .9-10

Table 9-6. Pentium® Pro Processor Power-on Configuration Register APIC

Cluster ID bit Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11

Table 9-7. Pentium® Pro Processor Power-on Configuration Register Bus

Frequency to Core Frequency Ratio Bit Field. . . . . . . . . . . . . . . . . . . . . . . . .9-11

Table 9-8. Pentium® Pro Processor Power-on Configuration Register

Arbitration ID Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12

Table 10-1. 1149.1 Instructions in the Pentium® Pro Processor TAP . . . . . . . . . . . . . . . .10-7

Table 10-2. TAP Data Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8

Table 10-3. Device ID Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9

Table 10-4. TAP Reset Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-10

Table 11-1. Voltage Identification Definition, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7

Table 11-2. Signal Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10

Table 11-3. Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-13

Table 11-4. Voltage Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-14

Table 11-5. Power Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15

Table 11-6. GTL+ Signal Groups D.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . .11-16

Table 11-7. Non-GTL+ Signal Groups D.C. Specifications. . . . . . . . . . . . . . . . . . . . . . .11-16

Table 11-8. GTL+ Bus D.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-17

Table 11-9. Bus Clock A.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-18

Table 11-10. Supported Clock Ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19

Table 11-11. GTL+ Signal Groups A.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19

TABLE OF TABLES

xviii

Table 11-12. GTL+ Signal Groups Ringback Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . .11-20

Table 11-13. 3.3V Tolerant Signal Groups A.C. Specifications. . . . . . . . . . . . . . . . . . . . .11-20

Table 11-14. Reset Conditions A.C. Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-21

Table 11-15. APIC Clock and APIC I/O A.C. Specifications . . . . . . . . . . . . . . . . . . . . . . .11-22

Table 11-16. Boundary Scan Interface A.C. Specifications. . . . . . . . . . . . . . . . . . . . . . . .11-23

Table 11-17. Flexible Motherboard (FMB) Power Recommendations . . . . . . . . . . . . . . .11-28

Table 12-1. System DC Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3

Table 12-2. System Topological Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4

Table 12-3. Specifications for Signal Quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5

Table 12-4. I/O Buffer DC Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13

Table 12-5. I/O Buffer AC Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14

Table 13-1. Signal Ringback Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2

Table 14-1. Case-To-Ambient Thermal Resistance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4

Table 14-2. Ambient Temperatures Required at Heat Sink for 29.2W and 85° Case . . . .14-5

Table 14-3. Ambient Temperatures Required at Heat Sink for 40W and 85 ° Cas e. . . . . .14-5

Table 15-1. Pentium® Pro Processor Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3

Table 15-2. Pin Listing in Pin # Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5

Table 15-3. Pin Listing in Alphabetic Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-9

Table 16-1. Debug Port Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2

Table 16-2. TCK Pull-Up Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-5

Table 17-1. OverDrive® Processor Signal Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . .17-4

Table 17-2. Header 8 Pin Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-10

Table 17-3. OverDrive® Processor CPUID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-14

Table 17-4. OverDrive® Processor D.C. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . .17-15

Table 17-5. OverDrive® VRM Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-16

Table 17-6. OverDrive® VRM Power Dissipation for Thermal Design . . . . . . . . . . . . . . .17-18

Table 17-7. OverDrive® Processor Thermal Resistance and Maximum Ambient

Temperature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-19

Table 17-8. Electrical Test Criteria for Systems Employing Header 8. . . . . . . . . . . . . . .17-21

Table 17-9. Electrical Test Criteria for Systems Not Employing Header 8 . . . . . . . . . . .17-21

Table 17-10. Electrical Test Criteria for all Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-22

Table 17-11. Thermal Test Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-23

Table 17-12. Mechanical Test Criteria for the OverDrive® Processor . . . . . . . . . . . . . . . .17-23

Table 17-13. Functional Test Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-24

Table A-1. ASZ[1:0]# Signal Decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

Table A-2. ATTR[7:0]# Field Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5

Table A-3. Special Transaction Encoding on BE[7:0]# . . . . . . . . . . . . . . . . . . . . . . . . . . A-5

Table A-4. BR0#(I/O), BR1#, BR2#, BR3# Signals Rotating Interconnect. . . . . . . . . . . . A-8

Table A-5. BR[3:0]# Signal Agent IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Table A-6. DID[7:0]# Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12

Table A-7. EFX[4:0]# Signal Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13

Table A-8. LEN[1:0]# Signals Data Transfer Lengths . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

Table A-9. Transaction Types Defined by REQa#/REQb# Signals . . . . . . . . . . . . . . . . A-18

Table A-10. Transaction Response Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20

Table A-11. Output Signals1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24

Table A-12. Input Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24

Table A-13. Input/Output Signals (Single Driver). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25

Table A-14. Input/Output Signals (Multiple Driver). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-27

Component

Introduction

1-1

CHAPTER 1

COMPONENT INTRODUCTION

The Pentium® Pro microp rocessor i s the next generatio n in the Intel38 6™, Intel 486™, and Pen-

tium family of processors. The Pentium Pro processor implements a Dynamic Ex ecution micro-

architecture — a unique combination of multiple branch prediction, data flow analysis, and

speculative execution while maintaining binary compatibility with the 8086/88, 80286,

Intel386, Intel486, and Pentium processors. The Pentium Pro processor integrates the second

le vel cache, the APIC, and the memory b us controller found in pre vious Intel processor families

into a single component, as shown in Figur e 1-1.

A significant new feature of the Pentium Pro processor, from a system perspective, is the built-

in direct multi-processing support. In order to achiev e multi-processing for up to four processors

and maintain the memory and I/O bandwidth to support them, new system designs are needed

which cons ider the additio nal power requirements and sig nal integrity issues o f supporting up

to eight loads on a high speed bus.

The Pentium Pro processor may be upgraded by a future OverDrive® processor and matching

volt age regulat or mo dul e des cri bed in C hapt er 17 , OverDrive® Processor Socket Specif ication .

Since increasing clock frequencies and silico n density can complicate sy stem designs, the Pen-

tium Pro processor integrates several system components which alleviate some of the previous

system requirements. The second level cache, cache controller, and Advanced Programmable

Interrupt Controller (APIC) are some of the components that existed in previous Intel processor

Figure 1-1. The Pentium® Pro Processor Integrating the CPU, L2 Cache, APIC and Bus

Controller

Pentium Pro Pentium Pro

Bus Interface Unit

Cache

Intel486

™

Cache

Controller

Bus Cache

SRAMs

Controller

APIC

or Pentium

Processor

Processor L2

Processor

Pentium Pro Processor

1-2

COMPONENT INTRODUCTION

family systems which are integrated into this single component. This integration results in the

Pentium Pro processor bus more closely resembling a symmetric multi-processing (SMP) sys-

tem bus rather than a previous generation processor-to-cache bus. This added level of integration

and improved performance results in higher power consumption and a new bus technology. This

means it is more important than ever to ensure adherence to the specifications contained in this

document.

The Pentium Pro processor may contain design defects or errors known as errata. Current char-

acterized errata are available upon request.

1.1. BUS FEATURES

The design of the external Pentium Pro processor bus enables it to be “multiprocessor ready.”

Bus arbitration and control, cache coherency circuitry, an MP interrupt controller and other sys-

tem-level functions are integrated into the bus interface.

To relax timing constraints, the Pentium Pro processor implements a synchronous, latched bus

protocol to enable a full clock cycle for signal transmission and a full clock cycle for signal in-

terpretation and generation. This latched protocol simplifies interconnect timing requirements

and supports higher frequency system designs using inexpensive ASIC interconnect technology.

The Pentium Pro processor bus uses low-voltage-swing GTL+ I/O buffers, making

high-frequency signal communication easier.

All output pins are actually implemented in the Pentium Pro processor as I/O buffers. This buffer

design complies with IEEE 1149.1 Boundary Scan Specification, allowing all pins to be sam-

pled and tested. An output only buffer is used only for TDO, which is not sampled in the bound-

ary scan chain. A pin is an output pin when it is not an input for normal operation or FRC.

Most of the Pentium Pro processor cache protocol complexity is handled by the processor. A

non-caching I/O bridge on the Pentium Pro processor bus does not need to recognize the cache

protocol and does not need snoop logic. The I/O bridge can issue standard memory accesses on

the Pentium Pro processor bus, which are transparently snooped by all Pentium Pro processor

bus agents. If data is modified in a Pentium Pro processor cache, the processor transparently pro-

vides data on the bus, instead of the memory controller. This functionality eliminates the need

for a back-off capability that existing I/O bridges require to enable cache writeback cycles. The

memory controller must observe snoop response signals driven by the Pentium Pro processor

bus agents, absorb writeback data on a modified hit, and merge any write data.

The Pentium Pro processor integrates memory type range registers (MTRRs) to replace the ex-

ternal address decode logic used to decode cacheability attributes.

The Pentium Pro processor bus protocol enables a near linear increase in system performance

with an increase in the number of processors. The Pentium Pro processor interfaces to a multi-

processor system without any support logic. This “glueless” interface enables a desktop system

to be built with an upgrade socket for another Pentium Pro processor.

The external Pentium Pro processor bus and Pentium Pro processor use a ratio clock design that

provides modularity and an upgrade path. The processor internal clock frequency is an n/2 mul-

tiple of the bus clock frequency where n is an integer equal to or greater than 4 but only certain

ch01.fm4 Page 2 Thursday, August 22, 1996 8:35 AM

1-3

COMPONENT INTRODUCTION

The ratio clock approach reduces the tight coupling between the processor clock and the external

bus clock. For a fix ed sy stem bu s clock frequen cy, Pentium Pro process ors introd uced later with

higher processor clock frequenc ies can use the same support chip-set at the same bus fr equency.

An in vestment in a Pentium Pro processor chip-set is protected fo r a longer time and for a gr eater

range of processor frequencies. The ratio clock approach also preserves system modularity, al-

lowing the system electrical topology to determine the system bus clock frequency while pro-

cess technology can determine the processor clock frequency.

The Pentium Pro processor bus architecture provides a number of features to support high reli-

ability and high availability designs. Most of these additional features can be disabled, if neces-

sary. For example, the bus architecture allows the data bus to be unprot ected or protected with

an error correcting code (ECC). Error detection and limited recovery are built into the bus

protocol.

A Pentium Pr o pro cessor b us can con tain up t o four Pentiu m Pro pr ocesso rs, and a combinat ion

of four other loads consisting primarily of bus clusters, memory controllers, I/O bridges, and

custom attachments.

In a four-processor system, the data bus is the most critical resource. To account for this situa-

tion, the Pentium Pro processor bus implements several features to maximize available bus

bandwidth including pip elined transactions in which bus transactio ns in different ph ases over-

lap, an increase in transaction pipeline depth over previous generations, and support for defer-

ring a transaction for later completion .

The Pentium Pro pro cessor b us architecture is therefore ada ptable to various classes of systems.

In desktop multiproces sor sy stems, a subs et of the bus features can be used . In server designs,

the Pentium Pro processor bus provides an entry into low-end multiprocessing offering linear

increases in performance as CPUs are added to scale perfor mance upward allo wing Pentium Pro

processor systems to be superior for applications that would otherwise indicate a downsized

solution.

1.2. BUS DESCRIPTION

The Pentium Pro processor bus is a demultiplexed bus with a 64-bit data path and a 36-bit

address path. This section p rovides more details on the bus features introd uced in th e pr eceding

section:

•Ease of system design

•Efficient bus utilization

•Multiprocessor ready

•Data integrity

1-4

COMPONENT INTRODUCTION

1.2.1. System De sign Aspects

The Pentium Pro processor bus clock and the Pentium Pro processor internal execution clock

run at dif ferent frequencies, related b y a ratio. Section 9.2., “Clock Frequencies and Ratios” pro-

vides more information about bus frequency and processor frequency.

The Pentium Pro processor bus uses GTL+. The GTL+ low voltage swing reduces both power

consumption and electromagnetic interferen ce (EMI). The lo w v o ltage swing GTL+ I/O b uf fers

also enable direct drive by ASICs and make high-frequency signal communication easier and

cheaper to implement.

The Pentium Pro processor bus i s a synchronous, l atched b us. The b us protocol lat ches all inputs

on the bus clock rising edge, which are used internally in the following cycle. The Pentium Pro

processor and other bus agents drive outputs on the bus clock rising edge. The bus protocol

therefore provides a full cycle for signal transmission and an agent also has a full cl ock period

to determin e its output.

1.2.2. Efficient Bus Utilization

The Pentium Pro processor bus supports multiple o uts tanding bus transactions. The transaction

pipeline depth is limited to the smallest depth supported by any agent (processors, memory, or

I/O). The Pentium Pro processor bus can be configured at power-on to support a maximum of

eight out standing b us transacti ons depending on the amount of b uf fering a vail able in the s ystem.

Each Pentium Pro processor is capable of issuing up to four outstanding transactions.

The Pentium Pro processor bus enables transactions with long latencies to be completed at a lat-

er time using separate deferr ed reply transactions. The same Pentium Pro processor bu s agent or

other Pentium Pro processor bu s agents can continue with subsequent reads and writes while a

slow agent is processing an outstanding request.

1.2.3. Multiprocessor Ready

The Pentium Pro processor bus enables multiple Pentium Pro processors to operate on one bus,

with no external support logic. The Pentium Pro processor requires n o separate snoop generation

logic. The processor I/O buffers can drive the Pentium Pro processor bus in an MP system.

The Pentium Pro processors and b us support a MESI cache protocol in the internal caches. The

cache protocol enables direct cache-to-cache line transfers with memory reflection.

The Pentium Pro processors and bus support fair, symmetric, round-robin bus arbitration that

minimizes ov erhead associated with bus o wnership exchange. An I/O agent may gener ate a high

priority bus request.

1-5

COMPONENT INTRODUCTION

1.2.4. Data Integrity

The Pentium Pro processor bus provides parity signals for address, request, and response sig-

nals. The bus protocol supports retrying bus requests.

The Pentium Pro processor bus supports error correcting code (ECC) on the data bus and has

correction capability at the receiver.

The Pentium Pro processor supports functional redundancy checking (FRC), similar to that of

the Pentium processor. FRC support enables the Pentium Pro processor to be used in high data-

integrity, fault-tolerant applications. In addition, two Pentium Pro processors can be configured

at power-on as an FRC pair or a multiprocessor-ready pair.

1.3. SYSTEM OVERVIEW

Figure 1-2 ill ustrates the Pentium Pro proces sor system environm ent, containi ng mu ltiple pro -

cessors (MP), memory, and I/O. This particular architectural view is not intended to imply any

implementation trade-offs.

Figure 1-2. Pentium® Pro Processor System Interface Block Diagram

Pentium® Pro

Agent 0

Pentium Pro

Agent 2

Pentium Pro

Agent 1

Pentium Pro

Agent 3

High Speed I/O

Interface Memory

Interface

System Int erf ace

Processor Processor Processor Processor

1-6

COMPONENT INTRODUCTION

Up to four Pe ntium Pro p rocesso rs can be gl ueles sly in tercon nected on the Pent ium Pro pr oces-

sor bus. These agents are bus masters, capable of supporting all the features described in this

document. The interf ace to the remainder of the system is represented b y the high-speed I/O in-

terface and memory interface blocks. The memory interface block represents a path to system

memory capable of supporting o v er 500 Mbyt es/second data ban dwidth. The high- speed I/O in-

terface block provides a fast path to system I/O. Various implementat ions of these two blocks

can provide different cost vs. performance trade-offs. For example, more than one memory in-

terface or high-speed I/O interface may be included.

An MP system containing more than f our Pentium Pro pro cessors can be created based on clus-

ters that each contain four processors. Such a system can use cluster controllers that connect

Pentium Pro processor buses to a global memory bus. The Pentium Pro processor bus provides

appropriate proto col support for b uilding e xternal caches and memory directory-b ased systems.

1.4. TE RMINOLOGY CLARIFICATION

Some key definitions and concepts are introduced here to aid the understanding of this

document.

A ‘#” symbol after a signal name refers to an active low signal. This means that a signal is in

the acti ve state (based on the name of the signal) when dri ven lo w. For ex ample, when FLUSH#

is low a flush has been requested. When NMI is high, a Non-maskable interrupt has occurred.

In the case of lines where the name does not imply an activ e state but describes part of a binary

sequence (such as address or data), the ‘#’ symbol implies that the signal is inverted. For

example, D[3:0] = ‘HLHL’ refers to a hex ‘A’, and D#[3:0] = ‘LHLH’ also refers to a hex

‘A’. (H= High logic level, L= Low l ogic level)

Pe ntium Pr o pr oces so r bus agen ts issue transactions to transfer data and system informatio n.

A bus agent is any device that connects to the processor bus including the Pentium Pro proces-

sors themselves.

This specification refers to several classifications of bus agents.

•Central Agent. Handles reset, hardware configuration and initialization, special transac-

tions, and centralized hardware error detection and handling.

•I/O Agent. Interfaces to I/O devices using I/O port addresses. Can be a bus bridge to

another bus used for I/O devices, such as a PCI bridge.

•Memory Agent. Provides access to main memory.

A particular bus agent can have one or more of several roles in a transaction.

•Requesting Agent. The agent that issues the transaction.

•Addressed Agent. The agent that is addressed by the transaction. Also called the Target

Agent. A memory or I/O transaction is addressed to the memory or I/O agent that

recognizes the specif ied me mory or I /O address. A Deferred Reply tr ansaction is addressed

to the agent that issued the original transaction. Special transactions are considered to be

issued to the central agent.

1-7

COMPONENT INTRODUCTION

•Snooping Agent. A caching bus agent that observes (“snoops”) bus transactions to

maintain cache coherency.

•Responding Agent. The agent that provides the response on the RS[2:0]# signals to the

transaction. Typically the addressed agent.

Each transaction has several phases that include so me or all of the following phases.

•Arbitration Phase. No transactions can be issued until the bus agent owns the bus. A

transaction only needs to have this phase if the agent that wants to drive the transaction

doesn’t already own the bus. Note that there is a distinction between a symmetric bus

owner and the actual bu s owner. The actual bus owner is the one and only bus agent that is

allowed to drive a transaction at that time. The symmetric bus owner is the bus owner

unless the priority agent owns the bus.

•Request Phas e. This is the phase in which the transaction is actually issued to the bus. The

request agent drives ADS# and the address in this phase. All transactions must have this

phase.

•Error Phase. Any errors that occur during the Request Phase are reported in the Error

Phase. All transactions have this phase (1 clock).

•Snoop Phase. This is the phase in which cache coherency is enforced. All caching agents

(snoop agents) drive HIT# and HITM# to appropriate values in this phase. All memory

transactions have this phase.

•Response Phase. The response agent drives the transaction response during this phase.

The response agent is the target device addressed during the Request Phase unless a

transaction is deferred for later completion. All transaction s h ave this phase.

•Data Phase. The response agent drives or accepts the transaction data, if there is any. Not

all transactions have this phase.

Other com monly used terms inc lude:

A requ est initiated da ta transfer means that the request ag ent has write data to transfer. A re-

quest initiated data transfer has a requ est initiated TRDY # asserti on.

A response initia ted data transfer means that the response agent must provide the read data to

the request agent.

A snoo p initiated da ta transfer means that there was a hit to a modified line during the snoop

phase, and the agent that asserted HITM# is going to drive the modified data to the bus. This is

also called an implicit writeback because every time HITM# is asserted, the addressed memory

agent knows that writeback data will follo w . A snoop initiated data transfer has a snoop initiated

TRDY# assertion.

There is a DEFER# signal that is sampled during the Snoop Phase to determine if a transaction

can be guaranteed in-order completion at that time. If the DEFER# signal is asserted, only two

responses are allowed by the bus protocol during the Response Phase, the Deferred Respo nse

or the Retry Response. If the Deferred Response is given, the response agent must later complete

the transaction with a Deferred Reply transaction.

1-8

COMPONENT INTRODUCTION

1.5. COMPATIBILITY NOTE

In this document, some register bits are Intel Reserved. When reserved bits are documented,

treat them as fully undefined. This is essential for software compatibility with future processors.

Follow the guidelines below:

1. Do not depend on the states of any undefined bits when testing the values of defined

2. Do not dep end o n t he s tat es o f any undefined bit s when s tori n g t hem t o memor y or another

regis ter.

3. Do not depen d on the ability to retain info rmation written into any undefined bits.

4. When loading registers, always load the undefined bits as zeros.

Pentium® Pro

Processor

Architecture

Overview

2-1

CHAPTER 2

PENTIUM® PRO PROCESSOR

ARCHITECTURE OVERVIEW

The Pentium Pro processor has a decoupled, 12-stage, superpipelined implementation, trading

less work per pipestage for more stages. The Pentium Pro processor also has a pipestage time

33 percent less than the Pentium processor, which helps achieve a higer clo ck rate o n any gi v en

process.

The approach used b y the Pentium Pro processo r remov es the constraint of linear instruction se-

quencing between the traditional “fetch” and “e x ecute” phases, and open s up a wide instruction

windo w using an instruction pool. This approach allo ws the “e x ecute” phase of the Pentium Pro

processor to have much more visibility into the program’s instruction stream so that better

scheduling may take place. It requires the instruction “fetch/decode” phase of the Pentium Pro

processor to be much more i nt el lig ent in term s of pr edic ti ng pr ogram flow. Optimized schedul-

ing requires the fundamental “execute” phase to be replaced by decoupled “dispatch/execute”

and “retire” phases. This allows instructions to be started in any order but always be compl e ted

in the original program order. The Pentium Pro processor is implemented as three independent

engines coupled with an instruction pool as shown in Figure 2-1.

Figure 2-1. Three Engines Communicating Using an Instruction Pool

Dispatch

/Execute

Unit

Retire

Unit

Instruction

Pool

Fetch/

Decode

Unit

2-2

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

2.1. FULL CORE UTILIZATION

The three independent-engine approach was taken to more fully utilize the CPU core. Consider

the code fragment in Figure 2-2:

The first instruction in this example is a load of r1 that, at run time, causes a cache miss. A tra-

ditional CPU core must wait for its bus interface unit to read this data from main memory and

return it before moving on to instruction 2. This CPU stalls while waiting for this data and is

thus being under-utilized.

To avoid this memory latency problem, the Pentium Pro processor “looks-ahead” into its in-

struction p ool at subs equent ins tructions and w ill do useful work rather than be stalled. In the

ex ample in F igure 2-2, inst ruction 2 is n ot e xecut able since it depends upon t he result o f inst ruc-

tion 1; how ever both instructions 3 and 4 are executable. The Pentium Pro processor executes

instructions 3 and 4 out-of-order . The results of this out-of-order execution can not be committed

to permanent machine state (i.e., the programmer-visible registers) immediately since the orig-

inal program order must be maintained. The results are instead stored back in the instruction

pool awaiting in-order retirement. The core executes instructions depending upon their readi-

ness to e xecu te, and no t on their or iginal pro gram order, and is therefore a true dat aflow engine .

This approach has the side effect that instructions are typically executed out-of-order.

The cache miss on instruction 1 will take many internal clocks, so the Pentium Pro processor

core continues to look ahead for other ins tructions that could be speculatively executed, and is

typically looking 20 to 30 instructions in front of the instruction pointer. Within this 20 to 30

instruction window there will be, on average, five branches that the fetch/decode unit must cor-

rectly predict if the dispatch/execute unit is to do useful work. The sparse register set of an Intel

Architecture (IA) processor will create many false dependencies on registers so the dispatch/ex-

ecute unit will rename the IA registers into a larger register set to enable additional forward

progress. The reti re unit owns the programmer’s IA register set and results are only comm itted

to permanent machine state in these registers w hen it removes completed instructions from the

pool in original program order.

Dynamic Execution technology can be summarized as optimally adjusting instruction executio n

by predicting program flow, having the ability to speculatively execute instructions in any

order, and then analy zing the pr ogram ’s dataflow graph to ch oose the b est order to execute

the instructions.

r1 <= mem [r0] /* Instruction 1 */

r2 <= r1 + r2 /* Instruction 2 */

r5 <= r5 + 1 /* Instruction 3 */

r6 <= r6 - r3 /* Instruction 4 */

Figure 2-2. A Typical Code Fragment

2-3

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

2.2. THE PENTIUM® PRO PR OCE SSOR PIPE LINE

In order to g et a closer loo k at how the Pentium Pro processor implements Dyn amic Execution,

Figure 2-3 shows a block diagram including cache and memory interfaces. The “Units” shown

in Figure 2-3 represent stages of the Pentium Pro processor pipeline.

Figure 2-3. The Three Core Engines Interface with Memory via Unified Caches

Bus Interface Unit

Fetch Load Store

L1 ICache L1 DCache

L2 Cache

System Bus

Dispatch

/Execute

Unit

Retire

Unit

Instruction

Pool

Fetch/

Decode

Unit

2-4

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

•The FETCH/DECODE unit: An in-order unit that takes as input the user program

instruction stream from the instruction cache, and decodes them into a series of micro-

operations (µops) that represent the dataflow of that instruction stream. The pre-fetch is

speculative.

•The DISPATCH/EXECUTE unit: An out-of-order unit that accepts the dataflow stream,

schedules execution of the µops subject to data dep endenci es and reso urce availability and

temporarily stores the results of these speculative executions.

•The RETIRE unit: An in-order unit that knows how and when to commit (“retire”) the

temporary, speculative result s to permanent architectural state.

•The BUS INTERFACE unit: A partially ordered unit responsible for connecting the three

internal units to the real world. The bus interface unit commu nicates directly with the L2

(second level) cache supporting up to four concurrent cache accesses. The bus interface

unit also controls a transaction bus, with MESI snooping protocol, to system memory.

2.2.1. The Fetch/Decode Unit

Figure 2-4 shows a mor e deta iled view of the Fetc h/Decode Unit.

Figure 2-4. Inside the Fetch/Decode Unit

(x3)

Next_IP

BTB

MIS

RAT

Allocate

From BIU

ICache

Instruction

Pool (R OB)

BIU - Bus Interface Unit

ID - Instruction Decoder

BTB - Branch Target Buffer

MIS - Microcode Instruction

Sequencer

RAT - Register Alias Table

ROB - ReOrder Buffer

2-5

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

The ICache is a local instruction cache. The Next_IP unit provides the ICache index, based on

inputs from the Branch Tar get Buffer (BTB), trap /interru pt status, and b ranch -misprediction in-

dications from the integer execution section.

The ICache fetches the cache line co rresponding to the index from the Next_IP, and the next line,

and presents 16 aligned bytes t o the decoder. The prefetched bytes are rotated so that they are

justified for the instruction decoders (ID). The beginning and end of the IA instructions are

marked.

Three parallel decoders accept this stream of marked bytes, and proceed to find and decode the

IA instructions contained therein. The decoder converts the IA instructions into triadic µops

(two logical sources, one logical destination per µop). Most IA instructions are conv erted direct-

ly into single µops, some instructions are decoded into one-to-four µops and the complex in-

structio ns requir e microcode (the box label ed MIS in Fig ure 2-4). This microcod e is just a set of

preprogrammed sequ ences of nor mal µop s. Th e µops are queu ed, and sent to the Regis te r Alias

Table (RAT) unit, where the logical IA-based register references are con v erted into Pentium Pro

processor physical reg ister references, and to the Allocator stage, which adds status information

to the µops and enters them into the instruction pool. The instruction pool is implemented as an

array of Content Addressable Memory called the ReOrder Buffer (ROB).

This is the end of the in-order pipe.

2.2.2. The Dispatch/Execute Unit

The dispatch unit selects µops from the instructio n pool depend ing upon their status. If t he status

indicates that a µop has all of its operands then the dispatch unit checks to see if the execution

resource needed by that µop is also available. If both are true, the Reservation Station removes

that µop and sends it to the resource where it is ex ecuted. The results of the µop are later retu rned

to the pool. There are five ports on the Reservation Station, and the multiple resources are

accessed as shown in Figure 2-5.

2-6

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

The Pentium Pro processor can schedule at a peak r ate of 5 µops per clock, one to each resource

port, but a sustained rate of 3 µops per clock is typical. The activity of this scheduling process

is the out-of-order process; µops are dispatched to the execution resources strictly according to

dataflow constraints and resource availability, without regard to the original ordering of the

program.

Note that the actu al algorithm employed by this execution-sched uling proces s is v itally i mpo r-

tant to per formance. If only one µo p per resource becomes data-ready per clock c ycle, then there

is no choice. But if several are a vailable, it must choose. The Pentium Pro processor uses a pseu-

do FIFO scheduling algorithm favoring back-to-back µops.

Note that many of the µops are branches. The Branch Target Buffer will correctly predict most

of these branches b ut it can’t correctly predict them all. Consider a BTB that is correctly pr edict-

ing the backward branch at the bottom of a loop; eventually that loop is going to terminate, and

when it does, that branch will be mispredicted. Branch µops are tagged (in the in-order pipeline)

with their fall- through addr ess and the destination that w as predicted for them. When the branch

ex ecutes, what the branch actually did is compared ag ainst what the prediction har dw are said it

would do. If those coincide, then the branch ev entually retires, and most of the speculativ ely ex-

ecuted work behind it in the instruction pool is good.

But if they do not coincide, then the Jump Execution Unit (JEU) changes the status of all of the

µops behi nd the b ranch to remo v e them fr om the in struction pool. In that case the p roper branch

destination is provided to the BTB which restarts the whole pipeline from the new tar get address.

Figure 2-5. Inside the Dispatch/Execute Unit

FEU

IEU

JEU

IEU

AGU

Port 0

Port 1

Port 2

Port 3,4

Load

Store

To/from

Instruction

Pool (R OB )

R S - Reservation Station

E U - Execution U nit

F EU - F lo a tin g P o in t E U

IE U - Inte ge r E U

JE U - Jum p EU

A G U - A ddress Generation U nit

R OB - R eOrd er B u ffer

2-7

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

2.2.3. The Retire Unit

Figure 2-6 shows a more detailed view of the Retire Unit.

The retire unit is also checking the statu s of µops in the inst ruction pool. It is look ing for µops

that have executed and can be removed from the pool. Once removed, the origi nal architectural

target of the µops is written as per the original IA instruction. The retirement unit must not only

notice which µops are complete, it must also re-impose the original program order on them. It

must also do this in the face of interrupts, traps, faults, breakpoints and mispredictions.

The retirement unit must first read the instruction pool to find the potential candidates for retire-

ment and determine which of these candidates are next in the original program order. Then it

writes the results of this cycle’ s retiremen ts to both the Instruction Pool and the Retirement Reg-

ister File (RRF). The retirement unit is capable of retiring 3 µops per clock.

2.2.4. The Bus Interface Unit

Figure 2-7 shows a more detailed view of the Bus Interface Unit.

Figure 2-6. Inside the Retire Unit

RS - Reservation Station

MIU - Memory Interface Unit

RRF - Retirement Register File

MIU

RRF

From To

Instru ction Pool

To/from DCache

2-8

PENTIUM® PRO PROCESSOR ARCHITECTURE OVERVIEW

There are tw o types of memory access: loads and stores. Loads o nly need to specify the memory

address to be accessed, the width of the data b eing retr ieved, and the destination register. Loads

are encoded into a single µop.

Stores need to provide a memory address, a data width, and the data to be written. Stores there-

fore require two µops, one to generate the address, and o ne to generate the d ata. These µops must

later re-combine for the store to complete.

Stores are ne ver perform ed specu latively since there is no transpar ent w ay to undo them. Stores

are also never re-ordered among themselves. A store is dispatched only when both the address

and the data are available and there are no older stores awaiting dispatch.

A study of the importance of memory access reordering concluded:

•Stores must be constrained from passing other stores, for only a small impact on

performance.

•Stores can be constrained from passing loads, for an inconsequential performance loss.

•Constraining loads from passing other loads or stores has a significant impact on

performance.

The Memory Order Buffer (MOB) allows loads to pass other loads and stores by acting like a

reservation station and re-order buffer. It holds suspended loads and stores and re-dispatches

them when a blocking condition (dependency or resource) disappears.

2.3. ARCHITECTURE SUMMARY

Dynamic Execution is this combination of improved branch predictio n, speculative execu-

tion and data flow analysis that enables the Pentium Pro processor to deliver its superior

performance.

Figure 2-7. Inside the Bus Interface Unit

MOB - Memory Order Buffer

AGU - Address Generation Unit

ROB - ReOrder Buffer

Mem

I/F

MOB

DCache

From

AGU

To/from

Instruction

Pool (ROB)

Sys Mem

L2 Cache

Bus Overview

3-1

CHAPTER 3

BUS OVERVIEW

This chapter provides an overview of the Pentium Pro processor bus protocol, transactions, and

bus signals. The Pentium Pro processor supports two other synchronous busses, APIC and

JTAG. It also has PC compatibility signals and implementation specific signals. This chapter

provides a functional description of the Pentium Pro processor bus only. For the Pentium Pro

processor bus protocol specifications, see Chapter 4, Bus Protocol . For details on the Pentium

Pro processor bus transactions, see Chapter 5, Bus Transactions and Operations. For the full

Pentium Pro processor sig nal specifications, see Appendix A, Sign als Refer en ce and Table 1 1-2.

3.1. SIGNAL AND DIAGRAM CONVENTIONS

Signal names use uppercase letters, such as AD S#. Signals in a set of related signals are distin-

guished by numeric suffixes, such as AP1 for address parity bit 1. A set of signals covering a

range of numeric s uffixes is d enot ed as AP[1: 0] , for addr ess pari ty b its 1 and 0. A # s uffix indi-

cates that the signal is active low. A signal name without a # suffix indicates that the s ignal is

acti v e high .

In many cases, signals are mapped one-to-one to physical pins with the same names. In other

cases, dif ferent sign als are mapped onto the same pin. For example, this is the case with the ad-

dress pins A[35:3]#. During the first clock of the Request Phase, the address signals are driven.

The first clock is indicated by the lower case a, or just the pin name itself: Aa[35:3]#, or

A[35:3]#. During the second clock of the Request Phase other information is driven on the re-

quest pins. These signals are referenced either by their functional signal n ames DID[7:0]#, or by

using a lower case b with the pin name: Ab[23:16]#. Note also that several pins have configu-

ration functions at the active to inactive edge of RESET#.

The term asserted implies that a signal is driven to its active level (logic 1, FRCERR high, or

ADS# low). The term deasserted implies that a signal is driven to its inactive level (logic 0,

FRCERR low, or ADS# high). A signal driven to its active level is said to be active; a signal

driven to its inactive level is said to be inactive.

In timing diagrams, square and circle symbols indicate the clock in which particular signals of

interest are driven and sampled. The square indicates that a signal is driven in that clock. The

circle indicates that a signal is sampled in that clock.

All timing diagrams in this specification show signals as they are driven asserted or deasserted

on the Pentium Pro processor bus. There is a one-clock delay in the signal values observed by

bus agents. Any signal names that appear in lower case letters in brackets {rcn t} are internal sig-

nals only, and are not driven to the bus. Upper case letters that appear in brackets represent a

group of signals such as the Request Phase signals {REQUEST}. The timing diagrams some-

times include internal signals to indicate internal states and show ho w it affec ts external signals.

3-2

BUS OVERVIEW

When signal v alues are referenced in tables, a 0 indicates inacti ve and a 1 indicates acti v e. 0 and

1 do not r eflect voltage levels. Remember, a # after a signal name indicates active low. An entr y

of 1 for ADS# means that ADS# is active, with a low voltage level.

3.2. SIGNALING ON THE PENTIUM® PRO PROCESSOR BUS

The Pentium Pro processor bus supports a synchronous latched protocol. On the rising edge of

the bus clock, all agents on the Pentium Pro p rocessor bus are required to drive their active ou t-

puts and sample required inputs. No additional logic is located in the output and input paths be-

tween the buffer and the latch stage, thus keeping setup and hold times constant for all bus

signals following the latched protocol. The Pentium Pro processor bus requires that ev ery input

be sampled during a valid sampling window on a rising cloc k edge and its effect be driven

out no sooner than the next rising clock edge. This approach allows one full clock for inter-

component communication and at least one full clock at the receiver to compute a response.

Figure 3-1 illustrates the latched bus pro tocol as it appears on the bus. In subseq uent descrip-

tions, the protocol is described as “B# is asserted in the clock after A# is observed active”, or

“B# is asserted two clocks after A# is asserted”. Note that A# is asserted in T1, but not observ ed

acti ve until T2. The recei ving agent uses T2 to determine its response and asserts B# in T3. Oth-

er agents observe B# active in T4.

The square and circle symbols are used in the timing diagrams to indicate the cl ock in which

particular signals of interest are dr iven and sampled. The sq uare indicates that a signal is dr iven

(asserted, initiated) in that clock. The circle indicates that a signal is sampled (observed, latched)

in that clock.

3-3

BUS OVERVIEW

Any signal names that appear in brackets {} are internal signals only, and are not driven to the

bus. The timing diagrams sometimes include internal signals to indicate internal state and show

ho w it aff ects external signals. All timing diagrams in this specification show b us signals as they

are driven asserted or deasserted on the Pentium Pro processor bus. Internal signals are shown

to change state in the clock that they would be driven to the bus if they were external signals .

Internal signals actually change state internal ly one clock earlier.

Signals that are driven in the same clock by multiple Pentium Pro processor bus agents exhibit

a “wired-OR glitch” on the electrical-low-to-electrical-high transition. To account for this situ-

ation, thes e signal state trans ition s are specified to have two clocks of settlin g time when deas -

serted before they can be safely observed. The bus signals that must meet this criteria are:

BINIT#, HIT#, HITM#, BNR#, AERR#, BERR#.

Figure 3-1. Latched Bus Protocol

Assert A#

Latch A# Assert B#

12 34

Full clock allowed

for logic delays

Full clock allowed

for signal propagation

BCLK

Latch B#

3-4

BUS OVERVIEW

3.3. PENTIUM® PRO PROCESSOR BUS PROTOCOL OVERVIEW

Bus activity is hierarchically organized into operations, transactions, and phases.

An operation is a bus proced ure that appears atomic to software ev en though it may not be atom -

ic on the bus. An operation may consist of a single bus transaction, but sometimes may involve

multiple bus transactions or a single transaction with multiple data transfers. Examples of com-

plex bus operations include: locked read/modify/write operations and deferred operations.

A transaction is the set of bus acti vities related to a single bus request. A transaction begins with

bus arbit ration, and the assertion of ADS# and a transaction address. Transactions are driven to

transfer data, to inquire about or change cache state, or to provide the system with information.

A transaction contains up to six phases. A phase uses a specific set of signals to communicate a

particular type of information. The six phases of the Pentium Pro processor bus protocol are:

•Arbitration

•Request

•Error

•Snoop

•Response

•Data

Not all transactions contain all phases, and some phases can be overlapped.

3.3.1. Transac t ion Phas e Descri ption

Figure 3-2 shows all of the Pentium Pro processor bus transaction phases for two transactions

with data transfers.

3-5

BUS OVERVIEW

When the requesting agent does not own the bus, transactions begin with an Arbitration Phase,

in which a requesting agent becomes the bus owner.

After the requesting agent becomes the bus owner, the transaction enters the Request Phase. In

the Request Phase, the bus owner drives request and address information on the bus. The Re-

quest Phase is two clocks long. In the f irst clock, ADS# is driven along with the transaction ad-

dress and sufficient information to begin snoop ing and memory access. In th e second clock , th e

byte enables, deferred ID, transaction length, and other transaction information are driven.

Every transaction’s third phase is an Error Phase which occurs three clocks after the Request

Phase begins. The Error Phase indicates any parity errors triggered by the request.

Every transaction that isn’t cancelled because an error was indicated in the Error Phase has a

Snoop Phase, four or more clock s from the Req uest Phase. The snoop results indicate if the ad-

dress dri ven for a transaction references a v alid or mod if ied (dirty) cache line in any bu s agent’s

cache. The snoop results also indicate whether a transaction will be completed in-order or may

be deferred for possible out-of-order completion.

Every transaction that isn’t cancelled because an error was indicated in the Error Phase has a

Response Phase. The Response Phase indicates whether the transaction has failed or succeeded,

whether transaction completion is immediate or deferred, whether the transaction will be retried,

and whether the transaction contains a Data Phase. The val id transaction responses are:

•Normal Data

•Implicit Writeback

•No Data

•Hard Failure

Figure 3-2. Pentium® Pro Processor Bus Transaction Phases

BCLK

Arbitration

Request

Response

Data Transfer

Error

Snoop

1 2 3 456789

10 11 12* 13 14 15 16

NOTE: The shaded vertical bar indicates one or more clock cycles are allowed between different phases.

3-6

BUS OVERVIEW

•Deferred

•Retry

If the transaction does not have a Data Phase, that transaction is complete after the Response

Phase. If the request agent has write dat a to transfer or is requesting read data, the transaction

has a Data Phase which may extend beyond the Response Phase.

Not all transactions contain all phases, not all phases occur in order, and some phases can be

overlapped.

•All transactions that are not cancelled in the Error Phase have the Request, Error, Snoop,

and Response Phases.

•Arbitration can be explicit or implicit. The Arbitration Phase only needs to occur if the

agent that is driving the next transaction does not already own the bus.

•The Data Phase only occurs if a transaction requires a data transfer. The Data Phase can be

absent, response initiated, request ini tiated, snoop initiated, or request and snoop initiated.

•The Response Phase overlaps with the beginning of the Data Phase for read transactions.

•The Response Phase (TRDY#) triggers the Data Phase for write transactions.

In addition, since the Pentium Pro processor bus supports bus transaction pipelining, phases

from one transaction can overlap phases from another transaction, see Figure 3-2.

3.3.2. Bus Transaction Pipelining and Transaction Tracking

The Pentium Pro processor bus architecture supports pipelined transactions in which bus trans-

actions i n dif ferent phases over lap. The Penti um Pro pro cessor bus may be conf igured t o support

a maximum of 1 or 8 outstanding transact ions simultaneously. Each Pentium Pro processor is

capable of issuing up to four outstanding transactions.

In order to track transactions, all bus agents must track certain transaction information. The

transaction information that must be tracked by each bus agent is:

•Number of transactions outst a nding

•What transaction is next to be snooped

•What transaction is next to receive a response

•If the transaction was issued to or from this agent

This information is tracked in a queue called an In- orde r Queue (I OQ). All b us ag ents maintain

identical In-order Queue status to track every transaction that is issued to the b us. When a trans-

action is issued to the bus, it is also entered in the IOQ of each agent. The depth of the smallest

IOQ is the limit of how many transactions can be outstanding on the bus simultaneously. Be-

cause transactions receive their responses and data in the same order as they were issued, the

transaction at the top of the IOQ is the next transaction to enter the Response and Data Phases.

A transaction is remov ed from the IOQ after the Response Phase is complete or after an error is

detected in the Error Phase. The simp lest b us agents can simp ly cou nt events rather than impl e-

ment a queue.

3-7

BUS OVERVIEW

Other, agent specific, bus information must be tracked as well. Note that not every agent needs

to track all of this additional information. Examples of additional information that might be

tracked follow.

Request agents (agents that issue transactions) might track:

•How many more transactions this agent can still issue?

•Is this transaction a read or a write?

•Does this bus agent need to provide or accept data?

Response agents (agents that can provide transaction response and data) might track:

•Does this agent own the response for the transaction at the top of the IOQ?

•Does this transaction contain an implicit writeback data and does this agent ha v e to receive

the writeback data?

•If the transaction is a read, does this agent own the data transfer?

•If the transaction is a write, must this agent accept the data?

•Availability of buffer resources so it can stall further trans actions if it needs to.

Snooping agents (agents with a cache) might track:

•If the transaction needs to be snooped.

•If the Snoop Phase needs to be extended.

•Does this transaction contain an imp licit writeback data to be supplied by this agent?

•How many snoop requests are in the queue.

Agents whose transactions can be deferred might track:

•The deferred transaction and its agent ID.

•Availability of buffer resources.

This transaction information can be tracked by implementing multiple queues or one all encom-

passing In-order Queue. This document refers to these internal queue(s) as the Transaction

Queues (T Q), un le ss the In-o r de r Queu e is sp ecifically being ref er en ced. No te t hat the IOQ

is completely visible from the bus protocol, but the Transaction Queues use internal state

information.

3.3.3. Bus Transactions

The Pentium Pro processor bus supports the following types of bus transactions.

•Read and write a cache line.

•Read and write any combination of bytes in an aligned 8-byte span.

3-8

BUS OVERVIEW

•Read and write multiple 8-byte spans.

•Read a cache line and invalidate it in other caches.

•Invalidate a cache line in other caches.

•I/O read and write.

•Interrupt Acknowledge (requiring a 1 byte interrupt vector).

•Special transactions are used to send various messages on the bus. The special transaction

for the Pentium Pro processor are:

—Shutdown

—Flush

—Halt

—Sync

— Flus h Ac k nowledge

— Stop Clock Acknowledge

— SMI Acknowledge

— Branch trace message (providing an 8-byte branch trace address)

•Deferred reply to an earlier read or write that received a deferred response.

Specific descriptions of each transa ction can be found in Chapte r 5, Bus Transactions an d

Operations.

3.3.4. Data Transfers

The Pentium Pro processor bus distinguishes between memory and I/O transactions.

Memory transactions are used to transfer data to and from memory. Memory transactions ad-

dress memory using the full width of the address bus. The Pentium Pro processor can address

up to 64 Gbytes of physical memory.

I/O transactions are used to transfer data to and from the I/O address space. The Pentium Pro

processor limits I/O accesses to a 64K + 3 byte I/O address space. I/O transactions use A[16:3]#

to address I/O ports and always deassert A[35:17]#. A16# is zero except when the first three

bytes abo ve the 64KByte address space are accessed (I/O wraparound). This is required for com-

patibility with previous Intel processo rs.

The Pentium Pro processor bus distinguishes between different transfer lengths.

3-9

BUS OVERVIEW

3.3.4.1. LINE TRANSFERS

A line transfer reads or wri tes a cache line, the unit of caching in a Pentium Pro processor sys-

tem. On the Pentium Pro pro cessor t hi s is 32 b y tes ali g ned on a 32-byte boundar y. Whil e a line

is always aligned on a 32-byte boundary, a line transfer need not begin on that boundary. For a

line transfer o n the Pentium Pro pro cessor, A[35:3]# car ry the u pper 33 bits of a 3 6-bit ph ysical

address. Address bits A[4:3]# determine the transfer order, called bu rst o rd er. A line is trans-

ferred in four eigh t-byte chunks, each of which can be identified by ad dress bits 4:3. The chunk

size is 64-bits. Table 3-1 specifies the transfer order used for a 32-byte line, based on address

bits A[4:3]# specified in the transaction’s Request Phase.

Note that the requested read data is always transferred f irst. Unlike the Pentium processor , which

always transfers writeback data address 0 first, the Pentium Pro processor transfers writeback

data requ ested address firs t.

3.3.4.2. PART LINE ALIGNED TRANSFERS

A part-line aligned transfer moves a quantity of data smaller than a cache line but an even mul-

tiple of the chunk size between a bus agent and memory using the b urst order. A part-line trans-

fer affects no more than one line in a cache.

A 16-byte transfer on a 64-bit data bus with a 32-byte cache line size is a part-line transfer , where

a chunk is eight bytes aligned on an eight-byte boundary. All chunks in the span of a part-line

transfer are moved across the data bus. Address bits A[4:3]# determines the transfer order for

the included chunks, using the burst order specified in Table 3-1 for line transfers.

A 16-byte aligned transfer requires two data transfer clocks on a 64-bit bus. Note that the Pen-

tium Pro processor will not is sue 16-byte transactions.

3.3.4.3. PARTIAL TRANSFERS

On a 64-bit data bus, a partial transfer moves from 0-8 bytes within an aligned 8-byte span to or

from a memory or I/O address. The byte enab le signals, BE[7:0]#, select which by tes in the span

are transferred.

Table 3-1. Burst Order Used For Pentium® Pro Processor Bus Line Transfers

A[4:3]#

(binary)

Requested

Address

(hex)

1st Address

Transferred

(hex)

2nd Address

Transferred

(hex)

3rd Address

Transferred

(hex)

4th Address

Transferred

(hex)

00 0 0 8 10 18

01 8 8 0 18 10

10 10 10 18 0 8

11 18 18 10 8 0

3-10

BUS OVERVIEW

The Pentium Pro processor converts non-cacheable misaligned memory accesses that cross 8-

byte bound aries into two partial transfers. For e xample, a non-cacheable, misaligned 8-byte read

requires two Read Data Partial transactions. Similarly, the Pentiu m Pro processor converts I/O

write accesses that cross 4-byte boundaries into 2 partial transfers. I/O reads are treated the same

as memory reads.

On the Pentium Pro processor , I/O Read and I/O Write transactions are 1 to 4 byte partial trans-

actions.

3.4. SIGNAL OVERVIEW

This section describes the function of the Pentium Pro processor bus signals. In this section, the

signals are grouped according to function.

In many cases, signals are mapped one-to-one to physical pins with the same names. In other

cases, dif ferent sig nals are mapp ed on to the same pin. F o r example, this is the case with the ad-

dress pins A[35:3]#. During the first clock of the Request Phase, the address signals are dri v en .

The first clock is indicated by the lower case a, or just the pin name itself: Aa[35:3]#, or

A[35:3]#. During the second clock of the Request Phase, other information is driven on the re-

quest pins . These signals are referenced eith er by their functi onal signal names DID[7:0]# , or by

using a lower case b with the pin name: Ab[23:16]#. Note that several pins also have configu-

ration functions at the active to inactive transition of RESET#.

3.4.1. Execution Control Signals

The BCLK (Bus Clock) input signal is the Pentium Pro processor bus clock. All agents drive

their outputs and latch their inputs on the BCLK rising edge. Each Pentium Pro processor de-

rives its internal clock from BCLK by multiplying th e BCLK frequency by a multiplier deter-

mined at configuration. See Chapter 9, Configuration for configuration specif i cations.

The RESET# input signal resets all Pentium Pro processor bus agents to known states and in-

validates their i nternal caches. Modified or dirty cach e lines are NOT written back. After RE-

SET# is deasserted, each Pentium Pro processor begins execution at the power on reset vector

defined during configuration. On observing active RESET#, all bus agents must deassert their

outputs within two clocks. Configuration parameters are sampled on the clock following the

sampling of RESET# inactive. (Two clocks following the deassertion of RESET#.)

Table 3-2. Execution Control Signals

Pin/Signal Name Pin/Signal Mnemonic Number

Bus Clock BCLK 1

Initialization INIT#, RESET# 2

Flush FLUSH# 1

Stop Clock STPCLK# 1

Interprocesso r Communication and Interrupts PICCLK, PICD[1:0]#, LINT[1:0] 5

3-11

BUS OVERVIEW

The INIT# input signal resets all Pentium Pro processor bus agents without affecting their inter-

nal (L1 or L2) caches or their floating-point registers. Each Pentium Pro processor begins exe-

cution at the address vector as defined during power on configuration. INIT# has another

meaning on RESET#’s active to inacti ve tran sition: if INIT# is sampled active on RE SET#’ s ac-

tive to inactive trans ition, then the Pentium Pr o processor executes its built-in self test (BIST).

If the FLUSH# input signal is asserted, the Pentium Pro processor bus agent writes back all in-

ternal cache lines in the Modified state (L1 and L2 caches) and invalidates all internal cache

lines (L1 and L2 caches). The flush operation puts all internal cache lines in the Invali d state.

After all lines are written back and inv alidated, the Pentium Pro processor drives a special trans-

action, the Flush Acknowledge transaction, to indicate completion of the flush operation. The

FLUSH# signal has a different meaning when it is sampled asserted on the active to inactive

transition of RESET#. If FLUSH# is sampled asserted on the activ e to inactiv e transition of RE-

SET#, then the Pentium Pro processor tristates all of its outputs. This function is used during

board testing.

The Pentium Pro pr ocessor supplies a STPCLK# pin to enable the p rocessor to enter a lo w po w-

er state. When STPCLK# is asserted, the Pentium Pro processor puts itself into the stop grant

state, issues a Stop Grant Acknowledge special transaction, and optionally stops providing in-

ternal clock signals to all units except the bus unit and the APIC unit. The processor continues

to snoop bus transactions while in stop grant state. When STPCLK# is deasserted, the processor

restarts its internal clock to all units and resumes execution . The assertion of STPCLK# has no

effect on the bus clock.

The PICCLK and P ICD[1:0]# si gnals support the Adv anced Pro grammable I nterrupt Cont roller

(APIC) interface. The PICCLK signal is an input clock to the Pentium Pro processor for syn-

chronous operation of the APIC bus. The PICD[1:0]# signals are used for bidirectional serial

message passing on the APIC bus.

LINT[1:0] are local interrupt signals, also defined by the APIC interface. In APIC disabled

mode, LINT0 defaults to INTR, a maskable interrupt request signal. LINT1 defaults to NMI, a

non-maskable interrupt. Both signals are asynchronous inpu ts. In the APIC enable mode, LINT0

and LINT1 are defined with the local vector table.

LINT[1:0] are also used along with the A20M# and IGNNE# signals to de termine the multiplier

for the internal clock frequency as described in Chapter 9, Configuration.

3-12

BUS OVERVIEW

3.4.2. Arbitration Phas e Signals

This signal group is used to arbitrate for the bus.

Up to five agents can simultaneously arbitrate for the bus, one to four symmetric agents (on

BREQ[3:0]#) and one priority agent (on BPRI#). Pentium Pro processors arbitrate as symmetric

agents. The priority agent normally arbitrates on behalf of the I/O subsystem (I/O agents) and

memory subsystem (memory agents).

Owning the bus is a necessary condition for initiating a bus transaction.

The symmetric agents arbitrate for the bus based on a round-robin rotating priority scheme. The

arbitration is fair and symmetric. After reset, agent 0 has the highest priority followed by agents

1, 2, and 3. All bus agents track the current bus owner. A symmetric agent requests the bus by

asserting it s BREQn# signal. Based on the values samp led on BREQ[3:0]#, and the last sym-

metric bus owner, all agents simu ltaneously determi ne the next symmetric bus owner.

The priority agent asks for the bus by asserting BPRI#. The assertion of BPRI# temporarily

overrides, but does not otherwis e alter the symmetric arbitration sch eme. When BPR I# is sa m-

pled acti ve, no symmetric agent issues another unlocked bus transaction until BPRI# is sampled

inactive. The priority agent is always the next bus owner.

BNR# can be asserted by any bus agent to block further transactions from being issued to the

bus. It is typically asserted when system resources (such as address and/or data buffers) are

about to become temporarily busy or filled and cannot accommodat e another transaction. After

bus initialization, BNR# can be asserted to delay the first bus transaction until all b us agents are

initialized.

The assertion of the LOC K# sign al ind icates that the bus agent is e xecuting an atomic seque nce

of b us transactions that must not be interrupted. A lock ed operation can not be interrupted b y an-

other transaction regardless of the assertion of BREQ[3:0]# or BPRI#. LOCK# can be used to

implement memory-based semaphores. LOCK# is asserted from the first transaction’s Request

Phase through the last transaction’s Response Phase.

Ta ble 3-3. Arbitration Phase Signals

Pin/Signal Name Pin Mnemonic Signal Mnemonic Number

Symmetric Agent Bus Request BR[3:0]# BREQ[3:0]# 4

Priority Agent Bus Request BPRI# BPRI# 1

Block Next Request BNR# BNR# 1

Lock LOCK# LOCK# 1

3-13

BUS OVERVIEW

3.4.3. Request Signals

The request signals transfer request information, including the transaction address. A Request

Phase is two clocks long beginning with the assertion of ADS#, the Address Strobe signal, as

shown in Table 3-4.

The assertion of ADS# defines the beginning of the Request Phase. The REQa[4:0]# and

Aa[35:3]# sig nals are valid in the clock that ADS# is asserted. Th e REQb[4:0]#, ATTR[7:0]#,

DID[7:0], BE[7:0]#, an d the EXF[4:0]# signals are all v alid in the clock after ADS# is asserted.

RP# and AP[1:0]# are valid in both clocks of the Request Phase. The LOCK# signal from the

Arbitration Phase is asserted in the clock that ADS# is asserted for a bus locked operation.

The REQa[4:0]# and th e REQb[4:0]# sig nals identify th e transaction typ e as defined by Tab l e

3-5. Note that partial memory read/write transactions can be locked on the bus by asserting

the LOCK# signal. Transactions are described in detail in Chapter 5, Bus Transactions and

Operations.

NOTES:

1. These signals are driven on the indicated pin during the first clock of the Request Phase (the clock in

which ADS# is driv en asserted).

2. These signals are driven on the indicated pin during the second clock of the Request Phase (the clock

after ADS# is driven asserted).

Table 3-4. Request Signals

Pin Name Pin Mnemonic Signal Name Signal Mnemonic Number

Address Strobe ADS# Address Strobe ADS# 1

Request Command REQ[4:0]# Request1REQa[4:0]# 5

Extended Request2REQb[4:0]#

Address A[35:3]# Address1Aa[35:3]# 33

Debug (optional)2Ab[35:32]#

Attributes2ATTR[7:0]# or

Ab[31:24]#

Deferred ID2DID[7:0]# or

Ab[23:16]#

Byte Enables2BE[7:0]# o r

Ab[15:8]#

Extended Functions2EXF[4:0]# or

Ab[7:3]#

Address Parity AP[1:0]# Address Parity AP[1: 0]# 2

Request P arity RP# Request P arity RP# 1

3-14

BUS OVERVIEW

NOTES:

1. All commands must determine response ownership with REQa.

2. For the Pentium® Pro processor , x implies “don’t care.”

3. All memory commands must be snooped.

4. Special Transactions are encoded by the byte enables. See Table 3-10.

5. D/C# indicates data or code. 0 = Code, 1 = Data.

6. W/WB# = 0 indicates writeback, W/WB# = 1 indicates write.

7. ASZ# indicates address bus size. See Table 3-6.

8. LEN# indicates the length of the data transfer. See Table 3-7.

9. REQa0# active indicates the bus agent will have to provide write data and must have a TRDY#.

10. REQa1# or REQa2# active indicate that the transaction is to memory.

11. DSZ# is dr iven by the initiator and ignored by the responder. For the Pentium Pro processor, DS Z# =

00.

Table 3-5. Transaction Types Defined by REQa#/REQb# Signals

Transaction REQa[4:0]# REQb[4:0]#

432 1 043210

Deferred Reply 0 0 0 0 0 x x x x x

Rsvd

(Ignore)

000 0 1x xx x x

Interrupt Acknowledge 0 1 0 0 0 DSZ# x 0 0

Special Transactions 0 1 0 0 0 DSZ# x 0 1

Rsvd

(Central agent response)

010 0 0DSZ#x1x

Branch Trace Message 0 1 0 0 1 DSZ# x 0 0

Rsvd

(Central agent response)

010 0 1DSZ#x01

Rsvd

(Central agent response)

010 0 1DSZ#x1x

I/O Read 1 0 0 0 0 DSZ# x LEN#

I/O Write 1 0 0 0 1 DS Z# x LEN #

Rsvd

(Ignore)

110 0 x DSZ# xx x

Memor y Read & Invalidate ASZ# 0 1 0 DSZ# x LEN#

Rsvd

(Memory Write)

ASZ# 0 1 1 DSZ# x LEN#

Memor y Code Read ASZ# 1 D/C#=0 0 DSZ# x LEN#

Memor y Data Read ASZ# 1 D/C#=1 0 DSZ# x LEN#

Memor y Write

(may not be retr ied) ASZ# 1 W/WB#=0 1 DSZ# x LEN#

Memory Write (ma y be retried) ASZ# 1 W/WB#=1 1 DSZ# x LEN#

3-15

BUS OVERVIEW

If the memory access is within the 0-to-(4GByte -1) address space, ASZ[1:0]# must be 00B. If

the memory access is within the 4Gbyte-to-(64GByte -1) address space, ASZ[1:0]# must be

01B. All observing bus agents that support the 4Gbyte (32 bit) address space must respond to

the transaction only when ASZ[1:0]# equals 00B. All observing bus agents that support the

64GByte (36- bi t) address space must respond to th e transaction when ASZ[1:0]# equals 00B or

01B.

The LEN[1:0]# signals determine the length of the transfer. The Pentium Pro processor will not

issue a request for a 16 byte data transfer.

In the clock that ADS# is asserted, the Aa[35:3]# signals provide a 36-bit, active-low

address as part of the request. The Pentium Pro processor physical address space is 236 bytes

or 64-Gigabytes (64 Gbyte). Address bits 2, 1, and 0 are mapped into byte enable signals

f or 0 to 8 byte transfers.

The address signals are protected by the AP[1:0]# pins. AP1# covers A[35:24]#, AP0# covers

A[23:3]#. AP[1:0]# must be valid for two clocks beginning when ADS# is asserted. A parity

error detected on AP[1:0]# is indicated in the Error Phase. A parity signal on the Pentium Pro

processor b us is correct if there are an even number of electrically lo w signals in the set consist-

ing of the covered signals plus the parity signal. Parity is computed using voltage lev els, re gard-

less of whether the cov e red signals are active high or active lo w.

The Request Parity pin RP# covers the request pins REQ[4:0]# and the address strobe, ADS#.

RP# must be valid for two clocks beginning when ADS# is asserted. A parity error detected on

RP# is indicated in the Error Phase.

In the clock after ADS# is asserted, the A[35:3]# pins supply cache attribute information, a

deferred ID, the byte enables and other information regarding the transaction. Specifically,

the following signals are supported: ATTR[7:0]#, DID[7:0]#, BE[7:0]#, and EXF[4:0]#. The

description for these signals follows.

Table 3-6. Address Space Size

ASZ[1:0]# Memory Address Space Observing Agents

0 0 32-bit 32 & 36 bit agents

0 1 36-bit 36 bit agents only

1 0 Reserved None

1 1 Reserved None

Table 3-7. Length of Data Transfer

LEN[1:0]# Length BE[7:0]#

0 0 0-8-bytes Specify granularity

0 1 16-bytes All active

1 0 32-bytes All active

11 Reserved

3-16

BUS OVERVIEW

The ATTR[7:0]# pin s descr ibe the cache attributes. They are driven based on the Memo ry Type

Range Register attributes and the Page Table attributes as described in Table 3-8. See Chapter

6, Range Registers for a description of the memory types.

The DID[7:0]# signals contain the request agent ID on bits DID[6:4]#, the transaction ID on

DID[3:0]#, and th e agent type on DID[7]#. Symmetric agents use an agent type of 0. All priority

agents use an agent type of 1. Every deferrable transaction (DEN# asserted) issued on the Pen-

tium Pro processor bus w hich has not been guaranteed completion will have a unique Deferred

ID. After one of th ese transactions passes its Snoop Result Phase without DEFER# asserted, its

Deferred ID may be reused. During a deferred reply transaction, the Deferred ID of the agent

that deferred the original transaction is driven instead of an address.

The Byte Enab les BE[7:0]# are used to determine wh ich bytes of data sh ould be transferred if

the data transfer is less th an 8 bytes wide. BE7# applies to D[63 :56], BE0# applies to D[7:0].

The byte enables are also used for special transaction encoding (see Table 3-10).

Table 3-8. Memory Range Register Signal Encoding

ATTR[7:0]# Memory Type Description

00000000 UC UnCacheable

00000100 WC Write-combining

00000101 WT WriteThrough

00000110 WP WriiteProtect

00000111 WB WriteBack

All others Reserved

Table 3-9. DID[7:0]# Encoding

DID[7]# DID[6:4]# DID[3:0]#

Agent Type Agent ID Transaction ID

3-17

BUS OVERVIEW

The Extended Functions, EXF[4:0]#, supported are listed in Table 3-11.

EXF4# (SMM Memory) is asserted by the Pentium Pro processor if the processor is in System

Management Mode and indicates that the processor is accessing a separate “shadow” memory,

the SMRAM. Each memory or I/O agent mu st obser ve th is signal and on ly accept a tran saction

involving SMRAM if the agent provides the SMRAM.

EXF3# (Split Lock) is asserted to indicate that a locked operation is split across 32-b yte bound-

aries for writeback memory or 8-byte boundaries for uncacheable memory. Note that SPLCK#

is asserted for the first transaction in a locked op eration only.

EXF1# is asserted if the transaction can be deferred by the responding agent. EXF1# is always

deasserted for the transactions in a locked o peration, deferr ed reply transactions, and bus Write-

back Line transactions.

Table 3-10. Special Transaction Encoding on Byte Enables

Special Transaction Byte Enables[7:0]#

Shutdown 0000 0001

Flush 0000 0010

Halt 0000 0011

Sync 0000 0100

Flush Acknowledge 0000 0101

Stop Grant Acknowledge 0000 0110

SMI Acknowledge 0000 0111

Reserved all other encodings

Table 3-11. Extended Function Pins

Extended Function Pin Extended Function Signal Function

EXF4# SMMEM# Accessing SMRAM space

EXF3# SPLCK# Split Lock

EXF2# Reserved

EXF1# DEN# Defer Enable

EXF0# Reserved

3-18

BUS OVERVIEW

3.4.4. Error Phase Signals

The Error Phase signal group (see Table 3-12) contains signals driven in the Error Phase. This

phase is one clock long and al wa ys begins thr ee clocks after the Request Phase be gins (3 clocks

after ADS# is asserted).

The AERR# dri v er can be enabled or disabled as p art of the po wer on conf iguration (see Chapter

9, Configuration). If the AERR# driver of all bus agents is disabled, request and address parity

errors are ignored and no action is taken b y the Pentium Pro pro cessor bus agen ts. If the AERR#

driver of at least one bus agent is enabled, the agents observing a Request Phase check the Ad-

dress Parity signals (AP[1:0]#) and assert AERR# in the Error Phase if an address parity error

is detected. AERR# is also asserted if an RP# parity error is detected in the Request Phase.

AERR# must not be asserted by an agent for an upper address parity error (AP1#) when the

transaction address is not in the address range of the agent. Thus 32-bit agents must ignore mem-

ory trans actions unless ASZ[1 :0]# = 00B. 36- bit agents must ig nore memory tran sactions unless

ASZ[1:0]# = 00B or 01B.

The Pentium P ro processor supports tw o modes of respon se when the AERR# dri v er is enable d.

This is the “AERR# observation” which may be configured at power-up. AERR# observation

configuration must be consistent between all bus agents. If AERR# observation is disabled,

AERR# is ignored and no action is taken by the bus agents. If AERR# observation is enabled

and AERR# is sampled asserted, the request is can celled. In add ition, the r equest agen t may r e-

try the transaction at a later time up to its retry limit. The Pentium Pro processor has a retry limit

of 1, after which the error becomes a hard error as determined by the initiating processor.

If a transaction is cancelled by AERR# assertion, then the transaction is aborted, removed fro m

the In-order Queue and there are no further valid phases for that transaction. Snoop results are

ignored if they cannot be cancelled in time. All agents reset their rotating ID for bus arbitration

to the state at reset (such that bus agent 0 has h ighest priority).

3.4.5. Snoop Signals

The snoop signal group (see Table 3-13) provides snoop result information to the Pentium Pro

processor bus agents in the Snoop Phase. The Snoop Phase is four clocks after a transaction’s

Request Phase begins (4 clocks after ADS# is asserted), or the 3rd clock after the pre vious snoop

results, whichever is later.

Table 3-12. Error Phase Signals

Type Signal Names Number

Address Parity Error AERR# 1

3-19

BUS OVERVIEW

On observing a Request Phase (ADS# active) for a memory access, all caching agents are re-

quired to perf orm an in ter nal sn oop operation and appropriately retu rn HIT# and HITM# in the

Snoop Phase. HIT# and HITM# are be used to indicate that the line is valid or invalid in the

snooping agent, whether the line is in the modified (dirty) state in the caching agen t, or whether

the Snoop Phase needs to be e xtended. Th e HIT# and HIT M# signals are used to m aintain cache

coherency at the system level. A caching agent must assert HIT# and deassert HITM# in the

Snoop Phase if the agent plans to retain the line in its cache after the snoop. Ot herwise, unless

the caching agent wishes to stall the Snoop Phase, the H IT# signal should be deasserted. The

requesting agent determines the highest permissible cache state of the line using the HIT# signal.

If HIT# is asserted, the requester may cache the line in the Shared state. If HIT# is deasserted,

the requester may cache the line in the Exclusive or Shared state. Multiple caching agents can

assert HIT# in the same Snoop Phase.

A snooping agent asserts HITM# if the line is in the Modified state. After assert ing HITM#, the

agent assumes responsibility for writing back the modified line during the Data Phase (this is

called an implicit writeback).

The memory agent must observe HITM# in the Snoop Phase. If the memory agent observes

HITM# activ e, it relinquishes responsibility for the data return and becomes a target for the im-

plicit cache line writeback. The memory agent must merge the cache line being written back

with any write d ata and update memor y . The mem ory agent must also prov ide the implicit write-

back response for the transaction.

The Pentium Pro processor and bus supports self snooping. Self snooping means that an

agent can snoop its own request and driv e the snoop result in the Snoop Phase. The Pentium

Pro processor uses self-snooping to resolve certain boundary conditions associated with

bus-lock oper ations that hit Modified cac he lines, and co nflicts associa ted with page table

aliasing. Because the Pentium Pro processor uses self-snooping, the memory agent must

always provide supp ort for implicit writebacks, even in uniprocessor systems.

If HIT# and HITM# are sampled asserted together in the Snoop Phase, it means that a caching

agent is not ready to indicate sn oop status, and it n eeds to stall the Sno op Phase. Th e snoo p sig-

nals (HIT#, HITM#, and DEFER#) are sampled again two clocks lat er. This process continues

as long as the stall state is sampled. The snoop stall is provided to stretch the com pletion of a

snoop as needed by any agent that needs to block further progress of snoops.

The DEFER# signal is also driven in the Snoop Phase. DEFER# is deasserted to indicate that

the transaction can be guaranteed in-order completion. An agent asserting DEFER# ensures

proper re moval of the tr ansaction from the In-order Q ueue by generating the appr opriate

response. There are three valid responses when DEFER# is sampled asserted (and HITM# is

sampled deasserted): the deferred response, implying that the operation will be completed at a

Table 3-13. Snoop Signals

Type Signal Names Number

Keeping a Non-Modified Cache Line HIT# 1

Hit to a Modified Cache Line HITM# 1

Defer Transaction Completion DEFER# 1

3-20

BUS OVERVIEW

later time; a retry response, imply ing that the transaction should be retried; or a hard erro r

response.

HITM# overrides DEFER# to determine the response type. DEFER# may still affect a locked

operation. See Chapter 5, Bus Transactions and Operations for details.

The requesting agen t observ es HIT#, HITM#, and DEFER# to determ ine the line’s f inal state in

its cache. DEFER# inactive enables the requesting agent to complete the transaction in order and

make the transition to the final cache state. A transaction with DEFER# active (and HITM# in-

active) can be completed with a deferred reply transaction (and a delayed transition to final

cache state) or can be retried.

3.4.6. Response Signals

The response signal group (see Table 3-14) provides response information to the requesting

agent in the Response Phase. The Response Phase of a transaction occu rs after the Snoop Phase

of the same transaction, and after the Response Phase of a previous transaction. Also, if the

transaction includes a data transfer , the data transfer of a pre viou s transaction must be complete

before the Response Phase for the new transaction is entered.

Requests initiated in the Request Phase enter the In-order Queue, which is maintained by every

agent. The response agent is the agent responsible for completing the transaction at the top of

the In-order Queue. The response agent is the agent addressed by the transaction.

For write transactions, TRDY# is asserted by the response agent to indicate that it is ready to

accept write or writeback data. For write transactions with an implicit writeback, TRDY#

is asserted twice, first for the write data transfer and then again for the implicit writeback

data transfer.

The response agent asserts RS[2:0]# to indicate one of the v alid transaction responses indicated

in Table 3-15.

Table 3-14. Response Signals

Type Signal Names Number

Response Status RS[2:0]# 3

Response Par ity RSP# 1

Target Ready (for writes) TRDY# 1

3-21

BUS OVERVIEW

The R S2#, RS1#, and R S0# signa ls must be inte rpreted together and cannot be inter preted

individually.

The RSP# signal provides parity for RS[2:0]#. RSP# must be valid on all clocks, not just re-

sponse clocks. A parity signal on the Pentium Pro processor bus is correct if there are an even

number of low signals in the set consisting of the covered signals plus the parity signal. Parity

is computed using voltage levels, regardless of whether the covered signals are active high or

acti v e low.

3.4.7. Data Phase Signals

The data transfer signa ls group (see Table 3-16) contains signals dri v en in the Data Phase. Some

transact io ns do no t t rans fer dat a and have no Data P has e. A Dat a P h ase r a nge s from one to four

clocks of actual data being transferred. A cache line transfer takes four data transfers on a 64-bit

bus. A transfer can contain waitstates which extends the length of the Data Phase. Read trans-

actions have zero or one Data Phase, write transactions have zero, one or two Data Phases.

Table 3-15. Transaction Response Encodings

RS2# RS 1# RS0# Description and Required Snoop Result

0 0 0 Idle state. (The RS[2:0]# pins must be driven inactive aft er being

sampled asserted)

0 0 1 Retry response.

0 1 0 Deferred response. The data bus is used only by a writing agent.

0 1 1 Reserved.

1 0 0 Hard failure response.

1 0 1 No Data response.

1 1 0 Implicit writeback response. A snooping agent will transf er writeback

data on the data bus. Memory agent must merge writeback data

with any transaction data and provide the response. (HITM#=1)

1 1 1 Normal data response

Tabl e 3- 16. Data Phase Signals

Type Signal Names Number

Data Ready DRDY# 1

Data Bus Busy DBSY# 1

Data D[63:0]# 64

Data ECC Protection DEP[7:0]# 8

3-22

BUS OVERVIEW

DRDY# indicat es that valid data is on the bus and mus t be latche d. The data bus owner asserts

DRDY# for each clock in which valid data is to be transferred. DRDY# can be deasserted to

insert wait states in the Data Phase.

DBSY# is used to hold the bus before the first DRDY# and between DRDY# assertions for a

multiple clock data transfer. DBSY# need not be asserted for single clock data transfers if no

wait states are needed.

During deferred reply transactions, the agent that initiates the deferred reply provides the re-

sponse for the transaction. If there is data to transfer, it is transferred with the sam e protocol as

read data (in other words, no TRDY# is needed).

The D[63:0]# signals provide a 64-bit data path between bus agents. For a partial transfer, in-

cluding I/O Read and I/O Write, the byte enable signals, BE[7:0]# determine which bytes of the

data bus will contain the valid data.

The DEP[ 7:0]# s ignals pr ov ide o ptional ECC (err or corr ectin g code) cov erin g D[63:0] #. As d e-

scribed in Ch apter 9, Configuration, the Pentium Pro processor data bus can be configured with

either no checking or ECC. If ECC is enabled, then DEP[7:0]# pro vides v alid ECC for the entire

data bus on each data clock, regardless of which bytes are enabled. The error correcting code

can correct single bit errors and detect double bit errors.

3.4.8. Error Signals

The error signals group (see Table 3-17) contains error signals that are not part of the Error

Phase.

BINIT# is used to signal any bus condition that prevents reliable future operation of the bus.

Like the AERR# pin, the BINIT# d ri v er can be en abled or disabled a s part of the power-on con-

fi gur atio n (see Chapter 9, Configuration). If the BINIT# driver is di sabled, BINIT# is never as-

serted and no action is take n by the Pentium Pro pro cessor on bus errors.

Regardless of w hether the BINIT# driver is enabled, the Pentium Pro processor bus agent sup-

ports two modes o f op eration that may b e con figured at power on. These are the BINIT # ob ser-

vation and driving modes. If BINIT# observation is disabled, BINIT# is ignored and no action

is taken by the processor even if BINIT# is sampled asserted. If BINIT# observation is enabled

and BINIT# is sampled asserted, all bus state machines are reset. All agents reset their rotating

ID for bus arbitration, and internal state information is lost. L1 and L2 cache contents are not

affected. BINIT# observation and driving must be enabled for proper Pentium Pro processor

operation.

Table 3-17. Error Signals

Type Signal Names Number

Bus Initialization BINIT# 1

Bus Error BERR# 1

Internal Error IERR# 1

FRC Error FRCERR 1

3-23

BUS OVERVIEW

A machine-check exception may or may not be taken for each assertion of BINIT# as config ured

in software.

The BERR# pin is used to signal any error conditi on caused by a bus transaction that will not

impact the reliable operation of the b us protocol (fo r example, memory data err or , non-mod ified

snoop error). A bus error that causes the assertion of BERR# can be detected by the processor,

or by another bus agent. The BERR# driver can be enabled or disabled at power-on reset. If the

BERR# driver is disabled, BERR# is never asserted. If the BERR# driver is enabled, the Pen-

tium Pro processor may assert BERR#.

A machine check exception may or may not be taken for each assertio n of BERR# as config ured

at power on. The Pentium Pro processor will always disable the machine check exception by

default.

If a Pentium Pro processor detects an internal error unrelated to bus operation, it asserts IERR#.

For e xample, a parity error in an L1 or L2 cache causes a Pentium Pro processor to assert IERR#.

A machine check e xception m ay or may no t be tak en for each asser tion of IERR# as conf ig ured

with software.

Two Pentium Pro processors may be configured as an FRC (functional redundancy checking)

pair. In this configuration, one processor acts as the master and the other acts as a checker, and

the pair operates as a single, logical Pentium Pro processor . If the checker Pentium Pro processor

detects a mismatch between its internally sampled outputs and the master Pentium Pro proces-

sor’s outputs, the checker asserts FRCERR. FRCERR observation can be enabled at the master

processor with software. The master enters machine check on an FRCERR provided that Ma-

chine Check Execution is enabled.

The FRCERR si gnal is also t oggled du ring the Pen tium P ro proces sor’s rese t action. A Penti um

Pro processor asserts FRCERR one clock after RESET# transitions from its active to inactive

state. If the Pentium Pro processor ex ecutes its built-in self test (BIST), then FRCERR is assert-

ed throughout that test. When BIST completes, the Pentiu m Pro processor desserts FRCE RR if

BIST succeeds and continues to assert FRCERR if BIST f ails. If the Pentium Pro processor does

not execute the BIST action, then it keeps FRCERR asserted for less than 20 clocks and then

deasserts it.

3.4.9. Compatibility Signals

The compatibility signals group (see Table 3-18) contains signals defined for compatibility

within the Intel architecture processor family.

Table 3-18. PC Compatibility Signals

Type Signal Names Number

Floating-Point Error FERR# 1

Ignore Numeric Error IGNNE# 1

Address 20 Mask A20M# 1

System Management Interrupt SMI# 1

3-24

BUS OVERVIEW

The Pentium Pro processor asserts FERR# when it detects an unmasked floating-point error.

FERR# is included for compatibility with systems using DOS-type floating-point error

reporting.

If the IGNNE# input signal is asserted, the Pentium Pro processor ignores a numeric error and

continues to ex ecute non-co ntrol floati ng-point in structions. If t he IGNNE# input signal is deas-

serted, the Pentium Pro processor freezes on a non-control floating-point instruction if a previ-

ous instruction caused an error.

If the A20M# input signal is asserted, the Pentium Pro processor masks physical address bit 20

(A20#) before looking up a line in any internal cache and before driving a memory read/write

transaction on the bus. Asserting A20M# emulates the 8086 processor’s address wraparound at

the one Mbyte boundary. A20M# must only be asserted when the processor is in real mode.

A20M# is not used to mask external snoop addresses.

The IGNNE# and A20M# signals are valid at all times. These signals are normally not guaran-

teed recognition at specific boundaries. However, to guarantee recognition of A20M#, and the

trailing edge of IGNNE# following an I/O write instruction, these signals must be valid in the

Response Phase of the corresponding I/O Write bus transaction.

The A20M# and IGNNE# signals ha v e different meanings during a reset. A20M# and IGNNE#

are sampled on the active to inactive transition of RESET# to determine the multiplier for the

internal clock frequency, as described in Chapter 9, Configuration.

System Management Interrupt is asserted asynchronously by system logic. On accep ting a Sys-

tem Management Int errupt, the Pentium Pro processor saves the current state and enters SMM

mode. It issues an SMI Acknowledge Bus transaction and then begins program execution from

the SMM handler.

3.4.10. Diagnostic Signals

The BP[3:2]# signals are the System Support group Breakpoint signals. They are outputs from

the Pentium Pro processor that indicate the status of breakpoints.

The BPM[1:0]# signals are more System Support group breakpoint and performance monitor

signals. They are outputs from the Pent ium Pro pro cessor that ind icate the statu s of breakpoints

and programmable counters used for monitoring Pentium Pro processor performance.

Table 3-19. Diagnostic Support Signals

Type Signal Names Number

Breakpoint Signals BP[3:2]# 2

Performance Monitor BPM[1:0]# 2

Boundary Scan/Test Access TCK, TDI, TDO , TMS, TRST# 5

3-25

BUS OVERVIEW

The diagnost i c si g nals group shown in Table 3-19 provides s ignal s for probing the Pent i um Pro

processor, monitoring Pentium Pro processor performance, and implementing an IEEE 1149.1

boundary scan.

PM[1:0]# are the Performance Monitor signals. These signals are outputs from the Pentium Pro

processor that indicate the status of four programmable counters for monitoring Pentium Pro

processor perf orman ce.

TCK is the Test Clock, used to clock activity on the five-signal Test Access Port (TAP). TDI is

the Test Data In signal, transferring serial test dat a into the Pentium Pro process or. TDO is the

Test Data Out signal, transferring serial test data o ut of th e Pentium Pro pro cessor. TMS is used

to control the sequence of TAP controller state changes. TRST# is used to asynchronously ini-

tialize the TAP controller.

3.4.11. Power, Ground, and Reserved Pins

The Pentium Pro processor bus and Pentium Pro processor dedicate many pins to power and

ground signals. Refer to Chapter 15, Mechanical Specifications for the pin assignment.

Bus Protocol

4-1

CHAPTER 4

BUS PROTOCOL

This chapter describes the protocol followed by bus agents in a transaction’s six phases. The

phases are:

•Arbitration Phase

•Request Phase

•Error Phase

•Snoop Phase

•Response Phase

•Data Phase

4.1. ARBITRATION PHASE

A bus agent must have bus ownership before it can initiate a transaction. If the agent is not the

bus owner, it enters the Arbi tration Phase to obtain ownership. Once ownership is obtain e d, the

agent can enter the Request Phase and issue a transaction to the bus.

4.1.1. Protocol Overview

The Pentium Pro processor b us arbitration pr otocol supports two classes of bus agen ts: symmet-

ric agents and priority agents.

The symmetric agents support fair, distributed arbitration using a round-robin algorithm. Each

symmetric agent has a unique Agent ID between zero and three assigned at reset. The algorithm

arranges the four symmetric agents in a circular order of priority: 0, 1, 2, 3, 0, 1, 2, etc. Each

symmetric agent also maintains a common Rotating ID that reflects the symmetric Agent ID of

the most recent b us o wner. On e v ery arbitration event, th e symmetric agent with the highe st pri-

ority becomes the symmetric owner . Note that the symmetric owner is not necessarily the ov erall

bus o wner. The symmetric o wner is allowed to enter the Request Phase pro vided no other action

of higher priority is preventing the use of the bus.

The priority agent(s) has higher priority than th e symmetric owner. Once the priority agent ar-

bitrates for the bus, it prevents the symmetric owner from entering into a new Request Phase

unless the new transaction is part of an ongoing bus locked operation. The priori ty agent is al-

lowed to enter the Request Phase provided no other action of higher priority is preventing the

use of the bus.

Pentium Pro processors are symmetric agents. The priority agent normally arbitrates on behalf

of the I/O and possibly memory subsystems.

4-2

BUS PROTOCOL

Besides the two classes of arbitration agents, each bus agent has two actions available that act

as arbitration modifiers: the bus lock and the request stall.

The bus lock action is a vailable to the current symmetric owner to block other agents, including

the priority agent from acquiring the bus. Typically a bus locked operation consists of two or

more transactions issued on the bus as an indivisible sequence (this is indicated on the bus by

the assertion of the LOCK# pin). Once the s ymmetric bus owner has successfully initiated the

first bus locked transaction it continues to issue remaining requests that are part of the same in-

divisible operation witho ut releasing the bus.

The request stall action is available to any bus agent that is unable to accept new bus transac-

tions. By asserting a signal (BNR#) any agent can prevent the current bus owner from issuing

new transactions.

In summary, the priority for entering the Request Transfer Phase, assuming there is no bus stall

or arbitration reset event, is:

1. The current bus owner retains ownership until it completes an ongoing indivisible bus

locked operation.

2. The priority agent gains bus ownership over a symmetric owner.

3. Otherwise, the current symmetric owner as determined by the rotating priority is allowed

to generate new transactions.

4.1.2. Bus Signals

The Arbitration Phase signals are BREQ[3:0]#, BPRI#, BNR#, and LOCK#.

BREQ[3:0]# bus signals are connected to the four symmetric agents in a rotating manner as

shown in Figure 4-1. This arrangement initializes every symmetric agent with a unique Agent

ID during power-on configuration. Every symmetric agent has one input/output pin, BR0#, to

arbitrate for the b us during normal operation. The remaining three pins, BR1#, BR2#, and BR3#,

are input on ly an d ar e used to observe the arbi tration requ ests of the remain ing three symmetric

agents.

At reset, the central agent is responsible for asserting the BREQ0# bus signal. BREQ[3:1]#

remain deasserted. All Pentium Pro processors sample BR[3:1]# on the active to inactive tran-

sition of RESET# to determine their arbitration IDas follows :

•The BR1#, BR2#, and BR3# pins are all inactive on Agent 0.

•Agent 1 has BR3# active.

•Agent 2 has BR2# active.

•Agent 3 has BR1# active.

The BPRI# sig nal is an output from the pri ority agent by w hich it arbitrates for the bus owner-

ship and an input to the symmetric agents. The LOCK# and BNR# signals are bi-directional sig-

nals bused among all agents. The current bus owner uses LOC K# to define an indivisible bus

locked operation. BNR # is us ed by any bus agent to stall further request phase initiation.

4-3

BUS PROTOCOL

4.1.3. Internal Bus States

In order to maintain a glueless MP interface, some bus state is distributed and must be tracked

by all agents on the bus. This section describes the bus state that needs to be tracked internally

by Pentium Pro processor bus agents.

4.1.3.1. SYMMETRIC ARBITRATION STATES

As described before, each symmetric agent must maintain a two-bit Agent ID and a two-bit

Rotating ID to perform distributed round-robin arbitration. In addition, each symmetric agent

must also main tain a symmetric ownership state bit that describes if the bus ownership is being

retained by the current symmetric owner (“busy” state) or being returned to a state where no

Figure 4-1. BR[3:0]# Physical Interconnection

Agent 0 Agent 1 Agent 2 Agent 3

BR1#

BR2#

BR3#

BREQ0#

BREQ1#

BREQ2#

BREQ3#

Priority

BPRI#

Agent

BR0#

BR1#

BR2#

BR3#

System

Interface Logic

During Reset

4-4

BUS PROTOCOL

symmetric agent currently owns the bus (“idle” state). The Pentium Pro processor will enter the

idle state after AERR#, BINIT# and RESET#. The notion of idle state enables a sh orter, two-

clock arbit ration l aten cy f rom b us requ est to it s o wn ershi p. The no tio n of b us y state enables b us

parking but increases arbitration latency to a minimum of four clocks due to a handshake with

the current symmetric o wner. Bus parking means that the current b us owner maintains bus own-

ership e v en if it curren tly does not ha v e a pendin g transaction. If a transaction becomes pendin g

before that bus owner rel inqu is hes bus ownership, it can drive the tr ans actio n wi t hou t having to

arbitrate for the bus. The Pentium Pro processor implements bus parking.

4.1.3.1.1. Agent ID

An agent’s Agent ID is determined at reset and can not change without the assertion of RESET#.

The Agent ID is unique for every symmetric agent.

4.1.3.1.2. Rotating ID

The Rotating ID poin ts to the agent that will b e the lowest priority agent in the next arbitration

event with active requests, (this is the Agent ID of the current symmetric bus owner). All sym-

metric agents ma intain the same Rotating ID. The Rotating ID is initialized to 3 at reset. It is

assigned the Agent ID of the new symmetric owner after an arbitration event so that the new

ow ner becomes the lowest priority agent on the next arbitration event.

4.1.3.1.3. Symmetric Ownership State

The symmetric ownership state i s reset to idle on an arbitration reset. The state becomes busy

when an y symmetric agent completes the Arbitration Phase and becomes symmetric o wner. The

state remains busy while the current symme tric owner retains bus ownership or trans fers it to a

different symmetric agent on the next arbitration event. When the state is busy, the Rotating ID

is the same as the symmetric owner Agent ID. When the state is idle, the Rotating ID is the same

as the last symmetric owner Agent ID. Note that the symmetric ownership state refers only to

the symmetric bus owner. The priority agent can have actual physical ownership of the request

bus, even while the state is busy and there is also a symmetric bus owne r.

4.1.3.2. REQUES T STALL PROTOCOL

Any bus agent can stop all agents from issuing transactions via the BNR# (block next request)

pin. This is typically don e when the agen t has one f ree request b uffer remaining and cannot rely

on the In-order Queue depth limit to suff iciently limit the number of transactions initiated on the

bus. BNR# can be used to stall transactions for a user-defined amount of time, or it can be used

to throttle the frequency of the transactions issued to the bus. BNR# can also be used to prevent

any transactions from being issued after RESET# or BINIT# to block transactions while bus

agents initialize themselves. For deb ugging, performance monitoring, or test purposes, an agent

can assert BNR# to issue one transaction to the bus at a time (no pipelining). When stallin g the

bus, the stalling condition must be able to clear without requiring access to the bus.

4-5

BUS PROTOCOL

4.1.3.2.1. Request Stall States

The request stall protocol can be described using three states: The “free” state in which transac-

tions can be driv en to the b u s normally, one e v ery 3 clocks, th e “stalled” state in which n o trans-

actions are driv en to the b us, and the “throttled” state in which one transaction may be dri v en to

the bus. The throttled state is a temporary state wh ich will transiti on to either free or stalled at

the next sample point.

If BNR# is always active when sampled, then no transactions are driven to the bus because all

agents remain in the stalled state.

To get to the free state where transactions are driven normally to the bus (a maximum of one

ADS# every three clocks), BNR# must be sampled inactive on two consecutive sample points.

The existence of the throttled state enables one transaction to be sent to the bus e very time BNR#

is sampled deasserted. When the processor is in the throttled state, one transaction can be dri ven

to the bus. The throttled state is a temporary state.

4.1.3.2.2. BNR# Sampling

BNR# is deasserted with RESET# and BINIT#. After RESET#, BNR# is first sampled 2 clocks

after RESET# is sampled deasserted. After BINIT#, BNR# is first sampled 4 clocks after

BINIT# is sampled asserted. BNR# is a wired-OR signal and must not be driven active for two

consecutive clocks, if it is asserted in one clock, it must be deasserted in the next clock.

BNR# has two sampling modes. It is sampled every other clock while in the stalled or throttled

state, and it is sampled in the third clock after ADS# is sampled asserted in the free state.

BNR# must be driven active only during a valid sampling window and should be deasserted in

the following clock. Bus agents must ignore BNR# in the cloc k after a valid sampling window.

4.1.4. Arbitration Protocol Description

This section describes the arbitration protocol using examples. For reference, Section 4.1.5.,

“Symmetric Agent Arbitration Protocol Rules” through Section 4.1.7., “Bus Lock Protocol

Rules” list the rules.

4.1.4.1. SYMMETRIC ARBITRATION OF A SINGLE AGENT AFTER RESET#

Figure 4-2 illustrates bus arbitration initiated after a reset sequence. BREQ[3:0]#, BPRI#,

LOCK#, and BNR# must be deasserted during RESET#. (BREQ0# is asserted 2 clocks before

RESET# is deasserted for initiali zation reaso ns as describ ed in Section 4.1.2 ., “Bus S ignals”.)

Symmetric agents can begin arbitration after BIST and MP initialization by driving the

BREQ[3:0]# signals. Once ownership is obtained, the symmetric owner can park on the bus as

long as no other symmetric agent is requesting it. The symmetric owner can voluntarily release

the bus to idle.

4-6

BUS PROTOCOL

RESET# is asserted in T1, which is observed by all agents in T2. This signal forces all agents to

initialize their in ternal states and bus signals. In T3 or T4, al l agents deassert their arbi tration

request signals BREQ[3:0]#, BPRI# and arbitration modifier signals BNR# and LOCK#. The

symmetric agents reset the ownership state to idle and the Rotating ID to three (so that bus agent

0 has the highest symmetric priority after RESET# is deasserted).

In T9, after BIST and MP initialization, agent 1 asserts BREQ1# to arbitrate for the bus. In T10,

all agents observ e acti ve BREQ1# and inacti ve B REQ[0,2,3]#. During T10 , all agents determine

that agent 1 is the only symmetr ic agent arbitrating f or the b us and therefore h as the highest pri-

ority. As a result, in T11, all agents update their Rotating ID to “1”, the Agent ID of the new

symmetric owner and its ownership state to busy, indicating that the bus is busy.

Starting from T10, agent 1 continually monitors BREQ[0,2,3]# to determine if it can park on the

bus. Since BREQ[0,2,3]# are ob served inacti ve, it continues to maintain bus o wnership by keep-

ing BREQ1 # asse rt ed.

In T16, agent 1 voluntarily deasserts BREQ1# to release bus ownership, which is observed by

all agents in T17. In T18 all agents update the ownership state from busy to idle. This action

reduces the arbitration latency of a new symmetric agent to two clocks on the next arbitration

event.

Figure 4-2. Symmetric Arbitration of a Single Agent After RESET#

CLK

BREQ0#

BREQ1#

BPRI#

RESET#

BREQ2#

BREQ3#

1 2345

68910 11 13 14 15 16 17

{rotati ng id} --

3333

31 101111

{ownership} --

IIII BBBBBI

4-7

BUS PROTOCOL

4.1.4.2. SIGNAL DEASSERTION AFTER BUS RESET

Figure 4-3 illustrates how signals are deasserted after a bus reset. This relaxed deassertion pro-

tocol gives all bus agents time to initialize. Since agents must deassert bus signals in response

to both BINIT# and RESET#, agents will respond to both reset assertio ns in the same fashion.

On observation of the start of the reset event, all bus signals must be deasserted as indicated in

Figure 4-3. This event is the deasserted to asserted transition of RESET# or BINIT#. In T1 the

first agent asserts B INIT#. In T2 all agents sample RESET# or BINIT# active. In response to

observing BINIT# active in T2 any agent driving BINIT# from the first or second clock must

deassert BINIT# in T4 (see Chapter 8, Data Integrity for details on the BINIT# protocol). Also

in T4, at the latest, all agents must deassert the wired-or contr ol signals HIT#, HITM#, AER R#,

BERR# and BNR#.

In T5, BINIT#, BNR#, H IT#, HITM#, AERR# and BERR# may have invalid signal level due

to wired-or glitches. T5 is the latest that an agent can deassert all other no n wired-or b us signals.

In T6 all signals should have a valid inactive level.

All bus signals are sampled two clocks after the end of the reset event. This event for RESET#

is sampling the asserted to deasserted transition. For BINIT#, this event is the fourth clock of

BINIT# assertion. BNR# must be asserted in the clock after the end of reset event, if the agent

intends to block ADS #.

All bus drivers must be aware of potential wired-or glitches due to power on configuration. If a

signal cou ld b e driven due to p ower o n configuration, a driver must wait one ad ditional cycle

after the end of the reset event before the signal can be asserted for normal operation.

Figure 4-3. Signal Deassertion After Bus Reset

CLK

BINIT#

BNR#

wire-or signals

other signals

1 2345

4-8

BUS PROTOCOL

4.1.4.3. DELAY OF TRANSACTION GENERATION AFTER RESET

Figure 4-4 illustrates how transactions can be prev ented from being issued to the bus after reset

in order to give all bus agents time to initialize. Note that symm etric arbitration is not affected

by the state of BNR#.

Figure 4-4 is identical to Fig ure 4-2 except that BNR# is sampled as serted at its first sampling

point in T8. This keeps the request stall state in the stalled state(S) where no transactions are

allowed to be generated. Note that this does not affect the arbitration event starting with

BREQ1# assert ion in T7. Agent 1 wins symmetric o wnership in T8 , ev en though no t ransactions

may be generated.

BNR# is sampled deasserted in its next two sampling points and the request stall state transitions

through the throttled state(T) in T11 to the free state(F) in T13. Transactions can be issued by

agent 1 in any clock starting from T11 through T15.

Figure 4-4. Delay of Transaction Generation After Reset

CLK

BREQ0#

BREQ1#

BPRI#

BNR#

RESET#

BREQ2#

BREQ3#

1 2 3 4 5 6 8 9 10 11 13 14 15 16 17

{ro tating id} --3 33 311 101111

{ownership} --I I I I BBB BBI

{request stall

state} TTFFFFSSSSS

4-9

BUS PROTOCOL

4.1.4.4. SYMMETRIC ARBITRATION WITH NO LOCK#

Figure 4-5 illustrates arbitration between two or more symmetric agents while LOCK# and

BPRI# stay inactiv e. Because LOCK# a nd BPRI# rem ain inacti v e, b us ownership is determined

based on a Rotating ID and b u s o wnersh ip state. The symmetric ag ent that wins the b us releases

it to th e other ag ent as soon as po ssible (th e Pentiu m Pro process or limit s it to on e transactio n,

unless the outstanding o peration is lo ck ed). Th e symm etric agen t may re-arbitrate one clock af-

ter releasin g the bus. Also note th at when a symmetric agent n issues a transaction to t he bus,

BREQn# mu st stay asserted until the clock in which ADS# is asserted.

In T1, all arbitration requests BREQ[3:0]# and BPRI# are inactive. The bus is not stalled by

BNR#. The Rotating ID is 3 and bus ownership state is idle(I). Hence, the round-robin arbitra-

tion prio rity is 0,1,2,3.

In T2, agent 0 and agent 1 activate BREQ0# and BREQ1# respectively to arbitrate for the bus.

In T3, all agents observe inactive BREQ[3:2]# and active BREQ[1:0]#. Since the Rotating ID

is 3, during T3, all agents determine that agent 0 has the hig hest priority and is the ne xt symmet-

ric owner. In T4, all agents update the Rotating ID to zero and the bus ownership state to

busy(B).

Figure 4-5. Symmetric Bus Arbitration with no LOCK#

CLK

BREQ0#

BREQ1#

BPRI#

BNR#

ADS#

BREQ2#

BREQ3#

{REQUEST}

0a 1a 2a

1 23456789 10111213141516

{rotating id} 333 001 1 1 2000002

{ownership} IIIBBBBBBB

BB BBB

LOCK#

4-10

BUS PROTOCOL

Since BPRI# is observed inacti v e in T3 and the bus is not stalled, in T4, agent 0 can begi n a new

Request Phase. (If BPRI# has been asserted in T3, the arbitration event, the upd ating o f th e Ro-

tating ID, and ownership states would not have been affected. However, agent 0 would not be

able to drive a transaction in T4). In T4, agent 0 initiates request phase 0a.

In response to active BREQ1# observed in T3, agent 0 deasserts BREQ0# in T4 to release bus

ownership. Since it has another internal request, it immediately reasserts BREQ0# after one

clock in T5.

In T5, all symmetric agents observe BREQ0# deassertion, the release of bus ow nership by the

current symmetric owner. During T5, all s ymmetric agents recognize that agent 1 now remains

the only symmetric agent arbitrating for the bus. In T6, they update the Rotating ID to 1. The

ownership state remains busy.

Agent 1 assumes bus ownership in T6 and generates request phase 1a in T7 (three cycles from

request 0a). In response to active BREQ0# observed in T5, agent 1 deasserts BREQ1# in T7

along with the first clock of the Request Phase and releases symmetric ownership. Meanwhile,

agent 2 asserts BREQ2# to arbitrate for the bus. In T8, all agents observ e inacti v e BREQ1#, the

release of ownership by the current symmetric owner. Since the Rotating ID is one, and

BREQ0#, BREQ2# are activ e, a ll agents d etermine that ag ent 2 is the next symmetric owner. In

T9, all agents update the Rotating ID to 2. The ownership state remains busy.

In T10, (three cycles from request 1a) agent 2 drives request 2a. In response to active BREQ0#

observed in T9, agent 2 deasserts BREQ2# in T10. In T11 all agents observe inactive BREQ2#

and active BREQ0#. During T11, they recognize that agent 0 is the only symmetric agent arbi-

trating for the bus. In T12, all agents upd ate the Ro tating ID to 0. The ownership state remains

busy.

In T12, agent 0 assumes bus ownership. In T13 agent 0 initiates request 0b (t hree cycles from

request 2a). Because no other agent has requested the bus, agent 0 parks on the bus by keeping

its BREQ0# signal active.

4.1.4.5. SYMMETRIC BUS ARBITRATION WITH NO TRANSACTION

GENERATION

Figure 4-6 is a modification of Figure 4-5 to illustrate what happens if an agent n asserts

BREQn#, but does not drive a transaction. Note that once bus ownership is requested by an

agent by asserting its BREQn# sign al, BRE Qn# must not be deasserted un til bus ownership is

gained by agent n. Bus agent n need not drive a transaction, however bus ownership must be

acquired. Notice that since transaction 2a is not driven that transaction 0b can be driven sooner

than it was in Figure 4-5.

4-11

BUS PROTOCOL

This figure is the same as Figure 4-5 up until T9.

In T9, the clock that bus agent 2 wins bus ownership, bus agent 2 deasserts BREQ2# because

the need to drive the transaction was removed (for example, on the Pentium Pro processor, if a

transaction is p ending to writeback a replaced cache li ne and i t gets snooped, HITM# will be

asserted and the line will be written out as an implicit writeback. The pending transaction to

writeback the line gets cancelled).

In T10, all agents observe an inacti v e BREQ2# and an acti v e BREQ0#. During T10 the y recog-

nize that agent 0 is the only symmetric agent arbitrating for the bus. In T11, all agents update

the Rotating ID to 0. Th e ownership remains busy and agent 0 initiates request 0b. Because n o

other agent has requested the bus, agent 0 parks on the b us by keeping its BREQ0# signal active .

4.1.4.6. BUS EXCHANGE AMONG SYMMETRIC AND PRIORITY AGENTS

WITH NO LOCK#

Figure 4-7 illustrates b us e xchange between a priority agent and two symmetric agents. A sym-

metric agent rel inquishe s physical b us o wners hip to a priori ty agent as soon as possible. A max-

imum of one un lock ed ADS# can be generat ed b y the current symmetr ic b us owner in the clock

after BPRI# is asserted because BPRI# has not yet been observed. Note that the symmetric bus

own er (Rotating ID) does not change du e to the assertion of BPRI#. BPRI # does not af fect sym-

metric agent arbitration, or the symmetric b us owner. Finally , note that in this example BREQ0#

must remain asserted until T12 becau se transaction 0b has not yet been dr i ven. An agent can no t

drive a transaction unless it owns the bus in the clock in which ADS# is to be driven for that

transaction.

Figure 4-6. Symmetric Arbitration with no Transaction Generation

CLK

BREQ0#

BREQ1#

BPRI#

BNR#

ADS#

BREQ2#

BREQ3#

{REQUEST}

0a 1a

1 23456789 10111213141516

{rotating id} 333 001 1 1 00000

{ownership} IIIBB BBB B

BBB

4-12

BUS PROTOCOL

In Figure 4-7, before T1, agent 0 owns the bus. The Rotating ID is zero, the ow nership state is

busy.

In T3, the priority agent asserts BPRI# to request bus owner ship. In T4, agent 0, the current own-

er , issues its last request 0a. In T4, all symmetric agen ts observe BPRI# acti v e, and guarantee no

new unlocked request generation starting in T5.

In T3, the priority agent observes inactive ADS# and inactive LOCK# and determines that it

may not gain request bus ownership in T5 because the current request bus owner might issue

one last request in T4. In T5, the priority agent observes inacti ve LOCK# and determines that it

ow ns th e bus and may begin issuing requ est s star ting in T7, f our c lock s fro m BP RI# a sser tion

and three clocks from previous request generation.

The priority agent issues two requests, I/Oa, and I/Ob, and continues to assert BPRI# through

T10. In T10, the priority agent deasserts BPRI# to release b us o wnershi p back to the symmetric

agents. In T10, agent 1 asserts BREQ1# to arbitrate for the bus.

In T11, agen t 0, th e current s ymmetric owner observes inactive BPRI# and initiates requ est 0b

in T13 (three clocks from previous request.) In response to active BREQ1#, agent 0 deasserts

BREQ0# in T13 to release symmetric ownership. In T14 all symmetric agents observe inactive

BREQ0#, the release of ownership by the current symmetric owner. Since BREQ1# is the only

active bus request they assign agent 1 as the next symmetric owner. In T15 symmetric agents

update the Rotatin g ID to one the Agent ID of the new symmetric owner.

Figure 4-7. Bus Exchange Among Symmetric and Priority Agent with no LOCK#

CLK

BREQ0#

BREQ1#

BPRI#

LOCK#

ADS#

BREQ2#

BREQ3#

{REQUEST}

0a I/O a I/O b 0b

1 2345678910111213141516

000 00 0 00 0 000011

{ro tating id} 0

4-13

BUS PROTOCOL

4.1.4.7. SYMMETRIC AND PRIORITY BUS EXCHANGE DURING LOCK#

Figure 4-8 illustrates an ownership request made by both a symmetric an d a priority agent dur-

ing an ongoing indi visible sequence by a symmetric o wner. When this is the case, LOCK# takes

priority over BPRI#. That is, the symmetric bus ow ner do es not give up the bus to the priority

agent while it is dri ving an indi visible locked o peration. Note that b us agent 1 can hold b us o wn-

ership even though BPRI# is asserted. Like the BREQ[3:0]# signals, if the priority agent is going

to issue a transaction, BPRI# must not be driven inacti ve until the clock in which ADS# is dri ven

asserted.

Before T1, agent 0 owns the bus. In T1, agent 0 initiates the first transaction in a bus locked op-

eration by asserting LOCK# along with request 0a. Also in T1, the priority agent an d agent 1

assert BPRI# and BREQ1# respectively to arbitrate for the bus. Agent 0 does not deassert

BREQ0# or LOCK# since it is in the midd le of a bus locked operation.

In T7, agent 0 initiates the last transaction in the bus locked operation. At the request’s success-

ful completion the indi visibl e sequence is complete an d agent 0 deasserts L OCK# in T11. Since

BREQ1# is observed acti ve in T10, age nt 0 also deasserts BREQ0# in T11 to release symmetric

ownership.

The deassertion of LOCK# is observed by the priority agent in T12 and it begins new-request

generatio n from T1 3. The deas sertio n of BREQ0# is observ ed b y all s ymmetri c agents and the y

assign the symmetric ownership to agent 1, the agent with active bus request. In T13, all sym-

metric agents up date the Rotating ID to one, the Agent ID of the new symmetric owner.

Figure 4-8. Symmetric and Priority Bus Exchange During LOCK#

CLK

BREQ0#

BREQ1#

BPRI#

LOCK#

ADS#

BREQ2#

BREQ3#

{REQUEST}

0a 0b

1 23456789 10111213141516

000 00 0 0 0 00 001111

{ro tating id}

I/Oa

4-14

BUS PROTOCOL

Since agent 1 observ e d active BPRI# in T12, it guar antees n o ne w requ est g enerati on be gi nning

T13. In T13, the priority agent deasserts BPRI#. In T15, three clocks from the previous request

and at least two clocks from BPRI# deassertion agent 1, the current symmetric owner issues

request 1a.

4.1.4.8. BNR# SAMPLING

This section illustrates how BNR# is sampled by all agents, and how the stall protocol is imple-

mented. Fi gure 4-9 il lustrates B NR# samplin g as it begins afte r the process or is brou ght ou t of

reset. Figure 4-10 illustrates how BNR# is sampled once the stall protocol state machine

reaches the free state. Section 4.1.3.2., “Request Stall Protocol” may be useful as reference

when reading this section.

RESET# is asserted in T1, and observed by all agents in T2. In T3 or T4, BNR# must be deas-

serted and the request stall state is initialized to the stalled state.

In T5, RESET# is d riven inactive, and in T6, RESET# is sampled inactive. Any agent that re-

quires more time to initialize its bus unit logic after reset is allowed to delay transaction gen e r-

ation by asserting BNR# in T7. In T7, the clock after RESET# is sampled inactive, BNR# is

driven to a valid level. In T8, two clocks after RESET# is sampled i nactive, BNR# i s sampled

active, causing the processor to remain in the stalled state in T9.

Because the processor is in the stalled state, BNR# is sampled e v er y 2 clocks. B NR# is sampled

asserted again in T10, so the state remains stalled. In T12, BNR# is sampled inactive. In T13,

the request stall state transit ions to t he throttled state. One transactio n can be is sued to the bus

in the throttled state, so ADS# is driven active in T13. In the throttled state, BNR# continues to

be sampled every other clock.

Figure 4-9. BNR# Sampling After RESET#

CLK

RESET#

BINIT#

ADS#

BNR#

1 23456789 101112

13 14 15 16

- - S SSS SSSS SSTTSS

{request stall

state}

17 18 19

TT F

4-15

BUS PROTOCOL

In T14, BNR# is ag ain sampled asserted, so the state transitions to stalled in T15 and n o f urther

transactions are issued. In T16, BNR# is sampled deasserted, which causes the state machine to

transition to throttled in T17. In T1 8, BNR is again sampled deass erted, which transitions the

state machine to free in T19. BNR# is not sampled again until after ADS#, RESET#, or BINIT#.

A transaction may be issued in T17 or any time after.

Once the request stall state moves into the free state, BNR# sampling no longer occurs

every other clock, it occurs 3 clocks after ADS# is dri ven asserted. Figure 4-10 illustrates

this occurrence.

In T1, the request stall state is in the throttled state and a transaction is issued. BNR# is sampled

every other clock. BNR# is sampled asserted in T2, so the request-stall st ate transitions to the

stall state in T3 and no further transactions are issued. BNR# sampling continues every other

clock.

In T4, BNR# is sampled deasserted, so the throttled state is entered again in T5, and a transaction

is issued. In T6, BNR# is sampled deasserted again, so the request-stall state machine moves

into the free state in T7. BNR# sampling changes to the 3rd clock after ADS# is sampled activ e.

In T8 (3 clocks after the last ADS# is driven), another Request Phase is driven. In T9, 3 clocks

after the last ADS# is sampled activ e, BNR# is again sa mpled. Because BNR# is sampled deas-

serted, the state remains free in T10. ADS# could h a ve been driven asserted in T11 , but a trans-

action was not internally pending in time, so a new transaction is driven to the bus in T12.

BNR# is sampled again in T12 (3 clocks after the last ADS# was sampled activ e). BNR# is sam-

pled asserted, so in T13, the request stall state transitions to the stalled state, and BNR# sampling

returns to e very other clock. Note that the ADS# driven in T12 is the last time a transaction can

be driven to the bus after BNR# is sampled active.

In T14, BNR# is sampled deasserted so the reques t stall state tran siti ons to th rottled in T15. In

T16, BNR# is again sampled deasserted, so the state transitions to free in T17 (not shown).

Figure 4-10. BNR# Sampling After ADS#

CLK

RESET#

BINIT#

ADS#

BNR#

1 23456789 10111213141516

TTS STTFFFF FFSSTT

{request stal l

state}

4-16

BUS PROTOCOL

4.1.5. Symmetric Agent Arbitration Protocol Rules

4.1.5.1. RESET CONDITIONS

On observ ation of acti ve RESET# or BI NIT#, all BREQ[3:0]# signals must be deasser ted in one

or two clocks. On observation of active AERR# (with AERR# observation enabled), all

BREQ[3:0]# signals must be deass e rted in the next clock. All agents also re-initiali ze Rotating

ID to three and ownership state to idle. Based on this situation, the new arbitration priority is

0,1,2,3 and there is no current symmetric owner.

When a reset condi tion is generated by the activation of BINIT# , BREQn# must remain deas-

serted until 4 clocks after BINIT# is driven inactive. The first BREQ# sample point is 4 clocks

after BINIT# is sampled inactive.

When the reset cond iti on is genera ted b y the activatio n of R ESE T#, BREQn# as dri v en b y s ym-

metric agents must remain deasserted until 2 clocks after RESET# is driven inactive. The first

BREQ# sample point is 2 clocks after RESET# is sampled inactive. F or power -on configuration,

the system interface logic mu st assert BREQ0# for at least two clocks before the clock in wh ich

RESET# is deasserted. B REQ0# must be deasserted by the system interface logic in the clock

after RESET# i s sampled deasserted. Agent 0 m ust delay BREQ0# assertion for a minimum

of three clocks after the clock in which RESET# is deasserted to guarantee wire-or glitch

free operation.

When a reset condition is generated by A ERR#, all agents except for a symmetric owner that

has issued the second or subsequent transaction of a bus-locked operation must keep BREQn#

inacti ve for a minimum of four clocks. The bus ow ner n that has is sued the second or subs equent

transaction of bus locked operation must activate its BREQn# two clocks from inactive

BREQn#. This approach ensures that the locked operation remains indivisible.

4.1.5.2. BUS REQUES T ASSERTION

A symmetric agent n can activate BREQn# to arbitrate for the bus pro vid ed the reset con ditions

described in Section 4.1.5.1., “Reset Conditions” are satisfied. Once activated, BREQn# must

remain active until the agent becomes the symmetric owner. Becoming the symmetric owner is

a precondition to entering the Request Phase.

4.1.5.3. OWNERSHIP FROM IDLE STATE

When the ownership state is idle, a new arbitration event begins with activation of at least one

BREQ[ 3:0]# . Du ring t he next clo ck, all sym metric agen ts a ssign owner ship t o the hi ghest pri-

ority sym metric agent with active bus request. In the following clock, all sy mmetric agents up-

date the Rotating ID to the ne w symmetric owner Agent ID and the owner ship state to busy. The

new symmetric owner may enter the Request Phase as early as the clock the Rotating ID is

updated.

4-17

BUS PROTOCOL

4.1.5.4. OWNERSHIP FROM BUSY STATE

When the ownership state is busy, the next arbitration event begins with the deassertion of

BREQn# by the current symmetric owner.

4.1.5.4.1. Bus Parking and Release with a Single Bus Request

When the own ership state is busy, bus parkin g is an accepted mode of operation. The symmetric

owner can retain ownership even if it has no pending requests, provided no other symmetric

agent has an active arbitration request.

The symmetric owner “n” may eventually deassert BREQn# to release symmetric ownership

even when other requests are not active. When the owner deasserts BREQn#, all agents update

the ownership state to idle, but maintain the same Rotating ID.

4.1.5.4.2. Bus Exchange with Multiple Bus Requests

When the ownership state is busy, on observing at least one other BREQm# active, the current

symmetric owner n can hold the bus for back-to-back transactions by simply keeping BREQn#

active. This mechanism must be used for bus-lock operations and can be used for unlocked op-

erations, with care to prev ent other symmetric agents from gaining owner ship. (The Pentium Pro

processor limits the number of additional unlocked requests to one.)

A new arbitration event begins with deactivation of BREQn#. On observing release of owner-

ship by the current symmetric owner , all agents assign the o wnership to the highest priority sym-

metric agent arbitrating for the bus. In the following clock, all agents update the R otating ID to

the new symmetric owner Agent ID and maintain bus ownership state as busy.

A symmetric agent n shall deassert BR EQn# for a minimum of one clock.

4.1.6. Priority Agent Arbitration Protocol Rules

4.1.6.1. RESET CONDITIONS

On observation of active RESET# or BINIT#, BPRI# must be deasserted in one or two clocks.

On observation of active AERR# (with AERR# observation enabled), BPRI# must be deassert-

ed in the next clock.

When the reset co ndition is generated by the activation of BINIT#, B PRI# m ust remain deas-

serted un til 4 clocks after BINIT# is d riven inactive. The first BPRI # sample poin t is 4 clocks

after BINIT# is sampled inactive.

When reset con ditio n is g enerated by AERR#, the p rio rity agent mus t keep BPRI# in active for

a minimum of four clocks unless it has issued the second or subsequent transaction of a locked

operation. The priority owner that has issued the second or subsequent transaction of a locked

operation must activate its BPRI# two clocks from inacti ve BPRI#. This ensures that the locked

operation remains indivisible.

4-18

BUS PROTOCOL

4.1.6.2. BUS REQUES T ASSERTION

The priority agent can activate BPRI# to seek bus ownership provided the reset conditions de-

scribed in Section 4.1.6.1., “Reset Conditions” are satisfied. BPRI# can be deactivated at any

time.

On observing active BPRI#, all symmetric agents guarantee no new non-locked requests are

generated.

4.1.6.3. BUS EXCHANGE FROM AN UNLOCKED BUS

If LOCK# is observed inactive in two clocks after BPRI# is driven asserted, the priority agent

has permission to drive ADS# four clocks after BPRI# assertion. The priority agent can further

reduce its arbitration latency by observing the bus protocol and determining that no other agent

could drive a request. For example, Arbitration latency can be reduced by to two clocks by ob-

serving ADS# active and LOCK# inactive on the same clock BPRI# is driven asserted or it can

be reduced to three clocks by observing ADS# active and LOCK# inactive in the clock after

BPRI# is driven asserted.

4.1.6.4. BUS RELEASE

The priority agent can deassert BPRI# and release bus ownership in the same cycle that it gen-

erates its last request. It can keep BPRI# active even after the last request generation provided

it can guarantee forward progress of the symmetric agents. When deasserted, BPRI# must stay

inactive for a minimum of two clocks.

4.1.7. Bus Lock Protocol Rules

4.1.7.1. BUS OWNERSHIP EXCHANGE FROM A LOCKED BUS

The current symmetric owner n can retain ownership of the bus by keeping the LOCK# signal

acti ve (e ven if BPRI# is asserted). This mechanism is used during bus lock operations. After the

lock operation is complete, the symmetric owner deasserts LOCK# and guarantees no new re-

quest generation until BPRI# is ob served inactive.

On asserting BPRI#, the priority agent observes LOCK# for the next two clocks to monitor

request bu s acti vity. If the cur r en t sym metric owner is pe rf o rm in g lo cked requ es ts (LOCK#

active), the priority agent must wait until LOCK# is ob served inactive.

4.2. REQUEST PHASE

After completion of the Arb itration Phase, an agent is allowed to enter the Request Ph ase. This

phase is used to initiate new transactions on the bus, and lasts for two consecuti ve clocks. During

the first clock, the information required to snoop a transaction and start a memory access be-

comes av ailable. During the next clock, complete information required for the entire transaction

becomes available.

4-19

BUS PROTOCOL

4.2.1. Bus Signals

The Request Phase bus signals are ADS#, A[35:3]#, REQa[4:0]#, REQb[4:0]#, ATTR[7:0]#,

DID[7:0]#, BE[7: 0]#, EXF[4:0]#, AP[1 :0]#, and RP #. In add ition, th e LOCK# si gnal is dr iven

during this phase. Request Phase signals are bused among all agents. Since information is car-

ried during two clo cks, the first clock is identif ied with the suf fix a and the second clock is iden-

tified with the suffix b. For example, RPa# and RPb#.

4.2.2. Request Phase Protocol Description

The Request Phase occ urs when a transaction is actuall y issued to the bus. ADS# is a sserted

and the transaction information is driven. Figure 4-11 shows the Request Phase of several

transactions.

In T1, only one b us agent (agent 0) dri v es a request for the bus . In T2, BREQ[3:0 ]#, BPRI# and

BNR# are sampled and it is determined that BREQ0# becomes the bus owner in T3.

In T3, agent 0 drives a transaction by asserting ADS#. Also in T3, A[35:3]#, REQa[4:0]#,

AP[1:0]# and RP# are d ri v en valid. REQa0# indicates that the transaction is a write transaction .

In T4, the second clock of the Request Phase, the rest of the transaction information is driven

out on the following signals: REQb[4:0]#, ATTR[7:0]#, DID[7:0]#, BE[7:0]#, and EXF[4:0]#.

AP[1:0]#, and RP# remain valid in this clock.

When a transaction is driven to the bus, the internal state must be updated in the clock after

ADS# is observ ed asserted. Ther efore, in T5 the intern al request count {rcn t} is incremented by

one.

Figure 4-11. Request Gener ation Phase

CLK

BREQ0#

BPRI#

A[35:3]#

BNR#

ADS#

1 23456789 10111213141516

0 0 00 1 11 2 22 77 7 7 88

REQ[4:0]#

{.rcnt}

4-20

BUS PROTOCOL

In T6, agent 0 issues another transaction, and in T8, the internal state is updated appropriately.

In the series of clocks indicated in the diagram b y T10, fi v e more transactions become ou tstand-

ing (this status is indicated by the {rcnt}). In T13, the 8th transaction is issued as indicated on

the bus by ADS# assertion in T13 . In T15, the {rcnt} is incremented to 8, t he highest possible

value for {rcnt}. No additional transactions can be issued until a response is given for

transaction 0.

4.2.3. Request Phase Protocol Rules

4.2.3.1. REQUES T GENE RATIO N

The Request Phase is always one clock of acti ve ADS# follo wed by one clock of inactiv e ADS#.

There is always an idle clock between request phases for bus turnaround. Address, command,

and parity in formation is transferred on the first two clocks on pins A[35 :3]#, REQ[4:0]#, and

AP[1:0]# and RP#. Refer to Chapter 3, Bus Overview for a descrip tion of which signals are dri v-

en on these pins. Although LOCK# is part of the Arbitration Phase, it is driven during the first

clock of the Request Phase. AP[1:0]# and RP# are valid during a valid Request Phase.

On observ ation of a ne w r equest, the transaction co unts including {rcn t} and {scnt} are upd ated

with the new transaction.

4.2.3.2. REQUEST PHASE QUALIFIERS

The Request Phase for a new transaction may be in itiated when:

•The agent contains one or more pending requests.

•The agent owns the bus as described in the Arbitration Phase section.

•The internal request count state is less than the maximum number of entries in the IOQ.

•The bus is not stalled. In other words, the Request Stall state (as described in Section 4.1.,

“Arbitration Phase”) is free or throttled.

•The preceding transaction’s Request Phase is complete. In other words, ADS# is observed

inactive on the previous clock.

4.3. ERROR PHASE

Receiving agents use the Error Phase to indicate parity errors in Request Phase. Parity is

checked during valid Request Phase (One clock active ADS# followed by one clock inactive

ADS#) on AP[1:0]# and RP# signals.

If the request parity is enabled in the po wer -on configuration as described in Chapter 9, Config-

uration, then the agent ch ecks parity in the two clocks. If transaction cancellation due to AERR#

is enabled (AERR# observation) in the power-on-configuration and AERR# is observed active

4-21

BUS PROTOCOL

during Error Phase, then all agents remove the transaction from their In-order Queue, cancel

subsequent transaction phases, remov e bus requests, and reset their b us arbiters. Reset of the bus

arbiters enables errors in the Arbitration Phase to be corrected. The transaction may be retried.

4.3.1. Bus Signals

The only signal driven in this state is AERR#. AERR# is bused among all agents.

4.4. SNOOP PHASE

In the Snoop Phase, all cach ing agents dri ve their snoop results an d participate in co herency res-

olution. The agents generate internal snoop requests for all memory transactions. An agent is

also allowed to snoop its own bus requests and participate in the Snoop Phase along with other

bus agents. The Pentium Pro processor snoops its own transactions. The snoop results are dri ven

on HIT# and HITM# signals in this phase.

In addition, during the Snoop Phase, the memory agent or I/O agent dri ves DEFER# to indicate

whether the transaction is committed for completion immediately or if the commitment is

deferred.

The results of the Snoop Phase are used to determine the final state of the cache line in all agents

and which agent is responsible for completion of Data Phase and Response Phase of the current

transaction.

4.4.1. Snoop Phase Bus Signals

The bus signals driven in this phase are HIT#, HITM# and DEFER# . These signals are bused

among all agents. The requesting agen t uses the HIT# signa l to determine the per missible cache

state of the line. The HITM# signal is used to indicate what agent will provide the requested da-

ta. The DEFER# signal indicates whether the transaction will be committed for completion im-

mediately or if the commitment is deferred.

The results of combinations of HIT# and HITM# signal encodings during a valid Snoop Phase

is shown in Table 4-1.

NOTE:

1. 0 indicates inactive, 1 indicates active.

Table 4-1. HIT# and HITM# During Snoop Phase

Snoop Result HIT# HITM#

CLEAN 010

MODIFIED 0 1

SHARED 1 0

STALL 1 1

4-22

BUS PROTOCOL

The CLEAN result means that at the end of the transaction, no other caching agent will retain

the addressed line in its cache, and that the requesting agent can store the cache line in any state

(Modified, Exclusive, Shared or Invalid).

The MODIFIED result means that the addressed line is in the modified state in an agent on the

Pentium Pro pro cessor bus. The agent that “ow ns” the line will writeback the line to memory.

The requesting agent will pick the line off the bus as it is writt en back.

The SHARED result means that addressed line is valid in the cache of another ag ent on the Pen-

tium Pro processor bus, but that it is not modified. The requesting agent therefore can store the

cache line in the shared state only.

The STALL result means that the all agents on the Pentium Pro processor bus are not yet ready

to provide a snoop result, and that the Snoop Phase will be stalled for another 2 clocks. Any

agent on the bus may use the STALL state on any transaction as a stall mechanism.

4.4.2. Snoop Phase Protocol Description

This section describes the Snoop Phase using examples.

4.4.2.1. NORMAL SNOOP PHASE

Figure 4-12 illustrates a four-clock Snoop Resu lt Phase for pipelined requests. The snoop results

are driven four clocks after ADS # is asserted and at least three clocks from the Snoop Phase of

a previous transaction. Note that no snoop results are stalled and the maximum request genera-

tion rate is one request every three clocks.

Figure 4-12. Four-Clock Snoop Phase

CLK

ADS#

{REQUEST}

AERR#

HIT#, HITM#,

1 2 456789 10111213141516

2 3

0001112112111000

{scnt}

2 3

DEFER#

4-23

BUS PROTOCOL

In T1, there are no transactions outstanding on the bus and {scnt} is 0. In T2, transaction 1 is

issued. In T4, as a result of the transaction driven in T2, {scnt} is incremented.

In T5, transaction 2 is issued. In T6, which is four clocks after the corresponding ADS# in T2,

the snoop results for transaction 1 are driven. In T7, {scnt} is incremented indicating that there

are two transactions on the bus that ha ve not completed the Snoop Phase. Also in T7, th e snoop

results for transaction 1 are observed. As a result, in T8, {scnt} is decremented.

In T8, the third transaction is issued. Two clocks later in T10, {scnt} is incremented. In T11,

{scnt} is decremented because the snoop results from transaction 2 are observed in T10.

In T13, the snoop results for transaction 3 ar e obser ved and in T1 4 {scnt} is again decr emented.

4.4.2.2. STALLED SNOOP PHASE

Figure 4-13 illustrates ho w a slower snooping agent can delay the Snoop Phase if it is unable to

deliver valid snoop results within four clocks after ADS# is asserted. The figure also illustrates

that the snoop phase of subsequent trasactions are also stalled and occur two clocks late due to

the stall of transaction one’s snoop phase.

Transactions 1, 2 and 3 are initiated with ADS# activation in T2, T5, and T8.

The Snoop Phase for transaction 1 begins in T6 four clocks from AD S#. All agents capable of

driving valid snoop response in four clocks drive appropriate levels on the snoop signals HIT#,

HITM#, and DEFER #. A slo wer agen t that is unab le to generate a snoop res ponse in four clocks

asserts bot h HIT# and HITM# to gether in T6 to e x t end the Snoop P has e. No te th at i f t he Sn oop

Figure 4-13. Snoop Phase Stall Due to a Slower Agent

CLK

ADS#

{REQUEST}

HITM#

AERR#

HIT#

1 23456789 10111213141516

2 3

1 2

DEFER#

0001112222221110

{scnt}

4-24

BUS PROTOCOL

Phase is extended, {scnt} is not decremented. Because the Snoop Phase is extended, the value

of DEFER# is a “don’t care”.

On observing active HIT# and HITM# in T7, all agents determine that the transaction’s Snoop

Phase is extended by two additional clocks through T8. In T8, the slower snooping agent is

ready with valid snoop results and needs no additional Snoop Phase extensions. In T8, all agents

drive valid snoop results on the snoop signals. In T9, all agents observe that HIT# and HITM#

are not asserted in the same clock and determine that the valid snoop results for transaction 1 are

available on the snoop signals.

The Snoop Pha se fo r tran sact i on 2 begins in T11, three clo cks fro m Snoop Phase of transacti o n

1 or four clocks from Request P has e of t ransact ion 2, whichever is lat er. Si n ce the S noo p P hase

for transaction 2 is not extended, the Snoop Phase for transaction 2 completes in one clock.

The Snoop Ph ase fo r transaction 3 be g i ns in T14, t he lat er of three clocks from Sno op Phas e of

transaction 2, and four clocks from Request Phase of transaction 3. Since the Snoop Phase for

transaction 3 is not extended, the Snoop Phase for transaction 3 completes in one clock.

For the e xample shown, the Sno op Phase is always six clocks from the Request Phase due to the

initial Snoop Phase stall from Transact ion 1. How ever, the maximum request gen eration rate is

still one request every three clo c ks.

4.4.3. Snoop Phase Protocol Rules

This section will list the Snoo p Phase protocol rules for reference.

4.4.3.1. SNOOP PHASE RESULTS

During a valid Snoop Phase (as defined below), snoop results are presented on HIT#, HITM#,

and DEFER# signals for one clock. If the snooping agent contains a MODIFIED copy of the

cache line, then HITM# must be asserted. If the snooping agent does not assert HITM# and it

plans to retain a SHARED copy of the cache line at the end of the Snoop Phase, it must assert

HIT#. HIT# and HITM# are asserted together to indicate that the agent is requesting a STALL.

All non-memory accesses will indicate CLEAN or STALL. DEFER# must be asserted by an ad-

dressed memory or I/O agent if the agent is unable to guarantee in-order completion of the re-

quested transaction.

The results of the Snoop Phase require specific behavior from the addressed and snooping

agents for future p hases of the transaction. The agent asserting HIT M# normally must writeb ack

the modified cache line. The addressed agent must accept the writeback line from t he snooping

agent, merge it with any write data, and drive an implicit writeback response.

If HITM# is inactive, the agent asserting DEFER# must reply with a deferred or retry response

for the transaction. Only the addressed agent can assert DEFER#. The requesting agent must not

begin another order-dependent transaction until either DEFER# is sampled deasserted in the

Snoop Phase, or the deferred transaction receives a successful completion via a deferred reply

or a retry.

4-25

BUS PROTOCOL

For all transactions with LOC K# inactive, HITM# active guarantees in-order completion. Dur-

ing unlocked transactions, HITM# overrides the assertion of DEFER#.

If DEFER# is asserted during the Snoop Phase of a locked operation, the locked operation is pre-

maturely aborted. During the first transaction of a locked operation, if HITM# and DEFER# are

active together, the transaction completes with cache line writeback and implicit writeback re-

sponse, but the requ est agent must begin a ne w locked operation starting from a new Arbitration

Phase (BREQn# of the requesting agent must be deasserted if a symmetric agent issued the

locked operation). The assertion of DEFER# during the second or subsequent transaction of a

locked operation is a protocol violation. If DEFER# is asserted and HITM# is not asserted, a

Retry Response is driven in the Response Phase to force a retry of the entire locked operation.

4.4.3.2. VALID SNOO P PHASE

The Snoop Phase for a transaction begins 4 clo cks after ADS# is driv en asserted or 3 clocks after

the snoop results of the previous transaction are driven, whichever is later.

4.4.3.3. SNOOP PHASE STALL

A slow snooping agent can request a two-clock STALL in a valid Snoop Phase by activating

both HIT# and HITM#. In the case of a STALL, snoop results are sampled again 2 clocks after

the pre vious sample point. This process continues as long as the STALL state is sampled. When

stalling the bus, the stalling condition must be able to clear without requiring access to the bus.

4.4.3.4. SNOOP PHASE COMPLETION

If no STALL is requested during the valid Snoop Phase, the Snoop Phase is completed in the

clock after the snoop results are driven.

4.4.3.5. SNOOP RESULTS SAMPLING

Snoop Results are sampled during the valid snoop phase. Bus agents must ignore Snoop Results

in the clock after a val id sampling window.

4.5. RESPONSE PHASE

4.5.1. Response Phase Over view

A transaction enters the Response Phase when it is at the head of the In-order Queue. The agen t

responsible for the response is referred to as the response agent. The agent decoded by the ad-

dress in the Request Phase determines the response agent for the transaction.

After completion of the Response Phase, the transaction is removed from the In-order Queue.

4-26

BUS PROTOCOL

4.5.1.1. BUS SIGNALS

The Response Phase signals are TRDY#, RS[2:0]#, and RSP#. These signals are bused. RSP#

prov ides p arit y suppo rt only for RS[ 2:0]#. The t ransacti on resp onse i s encoded on t he RS[2: 0]#

signals. TRDY# is only asserted for transactions with write or writeback data to transfer. The

response encodings are indicated in Table 4-2.

NOTE:

1. 0 indicates inactive, 1 indicates active .

There is no single response strobe signal. The response value is Idle until the response is dri ven.

A response is driven when any one of RS[2:0]# is asserted.

4.5.2. Response Phase Protocol Description

The Response Phase is described in this section using examples. The rules for the Response

Phase are listed in the next section for reference.

4.5.2.1. RESPONSE FOR A TRANSACTION WITHOUT WRITE DATA

Figure 4-14 shows several transactions that have no write or writeback data to transfer. There-

fore the TRDY# signal is not asserted. The DBSY# signal is observed in this phase because if

there is read data to transfer, DB SY# must be sampled inactive before the response for transac-

tion n can be driven (this ensures that any data transfers from transaction n-1 are complete before

the response is driven for transaction n).

Tab le 4-2. Resp ons e Phase Encod ings

Response RS2# RS1# RS0#

Idle 0100

Retry 0 0 1

Deferred 0 1 0

reserved 0 1 1

Hard Failure 1 0 0

No data 1 0 1

Implicit Writeback 1 1 0

Nor mal Data 1 1 1

4-27

BUS PROTOCOL

Three transactions are issued in clocks T1, T4, and T7. None of these transactions have write

data to transfer as indicated by the REQa0# signal.

The Snoop Phase for each transaction indicates that no implicit writeback data will be trans-

ferred and the response agent indicated by the address will provide the transaction response and

the read data if there is any.

Because the transactions have no write or implicit writeback data, the TRDY# signal is not

asserted.

The rcnt indicates that the In-order Queue is empt y. The ADS# for transaction 1 is dri v en in T1.

The snoop results for transaction 1 are driv en four clocks later in T5 (observ ed in T6). Note that

the Response and Data Phases for transaction n-1 have to be complete before the response for

transaction n can be driven. Since transaction 1 is at the top of the IOQ and DBSY# is i nactive

in T6, RS[2:0]# can be dri ven f or transaction 1 in T7, two clocks after the snoo p results are dri v-

en. Transaction 1 is removed from the IOQ after T8, and transaction 2 is now at the top of the

IOQ. The rcnt is not decrem ented in T9 because tran saction 3 was issued in the same clock that

transaction 1 received its response.

Transaction 2 is issued to the bus in T4 (three clocks after Transaction 1). The snoop results for

transaction 2 are driven fo ur clock s later in T8. Transaction 2 is at the top of the IOQ. RS[2:0]#

for transaction 2 is driven two clocks later in T10 because DBSY# and RS[2:0]# were sampled

deasserted in T9.

The response for transaction 3 cannot be driven two clocks after the snoop results are driven in

T11 because DBSY# is asserted in T11. DBSY# is sampled deasserted in T13 and RS[2:0]# for

transaction 3 is driven in T14.

The response driven for each of these t ransactions is the Normal Data Response.

Figure 4-14. RS[2:0]# Activation with no TRDY#

CLK

DBSY#

TRDY#

HITM#

RS[2:0]#

1 23456789 10111213141516

ADS#

REQ0#

{rcnt} 00 11122222211110

4-28

BUS PROTOCOL

4.5.2.2. WRITE DATA TRANSACTION RESPONSE

Figure 4-15 shows a transaction with a simple request initiated data transfer. A request initiated

data transfer means that the request agent issuing the transaction has write data to transfer. Note

that TRDY# is always asserted after the response for transaction n-1 is driven and before the

transaction response for transaction n is driv e n .

Before T1, the IOQ is empty. A write transaction as indicated by active ADS# and REQa0# is

issued in T1.

Since the Response Phase for the previous transaction is complete, the Response Phase for trans-

action 1 can be gin with the assertion of TRDY# as early as T4, 3 clocks after ADS# is asserted.

In T4, DBSY# is observ e d inactiv e on the clock TRDY# is asse rted and TRDY# had pre v ious ly

been inacti v e fo r 3 clocks, so the TRDY# agent is allowed to deassert TRDY# within one clock

as a special o ptimization. Data is driven the clock after TRDY # is sampled and the d ata bus is

free. TRDY# need not be deasserted until the response is driven.

The snoop results are driven in T5 and sampled in T6.

Since RS[2:0]# is deasserted in T6, TRDY# has been asserted and deasserted, and the snoop re-

sults were ob served in T6, the res ponse fo r the tran saction is driven o n RS[2:0 ]# in T7. No tice

even if TRDY # is only asserted for one clo ck, the respon se may s till be asserted when TRDY#

is deasserted (assuming snoop results ha v e been observ ed). B ecause this is a simple write trans-

action the respons e driven is the No Data Response.

Figure 4-15. RS[2:0]# Activation with Request Initiated TRDY#

CLK

DBSY#

TRDY#

HITM#

RS[2:0]#

1 23456789

ADS#

REQ0#

{rcnt} 0

111111

4-29

BUS PROTOCOL

4.5.2.3. IMPLICIT WRITEBACK ON A READ TRANSACTION

Figure 4-16 shows a read transaction with an im plicit writeback. TR DY# is asserted in this op-

eration because there is writeback data to transfer. Note that the implicit writeback response

must be asserted exactly one clock after valid TRDY# assertion is sampled. That is, TR DY# is

sampled active and DBSY# is sampled inactive.

A transaction is issued in T1. The REQa0# pin indicates a read transaction, so TRDY# is as-

sumed not needed for thi s transaction.

But sno op results observed in T6 indicate that an implicit writeb ack will occur (HITM# is as-

serted), therefore a TRDY# assertion is needed. Since the response for the previous transaction

is complete, and no request initiated TRDY# assertion is needed, TRD Y# for the implicit write-

back is asserted in T7. (TRDY# assertion due to an implicit writeback is called a snoop initiated

TRDY#.) Since DBSY# is observed inactive in T7, TRDY# can be deasserted in one clock in

T8, but need not be deasserted until the response is driven on RS[2:0]# .

In T9, one clock after the observation of active TRDY# with inactive DBSY# for the implicit

writeback, th e Implicit Writeb ack R esponse m ust be driven on RS[2:0]# and the d ata is d riven

on the data bus. This makes the data transfer and response behave like both a read (for the re-

questing agent) and a write (for the addressed agent).

Figure 4-16. RS[2:0]# Activation with Snoop Initiated TRDY#

CLK

DBSY#

TRDY#

HITM#

RS[2:0]#

{scnt}

1 23456789 101112

ADS#

{rcnt}

REQ0#

001111000000

001111111100

4-30

BUS PROTOCOL

4.5.2.4. IMPLICIT WRITEBACK WITH A WRITE TRANSACTION

Figure 4-17 shows a write transaction combined with a hit to a modified line that requires an

implicit writeback. This operation has two data transfers and requires two assertions of TRD Y#.

The first TRDY# is asserted by the receiver of the write data whenever it is ready to receive the

write data. Once active T RDY# and inactiv e DBSY# is observed, the first TR DY# is deasserted

to allow the second TR D Y#. The second TRD Y# is asserted by the receiv er whene ver it is ready

to receive the writeback data. The second TRDY# may be deasserted when active TRDY # and

inacti ve DBSY# is sampled or when the response is driven on RS[2:0]#. One clock after ob ser -

v ation of acti ve TRDY# (and inacti ve DBSY#) for the implicit writeback, the imp licit writeback

response is driven on RS[2:0]# at the same tim e data is driven for the implicit writeback.

In T1, a write t ransaction is issued as indicated by active ADS# and REQa0#. At this point, the

transaction appears to be a normal write transaction, so TRDY# is asserted 3 clocks later in T4.

TRDY# is deasserted in T5. Since DBSY# was observed inactive in T4, TRDY# can be deas-

serted in one clock as a special opti mization to allow a faster implicit writeback TRDY#.

In T5, the snoop results are dri ven, and in T6, they are observed . In T7, TRD Y# is asserted again

for the implicit w riteback. TRDY# can be asserted immediately because the TRDY# for the re-

quest initiated data tran sfer was already deas serted.

In T9, one clock after observation of acti v e TRDY# with inacti ve DBSY# for the implicit write-

back, TRDY# must be deasserted and the impl icit writeback response is driven on RS[2:0]#.

Since DBSY# was observed active in T7, but inactive in T8, TRDY# is deasserted in T9.

Figure 4-17. RS[2:0]# Activation After Two TRDY# Assertions

CLK

DBSY#

TRDY#

HITM#

RS[2:0]#

1 23456789

ADS#

REQa0#

{rcnt} 01111 11

10 11 12

13 14

4-31

BUS PROTOCOL

4.5.3. Response Phase Protocol Rules

4.5.3.1. REQUEST INITIATED TRDY# ASSERTION

A request initiated transaction is a transaction where the request agent has write data to transfer.

The addressed agent asserts TRDY# to indicate its ability to receive data from the request

agent intending to perform a write data operation. Request initiated TR DY# for transaction

“n” is asserted:

•when the transaction has a write data transfer,

•a minimum of 3 clocks after ADS# of transaction “n”, and

•a minimum of 1 clock after RS[2:0]# active assertion for transaction “n-1”. (After the

response for transaction n-1 is driven).

4.5.3.2. SNOOP INITIATED TRDY# PROTOCOL

The response agent asserts TRD Y# to indicate its ability to recei ve the modif ied cache line from

a snooping agent. Snoop Initiated TRDY# for transaction “n” is asserted when:

•the transaction has an implicit writeback data transfer indicated in the Snoop Result Phase.

•in the case of a request initiated transfer, the request initiated TRDY# was asserted and

then deasserted (TRDY# must be deasserted for at least one clock between the TRDY# for

the write and the TRDY# for the implicit writeback),

•at least 1 clock has passed after RS[2:0]# active assertion for transaction “n-1” (after the

response for transaction n-1 is driven).

4.5.3.3. TRDY# DEASSERTION PROTOCOL

The agent asserting TRDY# can deassert it as soon as it can ensure that TRDY# deassertion

meets following conditio ns.

•TRDY# may be deasserted when inactive DBSY# and active TRDY# are observed for one

clock.

•TRDY# can be deasserted within one clock if DBSY# was observed inactive on the clock

TRDY# is asserted and the deassertion is at least three clocks from previous TRDY#

deassertion.

•TRDY# does not need to be deasserted until the response on RS[2:0]# is asserted.

•TRDY# for a request initiated transfer must be deasserted to allow the TRDY# for an

implicit writeback.

4-32

BUS PROTOCOL

4.5.3.4. RS[2:0]# ENCODING

Valid response encodings are determined based on the snoop results and the following request:

•Hard Failure is a valid response for all transactions and indicat es transaction failure. The

requesting agent is required to take recovery action.

•Implicit Writeback is a required response when HITM# is asserted during the Snoop

Phase. The snooping agent is required to transfer the modified cache line. The memory

agent is required to drive the response and accept the modified cache line.

•Deferred Response is only allowed when DEN# is asserted in the Request Phase and

DEFER# (with HITM# inactive) is asserted during Snoop Phase. With the Deferred

Response, the response agent promises to complete the transaction in the future using the

Deferred Reply transaction.

•Retry Response is only allowed when DEFER# (with HITM# inactive) is asserted during

the Snoop Phase. With the Retry Response, the response agent informs the request agent

that the transaction must be retried.

•Normal Data Response is required when the REQ[4:0]# encoding in the Request Phase

requires a read data response and HITM# and DEFER# are both inactive during Snoop

Phase. With the Normal Data Response, the response agent is required to transfer read data

along with the response.

•No Data Response is required when no data will be returned by the addressed agent and

DEFER# and HITM# are inactive during the Snoop Phase.

4.5.3.5. RS[2:0]#, RSP# PROTOCOL

The response signals are normally in idle state when not being driven active by any agent. The

response agent asserts RS[2:0]# and RSP# for one clock to indicate the type of response used

for transaction completion. In the next clock, the response agent must drive the signals inactive

to the idle state.

Response for transaction “n” is asserted when the following are true:

•Snoop Phase for transaction “n” is observed.

•RS[2:0]# for transaction “n-1” were asserted to an active response state and then sampled

inactive in the idle state (the response for transaction “n” is driven no sooner than three

clocks after the response for transaction “n-1”) .

•If the transaction contains a write data transfer, TRDY# deassertion conditions have been

met.

•If the transaction contains an implicit writeback data transfer, snoop initiated TRDY# is

asserted for transaction “n” and TRDY# is sampled active with inactive DBSY#.

•DBSY# is observed inactive if RS[2:0]# response is Normal Data Response.

4-33

BUS PROTOCOL

•A response that does not require the data bus (no data response, deferred response, retry

response, or hard failure response) may be driven even if DBSY# is active due to a

previous transaction.

On observation of active RS[2:0]# response, the Transaction Queues are updated and {rcnt} is

decremented.

4.6. DATA PHASE

4.6.1. Data Phase Overview

During the Data Phase, data is transferred between different bus agents. Data transfer responsi-

bilities are negotiated between bus agents as the transaction proceeds through various phases.

Based on the Request Phase, a transaction either contains a “request-initiated” (write) data trans-

fer, a “response-initiated” (read) data transfer, or no data transfer. On a modified hit during the

Snoop Phase, a “sno op-initiated ” data trans fer may be ad ded to th e request o r substitu ted from

the response in place of the “response-initiated” data transfer. On a deferred completion re-

sponse in the Response Phase, “response-initiated” data transfer is deferred.

4.6.1.1. BUS SIGNALS

The bus signals driven in this phase are D[63:0]#, DEP[7:0]#, DRDY#, and DBSY#.

All Data Phase signals are bused.

4.6.2. Data Phase Protocol Description

4.6.2.1. SIMPLE WRITE TRANSFER

Figure 4-18 shows a simple write transaction (request-initiated data transfer). Note that the data

is transferred before the response is driven.

4-34

BUS PROTOCOL

The write transaction is dri v en in T1 as indicated b y acti v e ADS# and REQa0#. TRDY# is driv-

en 3 clock s later in T4 . The No Data response is driven in T7 after inactive HITM# sam pled in

T6 indicates no implicit writeback.

In the example, the data transfer only takes one clock, so DBSY# is not asserted.

TRDY# is observed active and DBSY# is observed inactive in T5. Therefore the data transfer

can begin in T6 as indicated by DRDY# assertion. Note that since DBSY# was also observed

inacti v e in T4, th e same clock that TRDY# was asserted, TRDY# can be deasserted in T6. Refer

to Section 4.5.3.3., “TRDY# Deassertion Protocol” for further details.

RS[2:0]# is driven to No Data Resp onse in T7, two clocks after the snoop phase.

4.6.2.2. SIMPLE READ TRANSACTION

Figure 4-19 shows a simple read transaction (response-initiated data transfer). Note that the data

transfer begins in the same clock that the response is driven on RS[2:0]#.

Figure 4-18. Request Initiated Data Transfer

CLK

ADS#

21438765

REQa0#

DBSY#

D[63:0]#

DRDY#

HITM#

TRDY#

RS[[2:0]#

4-35

BUS PROTOCOL

A read transaction is driven in T1 as indicated by the ADS# and REQa0# pins. Because the

transaction is a read and HITM# indicates that there will be no implicit writeback data, TRDY#

is not asserted for this transaction.

The response for this transaction is driven on RS[2:0]# in T7, two clocks after the snoop results

are driven in T5. For read transactions (response initiated data transfers), the data transfer must

begin in the same clock that the response is driven.

4.6.2.3. IMPLICIT WRITEBACK

Figure 4-20 shows a simple implicit writeb ack (snoop-initi ated data transfer) occu rring during

a read transfer transaction. Note that wait states can be added into the data transfer by the deas-

sertion of DRDY#. No te also that the data tran sfer for th e implicit writeback must begin on the

same clock that the response is driven on RS[2:0]#.

Figure 4-19. Response Initiated Data Transfer

CLK

ADS#

21438765

REQa0#

DBSY#

D[63:0]#

DRDY#

HITM#

TRDY#

RS[2:0]#

109

4-36

BUS PROTOCOL

A transaction is issued to the bus in T1. REQa0# indicates that the transaction does not have

write data to transfer. The snoop results driven in T5 indicate that an implicit writeback will be

driven.

The response agent may assert TRDY# as early as T7, the clock after the snoop results are sam-

pled. In T8, TRDY# is sampled asserted while DBSY# is sampled deasserted. Therefore, the

snoop agent begins the data transfe r in T 9 w i th the assertion of DRDY#, DBSY#, and valid

data. Note, T RDY# must b e deasse rted in T 9. Refe r to Section 4.5.3.3. , “TRDY# D easser -

tion Protocol” for further details.

DBSY# must stay activ e at least until the clock before the last data transfer to indicate that more

data is coming. DRDY# is dri ven acti ve b y the snooping agent to indicate that it has dri ven v alid

data. To insert waitstates into the data transfer, DRDY# is deasserted.

The response agent must dri v e the response on RS[2:0] # in T9, the clock after the acti ve TRD Y#

for an implicit writeback and inactiv e DBSY# is sampled. Note that the response must be driv en

in the same c lock that t he data tran sfer be gins. Th is mak es the dat a transf er and response beha ve

like both a read (for the requesting agent) and a write (for the addressed agent).

4.6.2.4. FULL SPEED READ PARTIAL TRANSACTIONS

Figure 4-21 shows steady-state behavior with full speed Read Partial Transactions. DBSY# is

deasserted since the single chun k is transferred immediately. Note that there are no bottlenecks

to maint a ining this steady-state.

Figure 4-20. Snoop Initiated Data Transfer

CLK

ADS#

21438765

REQa0#

DBSY#

D[63:0]#

DRDY#

HITM#

TRDY#

RS[2:0]#

1091211 16151413

4-37

BUS PROTOCOL

4.6.2.5. RELAXED DBSY# DEASSERTION

DBSY# may be left asserted beyond the last DRDY# assertion. The data bus is released one

clock after DBSY# is deasserted, as shown in Figure 4-22. This figure also shows how the re-

sponse for transaction 2 may be driven even though DBSY is still active for the Data Phase of

transaction 1 because transaction 2 does not require the data bus. Because agent 1 deasserts

DBSY# in T13 and it is sampled inactiv e b y the other agents in T14, DBSY# and d ata are dri v en

for transaction 3 in T15.

Figure 4-21. Full Speed Read Partial Transactions

CLK

ADS#

21438765

{REQUEST}

DBSY#

D[63:0]#

DRDY#

HITM#

TRDY#

RS[2:0]#

1091211 16151413

123456

234

123456

1234

4-38

BUS PROTOCOL

4.6.2.6. FULL SPEED READ LINE TRANSFERS (SAME AGENT)

Figure 4-23 shows the steady-state behavior of Read Line Transactions with back-to-back read

data transfers from the same agent. Consecuti ve data tr ansfers may occur without a turn-around

cycle only if from the same agent. Note that DBSY# must be asserted in the same clock that the

response is dr iven on RS[2:0]# if the response is the Normal Data Resp onse. This means that

DBSY# must be deasserted before the response can be driven.

Figure 4-22. Relaxed DBSY# Deassertion

CLK

ADS#

21438765

{REQUEST}

DBSY#

D[63:0]#

DRDY#

HITM#

TRDY#

RS[2:0]#

1091211 16151413

1111

123456

134

4-39

BUS PROTOCOL

Read Line transactions are issued to the bus at full speed. TRDY# is not asserted because the

transactions are reads and the snoop results indicate no implicit writeback data transfers.

The response and data transfers for transaction 1 occur in T7, the clock after the snoop results

are sampled. The data is transferred in 4 consecutive clocks.

DBSY# is asse rted for trans action 1 in T7 and rem ains asse rted until T1 0, the clock before the

last data transfer. A special optimization can be made because the same agent drives both data

transfers. Since the response agent kno ws that DBSY# will be deasserted in T10 and it owns the

next data transfer, it can dri v e the next r esponse and data transf er in T11, one clock af ter DBSY#

deassertion.

Note that no waitstates are inserted by the single addressed/responding agent. The back end of

the bus will e ve ntually throttle the front end in this scenario, b ut full bus bandwidth is attainable.

4.6.2.7. FULL SPEED WRITE PARTIAL TRANSACTIONS

Figure 4-24 shows the steady-state behavior of the bus with full speed Write Partial

Transactions.

Figure 4-23. Full Speed Read Line Transactions

CLK

ADS#

21438765

{REQUEST}

DBSY#

D[63:0]#

DRDY#

HIT#

TRDY#

RS[2:0]#

1091211 16151413

11112222

123456

1234

123

4-40

BUS PROTOCOL

In the example, the data transfer only takes one clock, so DBSY# is not asserted.

Write Partial T ransactions are dri ven at full speed. The f irst transaction occurs on an idle b us and

looks just like t he simp le write case in Fi gure 4-18. TR DY# is driven 3 clocks later i n T4. The

Normal No Data response is driven in T7 after inact ive HITM# sampled in T6 indicates no im-

plicit writeback. TRDY# is observed active and DBSY# is observed inactive in T5. Therefore

the data transfer can begin in T6 as indicated by DRDY# assertion.

The TRD Y# for transaction 2 must wait until the response for transaction 1 is sampled. TRDY#

is asserted the c ycle a fter R S[2:0] # is sampled. B ecause the snoop results fo r tran saction 2 have

been observed in T9, the response may be driven on RS[2:0]# in T10. TRDY# is sampled with

DBSY# deasserted in T10 and data is driven in T11.

There are no bottlenecks to maintaining this steady state.

4.6.2.8. FULL SPEED WRITE LINE TRANSACTIONS (SAME AGENTS)

Figure 4-25 shows the steady-state behavior of the bus with full speed Write Line Transactions

with data transfers from the same req uest agen t to th e same addressed agen t.Data transfers m ay

occur without a turn-around cycle only if from the same agent.

Figure 4-24. Full Speed Write Partial Transactions

CLK

ADS#

21438765

{REQUEST}

DBSY#

D[63:0]#

DRDY#

HIT#

TRDY#

RS[2:0]#

1091211 16151413

123456

1234

1 234

4-41

BUS PROTOCOL

Write Line Transactions are driven at full speed. The first transaction occurs on an idle bus.

TRDY# is delayed until T5 to arrive at steady-state quicker for this example. The Normal No

Data response can be driven in T7 after inactive HITM# sampled in T6 indicates no implicit

writeback (it is dri ven in T8 in this example). TRDY# is observed activ e and DBSY# is observed

inactive in T6. Therefore the data transfer can begin in T7 as indicated by DRDY# assertion.

TRDY# for transaction 2 can be driven the cycle after RS[2:0]# is driven, if RS[2:0]# and

TRDY# both come from the same target. A special optimization can be made when the same

agent drives both request-initiated data transfers. Since in T10 the request agent is driving DB-

SY# deasserted, has sampled TRDY# asserted for transaction 2, and owns the data t ransfer for

transaction 2, it can drive the next data transfer in T11, one clock after DBSY# deassertion.

In T11, the target samples TRD Y# activ e and DBSY# inactiv e and accepts the data transfer start-

ing in T12. Because the snoop results for transaction 2 have been observed in T9, the target is

free to drive the response in T12.

Note that no waitstates are inserted by the requesting agent. The back end of the bus wil l even-

tually throttle the front end in th is scenario, but full bus b andwidth is attainable. The Pentium

Pro processor will always inse rt a turn-around cycle between write data transfers.

Figure 4-25. Full Speed Write Line Transactions

CLK

ADS#

21438765

{REQUEST}

DBSY#

D[63:0]#

DRDY#

HIT#

TRDY#

RS[2:0]#

1091211 16151413

123456

1234

123

111 22233

123

4-42

BUS PROTOCOL

4.6.3. Data Phase Protocol Rules

4.6.3.1. VALID DATA TRANSFER

All Data Phase bus signals; DBSY#, DRDY#, D[63:0]#, and DEP[7:0]# are driv en by the agent

responsible for data transfer. Multi-clock data transfers begin with assertion of DBSY# and

complete with deassertion of DBSY# no sooner than one clock prior to the last data transfer . Sin-

gle-clock and single-chunk data transfers are not required to assert DBSY#. The R equest Phase

and the Snoop Phase determine the number of valid data transfer chunks, which range from 0 -

4 chunks in the Pentium Pro processor. A valid data chunk on D[63:0]# and valid parity on

DEP[7:0]# is indicated by DRDY# assertion in that clock.

4.6.3.2. REQUEST INITIATED DATA TRANSFER

When REQa0# is active during the Request Phase of the transaction, the transaction contains a

request initiated data transfer. The request agent ma y not send any data in response to TRDY#

if the transaction length is zero. Request in itiated data transfer for transaction “ n” begins only

after transaction “n” reaches the top of the In-order Queue. On the first clock after TRDY# is

observed activ e and DBSY# is observ ed inacti ve, the request agent may be gin Valid Data T rans-

fer (as defi ned abo ve).

The request agent may also begin Valid Data Transfer on the same clock TRDY # is observed

active and DBSY# is observed inactive if it can predict this event one cycle earlier. This only

occurs when the request agent creates the event by driving the Valid Data Transfer for the pre-

vious transfer while the target is asserting TRDY#.

4.6.3.3. SNOOP INITIATED DATA TRANSFER

When HITM# is active during Snoop Phase of the transaction, the transaction contains snoop

initiated data transfer. Snoop initiated data transfer for transaction “n” be gins only after transac-

tion “n” reach es the top of the In-order Queue and Request initiated data transfer , if any, is com-

plete. Response Initiated Data Transfer

When HITM# is observed inacti ve during Snoop Phase and the Request Phase contains a request

for return of read data, the transaction contains response initiated data transfer.

Bus Transactions

and Operations

5-1

CHAPTER 5

BUS TRANSACTIONS AND OPERATIONS

This chapter describes in detail the bus transactions and operations supported by the Pentium

Pro processor bus.

5.1. B US TRANSACTIONS SUPPORTED

Figure 5-1 lists the d ifferent bus transactions.

The transactions classified as read data transactions normally expect a response initiated data

transfer from the agent addressed by the transaction. This is indicated by a Normal Data

Response in the Response Phase of the transaction. If no bytes are enabled, then a No Data Re-

sponse is returned by the addressed agent.

The transactions classified as write data transactions require requ est-initiated d ata transfer and

are identif ied by REQa[0]#. All responses ex cept Normal Data Response are allo wed. The targ et

asserts TRDY#. Implicit Writeb ack Resp ons es may als o occur an d send additio nal sn oop initi-

ated data.

Figure 5-1. Bus Transactions

All Bus Transactions

Memory

I/O Read

I/O Wr ite Branch Trace Message

Interrupt Acknowledge

I/O Other

Mem Read

Mem Write

Flush

Halt

Sync

Flush Acknowledge

Stop Grant Acknowledge

SMI Acknowledge

Shutdown

Mem (Read) Invalidate LIne

Deferred Reply

Write data:

Read data:

No Data:

Deferred:

5-2

BUS TRANSACTIONS AND OPERATIONS

The transactions classified as deferred transactions may or may not send data in normal opera-

tion. It will return what is expected from the original transaction, unless the Snoop Result Phase

indicates that data will return when not expected (HITM#).

The transactions classif ied as no d ata transaction s requir e no data tra nsfer. All responses e x cept

Normal Data Respons e and Implicit Writeback Response are allowed.

The transactions classified as memory transactions are cache-coherent and require snooping.

All responses are allowed.

The transactions classified as I/O transactions are not snooped. All responses except implicit

writeback are allowed.

The transactions classified as other transactions are not snooped. All responses are allowed.

5.2. BUS TRANSACTION DESCRIPTION

This section describes each bus transaction in detail. In all tables, a “1” denotes an active level,

and a “0” denotes an inactiv e level. Most transactions hav e a DSZ[1:0]# field, which is used

to support agents with dif ferent data width. Currently agents with only 64 bit data width are

supported.

5.2.1. Memory Transactions (see Table A -9 )

An agent issues memory transactions to read or write data from memory ad dress space. The ad-

dressed agent is the agent primarily responsible for completion of the transaction. Besides the

request initiator and the addressed agent, all caching agents are required to snoop a memory

transaction.

The memory transactions are indicated using the following request encodings:

DSZ[1:0]# Data Bus Width

0 0 64 bit Data Bus

0 1 Reserved

1 x Reserved

REQa[4:0]# REQb[4:0]#

read &

invalidate

ASZ[1:0]#

0 1 W/R#=0

DSZ[1:0]# rsvd LEN[1:0]#

rsvd 0 1 W/R#=1

read 1 x W/R#=0

write 1 x W/R#=1

5-3

BUS TRANSACTIONS AND OPERATIONS

Ab[15:3]# are used to encode additional information about the transaction as follows:

The ASZ[1:0]# signals are used to support agents with different memory address ing capability

to coexist on the same bus. The bits indicate what address range is being addr essed as sho wn in

the table below. If a reserved range is indicated, then Snooping Agents and Responding agents

must ignore this transaction.

The remaining three bits in the REQa[2:0]# field support identification of different types of

memory transactions.

The LEN[1:0]# signals are used to indicate the length of the memory transaction. It indicates

ho w much d ata will be tran sferred over the bus. The Pentium Pro pro cessor will issue 0 - 8 b y te

and 32 byte memory tran sactions. Response to reserved encodings should be the lar gest transfer

size supported.

BE[7:0]# is used in conjun ction with LEN[1:0]#. If 8 bytes or more are to be transferred, then

BE[7:0]# indicates that all bytes are enabled. If less than 8 bytes are to be transferred, then

BE[7:0]# indicates which bytes. Transaction lengths of less than 8 bytes may have any combi-

nation of byte enables. If no bytes are enabled, then no data is transferred (in the absence of an

Implicit Writeback). A zero byte-count transfer is indicated by BE[7:0]# = 00000000B and an

eight or more byte transfer is indicated by BE[7:0]# = 11111111B

Zero length requests (LEN= 00B and BE = 00H) for read transactions are modeled after the

Memory (Read) Invalidate transaction. Response m ust be No Data Response in th e absence of

HITM# or DEFER# assertion.

Ab[15:8]# Ab[7:3]#

BE[7:0]# SMMEM# SPLCK# rsvd DEN# rsvd

ASZ[1:0]# Address Range Observing Agents

0 0 0 <= A[35:3]# < 4 GB 32 & 36 bit agents

0 1 4 GB <= A[35:3]# < 64 GB 36 bit agents

1 x Reserved None

LEN[1:0]# Transaction Length

0 0 0 - 8 bytes

0 1 16 bytes

1 0 32 bytes

1 1 Reserved

5-4

BUS TRANSACTIONS AND OPERATIONS

For write transactions, TRDY# ass ertion is requ ired, even when no requ est-initiated data is be-

ing transferred. This simplifies this rare special case (Pentium Pro processor will not issue this

transaction). The request agent must not assert DRDY# in response to TRDY#.

SMMEM# is asserted while the requestor is in System Management Mode (see Section

5.2.3.6.7., “SMI Acknowledge”). SPLCK# indicates an atomic split locked operation (see

Section 5.3.4.1., “[Split] Bus Lock”). DE N# indicates that this transaction is deferrable (see

Section 5.3.3., “Deferred Operations”).

Request Initiator Responsibilities

A 32 bit address request initiator must always assert AS Z[1:0]# = 00 when m aking a memory

transacti on reques t and dri v e a valid 32 bit addr ess on A[ 31:3 ]# pins. If pari ty i s enabled i t must

also drive correct parity for A[23:3]# on AP0# and A[31:24]# on AP1#. (See Section 3.4.3.,

“Request Signals”.)

A 36 bit address request in itiator must assert ASZ[1:0] # = 01B when making a memory trans-

action request between 4G and 64G-1 and ASZ[1:0]# = 00 B when making a memory transaction

request between 0 to 4G-1. It also mu st dri ve a v alid 36 bit address on A[3 5:2]# pins at all times.

If parity is enabled it must drive correct parity for A[23:3]# on AP0# and A[35:24]# on AP1#.

A 64 bit data request initiator must always assert DSZ[1:0]# = 00B when making a memory

transaction request.

All request initi ator s issue the re quired encodings on REQ[ 2:0] # and LEN[1:0]# pins to request

the proper transaction. All reserved encodings are always driven inactive.

Addressed Agent Responsibilities

A 32 bit address memory agent must ignore all memory transaction requests besides ASZ[1:0]#

= 00B. Whenever ASZ[1:0]# = 00B it must be capable of responding to the transaction.

A 36 bit address memory agent must ignore all memory transaction requests besides ASZ[1:0]#

= 01 and 00. Whenever ASZ[1:0]# = 00B it must be capable of filtering the A[35:32]# signals

from the address if they are not guaranteed to be in the inactive state.

A 64 bit data addressed agent must ignore the DSZ[1: 0]# field. All addressed agents currently

defined must obey reserved field restrictions. L3 Cache agents use ATTR[7:0]# to determine

cache line allocation policy.

All addressed agents must observe the snoop results presented in the snoop phase and modify

their ownerships towards transaction completio n if HITM# or DEFER# is asserted by a snoop-

ing agent. These special cases ar e described in g reater detail in later subsections of this chap ter.

5-5

BUS TRANSACTIONS AND OPERATIONS

5.2.1.1. MEMORY READ TRANSACTIONS

Memory Read Transactions perform reads of memory or memory-mapped I/ O. R EQa[1] # i nd i-

cates whether the read is for code or data. This can be used to make cache coherency assump-

tions (see Chapter 7, Cache Protocol).

5.2.1.2. MEMORY WRITE TRANSACTIONS

Memory Write Transactions perform writes to memory or memory-mapped I/O. REQa[1]# in-

dicates whether the write transaction is a writeback and may not be retried. REQa[1]# asserted

indicates that the write transaction may be retried. REQa[1]# is asserted by a non-cacheable

(DMA) agent to write data to memory. The Pentium Pro processor asserts REQa[1]# when writ-

ing through the cache and when evicting a full Write Combining Buffer. This transaction is

snooped and can receive an Implicit Writeback Response. When REQa[1]# is deasserted, no

agent may assert DEFER# to retry the transaction. A writeback caching agent must deassert

REQa[1]# when writing back a modified cache line to mem ory . If deasserted and this transaction

hits a valid line in a snooping cache, a cache coherency violation has occurred.

5.2.1.3. MEMORY (READ) INVALIDATE TRANSA CTIONS

An agent issues a Read Invalidate T ransaction to satisfy an internal cach e line f ill and obtain e x-

clusive ownership of the line. All snooping agents will invalidate the line addressed by this

transaction. A Read Inv alidate transaction has BE[7 :0]# = FFH and LEN[1:0]# = 10B. Note that

if the issuing agent alr eady has the line in the shared state, it need only in v alidate the line in other

caches to allow a transition to the exclusive state. In this case the requesting agent issues a zero

length transaction (BE[7:0]# = 00H and LEN[1:0]# = 00) indicating that no data is required.

REQa[2:0]#

code read 1 D/C#=0 0

data read 1 D/C#=1 0

REQa[2:0]#

may not be retried 1 W/W B#=0 1

may be retried 1 W/WB#=1 1

REQa[2:0]#

Memory (Read) Invalidate 0 1 0

5-6

BUS TRANSACTIONS AND OPERATIONS

5.2.1.4. RESERVED MEMORY WRITE TRANSACTION

This transaction is reserved, and must not be issu ed by any bus agents. Future bus agents may

use this encoding. Current memory agents and snooping agents must treat this transaction as a

Memory Write Transaction.

5.2.2. I/O Transactions

An agent issues an I/O transaction to read or write an I/O location. The addressed agent is the

agent primarily responsible for completion of the I/O transaction. I/O transaction may be de-

ferred in the snoop phase by any agent as described in the later subsection.

The I/O transactions are indicated using the following request encodings:

I/O transactions hav e similar request fields to memory transactions. Howe v er, the address space

is always 64K+3 b y tes1. Therefore, A[35:17]# will always be zero. A[16]# is zero except when

the first three bytes ab ove the 64Kbyte sp ace are accessed (I/O wraparound). BE[7:0]# will al-

ways indicate at most 4 bytes when issued by the Pentium Pro processor.

The LEN[1:0]# signals are identical to the memory transactions, and are used to indicate the

length of the I/O transaction. It indicates how much data will be transferred over the bus. Re-

sponse to reserved encodings should be the largest transfer size supported.

1 The Pentium® Pro pro ce ssor is backwards compat ible wit h previous implem ent a tions of the Intel Arch i te ct ure I/O

space. A[16]# is active whenever an I/O access is made to 4 bytes from addresses 0FFFDH, 0FFFEH, or 0FFFFH.

A[16]# is also active when an I/O access is made to 2 bytes from address 0FFFFH.

REQa[2:0]#

Reserv ed Memory Write 0 1 1

REQa[4:0]# REQb[4:0]#

read 1 0 0 0 W/R#=0

DSZ[1:0]# rsvd LEN[1:0]

write 1 0 0 0 W/R#=1

Ab[15:8]# Ab[7:3]#

BE[7:0]# SMMEM# SPLCK#=0 rsvd DEN# rsvd

5-7

BUS TRANSACTIONS AND OPERATIONS

BE[7:0]# is used in conjun ction with LEN[1:0]#. If 8 bytes or more are to be transferred, then

BE[7:0]# indicates that all bytes are enabled. If less than 8 bytes are to be transferred, then

BE[7:0]# indicates which bytes. Transaction lengths of less than 8 bytes may have any combi-

nation of by te enables. If no bytes are enabled, then no data is transferred. The Pentium Pro pro-

cessor will always assert 1 to 4 consecutive byte enables. I/O reads that lie within 8-byte

boundaries b ut cross 4-byte boundaries are issued as one transaction, b ut I/O writes that lie with-

in 8-byte boundaries but cross 4-byte boundaries are split into two transactions.

Zero length requ ests (LEN= 00B and BE = 00H) for read transactions are modeled after Memory

transactions. Response must be No Data Response in the absence of DEFER# assertion.

For write transactions, TRD Y# assertion is required, even though no request-initiated data is be-

ing transferred. This simplifies this rare special case (Pentium Pro processor will not issue this

transaction). The request agent must not assert DRDY# in response to TRDY#.

5.2.2.1. REQUEST INITIATOR RESPONSIBILITIES

The request initiator must assert W/R# if the transaction is an I/O Write, and must deassert W/R#

signal if the transactio n is an I/O R ead. A 64 bit request initiato r must always issue DSZ[1:0] #

= 00B. The reserved fi elds are driven inactive.

5.2.2.2. ADDRESSED AGENT RESPONSIBILITIES

The addressed I/O agent must ignore reserved fields. It must also ignore DSZ[1:0]#

5.2.3. Non-memory Central Transactions

These transactions are issued b y a bus agent to create special bus message. It is the respo nsibility

of the central agent in the system to capture these transactions. All non-memory central transac-

tion define Ab[15:8]# (BE[7:0]#) as an additional command encoding field. The central agent

responds with No Data Response, R S[ 2:0]# = 1 01, for all non-memory central transactions, ex-

cept for the Interrupt Acknowledge transaction which is covered in Section 5.2.3.4 ., “Interrupt

Acknowledge Transaction”.

LEN[1:0]# Transaction Length

0 0 0 - 8 bytes

0 1 16 bytes

1 0 32 bytes

1 1 Reserved

5-8

BUS TRANSACTIONS AND OPERATIONS

These transactions drive REQa[0]#active if request initiated data is being sent. The Central

Agent will then dr ive TRDY#.

5.2.3 .1. REQUEST INITIATOR RESPONSIBILITIES

Generate the request with valid encodings. The reserved fields are driven inactive.

5.2.3.2. CENTRAL AGENT RESPONSIBILITIES

Generate response for all encodings including all reserved encodings. Return data as necessary

5.2.3.3. OBSERVING AGENT RESPONSIBILITIES

Observing agents must deco de th e en tire req uest field and d etermine if they are req uired to tak e

any action. Of course, any agent may stall the Snoop Result Phase to delay completion.

5.2.3.4. INTERRUPT ACKNOWLEDGE TRANSACTION

A processor agent issues an In terrupt Ackno wledge Transaction in response to an interrupt from

an 8259A or similar interrupt contr oller. The response agent (normally the I /O agent) mu st per -

form whatever handshaking the interrupt controller requires. For example, an I/O agent inter-

faced to an 8259A interrupt controller must issue two locked-interrupt-acknowledge cycles to

the 8259A to process one Interrupt Acknowledge Transaction it receives from a Pentium Pro

processor. The I/O agent returns the interrupt v ector gener ated by the 8259A to the pro cessor as

a single data-cycle response on D[7:0]#. D[63:8]# are undefined. Note that the BE[7:0]# field

reflects this. The address Aa[35:3]# signals are reserved and can be driven to any value.

REQa[4:0]# REQb[4:0]#

read0100W/R#=0

write0100W/R#=1DSZ[1:0]#rsvdxx

Ab[15:8]# Ab[7:3]#

x SMMEM# SPLCK#=0 rsvd DEN# rsvd

REQa[0]# REQb[1:0]# Ab[15:8]#

000 01

5-9

BUS TRANSACTIONS AND OPERATIONS

5.2.3.5. BRANCH TRACE MESSAGE

Branch Trace Messages produce 64 bits of data. If execution tracing is enabled, an agent issues

a Branch Trace Message transaction for branches taken. The address Aa[35:3]# is reserved and

can be driven to any value. D[63:32]# contain the linear address of the target. D[31:0]# contain

either the address of the first byte of the branch instruction or the address of the i nstruction im-

mediately following the branch. If the instruction does not complete normally, then D[31:0]#

will contai n the address of the branch instruct ion itself. If the instruction completes normally,

then D[31:0]# will contain the address of the instruction immediately following the branch. The

BE[7:0]# field reflects that data will be valid on all bytes of the data bus. It is the responsibility

of the Central Agent to assert TRDY# and the res ponse for this transaction. If a different agent

is responsible for storage, it must capture the data from the bus.

5.2.3.6. SPECIAL TRANSACTIONS

These transactions are used to indicate to the system some rare events. The address Aa[35:3]#

is undefined and can be driven to any value.

REQa[0]# REQb[1:0]# Ab[15:8]#

100 FF

REQa[0]# REQb[1:0]# Ab[15:8]#

0 0 1 00-07

Special Transaction Ab[15:8]#

NOP 0000 0000

Shutdown 0000 0001

Flush 0000 0010

Halt 0000 0011

Sync 0000 0100

Flush Acknowledge 0000 0101

Stop Clock Acknowledge 0000 0110

SMI Ackno wledge 0000 0111

Reserved all others

5-10

BUS TRANSACTIONS AND OPERATIONS

5.2.3.6.1. Shutdown

An agent issues a Shutdown Transaction to indicate that it has det ected a severe software error

that prevents further processing. The Pentium Pro processor issues a Shutdown Transaction if

any other exception occurs while the processor is attempting to call the double fault handler . The

internal caches remain in the same state u nless a snoop hits a modif i ed line. The f ollowing table

describes how Pentium Pro processor reacts to various events while in the Shutdown state.

NOTE:

1. Shutdown transaction may be reissued by the Pentium® Pro processor.

5.2.3.6.2. Flush

An agent issues a Flush Tr ansaction to indicate that it has inv alidated its internal caches without

writing back any modified lines. If the software using the instruction requires other Pentium Pro

processor s to als o be flushed, it m ust do so v ia APIC IPIs. T he Pen tium P ro pr ocessor g enerates

this transaction on executing an INVD instruction.

5.2.3.6.3. Halt

A processor issues a Halt Transaction to indicate that it has executed the HLT instruction and

stopped program execution. T he following table describes ho w Pentium Pro p rocessor reacts to

variou s events while in the Halt state.

Event Immediate Action Final State

INTR Ignore Shutdown

NMI NMI Handler Entry Do not return to Shutdown on IRET

INIT# Reset Handler Do not return to Shutdown

RESET# Reset Handler Do not return to Shutdown

STPCLK# STPCLK Acknowledge Retur n to Shutdown on !STPCLK

SMI# SMI Handler Entry Return to Shutdown on RSM1

FLUSH# FLUSH Acknowledge Return to Shutdown Immediately

ADS# Snoop Results Return to Shutdown Immediately

BINIT# MCA Handler Entry Do not return to Shutdown

HardFail MCA Handler Entry Do not return to Shutdown

FRCERR MCA Handler Entry Do not return to Shutdown

5-11

BUS TRANSACTIONS AND OPERATIONS

5.2.3.6.4. Sync

An agent issues a Sync Trans action to indicate that it has written b ack all modified lin es in its

internal caches to memory and then invalidated its internal caches. If software wants to guaran-

tee that other processors are also synchronized, it must do so via APIC IPIs. The Pentium Pro

processor generates a Sync Transaction on executing a WBINVD instruction.

5.2.3.6.5. Flush Acknowledge

A caching agent issues a Flush Acknowledge Transaction when it has completed a cache sync,

and flush operation in response to an earlier FLUSH# signal acti vation. If FLUSH# pin is b ussed

to N agents, the Central Agent must expect N Flush Acknowledge transactions.

5.2.3.6.6. Stop Gr ant Acknowledge

An agent issues a Stop Grant Acknowledge Transaction when it enters Stop Grant mode.

The agent continues to respond to RESET#, BINIT#, ADS#, and FLUSH# while in Stop Grant

mode. The Pentium Pro processor powers down its caches in the Stop Grant mode to minimize

its power consumption and generates a delayed snoop response on an external bus snoop

request.

5.2.3.6.7. SMI Acknowledge

An agent issues an SMI Acknowledge Transaction when it enters the System Management

Mode handler. SMMEM# (Ab[ 7]#) is f i rst asserted at this entry p oint. It rem ains asserted for all

transactions issued by the agent. An agent issues another SMI Acknowledge Transaction when

it exits the System Management Mode handler. SMMEM# (Ab[7]#) is first deasserted at this

exit point.

Event Immediate Action Final State

INTR Interrupt Handler Entry Do not return to Halt on IRET

NMI NMI Handler Entry Do not return to Halt on IRET

INIT# Res et Handler Do not return to Halt

RESET# Reset Handler Do not return to Halt

STPCLK# STPCLK Acknowledge Return to Halt on !STPCLK

SMI# SMI Handler Entry Optionally return to Halt on RSM based on a

bit setting in SMRAM

FLUSH# FLUSH Ackno wledge Return to Halt Immediately

ADS# Snoop Results Return to halt Immediately

BINIT# MCA Handler Entry Do not retur n to Halt

HardFail MCA Handler Entry Do not return to Halt

FRCERR MCA Handler Entry Do not return to Halt

5-12

BUS TRANSACTIONS AND OPERATIONS

The SMI Acknowledge Transaction can be obser v ed by the bridge ag ents to determ ine wh en an

agent enters or exits SMM mode.

5.2.4. Deferred Reply Transaction

An agent is sues a Deferred R eply Transaction to complete an earlier transaction for which the

response was deferred. The Deferred Reply Transaction may return data to complete an earlier

Memory Read, I/O Read, or Interrupt Acknowledge Transaction, or it may simply indicate the

completion of an earlier Memory Write, I/O Write, or Invalidate Transaction (note that the data

transfer for a memory write or I/O write takes place in the data phase of the earlier transaction).

After being deferred, the Invalidate Transaction may have hit a modified line on another bus,

which will cause the De ferred R eply Transaction to return data.

The deferring agent is both the requesting agent and the responding agent for the Deferred Reply

Transaction. The addressed agent is the agent which issued the original transaction.

5.2.4.1. REQUEST INITIATOR RESPONSIBILITIES (DEFERRING AGENT)

This transaction uses the address bus to return the Deferred ID, which was sent with the original

request on DID[7:0]#. The Deferred ID is returned on address Aa[23:16]# signals. The deferring

agent will not place a unique ID onto Ab[23:16]#, since DEN# is deasserted.

See Section 5.3.3., “Deferred Operations” for Deferred ID generation.

The ownership transfer of a cache line transferred from the deferring agent to the original re-

questing agent takes place during Snoop Result Phase of this transaction. Since this transaction

is not snooped, HIT# and HITM# signals are used by the requesting agent. For a Deferred Reply

resulting from a Memory Read Data Line Transaction, the deferring agent must assert HIT# in

the deferred reply’s Snoop Result Phase if the original requesting agent should place the line in

the Shared state. If the original requester does not observe HIT# active, it may place the line in

Exclusi ve state. F or a Deferred Reply resulting from a Memory In v alidate T ran saction which hit

a modified line on another bus, the deferring agent must echo the HITM# in the Snoop Result

REQa[4:0]# REQb[4:0]#

00000xxxxx

Ab[15:8]# Ab[7:3]#

xx x SPLCK#=0 rsvd DEN#=0 rsvd

Aa[23:16]# Ab[23:16]#

DID[7:0]# (original) xx

5-13

BUS TRANSACTIONS AND OPERATIONS

Phase of the Deferred Reply (t he Snoop R esult Phase indicates all changes in the leng th of d ata

returned).

The deferring agent may assert DEFER# in the Snoop Result Phase of the Deferred Reply to

retry the original transaction.

A Deferred Reply may receive any response except a Deferred Response. The response must

follow the protocol illustrated in Chapter 4, Bus Protocol. If a Retry Response is received, then

the addressed ag ent will retry the origin al transaction.

5.2.4.2. ADDRESSED AGENT RESPONSIBILITIES (ORIGINAL REQUESTOR)

The addressed agent is the agent which issued the original transaction. It must decode the

DID[7:0]# returned on Aa[23:16]# and match it with a previously deferred transaction. At the

Snoop Result Phase of the Deferred Reply, the original requestor’s transaction is in the exact

same state as the Snoop Result phase for a non-deferred transaction (with DEN# assumed deas-

serted). HIT#/HITM#/DEFER# are used as in the original transaction. It must accept any re-

turned data and complete the original transaction as if it were not deferred. It must make the

appropriate snoop state transition at the Snoop Result Phase of the Deferred Reply, and must re-

issue the original transaction if a Retry Response is received.

5.2.5. Reserved Tran sac t ions

These transaction encodings are reserved. No agent should take any action when they are seen.

They should be completely ignored.

5.3. BUS OP ERATIONS

This section descr ibes b us operati ons . A b us oper ation i s a b us pro cedur e that appear s atom ic to

software even though it might not appear atomic on the bus. The operations discussed in this

section are those that have multiple transactions (such as locked operations) or those that have

potential m ulti ple data transfers (implicit writeback s).

5.3.1. Implicit Writeback Response

In response to any memory transaction, each caching agent issues an i nternal snoop operation.

If the snoop find s the accessed line in the Modified state in a writeback cache, then the caching

agent asserts HITM# in the Snoop Phase. The caching agent that asserted HITM# writes back

the Modified line from its cache during snoop-initiated Data Phase. This data transfer is called

REQa[4:0]#

00001

1100x

5-14

BUS TRANSACTIONS AND OPERATIONS

an implicit wr iteback. The response for a transaction that contains an implicit writeback is the

Implicit Writeback res ponse.

5.3.1.1. MEMORY AGENT RESPONSIBILITIES

On observing HITM# active in the Snoop Phase, the addressed memory agent remains the re-

sponse agent but changes its response to an implicit writeback response.

If the transaction contains a request-initiated data transfer , it remains responsible for TRD Y# as-

sertion to indicate that the write data transfer can begin.

Since the transaction contains a snoop-initiated data transfer, (modified line writeback) the

memory agent asserts a snoop initiated TRD Y# once it has a free cache line buf fer to recei ve the

modified line writeback (after the TRDY# assertion and deassertion for the request initiated

TRDY# is complete, if there was a request initi ated data transfer).

Precisely two clocks from active TRDY# and inactive DBSY#, the Memory Agent drives the

implicit writeback response synchronized with the DBSY# assertion from the snooping agent

for the implicit writeb ack data transfer of the snoop agent.

If the snooped transaction is a write request, the memory ag ent is responsible for merging the

write data with the writeback cache line. The memory agent then updates main memor y with the

latest cache line data. If the snooped transaction writes a full cache line, then there may or may

not be implicit writeback data. If DBSY# is not asserted precisely two clocks from active

TRDY# and inactive DBSY#, then there is no impli c it writeback data.

5.3.1.2. REQUESTING AGENT RESPONSIBILITIES

The requesting agent picks up snoop responsibi lity for the cache line after observing the trans-

action’s Snoop Phase.

The requesting agent always observes the Response Phase to determine if the snoop-initiated

Data Phase contains additional data beyond what was requested:

•If the original request is a Part Line Read Transaction, then the requester obtains the

needed data from the first 64-bit critical chunk (as defined by the burst order described in

Chapter 3, Bus Overview).

•If the original request is a Read Line or Read Invalidate Line Transaction, then the

requester absorbs the entire line.

•If the original request is an Invalidate Line Transaction and the line is modified in another

cache, then the requester updates its internal cache line with the updated cache line

received in the snoop-initiated Data Phase.

•If the original Invalidate Line Transaction receives a Deferred Reply, a HITM# in the

Snoop R esult Phase indicates data wi ll return, and the requ esting agent updates its internal

cache with the data.

5-15

BUS TRANSACTIONS AND OPERATIONS

5.3.2. Transferring Snoop Responsibilit y

A requesting agent picks up snoop responsibility for the cache line after observing a transac-

tion’s Snoop Phase. When a requesting agent accepts snoop responsibility for a cache line and

immediately drops that responsibility in response to a subsequent transaction, it is allowed to

use the cache line exactly once for internal use, before performing an implici t writeback.

Figure 5-2 illustrates the effect of response agent responsibility pickup on an outstanding Inv al-

idation Transaction (Read Invalidate Line, or an Invalidate Line Transaction). It also illustrates

that a cache line can be return ed in response to an Invalidate Line Transaction if two competing

agents request ownership of a Shared cache line simultaneously.

In T1, the requesting agent P1 asserts ADS# and drives the {REQUEST} group to issue Invali-

date Request 1. In T4, a different requesting agent, P2, asserts ADS # and intends to drive the

{REQUEST} group to issue Invalidation request 2 to the same cache line. However, the snoop

of Invalidate Request 1 will invalidate the shared line in P2, forcing P2 to instead issue Read

Invalidate Request 2, to the same cache line.

Figure 5-2. Response Responsibility Pickup Effect on an Outstanding Invalidation

Transaction

CLK

ADS#

21438765

{REQUEST}

DEFER#

DRDY#

TRDY#

RS[2:0]#

HIT#

HITM#

DBSY#

D[63:0]#

1091211 16151413

Owner ? ? ? ? ? ? 1 11 2 2222

5-16

BUS TRANSACTIONS AND OPERATIONS

In T5, P1 observes request 2 and notes that the request is to the same cache line for which it is

expecting ownership in T6. In T6, P1 observes inactive DEFER# and confirms that the transac-

tion has been com m itted for in-order completio n.

If P1 changes the state of the cache line to M (as opposed to E/I), then P1 asserts HITM# in T8

to indicate that it has the cache line in the Modified state. In T8, P1 receives a successful com-

pletion response for request 1. P1 recognizes that it has promised the cache line to a different

agent. It completes its internal cache line update and gets ready to return the line to P2.

In T9, th e memory agent observ es HITM# and as serts TRDY# in T10 in response to the HITM#.

In response in T12, the memory agent asserts implicit writeback response and P1 asserts DB-

SY#. From T12 to T15, P1 drives the implicit cache line data on the data bus. Agent P2 recog-

nizes that the Read Invalidate request is given an implicit writeback response. It receives the

new data associated with the cache line, updates its cache line, and then resumes operation.

Similar to this example, when an Invalidate Line Transaction receives a deferred response, the

corresponding Deferred Reply Transaction may or may not contain data depending on the race

condition. If the Deferred Reply Transaction does not contain data, the deferred reply agent as-

serts a No Data Response. If the Deferred Reply Transaction contains data, the deferred reply

agent asserts HITM# in the Snoop Phase of the Deferred Reply Transaction and asserts an Im-

plicit Writeback response. The original request initiator recognizes that a modified cache line is

being returned and receives the new cache line and updates its internal storage. Memory is not

updated with the Impl icit Writeback data of a Deferred Reply Transaction.

5.3.3. Deferr ed Op erati ons

During the Request Phase, an agent can define Defer Enable (DEN#) to indicate if the transac-

tion can be gi ven Deferred Respon se.

When the flag is inactive, the transaction must not receive a Deferred Response. Certain trans-

actions must always be issued with the fl ag inactiv e. T ransactions in a b us-locked operation, De-

ferred Reply transactions, and Writeback trans actions fall in this category. Transactio n-latency

sensitiv e agents may also use this feature to guarantee transaction completion within a restricted

latency. In-order completion of a transaction is indicated by an inactive DEFER# signal or an

activ e HITM# signal during the Snoop Phase, followed b y normal completion or implicit write-

back response in the Response Phase.

When Defer Enable (DEN#) is inactive, the transaction may be completed in-order or possibly

retried, but it cannot be deferred. All transactions may be completed in order. The only transac-

tions that may not be retried are explicit writeback transactions (REQa[2:0]# = 101B) and

locked transactions subsequent to the first transaction in a locked sequence. The retry feature is

available for use by any bus agent incapable of supporting Deferred Response. These transac-

tions may either be completed in-order (DEFER# inactive or HITM# active during the Snoop

Phase followed by normal completio n respon se), or they must be retried (DEFER# active and

HITM# inactive during the Snoop Phase followed by a Retry Response during the Response

Phase).

5-17

BUS TRANSACTIONS AND OPERATIONS

When Defer Enable (DEN#) is active, the transaction may be completed in-order, or it may be

retried or deferred. A deferred transaction is indicated by asserting DEFER # (with HITM# in-

active) during the Snoop Phase followed by Deferred Response in the Response Phase.

For e very transaction, only one agent is allowed to assert DEFER#. Normally it is the responsi-

bility of the agent addressed by the transaction. When th e addressed agent al ways guarantees in-

order completio n, the responsibility can be g iven to a unique third party ag ent who can assert

DEFER# on behalf of the addressed agent. Both agents m ust then agree on ho w to complete the

transaction and which agent will drive the response.

A deferred or retry response removes the transaction from the In-order Queue. On a retry re-

sponse, it is th e responsibility of the requesting agent to initiate the transaction repeatedly until

the transaction either receives a deferred or in-order completion response. On a deferred re-

sponse, the response agent must latch the Deferred ID, DID[7:0]# issued during the Request

Phase. After the response agent completes the original request, it must issue a matching De-

ferred Reply Bus Transaction. The Deferred Reply transaction’s Request Phase must begin at

least one clock after the Response Phase for the original transaction. The Deferred ID, a v ailable

during the original transaction’s Request Phase, is used as the address in the Deferred Reply

Transaction’s Request Phase.

A Deferred ID contains eight bits, di vided into two f our-bit f ields. The Deferred ID is transferred

on pins Ab[23:16]# (signals DID[7:0]#) in the second clock of the original transaction ’ s Request

Phase. Ab[23:20]# contain the request agent ID, which is unique for every agent. Ab[19:16]#

contains a request ID, assigned by the request agent based on its internal queue (typically a

queue index). Up to sixteen different agents can allow deferred responses. Up to sixteen deferred

responses can be pending for each of the sixteen agents. An agent that supports more than six-

teen outstanding deferred requests can use multiple agent IDs. The Pentium Pro processor limits

the number of outstanding deferred transactions to 4.

The deferred response agent uses the Deferred Reply Transaction phase to transfer completion

status of the deferred transaction. The Deferred ID is driven on address Aa[23:16]# during the

Deferred Reply Transaction’s Request Phase. The final cache state after completion of the De-

ferred Reply for a Read Line Transaction is indicated by the HIT# signal. F or a Deferre d Reply

resulting from a Memory Invalidate Trans action which hit a modified lin e on another bus, the

deferring ag ent must echo t he HITM# in the S noop Re sult P hase of the Deferred Reply i n order

to return une xpected data (the Snoo p Result Phase indicates all changes in the length of data re-

turned). During the response phase, the appropriate response is driven to indicate completion

status of the transaction.

Agents can use the deferred response mechanism when an operation has significantly greater la-

tency than the normal in-order response. The deferred response mechanism can be used to im-

plement non-blocki ng b ridg e comp onen ts be tween the Pentium Pro processor b us and a system

bus to maintain concurrency with guaranteed forward progress.

Deferred transactions enter the In-order Queu e in the same w ay as all other transactions. ADS#

for a deferred reply may be asserted no sooner than one cycle after RS[2:0]# is asserted for the

original transactions that has been deferred.

5-18

BUS TRANSACTIONS AND OPERATIONS

5.3.3.1. RESPONSE AGENT RESPONSIBILITIES

A response agent w illing to give a deferred response must m aintain an internal deferred reply

pool with up to n entries. At the time it wishes to give a deferred response, the response agent

must assign an entry for the transaction in the deferred reply pool and store the Deferred ID

av ailable during the req uest phase of the transaction. After the transaction’s Response Phase has

been dri ven, it must becom e a request bus o wner and initiate a Deferred Reply T ransaction u sing

the Deferred ID as the a ddress. It must also reclaim free q ueue entries in the deferred reply pool.

5.3.3.2. REQUESTING AGENT RESPONSIBILITIES

A requesting agent must assume that ever y outstanding transaction issued with an asserted Defer

Enable (DEN#) flag in the Request Phase may receive a deferred response. Therefore, it must

maintain an internal outstanding transaction queue and ID with the same size as its ability to

pipeline new requests. During the Deferred Reply Transaction, it must compare the reply ad-

dress with all Deferred IDs in its outstanding transaction queue. On an ID match, the requesting

agent can retire the original transaction from its outstanding transaction queue and complete the

operation.

Figure 5-3 illustrates a deferred response followed by the corresponding Deferred Reply for a

read operation.

Figure 5-3. Deferred Response Followed by a Deferred Reply to a Read Operation

CLK

ADS#

21438765

{REQUEST}

DEFER#

DRDY#

TRDY#

RS[2:0]#

HIT#

HITM#

DBSY#

D[63:0]#

1091211 16151413

5-19

BUS TRANSACTIONS AND OPERATIONS

In T1, the requesting agent asserts ADS# and dri ves the {REQUEST} group to issue a Read Line

request. In T5, the Snoop Phase, the addressed agent determines that t he transaction cannot be

completed in-order and hence asserts DEFER#. Since HITM# is observed inactive in T6, in T7

the addressed agent returns a deferred response by asserting the proper encoding on RS[2:0]#.

Before T9, the addressed response agent obtains the data required in the original request. In T9,

the original response agent issues a Deferred Reply Transaction, using the value latched from

the DID[7:0]# signals in the original transaction as the address. In T13, the response agent dri ves

a valid le v el on the HIT# signal to indicate the fin al cache state of the returned line. The original

requestor pick s up snoop res ponsibilit y. In T15, it drives no rmal completion response and als o

begins the Data Phase.

In T10, the or iginal requesting agent ob serves the Deferred Repl y Transaction. It mat ches the

DID[7:0]# to the Deferred ID stored with the original request in its outstanding transaction

queue. The original requesting agent observes the final state of the returned cache line in T14.

In T16, it observes the transaction response and removes the transaction from the outst anding

transaction queue and the In-order Queue. This completes the entire deferred operation

sequence.

5.3.4. Locked Operations

Locked operations provide a means of synchronization in a multiprocessor environment. They

guarantee in divisible sequencing between m ultiple memory tran sactions.

A locked instru ction is gu aranteed to lo ck the area o f me mory defined by the des tinatio n op er-

and. In addition, a lock’s integrity is not affected by the memory operand’s alignment.

In previous generation processors, lock semantics were implemented with a [split] bus lock.

This approach, although suff icient to guarantee indiv isibility , is not always necessary or ef f icient

in a writeback caching agent. During bus lock, other agents are pre vented from issuing b us trans-

actions. In multiprocessing systems, it is desirable to reduce the data bus bandwidth demands of

locked operations, so the Pentium Pro processor implements cache locks. Cache locks allow

locked operations to take place in the cache without tying up the bus.

A locked operation in the Intel386 and Intel486 architecture involves an indivisible read-

modify-write operation on the lock variable. Based on the memory type and alignment of the

lock variable, a locked operation is carried out using one of three options:

Cache Lock. When the lock variable is in a writeback-cacheable (WB) memory range and the

lock variable is contained in one cache line, the locked operation can be executed by:

1) executing any bus transactions necessary to bring the line into the Exclusive or Modified

cache state, and 2) executing the locked read-modify-write sequence in the cache, placing the

line in the Modified state.

[Split] Bus Lock. When the lock variable can not use a cache lock ( due to attribute conflicts) or

crosses an 8-byte boundary, the locked operation is issued on the Pentium Pro processor bus.

The bus is locked during the enti re read-modify-write sequence to guarantee indivisibility.

Some implementations might use a bus lock or split lock even when a cache lock is allowed.

5-20

BUS TRANSACTIONS AND OPERATIONS

5.3.4.1. [SPLIT] BUS LOCK

All variables that cannot be cache locked are locked using the standard [split] bus lock opera-

tion. A Pentium Pro processor [split] bus locked operation (read-modify-write or RMW) in-

volves 1 or 2 memory read transactions followed by 1 or 2 memory write transactions to the

same address. When an y ag ent issues a RMW oper ation, it asserts the LOC K# signal in the R e-

quest Phase and keeps it activ e during the entire Lock Operation. In a split bus locked operation,

the agent asserts Split Lock (SPLCK#) in the first transaction to indicate a split operation. Dur-

ing a RMW operation the agent always deasserts Defer Enable (DEN#) for all transactions in

the operation. The first transaction of the RMW operation may have DEFER# ass erted, which

will retry the entire RMW operation (regardless of the response). No transaction in the RMW

operation after the first read transaction may have DEFER# asserted.

The RMW Operation is successfully completed when the agent successfully completes all mem-

ory transactions. Successful completion occurs when the last transaction of the RMW operation

passes its Error Phase. The requestor retains o wnership of the b us by k eeping LOCK# acti ve un -

til the last transaction successfully completes. The RMW Operation is prematurely aborted an d

retried if the first read transaction receives an AERR# assertion in the Error Phase or DEFER#

assertion in the Snoop Phase. After a premature abortion, the agent issuing the lock operation

must ignore any data returned during Data Phase, deassert LOCK#, re-arbitrate for the bus

(deassert its BREQn# signal if active) and reissue the first transaction.

During the memory read transactions, if other writeback cache agents contain the variable in

Modified state, they supp ly the d ata via th e i mplicit writeb ack mech anism. If the lo ck variable

is contained in Modified state inside the requestor, it performs self-snooping after the locked

transaction is issued on the bus and evicts the cache line via the implicit writeback mechanism.

As e x plai ned in Chapter 4 , Bus Protocol , i f DEFER# assert ion is not o v er-ridden b y HITM# as -

sertion, the agent asserting DEFER# must dri ve a Retry Response in the Response Phase to force

a retry. If DEFER# assertion is overridden by HITM# assertion, the responding agent drives an

implicit writeback response, and the Data Phase completes with an implicit writeback from the

snooping agent. In either case, the lock sequence is aborted and retried.

The entire RMW Operation fails if any one of the b u s lock ed transactions receives a hard error/

deferred respon se or AERR# ass ertion beyon d the retry lim it of t he agent, or if any one o f the

second to fourth transactions recei ves DEFER# assertion. These are protocol violations. As ex-

plained in Chapter 4, Bus Protocol, AERR# assertion causes an arbitration reset sequence. If

AERR# gets asserted on the second to fourth transaction within the retry limit of the agent, the

retrying agen t must be guaranteed bus ownership to guarantee in divis ibility of the lock op era-

tion. The bus protocol requires the retrying agent to arbitrate for the bus two clocks before all

other agents.

Range Registers

6-1

CHAPTER 6

RANGE REGISTERS

6.1. INTRODUCTION

The Pentium Pro processor Memory Type Range Registers (MTRRs) are model specific regis-

ters specifying the types of memory occupying different physical address ranges. Some of this

information was available to previous Intel processors via external bus signals (for example,

KEN# and WB/WT#).

Because Pentium Pro processors on a particular Pentium Pro processor bus share the same mem-

ory address space, all Pentium Pro processors on a Pentium Pro processor bus must have iden-

tical range register contents. The Pentium Pro processor cache protocol assumes that different

caching agents (different Pentium Pro processors) agree on the memory type and cache at-

tributes of each memory line. MTRR updates are per mitted only if all caches h ave been flushed

before and after the update.

As described in following sections, the memory types affect both instruction execution and

cache attribut es.

6.2. RANGE REGISTERS AND PENTIUM® PRO PROCESSOR

INSTRUCTION EXECUTION

The Pentium Pro pr ocessor su pports out-o f-order and specu lative instru ctio n e xecu tion. Ou t-of-

order execution enables the processo r to execute an ins truction even if previous in structions in

the ex ecution stream ha ve not completed or e xecuted. Speculativ e ex ecution enables the proces-

sor to execute an instruction that may or may not be part of the execution stream (such as an

instruction following a conditional branch), so long as the processor can undo the instruction’s

effect if it is not part of the execution stream.

Some memory types should not be accessed by out-of-order or speculative accesses. Fo r e xam-

ple, loading from an address used for memory-mapped I/O can have side effects, such as clear-

ing the loaded v alue fr om an I/O contr oller’s buffer. Such an instruction should not be executed

speculativ ely, b u t only if it is definitely part of the Pentium Pro processor’s ex ecution stream. If

side ef fects of loads must take place in a certain sequence, then such loads should not be ex ecut-

ed out-of-order either.

The memory types in the Pentium Pro processor’s range registers can be used to block out-of-

order or speculative accesses to memory ranges, in additio n to controlling cache attr ibutes. The

two uses are not independent of each other; any memory type that blocks out-of-order or spec-

ulative accesses is also non-cacheable.

The Pentium Pro processor architecture def i nes memory types where speculative and out of or-

der execution is safe (in other words, can be undone in case of misprediction). The same memory

types are also extended to support different cacheability policies such as writeback, and

6-2

RANGE REGISTERS

writethrough. The memory types are defined for specific address ranges based on range regis-

ters. The memory types currently defined, are shown in Table 6-1. The Pentium Pro processor

drives the memory type to the Pentium Pro processor bus in the second clock of the Request

Phase on the ATTR[3:0]# (attribute) pins.

Table 6-1. Pentium® Pr o Pr o ces sor Architectu r e Memo ry Types

ATTR[7:0]#

Encoding Mnemonic Name Description

00000000 UC uncacheable Not c ached. All reads and writes appear on the bus.

Reads and writes can have side effects, therefore no

speculative accesses are made to UC memory.

UC memory is useful for memory-mapped I/O.

00000100 WC write-combining Reads are not cached. Writes can be delayed and

combined. They are also weakly ordered resulting in

substantially higher write throughput. Reading WC

memory cannot have side effects and speculative

reads are allowed.

WC memory is useful for applications such as linear

frame buffers.

00000101 WT write-through Cacheable memory for which all writes are written

through to main memory.

Writing WT memory never causes a cache fill o f an

invalid cache line and either invalidat es or updates a

va lid cache line.

00000110 WP write-protected Cacheab le memory for which reads can hi t the cache

and read misses cause cache fills, but writes bypass

the cache entirely.

00000111 WB wr iteback Cac heable memory for which write misses allocate

cache lines and writes are performed entirely in the

cache whenev er possible.

WB memory is useful for normal memory, providing

the best perform ance and the least bus traffic for

many applications.

All others — Reserved Attempting to write a reserved val ue into a memory

type field of an MTRR signals a #GP(0) fault and

does not update the MTRR.

6-3

RANGE REGISTERS

6.3. MEMORY TYPE DE SCRIPT IONS

This section provides d etailed descriptions of the Pentium Pro processor’s memory type s: UC,

WC, WT, WP, and WB.

6.3.1. UC Memory Type

The UC (uncacheable) memory type provides an uncacheable memory space. The processor’s

accesses to UC memory are executed in program order, without reordering. Accesses to other

memory types can pass accesses to UC memory.

6.3.2. WC Memory Type

The WC (write-combining) memory type provides a write-combining buffering strategy for

write operations, useful for frame b uffers.

Writes to WC memory can be buf fered and combined in the processor’ s write-combining buf fers

(WCB). The WCBs are viewed as a special-purp ose outgoing write buffers, rather than a cache.

The WCBs are written to memory to allocate a diff erent address, or they are written to memory

after leav ing an interru pt, or e xecuting a serializing, locked, or I/O instruction. There are no or-

dering constraints on the writing of W CBs to memory.

The Pentium Pro processor uses line size WCBs. WCB to memory writes use a single Memory

Write T ransaction (W/WB# = 1) of 32 b ytes if all WCB bytes are v alid. If all WCB bytes are not

valid, the valid bytes are written to memory using a series of <= 8 byte Memory Write Transac-

tions. Such a series of transactions can be issued in an y ord er re ga rdless of the program o rder in

which the write data was generated. Therefore, WC memory is a weakly ordered memory type.

A particular Memory Write Transaction can write discontiguous bytes within an 8-byte span.

External hardware that supports the WC memory type must suppor t such writes.

6.3.3. WT Memory Type

The WT (write-through) memory type reads data in lines and caches read data, but maps all

writes to the bus, while updating the cache to maintain cache coherency.

Writes directed at WT memory can be split across 32-byte and 8-byte boundaries, but ar e never

combined.

The Pentium Pro proces so r implement atio n of writes to WT m emo ry upd ates valid lines in the

L1 data cache and invalidates valid lines in the L2 cache and in the L1 code cache.

6-4

RANGE REGISTERS

6.3.4. WP Memory Type

The WP (write-protected) memory type is used for cacheable memory for which reads can hit

the cache and read misses cause cache fills, while writes b ypass the cache entirely. WP memory

can be viewed as a combination of WT memory for reads and UC (nonexistent) memory for

writes.

Note that the WP mem ory type on ly p rotects lines in the cache from being updated by writes. It

does not protect main memory.

6.3.5. WB Memory Type

The WB (writeba ck) memory type is wr iteback memory that is cacheable in an y cache . The WB

memory type is processor -ord ered. The WB memory type is the most cacheable and the highest

performance memory type, and is recommended for all normal memory.

Cache Protocol

7-1

CHAPTER 7

CACHE PROTOCOL

The Pentium Pro processor and Pentium Pro processor bus support a high performance cache

hierarchy with complete support for cache coherency. The cache protocol supports multiple

caching agents (processors) executing concurrently, writeback caching, and multiple levels of

cache.

The cache protocol’s goals include performance and coherency. Performance is enhanced by

multiprocessor suppo rt, support for multiple cache levels, and writeback caching su pport. Co-

herency (or data consistency) guarantees that a system with multiple levels of cache and mem-

ory and multiple active agents presents a shared memory model in which no agent ever reads

stale data and actions can be serialized as needed.

A line is the unit of caching. In the Pentium Pro processor, a line is 32 bytes of data or instruc-

tions, aligned on a 32-byte boundary in the physical address space. A line can be identified by

physical address bits A[35:5].

The cache protocol associates states with lines and defines rules governing state transitions.

States and state trans itions depend on both Penti um Pro processor-generated activities and ac-

tivities by other bus agents (including other Pentium Pro process ors).

7.1. LINE STATES

Each line has a state in each cache. There are four line states, M (Modified), E (Exclusive),

S (Shared), and I (Invalid). The Pentium Pro processor cache protocol belongs to a family of

cache protocols called MESI protocols , named after the four line states. A line can hav e dif ferent

states in dif f erent ag ents, tho ugh the po ssible co mbination s are co nstrained by the protocol. For

example, a line can be Invalid in cache A and Shared in cache B.

A memory access (read or write) to a line in a cache can hav e dif ferent consequences depen ding

on whether it is an internal access, b y the Pentium Pro pro cessor or another bus agent containing

a cache, or an external access, by another Pentium Pro processor or some other bus agent.

The four states are defined as follows:

—I (Invalid)

The line is not available in this cache. An internal acces s to this line miss es the cache

and can cause the Pentium Pro processor to fetch the line into the cache from the bus

(from memory or from another cache).

—S (Shared)

The line is in this cache, contains the same value as in memory, and can have the

Shared state in other caches. Internally reading the line causes no bus activity.

Internally writing the line causes a Write In validate Line transaction to gain ownership

of the line.

7-2

CACHE PROTOCOL

—E (Exclusive)

The line is in this cache, contains the same value as in memory, and is Invalid in all

other caches. Internally reading the line causes no bus activity. Internally writing the

line causes no bus activity, but changes the line’s state to Modified.

—M (Modified)

The line is in this cache, contains a more recent value than memory, and is Invalid in

all other caches. Internally reading or writing the line causes no bus act ivity.

A line is valid in a cache if it is in the Shared, Exclusive, or Modified state.

7.2. MEMORY TYPES, AND TRANSACTIONS

A number of bus and processor t ransactions can cau se a line to trans ition fro m one st ate to an-

other. The transaction being executed, a line’s present state, snoop results, and memory range

attributes combine to determine a line’s new state and coherency-related bus activity (such as

writebacks). This section describes the snoop result signals, memory types, and transaction

types, the overall state transition diagram, and the possible final states for different bus

transactions.

7.2.1. Memory Types: WB , WT, WP, and UC

Each line has a memory type determined by the Pentium Pro processor’s range registers and

control registers, described in Chapter 6, Ra nge Registe rs . For caching purposes, the memory

type can be writeback (WB), wr ite-through ( WT), write-pro tected (WP), or u n-cacheable (UC).

A WB line is cacheable and is always fetched into the cache if a miss occurs. A write to a WB

line does not cause bus activity if the line is in the E or M states.

A WT line is cacheable but is not fetched into the cache on a write miss. A write to a WT line

goes out on the bus. For the Pentium Pro processor, a WT hit to the L1 cache updates the L1

cache. A WT hit to L2 cache inv alidates the L2 cache.

A WP line is also cacheable, but a write to it cannot modify the cache line and the write alw ays

goes out on the bus. A WP line is not fetched into the cache on a write miss. For the Pentium

Pro processor, a WP hit to the L2 cache invalidates the line in the L2 cache.

An UC line is not put into t he cache. A UC hit to the L1 or L2 cache invalidates the entry.

7.2.2. Bus Opera t ions

In this ch apter, th e bus trans actions described in Chapter 5, Bus Transactions and Operations

are classified into the following generic groups for ease of presentation:

BRL (Bus Read Line). A Bus Read Line transaction is a Memory Read Transaction for a full

cache line. This transaction indicates that a requesti ng agent has had a read miss.

7-3

CACHE PROTOCOL

BRP (Bus Read Part-line). A Bus Read Part-line transaction indicates that a requesting agent

issued a Memory Read Transaction for less than a full cache line.

BLR (Bus Locked Read). A Bus Locked Read transaction indicates that a requesting agent is-

sued a bus locked Memory Read T ransaction. For the Pentium Pro processor , this will be for <=

8 bytes.

BWL (Bus Write Line). A Bus Write Line transaction indicates that a requesting agent issued

a Memory Write Transaction for a full cache line. This transaction indicates that a requesting

agent intends to write back a Modified line or an I/O agent intends to write a line to mem ory.

BWP (Bus Write Part-line). A Bus Write Part-line tran saction indicates that a requesting agent

issued a Memory Write Tr ansaction for less than a full cache line.

BLW (Bus Locked Write). A Bus Locked Write transaction indicates that a requesting agent

issued a bus locked Memory Write Transaction. For the Pentium Pro processor, this will be for

<= 8 bytes.

BRIL (Bus Read Invalidate Li n e). A Bus Read Invalidate Line transaction indicates that a re-

questing agent issued a Memory (Read) In v alidate T ransaction for a full cache line. The request-

ing agent has had a read miss and intends to modify this line when th e line is returned.

BIL (Bus Invalidate Line). A Bus Invalidate Line transaction indicates that a reques ting agent

issued a Memory (Read) Invalidate Tr ansaction for 0 bytes. The requesting agent contains the

line in S state and intends to modify the line. In case of a race condition, the response for this

transaction can contain an impli cit writeback.

Implicit Writeback : A Response to Another Transaction . An implicit writeback is not an in-

dependen t bus trans action. It is a response t o another transaction that requests the most up-to-

date data. When an external request hits a Modif ied line in the local cache or buffer, an implicit

writeback is performed to provide the Modified line and at the same time, update memory.

7.2.3. Naming Convention for Transactions

The memory-access transaction names and abbreviations contain up to six components as

follows:

1. B=Bus, I=Internal, or omitted

2. A=Any, CL=Cache Locked, L=[split] Locked

3. R= Read, W= Writ e

4. I=Invalidate, or omitted

5. C=Code, D=Data, or omitted

6. L=Line, P=Partial, or omitted

All cache state transitions with respect to Internal requests assume that the DEFER# signal sam-

pled in the Snoop Result Phase is inactiv e. If DEFER# is sampled activ e and HITM# is inactive,

then no cache state transition is made. If the transaction receives a deferred response, the actual

cache state transition by the recei ver is made during the Snoop Result Phase of the deferred reply

transaction. Cache state transitions associated with “bus” requests ignore the DEFER# signal.

Data Integrity

8-1

CHAPTER 8

DATA INTEGRITY

The chapter has been updated from the EBS 3.0 to simplify and clarify the Data Integrity

features of the Pentium Pro processor bus, as well as updating the Pentium Pro processor

implementation.

The Pentium Pro processor and the Pentium Pro processor bus incorporate several advanced

data integrity features to improve err or detection, retry, and correction. The Pentium Pro proces-

sor bus includes parity protection for address/request signals, parity or protocol protection on

most control signals, and ECC protection for data signals. The Pentium Pro processor provides

the maxim um possible l e vel o f error de tection b y in corporating functional r edundanc y checki ng

(FRC) support.

The Pentium Pro processor dat a integrity features can be categorized as follows:

•Pentium Pro processor internal error detection

•Level 2 (L2) cache and Core-to-L2 cache-interface error detection and limited recovery

•Pentium Pro processor bus error detection and limited recovery

•Pentium Pro processor bus FRC support

In ad dition, the Pent ium Pr o proc essor ext ends the Pentium process or’s data i ntegrity feature s

in several ways to form a machine check architecture. Several model specific registers are de-

fined for reporting error status. Hardware corrected errors are reported to registers associated

with the unit reporting the error. Unrecoverable errors cause the INT 18 machine check excep-

tion, as in the Pentium processor.

If machine check is disabled, or an error occurs in a Pentium Pro processor bus agent without

the machine check architecture, the Pentium Pro processor bus defines a bus error reporting

mechanism. The central ag ent can then be configured to invoke the exception handler via an in-

terrupt (NMI) or soft reset (INIT#).

The terminology used in this chapter is listed b e low:

•Machine Check Architecture (MCA)

•Machine Check Exception (MCE)

•Machine Check Enable bit (CR4.MCE)

•Machine Check In Progress (MCIP)

8-2

DATA INTEGRITY

8.1. ERROR CLASSIFICATION

The Pentium Pro architecture uses the following error classification. An implementation may

always choose to report an error in a more severe category to simplify its logic.

•Recoverable error (RE): The error can be corrected by a retry or by using ECC infor-

mation. The error is logged in the MCA hardware.

•Unrecoverable error (UE): The error cannot be corrected, but it only affects one agent.

The memory interface logic and bus pipeline are intact, and can be used to report the error

via an exception handler.

•Fatal error (FE): The error cannot be corrected and may affect more than one agent. The

memory interface logic and bus pipeline integrity may have been violated, and cannot be

reliably used to report the error via an exception handler. A bus pipeline reset is required of

all bus agents before operation can continue. An exception handler may then proceed.

8.2. PENTIUM® PRO PROCESSOR BUS DATA INTEGRITY

ARCHITECTURE

The Pentium Pro processor bus’s major address and data paths are protected by ten check bits,

providing parity or ECC. Eight ECC bits protect the data bus. Single-bit data ECC errors are au-

tomatically corrected. A two-bit parity code protects the address bus. Any address parity error

on the address bus when the request is issued can be optionally retried to attempt a correction.

Two control signal groups are explicitly protected by individual parity bits: RP# and RSP#. Er-

rors on most remaining b us sign als can be d etected ind irectly due to a well-def i ned b us protocol

specifi cation that enables detection of p rotocol violation errors. Errors on a few b us signals can-

not be detected without the use of FRC mode.

An agent is not required to supp ort all data inte g rity featu res, as each feature is individually en-

abled throu gh the po wer-on co nf igurat ion re gis ter. See Chapter 9 , Configuration of the Pentium

Pro processor EBS 3.0.

8.2.1. Bus Signals Protected D irectly

Most Pentium Pro processor bus signals are protected b y parity or ECC. Table 8-1 shows which

signals protect which signals, what phases the protection is valid in, and what ef fect the address

size (ASZ[1:0]#) has on the protected signals.

8-3

DATA INTEGRITY

•Address/Request Bus Signals. A parity error detected on AP[1:0]# or RP# is reported or

retried based on the follow ing options defined by the power-on configuration:

— AERR# driver disabled.

The agent detecting the parity error ignores it and continues normal operation. This

option is no rmally used in power-on system initialization and system diagnostics.

— AERR# driver enabled, AERR# observation disabled.

The agent detecting the parity error asserts the A ERR# signal during the Error Phase.

This signal can be trapped by the central agent and be driven back to one of the

processors as NMI.

— AERR# driver enabled, AERR# observation enabled.

The agent detecting the parity error asserts the A ERR# signal during the Error Phase.

All bus agents must observe AERR# and on the next clock reset bus arbiters and abort

the erroneous transaction by removing the transaction from the In-Order Queue and

cancelling all remaining phases ass ociated with the transaction. The first n AERR#s to

any request are logged by the initiator as recoverable errors. (n i s an agent-determined

retry limit chosen by the Pentium Pro processor to be 1.) The initiator retries the

canceled request up to n more times. On a subsequent AERR# to the same request, the

requesting agent reports it as a unrecoverable error.

•Response Signals. A parity error detected on RSP# should be reported by the agent

detecting the error as a fatal error.

•Data Transfer Si gnals. The Pentium Pro processor bus can be configured with either no

data-bus error checking or with ECC. If ECC is s elected, single-bit errors can be corrected

and double-bit errors can be detected. Corrected single-bit ECC errors are logged as

recoverable errors. All other errors are repor ted as unrecoverable errors. The errors on read

data being returned are treated by the requ ester as unrecov erab le error s. The errors on write

or writeback data are treated by the target as fatal errors.

•Snoop Processing. An error discovered during a snoop lookup may be treated as a

recoverable error if the cache state is E,S, or I. If the cache is in the M state, the errors are

treated as fatal errors. Any implementation may choose to report all snoop errors as fatal

errors.

Table 8-1. Direct Bus Signal Protection

Signal Protects Phase ASZ[1:0]# ASZ[1:0]# Address range

RP# ADS#,REQ[4:0]# Request x x -

AP[0]# A[23:3]# Request x x -

AP[1]# A[31:24]# Request 0 0 0 <= Address < 4GB

A[35:24]# Request 0 1 4GB <= Address < 64GB

Reserved Request 1 x Reserved

RSP# RS[2:0]# All x x -

DEP[7:0]# D[63:0]# Data x x -

8-4

DATA INTEGRITY

8.2.2. Bus Signals Protected Indirectly

Some bus signals are not directly protected by parity or ECC. However, they can be indirectly

protected due to a requirement to follow a strict protocol. Although the Pentium Pro processor

implementation does not directly detect the errors, future Pentium Pro processor genera tions or

other bus agents can enhance error detection or correction for the bus by checking for protocol

violations. Pentium Pro processor bus protocol errors are treated as fatal errors unless specifi-

cally stated otherwise.

•Arbitration Signals BREQ[3:0]# and BPRI#. Any arbitration error can be detected as a

parity error during the Request Phase or as a Pentium Pro processor bus protocol error:

— If two request phases occur in the same cycle (a collision), a parity error in the address

is detected by all agents. All of these signals are open-drain, ensuring that no physical

damage results from a collision. The error can be optionally reported to the requ esting

agent by as serting AERR#. (AERR# protocol can be optionally enabled for retries to

reset the arbitration ID of all symmetric agents and begin re-arbitration. In this case,

AERR# is treated as a recoverable error.)

— If BREQn# is deasserted while the agent is not the bus o wner, the error can be detected

by all the bus agents as a Pentium Pro processor bus protocol error.

— If Request generation occurs while the agent is not the bus owner, the error can be

detected by the current bus owner. The same error can also be detected by other agents

by comparing the agent ID with the current bus owner ID driven on DID[7: 0]#.

— If a non-lock driver activates BREQn# or BPRI# sooner than the fourth clock after an

AERR# during a LOCK# sequence, the lock driver can detect the protocol violation

error.

— If a non-lock driver generates a request during a LOCK# sequence, the protocol

violation error can be detected by the lock driver.

— If the lock dri ver does not acti vate BREQn# two clocks after AERR# dur ing a LOCK#

sequence, the protocol violation error can be detected by all bus agents.

•Lock S ign al LOC K #. LOCK# can only be asserted with a valid ADS# assertion. LOCK#

can only be deasserted after sampling an active AERR# or DEFER# in the first locked bus

transaction, or after sampling a successful completion response RS[2:0]# on the last bus

locked transaction. All bus agents can detect a protocol violation on LOCK# assertion/de-

assertion.

•Block Next Request Si gnal, BNR#. In the BNR-free state, BNR# must be inactive when

no request is being generated (ADS# inactive), or during the first three clocks of a new

request generation (ADS#, ADS#+1, and ADS#+2). The following BNR# protocol errors

can be detected by all agents.

— Activation of BNR# when it must be inactive.

— Activation of ADS# during a valid BNR# assertion request.

8-5

DATA INTEGRITY

•Snoop Si gnals , HIT#, HI TM#, and DE FER#. These signals can only be asserted during

a valid snoop wind ow. The following snoo p pro t ocol vi o lation erro rs can be det ect ed by all

agents:

— Activation of snoop signals outside of a valid snoop window.

— HIT# asserted and HITM# deasserted for I/O, special, or ownership memory

transactions.

— HITM# assertion with HIT# deasserted for a non-memory transaction.

•Response Signals, RS[2:0]#. These signals can only be asserted during a valid response

window. The following protocol violation errors can be detected by all agents:

— Response is active for more than one consecutive clock or inactive for less than two

consecutive clocks.

The following protocol violation errors can be detected by the transaction initiator:

— The response does not match the request or snoop results data. The following are

response proto co l errors: no -data incon sistent with requ est, retry/deferred i ncons ist ent

with request, im plicit writeback inconsistent wi th HITM#, deferred/retry incons istent

with DEFER#.

— The response is activated in less than two clocks from the transaction s noop phase.

•Data Ready Signal, DRDY#.

— An error in this sig nal can be detected by the init iator or target if the number of clocks

DRDY# is active is inconsistent with the request or the snoop result.

— The initiator can detect a protocol error if read data returns before a valid Response

Phase.

— The target can detect a protocol error if write data returns before valid TRDY#.

— The data driver can detect a protocol error if DRDY# is asserted by the wrong agent.

— All agents can detect a protocol err or if DRDY# is acti v e with DB SY# inactive for two

consecutive clocks.

•Data Busy Signal, DBSY#.

— The initiator can detect a protocol error if DBSY# is not active with response when

more than one chunk of data is being returned, or DRDY# is inactive when a single

data chunk is being returned.

— The target can detect a protocol error if the proper number of chunks is not returned

after TRDY# assertion.

— The data driver (initiator, target, or snooper) can detect a protocol error if DBSY# is

being driven by the wrong agent.

8-6

DATA INTEGRITY

•Target Ready Signal, TRDY#.

— TRDY# protocol violation can be detected by all agents when TRDY# assertion is

detected with response assertion or when TRDY# is deasserted in less than three

clocks from the previous TRDY# deassertion, or when TRDY# is deasserted even

when it is required to be stretched due to DBSY# active from the previous data

transfer.

— The target can detect a TRDY# protocol error if TRDY# is asserted by the wrong

agent.

— The initiator and the target can detect a TRDY# protocol error if TRDY# is asserted

for a transaction other than a write or a writeback.

— The initiator or snooping agent can detect a TRDY# protocol error if TRDY# is not

asserted two clocks prior to an Implicit Writeback Respons e.

•Address Error Signal, AERR#. An AERR# protocol violation can be detected if AERR#

is asserted outside of a valid Error Phase.

•Bus Error Si gnal, BERR#. A BERR# protocol violation can be detected by all agents if

BERR# is asserted for greater than four clocks. (3 clocks plus 1 clock for a wired-OR

glitch)

•Bus Initia lize Signa l, BIN IT #. A BINIT# protocol violation can be detected by all agents

if BINIT# is asserted for greater than four clocks. (3 clocks plus 1 clock for a wired-OR

glitch)

8.2.3. Unprotected Bus Signals

Errors on some Pentium Pro processor bus signals cannot be detected:

•The execution control signals CLK, RESET#, and INIT# are not protected.

•The error signals FRCERR and IERR# are not prot ected.

•The PC compatibility signals FERR#, IGNNE#, A20M#, and FLUSH# are not protected.

•The system support si gnals S M I# and STPCLK# are not protected.

8.2.4. Time-out Errors

A centra l agent on the bus can enhanc e error detec tion or correction by observing sy stem-

dependent time-out errors.

•Response time-out. If the response is not returned after a reasonable delay from the

request, the central agent may provide a hard failure response to terminate the reques t.

•Lock time-out. If LOCK# is asserted for more than a reasonable number of clocks, then

the central agent should pro vide a hard failure response. The lock time-out duration should

be much longer than the response time-out duration.

8-7

DATA INTEGRITY

•Arbitratio n time-out. If BPRI# is ass erted for more than a reasonable number of clocks,

then the central agent should indicate a bus protocol violation.

8.2.5. Hard-error Response

The target can assert a hard-error response in the Response Phase to a transaction that has gen-

erated an error. The central agent can als o claim responsibility for a transaction after response

time-out expiration and terminate the transaction with a hard error response.

On observing a hard-error response, the initiat or may treat it as a u nrecoverable or a fatal error.

8.2.6. Bus Error Codes

8.2.6.1. PARITY ALGORITHM

All bus parity signals use the same algorithm to compute correct parity. A correct parity signal

is high if all cov ered signals are high, o r if an e v en nu mber of co v ered signals are lo w. A correct

parity signal is low if an odd number of covered signals are low. Parity is computed using volt-

age levels, regardless of whether the covered signals are active-high or active-low. Depending

on the number of covered signals, a parity signal can be viewed as providing “even” or “odd”

parity; this sp ecification does not use eith er term.

8.2.6.2. PENTIUM® PRO PROCESSOR BUS ECC ALGORITHM

The Pentium Pro processor bus uses an ECC code that can correct single-bit errors, detect dou-

ble-bit errors, an d d etect all er ror s confined to o ne nibb le (SEC -DED-S4ED). Syste m design ers

may choose to detect all these errors, or a subset of these errors. They may also choose to use

the same ECC code in L3 caches, main memory arrays, or I/O subsystem buffers.

8.3. ERROR REPORTING MECHANISM

8.3.1. MCA Hardware Log

If CR4.MCE is set, all errors are logged using the available MCA hardware.

8.3.2. MCA So ftware Log

If CR4.MCE is set, unrecoverable errors cause entry into the INT 18 exception handler , as in the

Pentium processor. The INT 18 exception handler will not be entered if the error occurs while a

machine check is in progress (MCIP). The exception handler will also not be entered by a check-

er of a FRC pair. The exception handler can be used to determine the exact source of the error

by reading the model specif ic registers associated with the unit reporting the error. Internal ma-

chine check errors are aborts, as in the Pentium processor, but may be restartable in some cases.

8-8

DATA INTEGRITY

8.3.3. IERR# Signal

The IERR# signal is asserted by a Pentium Pro processor when an unrecoverable error is not

handled with the MCA software log (MCA disabled). The IERR# signal stays asserted until

deasserted by the NMI handler or RESET#/INIT# resets the processor. BERR# can be config-

ured to report IERR# assertion.

8.3.4. BERR# Signal and Protocol

BERR# is asser ted to re port un reco v erable erro rs not handled b y MCA on the Pe ntium Pr o pro-

cessor bus. If bus error reporting o n initiator internal errors is enabl e d (see Section 9.1.9., “Bus

Error Driv ing Policy for Initiator Internal Errors”). The Pentium Pro processor asserts BERR#

once when IERR# is asserted (the Pentium Pro processor also can drive BERR# immediately

after a bus related unrecoverable error). If external error reporting is enabled, an external agent

asserts BERR# when unrecoverable errors are found.

The BERR# protocol takes into account multiple bus agents trying to assert BERR# at the same

time, as show n in Figure 8-1. Once BERR# is asserted by one bus agent , all agents ensure that

it is asserted for exactl y three clocks. An agent intending to assert BERR# observes BERR# to

ensure that it is inactiv e. If the agent samples BERR# inacti v e in the clock it first dri v es BERR#,

it retains BERR# active for exactly three clocks. If the agent samples BERR# active in the first

clock, it drives BERR# (due to another bus agent asserting BERR# one clock prior to its asser-

tion of BERR#, the agent retains BERR# active for exactly two clocks).

Figure 8-1. BERR# Protocol Mechanism

CLK

Processor 0

Processor 1

Processor 2

Processor 3

1 234567

CLK

Processor 1

Processor 2

Processor 3

1 234567

Processor 0

BERR#

Processo r 0 observe s BERR # inact iv e in CLK 2

and asserts BERR# for exactly three clocks. Processor 0 observes BERR# active in CLK 2

and asserts BERR# for exactly two clocks.

BERR# BERR#

8-9

DATA INTEGRITY

8.3.5. BINIT# Signal and Protocol

BINIT# is asserted when any Pentium Pro processor agent detects a fatal error and BINIT# dri v-

er is enabled. Sampling of BINIT#, if enabled, resets all bus state, clearing a path for an excep-

tion handler (disabling of BINIT# driving/sampling is provided for power on diagnostics only).

This typically causes undefined termination of all pending transactions. Therefore, it cannot be

used to fully recov er from the original error state. Ho we v er, once the bus pipeline is reset for all

Penti um Pro processor bus agent s, it is pos sible to run an exception handler to log the error. If

CR4.MCE is set, all Pentium Pro processors on the bus enter the MCE handler . If not set, IERR#

to BE RR# rep orting sh ould be en abled s o bu s error re porting can gen erate an in terrupt ( NMI)

or soft reset (INIT#). The programmer -visible re gister state can be read by the e xception handler

to attempt graceful error logging.

On observation of active BINIT#, all Pentium Pro processor bus agents must do the following:

•Deassert all signals on the bus.

•Reset the arbitration IDs to the value used at power-on reset.

•Reset the transaction queues included the In-order Queue.

•Begin a new arbitration sequence for the request bus and continue.

•Return programmer- visible register state and cache state to their previous values.

The BINIT# protocol takes into account multiple bus agents trying to assert BINIT# at the same

time, as shown in Figure 8 -2. Once BINIT# is asserted by one bu s agent, all agents ensure that

it is asserted for exactly three clocks. An agent intending to assert BINIT# observes BINIT# to

ensure that it is inactiv e. If the agent samples BINIT# inactive in the clock it f irst driv es BINIT#,

it retains BINIT# acti v e for exactly th ree clocks. If the agen t samples BINIT# activ e in the clock

it first driv es BINIT#, (due to another b us agent asserting BINIT# one clock prior to its assertion

of BINIT#) it retains BINIT# active for exactly two clocks.

8-10

DATA INTEGRITY

8.4. PENTIUM® PRO PROCESSOR IMPLEMENTATION

Figure 8-3 shows the sour ces of errors within th e Pentium Pro pro cessor for each of the Pentium

Pro processor error catego ries and the actions taken when an error occurs. The small squares in-

dicate the configuration option enabled in the Pentium Pro processor power-on configuration

error is logged in the MCA re gisters. A do wn ar ro w indicates which Pentium Pro processor sig -

nal is asserted via the protocol for that signal. “Master” refers to an action taken by the master

in a FRC pair, and “Checker” refers to an action taken by the checker in a FRC pair.

Figure 8-2. BINIT# Protocol Mechanism

CLK

Processor 0

Processor 1

Processor 2

Processor 3

1 234567

CLK

Processor 0

Processor 1

Processor 2

Processor 3

1 234567

BINIT#

Processor 0 observes BINIT# inactive in CLK 2

and asserts BINIT# for exactly three clocks. Processor 0 observes BINIT# active in CLK 2

and asserts BINIT# for exactly two clocks.

BINIT#

8-11

DATA INTEGRITY

8.4.1. Speculative Errors

The Pentium Pro processor may tr eat some erro rs on specu lative requests as recoverable errors.

The error is logged and, if the instruction is not executed, may be ignored.

8.4.2. Fatal Errors

In some circumstances, the Pentium Pro processor treats unrecoverable errors as fatal errors.

This occurs for unrecoverable errors on snoops, accesses to modified data, split accesses, and

locked accesses.

Figure 8-3. Pentium® Pro Processor Errors

Bus Read 1-bit ECC

Bus Request 1st AERR#

L2 1-bit ECC

Speculative

Bus Read 2-bit ECC

Bus Request 2nd AERR#

Bus Hard Error Response

L2 2-bit ECC

Inte rn a l Pa rity

BINIT#

FRCERR Master

Checker

NE on Snoop

NE on RFO

NE on M line

NE on Split

NE on Lock

Pentium® Pro Timeout

RSP# error

log CR4.MCE

!Checker

!MCIP

MCE

IERR# BERR#

log

BINIT#

ELSE

Non-

Fatal

Recoverable

SHUTDOWN

RESET BUS

Error

recoverable

Error

8-12

DATA INTEGRITY

8.4.3. Pentium® Pro Processor Time-Out Counter

The Pentium Pro processor implements a time-out counter, which issues a fatal error if the pro-

cessor is stalled for a long period of time. This mechanism is not related to the Pentium Pro pro-

cessor bus time-out errors described in Section 8.2.4., “Time-out Errors”. The timer is 31 bits

wide and is clock ed from BCLK. The pro cessor is not considered stalled wh en in normal modes

(e.g. Stopclock or HALT).

Configuration

9-1

CHAPTER 9

CONFIGURATION

This chapter describes configuration options for Pentium Pro processors and the Penti um Pro

processor bus agents.

A system can contain multip le Pentium Pro processors. Processors can be u sed in a multipro-

cessor conf igurati on, with one to f our Pentium P ro processor s on a singl e Pentium Pro processor

bus. Processor s can also be used in FRC con figurations, with two ph ysical processors per logical

FRC unit. All Pentium Pro processors are connected to one Pentium Pro processor bus unless

the description specifically stat es ot herwis e.

9.1. DESCRIPTION

Pentium Pro processor bus agents have some configuration options which are determined by

hardware, and some which are determined by software.

Pentium Pro processor bus agents sample their hardw are config uration at reset, on the activ e-to-

inactive transition of RESET#. The configuration signals (except IGNNE#, A20M# and

LINT[1:0]) must be asserted 4 clocks before the acti v e-to-inacti v e transitio n of RESET# and be

deasserted two clocks after the active-to-inactive transition of RESET# (see Figure 9-1). The

IGNNE#, A20M#, and LINT[1:0] signals must meet a setup time of 1ms to the active-to-inac-

tive transition of RESET#.

The sampled information configures the Pentium Pro processor and other bus agents for subse-

quent oper ation. These conf ig uration optio ns canno t be cha nged e xcept by another r eset. All re-

sets reconfigure the Pentium Pro processor bu s agents; the bus agents not distinguish between a

“warm” reset and a “power-on” reset.

Figure 9-1. Hardware Configuration Signal Sampling

CLK

1 23456789

{CONFIGURATION

PINS}

RESET#

9-2

CONFIGURATION

Pentium Pro processor bu s agents can also be configured with some additional softw are conf ig-

uration options. These options can be changed by writing to a pow er-on configuration register

which all bus agents must implement. These options should be changed only after taking into

account synchronization between multiple Pentium Pro processor bus agents.

Pentium Pro processor bus agents have the following configuration options:

•Output tristate {Hardware}

•Execution of the processor’s built-in self-test (BIST) {Hardware}

•Data bus error-checking policy: enabled or disabled {Software}

•Response signal error-checking policy: parity disabled or parity enabled {Software}

•AERR# dri v i ng poli c y : enabled or disab led {Software}

•AERR# observation policy: enabled or disabled {Hardware}

•BERR# driving policy for initiator bus errors: enabled or disabled {Software}

•BERR# driving policy for target bus errors: enabled or disabled {Software}

•BERR# driving policy for initiator internal errors: enabled or disabled {Software}

•BERR# observation policy: enabled or disabled {Hardware}

•BINIT# error-driving policy: enabled or disabled {Software}

•BINIT# error-observation policy: enabled or disabled {Hardware}

•In-order Queue depth:1 or 8 {Hardware}

•Power-on reset vector: 1M-16 or 4G-16 {Hardware}

•FRC mode: enabled or disabled {Hardware}

•APIC cluster ID: 0, 1, 2, or 3 {Hardware}

•APIC mode: enabled or disabled {Software}

•Symmetric agent arbitration ID: 0, 1, 2, or 3 {Hardware}

•Clock frequencies and ratios {Hardware}

9.1.1. Output Tristate

The Pentium Pro processor tristates all of its outputs if the FLUSH# signal is sampled activ e on

the RESET# signal’s active-to-inactive transition. The only way to exit from Output Tristate

mode is with a new activation of RESET# with inactive FLUS H#.

9-3

CONFIGURATION

9.1.2. Built-in Sel f Test

The Pentium Pro processor executes its built-in self test (BIST) if the INIT# signal is sam pled

active on the RESET# signal’s active-to-inactive transition. In an MP cluster based on the sys-

tem architecture, the INIT# pin of different processors may or may not be bused. No software

control is available to perform this function.

9.1.3. Data Bus Error Checking Policy

The Pentium Pro processor data b us error checking can be enabled or disabled. After acti ve RE-

SET#, data bus error checking is always disabled. Data bus error checking can be enabled under

software control.

9.1.4. Response Signal Parity Error Checking Policy

The Pentium Pro processor bus supports parity protection for the response signals, RS[2:0]#.

The parity checking on these signals ca n be enabled or disabled. After acti v e RESET#, response

signal parity checking is disabled. It can be enabled under software control.

9.1.5. AERR# Driving Policy

The Pentium Pro p rocessor addr ess b us supports parity protec tion on the Requ est Phase sig nals,

Aa[35:3]#, Ab[3 5: 3] #, ADS #, REQa[4:0]#, and REQb[3 : 0]# . Howeve r d riving the address par-

ity results on the AERR# pin is optional. After acti ve RESET#, address bus parity error dri ving

is always disabled. It may be enabled under software control.

9.1.6. AERR# Obser vation Poli cy

The AERR# input receiver is enabled if A8# is observed active on active-to-inactive transition

of RESET#. No software control is avail able to perform this function.

9.1.7. BERR# Driving Policy for Initiator Bus Errors

A Pentium Pro processor bus agent can be enabled to drive the BERR# signal if it detects a bus

error. After acti ve RESET#, BERR# signa l driving is d i sabled fo r d etected erro rs. It may be en-

abled under software control.

9-4

CONFIGURATION

9.1.8. BERR# Driving Policy for Target Bus Errors

A Pentium Pro processor bus agent can be enabled to drive the BERR# signal if the addressed

(target) bus agent detects an error. After active RESET#, BERR# signal driving is disabled on

target bus errors. It may be enab led under software control. The Pentium Pro p rocessor does n ot

dri ve BERR# on tar get detected bus errors. The Pent ium Pro processor does support observatio n

and machine check entrance.

9.1.9. Bus Error Driving Policy for Initiator Internal Errors

On internal errors, a Pentium Pro processor bu s agent can be enabled to driv e the BERR# signal.

After active RESET#, BERR# signal driving is disabled on internal errors. It may be enabled

under softw are cont r ol .

9.1.10. BERR# Observation Pol icy

The BERR# input receiver is enabled if A9# is observed active on the active-to-inactive transi-

tion of RESET#. The Pentium Pro processor does not support this configuration option.

9.1.11. BINIT# Driving Policy

On bus protocol violations, a Pentium Pro processor bus agent can be enabled to drive the

BINIT# signal. After active RESET#, BINIT# signal driving is disabled. It may be enabled un-

der software control. The Pentium Pro processor relies on BINIT# driving to be enabled during

normal operation.

9.1.12. BINIT# Observation Policy

The BINIT# input recei v er is en abled for b us initialization control if A10# is ob served acti v e on

the active-to-inactive transition of RESET#. The Pentium Pro processor relies on BINIT# ob-

servation being enabled during normal operation.

9.1.13. In-order Queue Pipelining

Pentium Pro processor bus agents are configured to an In-order Queue depth of one if A7# is

observed active on RESET#. Otherwise it defaults to an In-order Queue depth of eight. This

function cannot be controlled by software.

9-5

CONFIGURATION

9.1.14. Power-on Reset Vector

The reset vector on which the Pentium Pro processor begins execution after an active RESET#

is controlled by sampling A6# on the RESET# signal’s active-to-inactive transition. The reset

vector for the Pe ntium Pr o pro cessor is 0FFFF0H (1Meg - 16) if A6# is sample d active. Other-

wise, the reset vector is 0FFFFFFF0H (4Gig - 16).

9.1.15. FRC Mode Enable

Pentium Pro processor b us agents can be conf igured to support a mod e in which FRC is disabled

or a mode in which FRC is enabled. The Pentium Pro processor enters FRC enabled mode if

A5# is sampled active on the active-to-inactive transition of RESET#, otherwise it enters FRC

disabled mode.

9.1.16. APIC Mode

APIC may be enabled or disabled via software. For details, see the latest APIC EAS.

9.1.17. APIC Cluster ID

A Pentium Pr o processor sy stem provid es common APIC bus support for up to four Pentium Pro

processor-bus clusters, where each cluster contains a Pentium Pro processor bus and up to four

Pentium Pro pro cessors. The APIC cluster ID is a 2-bit value that identifies a bus cluster: 0, 1,

2, or 3. The Penti um Pr o proces sor dete rmi nes its AP IC clu ster ID b y sampli ng A12# and A11#

on the RESET# signal’s active-to-inactive transition based on Table 9-1.

NOTE:

1. L and H designate electrical levels.

Ta ble 9-1. APIC Cluster ID Configuration for the Pentium® Pro Processor

APIC ID A12# A11#

1HL

2LH

3LL

9-6

CONFIGURATION

9.1.18. Symmetric Agent Arbitration ID

The Pentium Pro processor bus supports symmetric distributed arbitration among one to four

agents. Each Pentium Pro processor identifies its initial position in the arbitration priority queue

based on an agent ID supplied at configuration. The agent ID can be 0, 1, 2, or 3. Each logical

Pentium Pro processor (not a FRC master/checker pair) on a particular Pentium Pro processor

bus must have a distinct agent ID.

BREQ[3:0]# bus signals are connected to the four symmetric agents in a rotating manner as

shown in Table 9-2 and Figure 9-2. Every symmetric agent has one I/O pin (BR0#) and three

input only pins (BR1#, BR2# and BR3#).

Table 9-2. BREQ[3:0]# Interconnect

Bus Signal Agent ID 0

Physical Pin Agent ID 1

Physical Pin Agent ID 2

Physical Pin Agent ID 3

Physical Pin

BREQ0# BR0# BR3# BR2# BR1#

BREQ1# BR1# BR0# BR3# BR2#

BREQ2# BR2# BR1# BR0# BR3#

BREQ3# BR3# BR2# BR1# BR0#

9-7

CONFIGURATION

At the RESET# signal’s active-to-inactive transition, system interface logic is responsible for

assertion of the BREQ0# bus signal. BREQ[3:1] # bus sign als remain deasserted. All Pentium

Pro proces sors sample their BR[3:1]# p ins on the RESET signal’s active-to-i nactive transition

and determine their agent ID from the sampled value.

If FRC is not enabled, then each physical processor is a logical processor . Each pr ocessor is des-

ignated a non-FRC master and each processor has a distinct agent ID.

Figure 9-2. BR[3:0]# Physical Interconnection

Agent 0 Agent 1 A gent 2 Agent 3

BR1#

BR2#

BR3#

BREQ0#

BREQ1#

BREQ2#

BREQ3#

Priority

BPRI#

Agent

BR0#

BR1#

BR2#

BR3#

System

Interface Logic

During Reset

9-8

CONFIGURATION

If FRC is used, then two physical processors are combined to create a single logical processor.

Processors with agent ID 0 and 2 are designated as FRC-masters and use their agent ID as their

parallel bus arbitration ID. Processors with agent ID 1 and 3 are designated as FRC checkers for

processors 0 and 2 respectively and assume the characteristics of their respective masters as

shown in Table 9-3.

NOTE:

1. L and H designate electrical levels.

9.1.19. Low Power Standby Enabl e

A configuration register bit which enables distribution of the core clock during AUTOHalt and

Stop Grant mode has been included in the power-on configuration register. This register will

support bit D26, which can be read and written by software.

—D26=1

In this mode when the Pentium Pro pro cessor enters AUTOHalt or Stop Grant, it will

not distribute a clock to its core units. This allows the Pentium Pro processor to reduce

its standby power consumption, but large current transients are produced upon

entering and exiting this mode.

—D26=0 (Default)

In this mode, AUTOHalt and Stop Grant will not stop internal clock distribution. The

Pentium Pro processor will have higher st andby power consumption, but will pro duce

smaller current transients on entering and exiting this mode.

Table 9-3. Arbitration ID Configuration

BR0# BR1# BR2# BR3# A5# Arb Id

L1HHHH0

HHHLL1

HHLHH2

HLHHH3

LHHHL0

HHHLL0

HHLHL2

HLHHL2

9-9

CONFIGURATION

9.2. CLOCK FREQUENCIES AND RAT IOS

The Pentiu m Pro pr ocessor b us and Pent ium Pro p rocessor u se a ratio clock design, in whi ch the

bus clock is multiplied by a ratio to produce the processor’s internal (or “core”) clock. The Pen-

tium Pro processor be gins sampling A20M# an d IGNNE# on th e inacti v e-to-active transition of

RESET# to determine the core-frequency to bus-frequency relationship and immediately begins

the internal PLL lock mode. On the active-to-inactive transition of RESET#, the Pentium Pro

processor internally latches the inputs to allow the pins to b e used for normal fun ctionality. Ef-

fectively, these pins must meet a large setup time (1ms) to the active-to-inactive transition

of RESET#.

Table 9-4 describes the relationship between bus frequency and core frequency. See Figure

11-10 for a list of tested ratios per product.

NOTE:

1. L and H designate electrical levels.

NOTES

If the power-on configuration information supplied on the two pins is the

same for all CP Us on the P ent ium Pro pro cessor bus, the C PUs wil l run with

identical core frequency. The system designer has the flexibility to operate

different CPUs at different core frequencies by supplying a different ratio to

individual CPU pins.

Intel may also introduce different bus frequency to core frequency ratios than

the ones currently specif ied. In order to introduce ratios other than 2, 3, and 4,

two additional configuration pins, LINT[1:0], are currently reserved.

Table 9-4. Bus Frequency to Core Frequency Ratio Configuration1

Ratio of Core

Freq to Bus Freq LINT[1] LINT[0] IGNNE# A20M#

2LLLL

3LLHL

4LLLH

Reserved L L H H

5/2 L H L L

7/2 L H H L

Reserved L H L H

Reserved L H H H

Reserved HLLL - HHHL

2HHHH

9-10

CONFIGURATION

9.2.1. Clock Frequencies and Ratios at Product Introduction

Only the 2 X ratio is supported by the Pentium Pro 133 MHz process or. All other combinatio ns

are reserved.

9.3. SOFTWARE-PROGRAMMABLE OPTIONS

All bus agents are required to m aintain some software read/writable b its in the power-on con-

fi gurat ion re gi ster fo r softwar e-configured options. This reg ister ins ide the Pent ium Pro pr oces-

sor is defined in Table 9-5.

Table 9-5. Pentium® Pro Processor Power-on Configuration Register

Feature

Pentium® Pro

Processor

Active

Signals

Pentium Pro

Processor

Output tristate enab led FLUSH# D8=1 Read N.A.

Ex ecute BIST INIT# D9=1 Read N.A.

{rcnt], {scnt} driven during REQb#

(debug mode) enabled N.A. D0=1 Read/Write disabled

Data error checking enabled N.A. D1=1 Re ad/Wr ite disabled

Response Error checking enabled

FRCERR obser vation enabled N.A. D2=1 Read/Write disabled

AERR# driver enabled N.A. D3=1 Read/Write disabled

AERR# observation enabled A8# D10=1 Read N.A.

BERR# driver enabled for initiator

bus requests N.A. D4=1 Read/Write disabled

BERR# driver enabled for target

bus requests N.A. Reserved Read/Write disabled

BERR# driver enabled for initiator

internal errors. N.A. D6=1 Read/Write disabled

BERR# observation enabled A9# Reserved Read N.A.

BINIT# driver enabled N.A. D7=1 Read/Write disabled

BINIT# observation enabled A10# D12=1 Read N.A.

In-order queue depth of 1 A7# D13=1 Read N.A.

9-11

CONFIGURATION

1 Mbyte power-on reset vector A6# D14=1 Read N.A.

FRC Mode enabled A5# D15=1 Read N.A.

APIC cluster ID A12#,A11# D17,D16

see Table 9-1 Read N.A.

Reser ved A14#,A13# D25,D19, D18 - -

Symmetric arbitrati on ID BR0#,

BR1#,

BR2#,

BR3#,

A5#

D21,D20

see Table 9-3 Read N.A.

Cloc k frequency ratios LINT[1:0],

A20M#,

IGNNE#

D24, D23,D22

see Table 9-4 Read N.A.

Enable rcnt/scnt debug mode N.A. D0 Read/Write disabled

Low power standby enable N.A. D26 Read/Write disabled

Table 9-6. Pentium® Pro Processor Power-on Configuration Register APIC Cluster ID bit

Field

APIC ID D[17:16]

000

101

210

311

Table 9-7. Pentium® Pro Processor Power-on Configuration Register Bus Frequency to

Core Frequency Ratio Bit Field

Ratio of Core Freq to Bus Freq D[24:22]

2 000

3 001

4 010

2 011

7/2 101

5/2 111

Table 9-5. Pentium® Pro Processor Power-on Configuration Register (Contd.)

Feature

Pentium® Pro

Processor

Active

Signal s

Pe ntium Pr o

Processor

9-12

CONFIGURATION

Table 9-8. Pentium® Pro Processor Power-on Configuration Register Arbitration ID

Configuration

Arb id D[21:20]

000

101

210

311

Pentium® Pro

Processor Test

Access Port (TAP)

10-1

CHAPTER 10

PENTIUM® PRO PROCESSOR TEST

ACCESS PORT (TAP)

This chapter describes the implementati on of the Pentium Pro processor test access port (TAP)

logic. The Pentium Pro processor TAP complies with the IEEE 1149.1 (“JTAG”) test architec-

ture standard. Basic functionality of the 1149.1-compatible test logic is described here, but this

chapter does not describe the IEEE 1149.1 standard in detail. For this information, the reader is

referred to the published standard1, and to the many books currently available on the subject.

A simplif ied block diagram of the Pentium Pro processor TAP is sho wn in Figure 10-1. The Pen-

tium Pro processor TAP logic consists of a finite state machine controller, a serially-accessible

instruction reg ister , instruction decod e logic and data re gisters. The set of data reg isters includes

those described in the 1149.1 standard (the bypass register, device ID register, BIST result reg-

ister, and boundary scan register).

1 ANSI/IEE E Std. 1149 .1 -1990 (incl ud ing IEEE Std. 114 9. 1a-1993), “IE E E Standard Test Acces s Port and Bounda ry-

Scan Architecture,” IEEE Pre ss, Piscataway NJ, 1993.

Figure 10-1. Simplified B lock Diagram of Pentium® Pro Processor TAP logic

Device Identification

BYPASS Register

Instruction Register

TDI

TMS

TCK

TRST#

Control Logic

Instruction Decode /

Control Logic

BIST Result

TAP

Boundary Scan Register

Control Signals

TDO

TAP

Controller

Machine

TDO

CPU

Mux

10-2

PENTIUM® PR O PR OCESSOR TEST ACCESS PORT (TAP)

10.1. INTERFACE

The TAP logic is accessed serially through 5 dedicated pins on the Pentium Pro processor

package:

•TCK: The TAP clock signal

•TMS: “Test mode select,” which controls the TAP finite state machine

•TDI: “Test data in put,” which inputs test instructions and data serially

•TRST#: “Test reset,” for TAP logic reset

•TDO: “Test d ata output,” throu gh which test output is read serially

TMS, TDI and TDO operate synchro nously with TCK (which is independent of any other Pen-

tium Pro processor clock). TRST# is an asynchronous input signal.

10.2. ACCESSING THE TAP LOGIC

The Pentium Pro processor TAP is accessed through a 1149.1-compliant TAP controller finite

state machine. This finite state machine, shown in Figure 10-2, contains a reset state, a run-

test/idle state, and two major branches. These b ranches allow access either to the TAP Instruc-

tion Register or to one of the data registers. The TMS pin is used as the controlling input to

trav erse this finite state machine. TAP instructions and test data are loaded serially (in the Shift-

IR and Shift-DR states, respecti vely) using the TDI pin. State transitions are made on th e risin g

edge of TCK.

Figure 10-2. TAP Controller Finite State Machine

Select -

IR-Scan

Capture-IR Shift-IR

Exit1-IR Pause-IR Exit2-IR

Update-IR

Select-

DR-Scan

Capture-DR Shift-DR

Exit1-DR Pause-DR Exit2-DR

Update-DR

Test-Logic

Reset

Run-Test/

Idle TMS 1

TMS 0

10-3

PENTIUM® PRO PROCESSOR TEST ACCESS PORT (TAP)

The following is a brief description of each of the states of the TAP controller state machine.

Refer to the IEEE 1149.1 standard for detailed descriptions of the states and their operation.

•Test-Logic-Reset: In this state, the test logic is disabled so that normal operation of the

Pentium Pro processor can continue. In this state, the instruction in the Instruction Register

is forced to IDCODE. The controller is guaranteed to enter Test-Logic-Reset when the

TMS input is held active for at least five clocks. The controller also enters this state

immediately when TRST# is pulled active, and automatically upon power-up of the

Pentium Pro processor. The TAP controller cannot leav e this state as long as TRST# is held

active.

•Run-Test/Idle: This is the idle st ate of the TAP co ntroller. In this state, the con tents of all

test data registers retain their previous values.

•Select-IR-Scan: This is a temporary controller state. All registers retain their previous

values.

•Capture-IR: In this state, the shift register contained in the Instruction Register loads a

fixed value (of which the two least significant bits are “01”) on the rising edge of TCK.

The parallel, latched output of the Instruction Register (“current instruction”) does not

change.

•Shift-IR: The shift register contained in the Instruction Register is connected between T DI

and TDO and is shifted one stage toward its serial output on each rising edge of TCK. The

output arr ives at TDO o n the falling edge of TCK. The cu rrent i n st ru ct io n d oes not ch ange.

•Exit1-IR: This is a temporary state. The current instruction does not change.

•Pause-IR: Allows shifting of the instruction register to be temporarily halted . The current

instruction d oes not change .

•Exit2-IR: This is a temporary state. The current instruction does not change.

•Update-IR: The instruction which h as been shifted into th e Instructio n Register is latched

onto the parallel output of the Instruction Register on the falling edge of TCK. Once the

new instruction has been latched, it remains the current instruction u nti l the next Up date-

IR (or until the TAP controller state machine is reset).

•Select-DR-Scan: This is a temporary controller state. All registers retain their previous

values.

•Capture-DR: In this state, the data register selected by the current instruction may captur e

data at its parallel inpu ts.

•Shift-DR: The Data Register connected between TDI and TDO as a result of selection by

the current instruction is shifted one stage toward its serial output on each rising edge of

TCK. The output arrives at TDO on the falling edge of TCK. The parallel, latched output

of the selected Data Register does not change while new data is being shifte d in.

•Exit1-DR: This is a temporary state. All registers retain their previous values.

•Pause-DR: Allows shifting of the selected Data Register to b e temporarily ha lted without

stopping TCK. All registers retain their previou s values.

10-4

PENTIUM® PR O PR OCESSOR TEST ACCESS PORT (TAP)

•Exit2-DR: This is a temporary state. All registers retain their previous values.

•Update-DR: Data from the shift register path is l oaded into the latch ed parallel o utputs of

the selected Data Register (if applicable) o n the falling edge of TCK. This (and Test-Logic-

Reset) is the only state in which the latched paralleled outputs of a data register can

change.

10.2.1. Accessing the Instruction Register

Figure 10-3 shows the (simplified) physical implem ent ation of th e Pentium Pro pro cessor TAP

instruction register. This register consists of a 6-bit shift register (connected between TDI and

TDO), and the actual instruction register (which is loaded in parallel from the shift register). The

parallel output of the TAP instruction register goes to the TAP instruction decoder, shown in

Figure 10-1. This architecture conforms to the 1149.1 specification.

Figure 10-4 shows the oper ati o n o f the TAP inst ructi on register during th e Cap ture-IR, Shift -IR

and Update-IR states of th e TAP controller. Flip-flops with in th e instructio n register which are

updated in each mode of operation are shaded. In Capture-IR, the shift register portion of the

instruction register is loaded in parallel with the fix ed v alue “000001.” In Shift-IR, the shift re g-

ister portion of the instru ction register forms a serial data path between TDI and TDO. In Up-

date-IR, the shift register contents are latched in parallel into the actual instruction register . Note

that the only time the outputs of the actual instruction register change is during Update-IR.

Therefore, a n ew instruction shifted into the Pentium Pro pro cessor TAP does not take ef fect un-

til the Update-IR state o f the TAP controller is entered.

Figure 10-3. Pentium® Pro Processor TAP instruction Register

TDI Shift Reg ister

Actual Inst ructio n Re gister

(LSB)(MSB) Parall el out put

Fixed capture value

TDO

10-5

PENTIUM® PRO PROCESSOR TEST ACCESS PORT (TAP)

A timing diagram for loading the BYPASS instruction (op-code “111111”) into the TAP is

shown in Figure 10-5. (Note that the LSB of the TAP instruction must be shifted in first.) Verti-

cal arrows on the figure show the specific clock edges on which the Capture-IR, Shift-IR

and Update-IR actions actually take place. Capture-IR (which pre-loads the instruction shift reg-

ister with “000001”) and Shift-IR operate on rising edges of TCK, and Update-IR (which up-

dates the actual instruction register) takes place on the falling edge of TCK.

Figure 10-4. Operation of the Pentium® Pro Processor TAP Instruction Register

(a) Capture-IR (b) Shift-IR (c) Up date -IR

10-6

PENTIUM® PR O PR OCESSOR TEST ACCESS PORT (TAP)

10.2.2. Accessing the Data Registers

The test data re gisters in the Pentium Pro processor are designed in the same way as the instruc-

tion register , with components (i.e. either the “capture” or “update” functionality) remov ed from

the basic structure as needed. Data registers are accessed just as the instruction register is, only

using the “select-DR-scan” branch of the TAP finite state machine in Figure 10-2. A specific

data register is selected for access by each TAP instruction. Note that the only controller states

in which data re gister contents actually change are Capture-DR, Shift-DR, Update-DR and Run-

Test/Idle. For each of the TAP instructions described belo w, therefore, it is noted what operation

(if any) occurs in the selected data register in each of these four states.

10.3. INSTRUCTION SET

Table 10-1 contains descriptions of the encoding and operation of the TAP instructions. There

are se ve n 1149.1- defi ned inst ructions imp lemented in the Penti um Pro p rocessor TAP. These in-

structi ons select fr om among four dif ferent TAP da ta regi sters – the bo undary scan, B IST result,

device ID, and bypass registers.

Figure 10-5. TAP Instruction Register Access

Exit1-IR

Update-IR

Run-Test/Idle

Test-Logic-Reset

Run-Test/Idle

Select-DR-Scan

Select-IR-Scan

Capture-IR

Shift-IR

“IDCODE” “BYPASS

TCK

TMS

TAP

controller

state

TDO

Instruc-

tion

TDI

10-7

PENTIUM® PRO PROCESSOR TEST ACCESS PORT (TAP)

TAP instructions in the Pentium Pro processor are 6 bits long. For each listed instruction, the

table sho ws the instruction’s encod ing, what happens o n the Pentium Pro processor pins, which

TAP data register is selected by the instruction, and the actions which occur in the selected data

that not all of the TAP data registers have a latched parallel output (i.e. some are only simple

shift registers). For these data registers, nothing happens during the Update-DR controller state.

NOTE:

1. The Pentium® Pro processor must be reset after this command.

Full details of the operation of these instructions can be found in the 1149.1 standard.

The only Pentium Pro processor TAP instruction which does not operate exactly as defined in

the 1149.1 standard is RU NBIST. In the 1149.1 specification, Rule 7.9.1(b) states that: “Self-

test mode(s) of operation accessed through the RUNB IST instruction shall execute only in the

Run-Test/Idle controller state.” In the Pentium Pro processor implementation of RUNBIST, the

ex ecution of the Pentium Pro processor BIST routine will not, ho wever , stop if the Run-T est/Idle

state is exited before BIST is complete. In all other regards, the Pentium Pro processor

RUNBIST instruction operates exactly as defined in the 1149.1 specification.

Table 10-1. 1149.1 Instructions in the Pentium® Pro Processor TAP

TAP

Instruction Opcode

Pentium®

Pro

processor

pins

driven

from:

Data

Selected

Action duri ng:

RT/Idle Capture-DR Shift-DR Update-DR

EXTEST 000000 Boundary

scan Boundary

scan - sample all

Pentium® Pro

processor pins

shift data

data

SAMPLE/

PRELOAD 000001 - Boundary

scan - sample all

Pentium Pro

processor pins

shift data

data

IDCODE 000010 - Device ID - load unique

Pentium Pro

processor ID

code

shift data

CLAMP 000100 Boundary

scan Bypass - reset

bypass reg shift data

RUNBIST 000111 Boundary

scan Bist result BIST

starts1capture

BIST result shift data

HIGHZ 001000 floated Bypass - reset

bypass reg shift data

BYPASS 111111 - Bypass - reset

bypass reg shift data

Reserved all other rsvd r svd r svd rsvd rsvd rsvd

10-8

PENTIUM® PR O PR OCESSOR TEST ACCESS PORT (TAP)

Note that RUNBIST will not function when the Pentium Pro processor core clock has been

stopped. All other 114 9.1-defined instructio ns operate indepen dently of the Pentium Pro pr oces-

sor core clock.

The op-codes are 1149.1-compliant, and are consistent with the Intel-standard op-code encod-

ings and backward-compatible with the Pentium processor 1149.1 instruction op-codes.

10.4. DATA REGISTER SUMMAR Y

Table 10-2 gives the complete list of test data registers which can be accessed through the Pen-

tium Pro processor TAP. The MSB of the register is connected to TDI (for writing), and the LSB

of the register is connected to TDO (for reading) when that register is selected.

10.4. 1. Bypass Re gist er

Provides a short path between TDI and TDO. It is loaded with a logical 0 in the Capture-DR

state.

10.4.2. Device ID Register

Contains the Pentium Pro processor device identification code in the format shown in Table

10-3. The manufacturer’s identification code is unique to Intel. The part number code is divided

into four fields: VCC (3.3v supply), product type (an Intel Architecture com patib le processor),

generation (sixth generation), and model (first in the Pentium Pro processor family). The version

field is used for stepping information.

Table 10-2. TAP Data Registers

TAP Data Register Size Selected by Instructions

Bypass 1 BYPASS

HIGHZ

CLAMP

Device ID 32 IDCODE

BIST result 1 RUNBIST

Boundary scan 159 EXTEST

SAMPLE/PRELOAD

10-9

PENTIUM® PRO PROCESSOR TEST ACCESS PORT (TAP)

10.4.3. BIST Result Bound ary Scan Register

Holds the results of BIST. It is loaded with a logical 0 on successful BIST completion.

10.4.4. Boundary Scan Register

Contains a cell for each d ef ined Pentium Pro processor sign al pin. The following is the bit order

of the cells in the register (left to right, top to bottom). The “Reserved” cells should be left alone.

PWRGOOD should never be driven low during TAP operation.

TDI -> CLK, PWRGOOD, Reserved, THERMTRIP#, STPCLK#, A20M#, FLUSH#,

INIT#, IGNNE#, FERR#, FRCERR, BERR#, IERR#, A[35:3]#, AP[0:1]#, RSP#,

SMI#, BPRI#, BNR#, BREQ[1:3]#, REQ[4: 0]#, DEFER#, DRDY#, TRDY#,

DBSY#, HIT#, HITM#, RP#, BREQ[0]#, ADS#, LOCK#, RS[0:2]#, AERR#,

LINT[1:0], PICD[1:0], PICCLK, BP[3:2]#, BPM[1:0]#, PREQ#, PRDY#,

RESET#, BINIT#, DEP[0:7]#, D[63:0]#, Reserved-> TDO

10.5. RESET BEHA VIOR

The TAP an d its related hardware are reset by transitioni ng the TAP controller finite state ma-

chine into the Test-Logic-Reset state. Once in this state, all of the reset actions listed in Table

10-4 are performed. The TAP is completely disab led upon reset (i.e. by resetting the TAP, the

Penti um Pro processor will functio n as though the TAP did not exist). Note that the TAP does

not receive RESET#.

Table 10-3. Device ID Register

Version

Part Number

Manufacturing

ID “1” Entire Code

VCC Product

Type Generation Model

Size 41 6 4 5 11 1 32

Binary xxxx 1 000001 0110 00001 00000001001 1 xxxx100000101100

0001000000010011

Hex x 1 01 6 01 09 1 x82c1013

10-10

PENTIUM® PR O PR OCESSOR TEST ACCESS PORT (TAP)

The TAP can be transitioned to the Test-Logic-Res et state in any one of three ways:

•Pow er on the Pentium Pro processo r. This automatically (asy nchronously) resets the TAP

controller.

•Assert the TRST# pin at any time. This asynchronously resets the TAP controller.

•Hold the TMS pin high for 5 consecutive cycles of TCK. This is guaranteed to transition

the TAP controller to the Test-Logic-Reset state on a rising edge of TCK.

Ta ble 10-4. TAP Reset Actions

TAP logic affected TAP reset state action Related TAP instructions

Instruction Register Loaded with

IDCODE

op-code

Pentium® Pro processor boundary

scan logic disabled CLAMP, HIGHZ, EXTEST

Pentium Pro processor TDO pin tr i-stated -

Electrical

Specifications

11-1

CHAPTER 11

ELECTRICAL SPECIFICATIONS

11.1. THE PENTIUM® PRO PROCESSOR BUS AND VREF

Most of the Pentium Pro processor signals use a variation of the low voltage GTL signaling

technology (Gunning Transceiver Logic).

The Pentium Pro processor bus specification is similar to the GTL specification but has been

enhanced to pro vide larger noise mar gins and reduced ringing. This is accomplished by increas-

ing the termination v oltage lev el and controlling the edge rates. Because this specification is dif-

ferent from the standard GTL specification, we will refer to the new specification as GTL+ in

this document.

The GTL+ signals are open-drain and require external termination to a supply that provides the

high signal level. The GTL+ inputs use differential receivers which require a reference signal

(VREF). Termination (Usually a resistor on each end of the signal trace) is used to pull the bus

up to the high voltage level and to control reflectio ns on the s tub-free transm ission line. VREF

is used by the receivers to determ ine if a signal is a logical 0 or a logical 1. See Table 11-8

for the bus termination specifications for GTL+, and Chapter 12, GTL+ Interface Specifi-

cation for the GTL+ Interface Specification.

There are 8 VREF pins on the Pentium Pro processor to ensure that internal noise will not af fect

the performance of the I/O buffers. Pins A1, C7, S7 and Y7 (VREF[3:0]) must be tied together

and pins A47, U41, AE47 and AG45 (VREF[7:4]) must be tied together. The two groups may

also be tied to each other if desired.

The GTL+ bus depends on incident wave switching. Therefore timing calculations for GTL+

signals are based on flight time as opposed to capacitive deratings. Analog signal simulation of

the Pentium Pro processor bus including trace lengths is highly recommended when designing

a system with a heavily loaded GTL+ bus. See Intel’s technical documents on the world w ide

web page (http:\\www.intel.com) to down-load the buffer models for the Pentium Pro processor

in IBIS format.

Figure 11-1. GTL+ Bus Topology

CPU CPU ASIC ASIC CPU CPU

1.5V 1.5V

No stubs

11-2

ELECTRICAL SPECIFICATIONS

11.2. POWER MANAGEMENT: STOP GRANT AND AUTO HALT

The Pentium Pro pr ocessor allo ws the use of Stop Grant and Auto HALT modes to imm ediately

reduce the power consumed by the device. When enabled, these cause the clock to be st opped

to most of the CPU’s internal units and thus significantly reduces power consumption by the

CPU as a whole.

Stop Grant is en tered by asserting the ST PCLK# pin of the Pentiu m Pro processor. When STP-

CLK# is recognized by the Pentium Pro processor, it will stop execution and will not service

interrupts. It will contin ue s noo ping the bus. Stop Grant p ower is specified assuming no s noop

hits occur.

Auto HALT is a low po wer state entered when the Pentium Pro processor ex ecutes a halt (HLT)

instruction. In this state the Pentiu m Pro processor behaves as if it executed a ha lt instruction,

and it additionally powers-down most internal units. In Auto HALT, the Pentium Pro processor

will recogni ze all interrup ts and sn oops. Auto HALT power is specified assum ing no sn oop hits

or interrupts occur.

The low power standby mode of Stop Grant or Auto H ALT can be defined by a configuration

bit to be either the lowest power achievable by the Pentium Pro processor (Stop Grant power),

or a power state in which the clock distribu tion is left running (Idle power). “Low power stand-

by” disabled lea v es the core logic running, while “Lo w po wer standby” enabled allows the Pen-

tium Pro processor to enter its lowest power mode. See the EBL_CR_POWERON Model

Specific Register in Appendix C of the Pentium® Pro Family Developer’s Manual, Volume 3:

Operating System Wr iter’s Guide (Order Number 242692-001).

11.3. POWER AND GROUND PINS

As future versions of the Pentium Pro processor are released, the operating voltage of the C PU

die and of the L2 Cache die may differ fr om each other. There are two po wer inpu ts on the Pen-

tium Pro processor package to support the difference between the two die in the package, and

one 5V pin to support a fan for the OverDrive® processor. There are also 4 pins defined on the

package for voltage identification These pins specify the voltage required by the CPU die. This

has been added to cleanly sup port v oltage speci f ication v ariat ions o n the Pentium Pro pr ocesso r

and future processors. See Section 11.6., “Voltage Identif ication” for an e xplan ation of the v olt-

age identification (VID) pins.

Future mains tream devices will fall into two groups. Either the CPU die and th e L2 Cache die

will both run at the same voltage (VccP), or the L2 Cache die will use VccS (3.3V) while the

CPU die runs at anot her vol tage on VccP. When the L2 Cache die is running on the same supply

as the CPU die, the VccS pins will consume no current. To properly support this, the system

should distribute 3.3V and a selectable voltage to the Pentium Pro processor socket. Selection

may be provided for by socketed regulation or by using the voltage identification pins. Note that

it is po ssible that VccP and VccS are both nominally 3.3V. It should not be assumed that these

will be able to use the same power supply.

For clean on-chip power distrib ution, th e Pentium Pr o processor has 76 Vcc (po wer) and 101Vss

(ground) inputs. The 76 Vcc pins are further divided to provide the different voltage levels to

the device. VccP inputs for the CPU die and some L2 die account for 47 of the V cc pins, while

11-3

ELECTRICAL SPECIFICATIONS

28 VccS inputs (3.3V) are for use by the on-package L2 Cache die of some processors. One

Vcc5 pin i s pr o v i ded for use by t he fan of the OverDri ve processor. V cc5, VccS and VccP must

remain electrically separated from each other. On the circuit board, all VccP pins must be con-

nected to a voltage island and all VccS pins must be connected to a separate voltage island (an

island is a portion of a power plane that has been divided, or an entire plane). Similarly, all Vss

pins must be connected to a system ground plane. S ee Figure 15- 3 for the lo cations of the po wer

and ground pins.

11.4. DECOUPLING RECOMMENDATIONS

Due to the lar ge number of tran sistors and high intern al clock speeds, the Pentium Pro processor

can create large, short duration transient (switching) current surges that occur on internal clock

edges which can cause power planes to spike above and bel ow their nominal value if not prop-

erly controlled. The Pentium Pro processor is also capable of generating large average current

swings between low and full power states, called Load-Change Transients, which can cause

power planes to sag below their nominal value if bulk decoupling is not adequate. See Figure

11-2 for an example of these current fluctuations. Care must be taken in the board design to guar-

antee that the voltage provided to th e Pentium P ro processo r remains with in the s pecifications

listed in this volume. Failure to do so can result in timing violations or a reduced lifetime of the

component.

Figure 11-2. Transient Types

Time (nS

)

Vss Current

Vcc Current

Averaged Vcc Current

Load-C hange

Transient

Switching

Transient Switching

Transient

11-4

ELECTRICAL SPECIFICATIONS

Adequate decoupling capacitance should be placed near the power pins of the Pentium Pro pro-

cessor. Low inductance capacitors such as the 1206 package surface mount capacitors are rec-

ommended for the best high frequency electrical performance. Forty (40) 1µF 1206-style

capacitors with a ±22% to lerance make a good starting point for simulation s as this is our rec-

ommended decoupling when using a standard Pentium Pro processor Voltage Regulator Mod-

ule. Inductance sho uld be reduced b y con necting capacitors directly to the VccP and Vss planes

with minimal trace length b etween the comp onent pads and vias to th e plane. Be sure to include

the ef fects of board inductance within the simulation. Also, when ch oosing the capacitors to use,

bear in mind the operating temperatures they will see and the tolerance that they are rated at.

Type Y5S or better are recommended (±22% tolerance over the temperature range -30°C to

+85°C).

Bulk capacitance with a low Effective Series Resistance (ESR) should also be placed near the

Pentium Pro processor in o rder to handle changes in a v erage current between the lo w po wer an d

normal op erating state s. About 40 00µF of capacitance with an ESR of 5m Ω makes a good start-

ing poin t for simu lations , althou gh more capacitance m ay be needed to bring t he ESR down to

this level due to the current technology in the industry . The standard Pentium Pro processor Volt-

age Regulator Modules already contain this b ulk capacitance. Be sure to determine what is av ail-

able on the market before choosing parameters for the models. Also, include power supply

response time and cable inductance in a full simulation.

See AP-523 Pentium® Pro Processor Power Distribution Guidelines Application Note (Order

Number 242764) for power modeling for the Pentium Pro processor.

11.4.1. VccS Decoupling

Decoupling of ten (10) 1µF ceramic capacitor s (type Y5S or better) an d a minimum of f i ve 22 µF

tantalum capacitors is recommended for th e VccS pins. This is to handle the transients that may

occur in future devices. These are not required for the processors described herein.

11.4.2. GTL+ Decoupling

Although the Pentium Pro proc essor GTL+ b us receive s po wer e xternal to the Pentium Pro pro -

cessor, it sh ould b e noted that th is power supply will also require th e same d iligen t decou pling

methodologies as the pr ocessor . No tice that the e xistence of external po wer entering through the

I/O buffers causes Vss current to be higher than the Vcc current as evidenced in Figure 11-2.

11.4.3. Phase Lock Loop (PLL) Decoupling

Isolated analog decoupling is required for the internal PLL. This should be equivalent to 0.1µF

of ceramic capacitance. The capacitor should be type Y5R or better and should be across the

PLL1 and PLL2 pins of the Pentium Pro processor. (“Y5R” implies ±15% tolerance over the

temperature range -30°C to +85°C.)

11-5

ELECTRICAL SPECIFICATIONS

11.5. BCLK CLOCK INPUT GUIDELINES

The BCLK input directly controls the op erating speed of the GTL+ b us interf ace. All GTL+ e x-

ternal timing parameters are specified with respect to the rising edge of the BCLK input. Clock

multiplyin g within the processor is provided by an in ternal Phase Lock Loop (PLL) which re-

quires a consta nt frequency B CLK input. Therefore the BCLK frequenc y cannot be changed dy-

namically. It can however be changed when RESET# is active assuming that all reset

specifi cations are met for the clock and the configuration signals.

The Pentium Pro processor core frequency m ust be configured during reset by using the A20M#,

IGNNE#, LINT1/NMI, and LINT0/INTR pins. The value on these pins during RESET#, and un-

til two clocks beyond the end of the RESET# pulse, determines the multiplier that the PLL will

use for the internal core clock. See the Appendix A for the defin itio n of these pins during reset.

At all other times their functionality is defined as the compatibility signals that the pins are

named after. These s ignals are 3.3V tolerant so that they may be dri ven by e xistin g logic de vices.

This is important for both functions of the p ins.

Supplying a b us clock multiplier this way is required in or der to increase processor performance

without changing the processor design, and to maintain the bus frequency such that system

boards can be designed to function properly as CPU frequencies increase.

11.5.1. Setting the Core Clock to Bus Clock Ratio

Table 9-4 lists the configuration pins and the values that must be driven at reset time in order to

set the core clock to bus clock ratio. Figure 11-3 shows the timing relationsh ip required for the

clock ratio signals with respect to RESET# and BCLK. CRESET# from an 82453GX is shown

since its timing is useful for controlling the multiplexing function that is required for sharing the

pins.

Figure 11-3. Timing Diagram of Clock Ratio Signals

CRESET#

Final

Ratio

Compatibility

BCLK

RESET#

Ratio pins# ≤ Final

Ratio

11-6

ELECTRICAL SPECIFICATIONS

Using CRESET# (CMOS reset), the circuit in Figure 11-4 can be used to share the pins. The pins

of the processors are bussed together to allo w any one of them to be the compatibility processor .

The compon ent used as the m ultiplex er must not b e po wered b y more than 3.3V in o rder to meet

the Pentium Pro processor’s 3.3V to lerant buffer specifications. The mu ltiplexer output current

should be limited to 200mA max, in case the VccP supply ever fails to the processor.

The pull-do wn resistors between the multiplex er and the processor (1KΩ) force a ratio of 2x into

the processor in the event that the Pentium Pro processor powers up before the multiplexer

and/or the chipset. This prevents the processor from ever seeing a ratio higher than the final

ratio.

If the multiplexer were po wered by V ccP, CRESET# wo uld still b e unkno wn until t he 3.3V sup-

ply came up to power the CRESET# driver. A pull-down can be used on CRESET# instead of

the four between the multiplexer and the Pentium Pro processor in this case. In this case, the

multiplexer must be desig ned such that the compatib ility inputs are tru ly ignored as their state

is unknown.

In any case, the compatibility inputs to the multiplexer must meet the input specifications of the

multiplexer. This may require a level translation before the multiplexer inputs unless the i nputs

and the signals driving them are already compatible.

For FRC mode processors, one multiplexer will be needed per FRC pair , and the multiplexer will

need to be clocked using BCLK to meet setup and hold times to the processors. This may require

the use of high sp eed programmable logic.

Figure 11-4. Example Schematic for Clock Ratio Pin Sharing

A20M#

IGNNE#

LINT1/NMI

LINT0/INTR

Set Ratio:

CRESET#

Pentium®

Pro

Processor

1KΩ

3.3V

Mux

1KΩ

3.3V

11-7

ELECTRICAL SPECIFICATIONS

11.5.2. Mixing Processors of Different Frequencies

Mixing components of dif ferent internal clock frequencies is not supported and has not been v al-

idated by Intel. One should also note when attempting to mix processors rated at different fre-

quencies in a multi-processor system that a common bus clock frequency and a set of multipliers

must be found that is acceptable to all processors in the system. Of course, a processor may be

run at a core fre quency as low as its minimum ra ting. Operating system suppor t for multi-

processin g with mixed frequency co mponents sh ould al so be consid ered.

Note that in order to support dif ferent freq uency multipliers to each processor, the design shown

above would require four multiplexers.

11.6. VOLTAGE IDENTIFICATION

There are 4 Voltage Identification P ins on the Pentium Pro processor package. These pins can

be used to support automatic selection of power supply voltages. These pins are not signals but

are each either an open circuit in th e pack age or a shor t cir cuit to Vss. The opens and shorts de-

fines the v oltage requ ired by the pro cessor . This has been added to cleanly support v oltage spec-

if ication variations on future Pentium Pro processors. These pins are named VID0 th rough VID3

and the definition of th ese pins is shown in Table 11-1. A ‘1’ in this tab le refers to an open p in

and ‘0’ refers to a shor t t o gr ound. The VccP power supply should supply the voltage that is

requested or disable itsel f.

NOTES:

1. Nominal setting requiring regulation to ±5% at the Pentium® Pro processor pins under all conditions . Sup-

port not expected for 2 .1V-2.3V.

2. 1= Open circuit; 0= Short to Vss

Table 11-1. Voltage Identification Definition1, 2

VID[3:0] Voltage setting VID[3:0] Voltage Setting

0000 3.5 1000 2.7

0001 3.4 1001 2.6

0010 3.3 1010 2.5

0011 3.2 1011 2.4

0100 3.1 1100 2.3

0101 3.0 1101 2.2

0110 2.9 1110 2.1

0111 2.8 1111 No CPU Present

11-8

ELECTRICAL SPECIFICATIONS

Support fo r a wi der rang e of VID s et ti ngs will b enefit the sys tem i n meeti n g the p ower require-

ments of fu ture Pentium Pro processors. N ote that the ‘1111’ (or all opens) ID can b e used to

detect the absence of a processor in a given socket as long as the power supply used does not

affect these lines .

To us e these pins, the y may need t o be pulled u p by an e xternal res istor to anot her po wer sour ce.

The power source chosen should be one that is guaranteed to be stable whenever the supply to

the voltage regulator is stable. This will prevent the possibility of the Pentium Pro processor sup-

ply running up to 3.5V in the event of a failure in the supply for the VID lines. Note that the

specifi cation for the standard Pentium Pro processor Voltage Regulato r Modules allows the use

of these signals either as TTL com patible lev els or as opens and shorts. Using them a s TTL com-

patible levels will require the us e of pu ll-up resis tors to 5V if the inpu t voltage to th e regulator

is 5V and the use o f a voltage divid er if the input voltag e to the regulator is 12 V. The resistors

chosen should not cause the current through a VID pin to exceed its specification in Table 11-3.

There must not be any other components on these signals if the VRM uses them as opens and

shorts.

11.7. JTAG CONNECTION

The Debug Port described in Section 16.2., “In-Target Probe for the Pentium® Pro Processor

(ITP)” should be at the start and end of the JTAG chain with TDI to the f irst component coming

from the Debug Port and TD O from the last component going to the Debug Port. The recom-

mended pull-up value for Pentium Pro processor TDO pins is 240Ω.

Due to the voltage le vels supported by the Pentium Pro processor JTAG logic, it is recommend-

ed that the Pentium Pro processors and any other 3.3V components be first in the JTAG chain.

A translation buffer should be used to connect to the rest of the chain unless a 5V component

can be used next that is capable of accepting a 3.3V input. Similar consideration s must be made

for TCK, TMS and TRST#. Com ponents may n eed these signals buf fered to match requir ed log-

ic levels.

In a multi-processor system, be cautious when in cluding empty Pentiu m Pro processor sockets

in the scan chain. All sockets in the scan chain must have a processor installed to complete the

chain or the system must support a method to bypass the empty sockets.

See Section 16.2., “In-Target Probe for the Pentium® Pro Processor (ITP)” for full information

on placing a Debug Port in the JTAG chain.

11-9

ELECTRICAL SPECIFICATIONS

11.8. SIGNAL GROUPS

In order to simplif y the foll owing dis cussi on, si gnal s ha v e been combi ned in to grou ps b y b uffer

type. All outputs are open drain and require an ex ternal hi-le v el source pro vided e xternally by

the termination or a pull-up resistor.

GTL+ input signals have differential input buffers which use VREF as their reference signal.

GTL+ output signals require termination to 1.5V. Later in this document, the term “GTL+ Input”

refers to the GTL+ input group as well as the GTL+ I/O group when receiving. Similarly,

“GTL+ Output” refers to the GTL+ output group as well as the GTL+ I/O group when driving.

The 3.3V tolerant, Clock, APIC and JTAG input s can each be driven from ground to 3.3V. The

3.3V tolerant, APIC, and JTAG outputs can each be pulled high to as much as 3.3V. See Table

11-7 for specifications.

The groups and the signals contained within each group are shown in Table 11-2. Note that the

signals ASZ[1:0]#, ATTR[7:0]#, BE[7:0]#, BREQ#[3:0], DEN#, DID[7:0]#, DSZ[1:0]#,

EXF[4:0]#, LEN[1:0]#, SMMEM# , and SPLCK# are all GTL+ signals that are shared onto an-

other pin. Therefore they do not appear in this table.

11.8.1. Asynchr onous vs. Synchronous

All GTL+ signals are synchronous. All of the 3.3V tolerant signal s can be applied asyn-

chronously, except when running two processors in FRC mode. To run in FRC mode,

synchronization logic is required on all signals, except PWRGOOD, going to both processors.

Also note the timing requirements for PICCLK with respect to BCLK. W ith FRC enabled, PIC-

CLK must be ¼X BCLK and synchronized with respect to BCLK with PICCLK lagging BCLK

by at least 1 ns and no more than 5 ns.

11-10

ELECTRICAL SPECIFICATIONS

NOTES:

1. The BR0# pin is the only BREQ signal that is bi-directional. The internal BREQ# signals are mapped onto

BR# pins after the agent ID is determined.

2. See PWRGOOD in Section 11.9., “PWRGOOD”.

3. See THERMTRIP# in Section 11.10., “THERMTRIP#”.

4. These signals are tolerant to 3.3V. Use a 150Ω pull-up resistor on PIC[1:0] and 240Ω on TDO.

5. CPUPRES# is a ground pin defined to allow a designer to detect the presence of a processor in a socket.

PLL1 & PLL2 are for decoupling the PLL (See Section 11.4.3., “Phase Lock Loop (PLL) Decoupling”).

TESTHI pins should be tied to VccP. A 10K pull-up may be used. See Section 11.11., “Unused Pins”.

TESTLO pins should be tied to Vss. A 1K pull-down ma y be used.See Section 11.11., “Unused Pins”.

UP# is an open in the Pentium® Pro processor and Vss in the OverDrive® processor See Chapter 17,

OverDr ive® Processor Socket Specification

VccP is the primary power supply.

VccS is the secondary power supply used by some versions of the second level cache.

Vcc5 is unused by the Pentium Pro processor and is used by the OverDriv e processor for fan-sink power.

VID[3:0] lines are described in Section 11.6., “Voltage Identification”.

VREF[7:0] are the refe rence voltage pins for the GTL+ buffers.

Vss is ground.

Table 11-2. Signal Groups

Group Name Signals

GTL+ Input BPRI#, BR[3:1]# 1, DEFER#, RESET#, RS[2:0]#, RSP#, TRDY#

GTL+ Output PRDY#

GTL+ I/O A[35:3]#, ADS#, AERR#, AP[1:0]#, BERR#, BINIT#, BNR#, BP[3:2]#,

BPM[1:0]#, BR0# 1, D[63:0]#, DBSY#, DEP[7:0]#, DRDY#, FRCERR, HIT#,

HITM#, LOCK#, REQ[4:0]#, RP#

3.3V Tolerant Input A20M#, FLUSH#, IGNNE#, INIT#, LINT0/INTR, LINT1/NMI, PREQ#,

PWRGOOD 2, SMI#, STPCLK#

3.3V Tolerant Output FERR#, IERR#, THERMTRIP#3

Cloc k 4BCLK

APIC Clock 4PICCLK

APIC I/ O 4PICD[1:0]

JTAG Input 4TCK, TDI, TMS, TRST#

JTAG Output 4TDO

Power/Other 5CPUPRES#, PLL1, PLL2, TESTHI, TESTLO , UP#, VccP, V ccS, Vcc5, VID[3:0],

VREF[7:0], Vss

11-11

ELECTRICAL SPECIFICATIONS

11.9. PWRGOOD

PWRGOOD is a 3.3V tolerant input. It is expected that this signal will be a clean indication that

clocks and the 3.3V, 5V and VccP supplies are stable and within their specifi cations. Clean im-

plies that the signal will remain low, (capable of sinking leakage current) without glitches, from

the time that the power supplies are turned on until they come within specification. The signal

will then transition monotonically to a high (3.3V) state. Figure 11-5 illustrates the relationship

of PWRGOOD to other system signals. PWRGOOD can be driven inactive at any time, but

po wer and clock s must again be stable before the rising edge of PWRGOOD. It must also meet

the minimum pulse width specif ication in Table 11-13 and be follo wed by a 1mS RESET# pulse.

This signal must be supplied to the Pentium Pro processor as it is used to protect internal circuits

against voltage sequencing issu es. Use of this sign al is recommended for added reliability.

This signal does not need to be synchronized for FRC operation. It should be high throughout

boundary scan testing.

11.10. THERMTRIP#

The Pentium Pro processor protects itself from catastrophic overheating by use of an internal

thermal sensor. This sensor is set well above the normal operating temperature to ensure that

there are no false trips. The processor will stop all execution when the junction temperature ex-

ceeds ~135° C. This is signaled to the system by the THERMTRIP# pin. Once activ ated, the sig-

nal remains latched, and the processor stopped, until RESET# goes acti ve. There is no hyster esis

built into the thermal sen sor its elf, so as lon g as the die tem perature drops below the trip level,

a RESET# pulse will reset the processor and execution will continue. If the temperature has not

dropp ed beyond the trip level, the processor will co ntinue to drive THERMTRIP# and remain

stopped.

Figure 11-5. PWR GOOD Relationship at Power-On

11-12

ELECTRICAL SPECIFICATIONS

11.11. UNUSED PINS

All RESERVED pins must remain unconnected. All pins named TESTHI must be pulled up, no

higher than VccP, and may be tied directly to VccP. All pins named TESTLO pulled low and

may be tied directly to Vss.

PICCLK must alw ays be dri ven with a clock input, and the PIC D[1:0] lines must each be pu lled-

up to 3.3V with a separate 150Ω resistor, even when the APIC will not be used.

For reliable operation, always connect unused inputs to an appropriate signal level. Unused

GTL+ inputs shoul d be pulled- up to V tt. Unused acti v e low 3.3V tolerant inpu ts shoul d be con-

nected to 3.3V with a 150Ω resistor and unused active high inputs should be connected to

ground (Vss). A resisto r must also be used when tyi ng bi-directional si gnals to po wer or ground.

When tieing any signal to power or ground, a resistor will also allow for fully tes ting the pro-

cessor after board assembly.

For unused pins , it is sugges ted that ~1 0KΩ resistor s be used for pull-u ps (ex cept for PICD[1:0]

discussed abo v e), and ~1KΩ res isto rs be us ed as p ull-downs. Nev er tie a pin dir ectly to a sup-

ply other than the processor’s own VCCP supply or to VSS.

11.12. MAXIMUM RATINGS

Tab le 11-3 con tain s Pentium Pr o proces sor st ress rat ings on ly. Fun ctio nal operat ion at t he abso -

lute maximum and minimum is not implied nor guaranteed. The Pentium Pro processor should

not recei v e a clock while subjected to these conditions. Functional operating conditions are gi v-

en in the A.C. and D.C. tables. Extended exposure to the maximum ratings may affect device

reliability. Furtherm ore, although the Pentium Pro processor contains protective ci rcuitry to re-

sist damage from static electric discharg e, one should always tak e precautions to av oid high stat-

ic voltages or electric fields.

11-13

ELECTRICAL SPECIFICATIONS

NOTES:

1. Functional operation at the absolute maximum and minimum is not implied nor guaranteed.

2. Operating voltage is the voltage that the component is designed to operate at. See Table 11-4.

3. Parameter applies to the GTL+ signal groups only.

4. P arameter applies to 3.3V tolerant, APIC, and JTAG signal groups only.

5. Current may flow through the buffer ESD diodes when VIH > VccP+1.1V, as in a po wer supply fault condi-

tion or while power supplies are sequencing. Thermal stress should be minimized by cycling power off if

the VccP supply fails.

Table 11-3. Absolute Maximum Ratings 1

Symbol Parameter Min Max Unit Notes

TStorage Storage Temperature -65 150 °C

TBias Case Temperature under Bias -65 110 °C

VccP(Abs) Primar y Supply Voltage with

respect to Vss -0.5 Operating

Voltage + 1.4 V2

VccS(Abs) 3.3V Supply Voltage with respect

to Vss -0.5 4.6 V

VccP-VccS Primary Supply Voltage with

respect to 3.3V Supply Voltage -3.7 Operating

Voltage + 0.4 V2

Vin GTL+ Buffer DC Input Voltage with

respect to Vss -0.5 VccP+ 0.5 but

Not to e x ceed 4.3 V3

Vin3 3.3V Tolerant Buffer DC Input

Voltage with respect to Vss -0.5 VccP+ 0.9 but

Not to e x ceed 4.7 V4

IIMax input current 200 mA 5

IVID Max VID pin current 5 mA

11-14

ELECTRICAL SPECIFICATIONS

11.13. D.C. SPECIFICATIONS

Table 11-4 through Table 11- 7 list the D.C. spe cifications associated with the Pe ntium Pro

processor. Specifications are valid only while meeting the processor specifications for case

temperature, clock frequ enc y and inp ut v oltages. Car e s houl d be tak en to r ead all n otes asso -

ciated with each parameter. See Section 11 .3., “Po wer and Gro und Pins” for an e xplanation o f

voltage plans for Pentium Pro processors. See Section 17.4.1.1., “OverDrive® Processor D.C.

Specifications” for OverDrive processor information and Section 11.16., “Flexible Mother-

Board Recommendations” for flexible motherboard recommendations.

The D.C. specif ication s for th e VccP, VccS and Vcc5 su pplie s ar e listed in Table 11-4 and Table

11-5.

NOTES:

1. This is a 5% tolerance. To comply with these guidelines and the indus tr y standard voltage regulator mod-

ule specifications, the equivalent of forty (40) 1µF±22% capacitors in 1206 packages should be placed

near the power pins of the processor. More specifically, at least 40µF of c apacitance should exist on the

power plane with less than 250pH of inductance and 4mΩ of resistance between it and the pins of the pro-

cessor, assuming a regulator set point of ±1%.

2. This voltage is currently not required by the Pentium® Pro processor. The voltage is defined for future use .

3. This voltage is required for OverDrive® processor support.

Table 11-4. Voltage Specification

Symbol Parameter Min Typ Max Unit Notes

VccP Primary Vcc 2.945

3.135 3.1

3.3 3.255

3.465 V

V@150MHz, 256K L2

All other components1

VccS Secondary

Vcc 3.135 3.3 3.465 V 3.3 ± 5% 2

Vcc5 5V Supply 4.75 5.0 5.25 V 5.0 ± 5% 3

11-15

ELECTRICAL SPECIFICATIONS

NOTES:

1. All power measurements taken with CMOS inputs driven to VCCP and to 0V.

2. Maximum values are measured at typical Vcc to take into account the thermal time constant of the pack-

age. Typical values not tested, but imply the maximum power one should see when run ning normal high

power applications on most devices. When designing a system to the typical power level, there should be

a fail-safe mechanism to guarantee control of the CPU TC specification in case of statistical anomalies in

the workload. This workload could cause a temporary rise in the maximum power.

3. Power specifications for 512K L2 components are PRELIMINARY. Consult your local FAE.

4. Max values measured at typical VCCP by asser ting the STPCLK # pin or executing the HALT instruction

(Auto Halt) with the EBL_CR_POWERON

Low_Power_Enable

bit set to

enabled

. See Model Specific

Registers in Appendix C of the

Pentium® Pro Family Developer’s Manual, Volume 3: Operating System

Wr iter’s Guide

(Order Number 242692 -001). Minimum values are gu aranteed by design/chara cterization

at minimum VCCP in the same state.

5. Max VCCP current measured at max VCC. All CMOS pins are driven with V IH = VCCP and VIL = 0V during the

execution of all Max ICC and ICC-Stop Grant/Auto HALT tests.

6. The L2 of the current processor will draw no current from the VccS inputs. IccS is 0A when the L2 die

receives its power from the VccP pins. See the recommended decoupling in Section 11.4.1., “VccS

Decoupling”.

Table 11-5. Power Specifications 1

Symbol Parameter Min Typ Max Unit Notes

PMax Thermal Design Power 23.0

27.5

24.8

27.3

32.6

29.2

35.0

31.7

35.0

37.9

@ 150MHz, 256K L2

@ 166MHz, 512K L2

@ 180MHz, 256K L2

@ 200MHz, 256K L2

@ 200MHz, 512K L2

2, 3

ISGntP VccP Stop Grant Current 0.3

0.3 1.0

1.2 A

A@ 150MHz, 256K L2

All other components

4, 3

ISGntS VccS Stop Grant Current 0 0 0 A All components

IccPV

ccP Current 9.9

11.2

10.1

11.2

12.4

@ 150MHz, 256K L2

@ 166MHz, 512K L2

@ 180MHz, 256K L2

@ 200MHz, 256K L2

@ 200MHz, 512K L2

5, 3

IccSV

ccS Current 0 A 6

Icc5 5V Supply Current 0 A All components

TCOperating Case Temperature 0 85 °C

11-16

ELECTRICAL SPECIFICATIONS

Most of the signals on the Pentium Pro processor are in the GTL+ signal group. These signals

are specifi ed to be terminated to 1.5V. The D.C. specif ications for these signals are listed in Ta-

ble 11-6. Care should be taken to read all notes associated with each parameter.

To allow compatibility with other devices, some of the signals are 3.3V tolerant and can there-

fore be terminated or driven to 3.3V. The D.C. specifications for these 3.3V tolerant inputs are

listed in Table 11-7. Care should be taken to read all notes associated with each parameter.

NOTES:

1. VREF worst case, not nominal. Noise on VREF should be accounted for.

2. Parameter measured into a 25Ω resistor to 1.5V. Min. VOL and max. IOL are guaranteed by design/charac-

terization.

3. (0 ≤ Vpin ≤ VccP).

4. Total current for all VREF pins. Section 11.1., “The Pentium® Pro Processor Bus and VREF” details the

VREF connections.

5. Total of I/O buffer, package parasitics and 0.5pF for a socket. Capacitance values guaranteed by design

for all GTL+ buff ers.

Table 11-6. GTL+ Signal Groups D.C. Specifications

Symbol Parameter Min Max Unit Notes

VIL Input Low Voltage -0.3 VREF - 0.2 V 1 See Table 11-8

VIH Input High Voltage VREF + 0.2 VccPV

OL Output Low Voltage 0.30 0.60 V 2

VOH Output High Voltage — — V See VTT max in

Table 11-8

IOL Output Low Current 36 48 mA 2

ILLeakage Current ± 100 µA3

IREF Reference Voltag e Current ± 15 µA4

CGTL+ GTL+ Pin Capacitance 8.5 pF 5

Table 11-7. Non-GTL+ 1 Signal Groups D.C. Specifications

Symbol Parameter Min Max Unit Notes

VIL Input Low Voltage -0.3 0.8 V

11-17

ELECTRICAL SPECIFICATIONS

11.14. GTL+ BUS SPECIFICATIONS

The GTL+ bus must be routed in a daisy-chain fa shion with t ermination resistors at each

end of every signal trace. These term ination resistors are placed b etween the ends of the signal

trace and the VTT v oltage supply and generally are chosen to approximate the board impedance.

The valid high and low levels are determined by the input buffers using a reference voltage

called VREF. Table 11-8 lists the nominal specifications for the GTL+ termination voltage

(VTT) and the GTL+ reference voltage (VREF). It is important that the printed circuit board

impedance be specified and held to a ±20% tolerance, and that the intrinsic trace capacitance

for the GTL+ signal group traces is known. For more details on GTL+, See Chapter 12,

GTL+ I nterfa ce Spec ific ation .

NOTE:

1. VREF should be created from VTT by a voltage divider of 1% resistors.

NOTES:

1. Table 11-7 applies to the 3.3V tolerant, APIC, and JTAG signal groups.

2. P arameter measured at 4 mA (for use with TTL inputs).

3. P arameter guaranteed by design at 100uA (for use with CMOS inputs).

4. (0 ≤ Vpin ≤ VccP).

5. Total of I/O buffer, package parasitics and 0.5pF for a socket. Capacitance values are guaranteed by

design.

VIH Input High Voltage 2.0 3.6 V

VOL Output Low Voltage 0.4

0.2 V

VOH Output High Voltage N/A N/A V All Outputs are Open-Drain

IOL Output Low Current 24 mA

ILInput Leakage Current ± 100 µA4

CTOL 3.3V Tol. Pin Capacitance 10 pF Except BCLK, TCK 5

CCLK BCLK Input Capacitance 9 pF 5

CTCK TCK Input Capacitance 8 pF 5

Table 11-8. GTL+ Bus D.C. Specifications

Symbol Parameter Min Typical Max Units Notes

VTT Bus Termination

Voltage 1.35 1.5 1.65 V ± 10%

VREF Input Reference

Voltage 2/3 VTT - 2% 2/3 VTT 2/3 VTT + 2% V ± 2% 1

Table 11-7. Non-GTL+ 1 Signal Groups D.C. Specifications

Symbol Parameter Min Max Unit Notes

11-18

ELECTRICAL SPECIFICATIONS

11.15. A.C. SPECIFICATIONS

Table 11-9 throu gh T a ble 11-16 list the A.C. specifications associated with the Pentium Pro pro-

cessor. T iming Diagr ams be gin with Figu re 11-7. The AC specifications are b roken into cate go-

ries. Table 11-9 and Table 11-10 contain the clock specifications, Table 11-11 and Table 11-12

contain the GTL+ speci f ications , Table 11-13 contain s th e 3.3V tol erant Signal group speci f ica-

tions, Table 11-14 contains timings for the reset conditions, Table 11-15 covers APIC bus tim-

ing, and Table 11-16 covers Boundary Scan timing.

All A.C. specifications for the GTL+ signal group are relative to the rising edge of the BCLK

input. All GTL+ timings are referenced to VREF for both “0” and “1 ” logic levels unless other-

wise specified.

Care should be taken to read all notes associated with a particu lar timing parameter.

NOTES:

1. The internal core clock freq uency is der ived from the bus clock. A clock ratio must be driven into the Pen-

tium® Pro processor on the signals LINT[1:0], A20M# and IGNNE# at reset. See the descriptions for

these signals in Appendix A. See Table 11-10 for a list of tested ratios per product.

2. Not 100% tested. Guaranteed by design/characterization.

3. Measured on rising edge of adjacent BCLKs at 1.5V.

The jitter present must be accounted for as a component of BCLK skew between devices.

Clock jitter is measured from one rising edge of the clock signal to the next rising edge at 1.5V. To remain

within the clock jitter specifications, all clock periods must be within 300ps of the ideal clock per iod for a

given frequency. For example, a 66.67 MH z clock with a nominal period of 15ns, must n ot have any sin-

gle clock period that is greater than 15.3ns or less than 14.7ns.

Table 11-9. Bus Clock A.C. Specifications

T# Parameter Min Max Unit Figure Notes

Core Frequency 100

150

166.67

180

200

MHz

@ 150MHz

@ 166MHz

@ 180MHz

@ 200MHz

Bus Frequency 50.00 66.67 MHz All Fr equencies 1

T1: BCLK Period 15 20 ns 11-7 All Frequencies

T2: BCLK Period Stability 300 ps 2, 3

T3: BCLK High Time 4 ns 11-7 @>2.0V, 2

T4: BCLK Low Time 4 ns 11-7 @<0.8V, 2

T5: BCLK Rise Time 0.3 1.5 ns 11-7 (0.8V - 2.0V), 2

T6: BCLK F all Time 0.3 1.5 ns 11-7 (2.0V- 0.8V),2

11-19

ELECTRICAL SPECIFICATIONS

NOTE:

1. Only those indicated here are tested during the manufacturing test process.

NOTES:

1. Valid delay timings for these signals are specified into an idealized 25Ω resistor to 1.5V with VREF at

1.0V. Minimum values guaranteed by design. See Figure 12-11 for the actual test configuration.

2. GTL+ timing specifications for 166MHz and higher components are PRELIMINARY. Consult your

local FAE.

3. A minimum of 3 clocks must be guaranteed between 2 active-to-inactive transitions of TRDY#.

4. RESET# can be asserted (active) asynchronously, but must be deasserted synchronously.

5. Specification takes into account a 0.3V/ns edge rate and the allowable VREF variation.

Guaranteed by design.

6. After Vcc, VTT, VREF, BCLK and the clock ratio become stable.

Table 11-10. Supported Clock Ratios1

PART: 2X 5/2X 3X 7/2X 4X

150MHz XXX

166MHz XX

180MHz XX

200MHz XX X

Table 11-11. GTL+ Signal Groups A.C. Specifications

RL = 25Ω terminated to 1.5V, VREF = 1.0V

T# Parameter Min Max Unit Figure Notes

T7A: GTL+ Output Valid Delay

H→L0.55

0.80 4.4

4.4 ns

ns 11-8 @ 150MHz, 256K L2

All other components

1, 2

T7B: GTL+ Output Valid Delay

L→H0.55

0.80 3.9

3.9 ns

ns 11-8 @ 150MHz, 256K L2

All other components

T8: GTL+ Input Setup Time 2.2 ns 11-9 3, 4, 5

T9: GTL+ Input Hold Time 0.45

0.70 ns

ns 11-9 @ 150MHz, 256K L2

All other components

T10: RESET# Pulse Width 1 ms 11-12

11-13 6

11-20

ELECTRICAL SPECIFICATIONS

NOTE:

1. Specified f or an edge rate of 0.3-0.8V/ns . See Section 12.1.3.1., “Ringbac k Tolerance” for the definiti on of

these terms. See Figure 12-3 and Figure 12-4 f or the generic waveforms. All values determined by

design/characterization.

NOTES:

1. Valid delay timings for these signals are specified into 150Ω to 3.3V. See Figure 11-6 for a capacitive der-

ating curve.

2. These inputs may be driven asynchronously. However, to guarantee recognition on a specific clock, the

setup and hold times with respect to BCLK must be met.

3. These signals must be driven synchronously in FRC mode.

4. A20M#, IGNNE#, INIT# and FLUSH# can be asynchronous inputs, but to guarantee recognition of these

signals following a synchronizing instruction such as an I/O write instruction, they must be valid with

active RS[2:0]# signals of the corresponding synchronizing bus transaction.

5. INTR and NMI are only valid in APIC disable mode. LINT[1: 0]# are only valid in APIC enabled mode.

6. When driven inactive, or after Power, VREF, BCLK, and the ratio signals are stable.

Table 11-12. GTL+ Signal Groups Ringback Tolerance

T# Parameter Min Unit Figure Notes

α: Overshoot 0.55 mV 11-10 1

τ: Minimum Time at High 1.5 ns 11-10 1

ρ: Amplitude of Ringback -100 mV 11-10 1

δ: Dur ation of Squarewave Ringback N/A ns 11-10 1

φ: Final Settling Voltage 100 mV 11-10 1

Table 11-13. 3.3V Tolerant Signal Groups A.C. Specifications

T# Parameter Min Max Unit Figure Notes

T11: 3.3V Tolerant Output Valid Delay 1 8 ns 11-8 1

T12: 3.3V Tolerant Input Setup Time 5 ns 11-9 2, 3, 4, 5

T13: 3.3V Tolerant Input Hold Time 1.5 ns 11-9

T14: 3.3V Tolerant Input Pulse Width,

except PWRGOOD 2 BCLKs 11-8 Active and

Inactive states

T15: PWRGOOD Inactive Pulse Width 10 BCLKs 11-8

11-13 6

11-21

ELECTRICAL SPECIFICATIONS

NOTE:

1. For a reset, the clock ratio defined by these signals must be a saf e value (their final or lower multiplier)

within this delay unless PWRGOOD is being driven inactive.

Figure 11-6. 3.3V Tolerant Group Derating Curve

Table 11-14. Reset Conditions A.C. Specifications

T# Parameter Min Max Unit Figure Notes

T16: Reset Configuration Signals (A[14:5]#,

BR0#, FLUSH#, INIT#) Setup Time 4 BCLKs 11-12 Before

deassertion of

RESET#

T17: Reset Configuration Signals (A[14:5]#,

BR0#, FLUSH#, INIT#) Hold Time 2 20 BCLKs 11-12 After clock that

deasserts

RESET#

T18: Reset Configuration Signal s (A20M#,

IGNNE#, LINT[1:0]#) Setup Time 1 ms 11-12 Before

deassertion of

RESET#

T19: Reset Configuration Signal s (A20M#,

IGNNE#, LINT[1:0]#) Delay Time 5 BCLKs 11-12 After assertion of

RESET# 1

T20: Reset Configuration Signal s (A20M#,

IGNNE#, LINT[1:0]#) Hold Time 2 20 BCLKs 11-12

11-13 After clock that

deasserts

RESET#

7.00

7.50

8.00

8.50

9.00

9.50

10.00

10.50

11.00

11.50

12.00

0 5 10 15 20 25 30 35 40 45 50

11-22

ELECTRICAL SPECIFICATIONS

NOTES:

1. With FRC enabled, PICCLK must be ¼X BCLK and synchronized with respect to BCLK with PICCLK lag-

ging BCLK by at least 1 ns and no more than 5 ns.

2. Referenced to PICCLK Rising Edge.

3. For open drain signals, Valid Delay is synonymous with Float Delay.

4. Valid delay timings for these signals are specified into 150Ω to 3.3V.

Table 11-15. APIC Clock and APIC I/O A.C. Specifications

T# Parameter Min Max Unit Figure Notes

T21A:PIC CLK Frequency 2 33.3 MHz

T21B:FRC Mode BCLK to PICCLK offset 1 5 ns 11-11 1

T22: PICCLK Period 30 500 ns 1 1-7

T23: PICCLK High Time 12 ns 11-7

T24: PICCLK Low Time 12 ns 11-7

T25: PICCLK Rise Time 1 5 ns 11-7

T26: PICCLK Fall Time 1 5 ns 11-7

T27: PICD[1:0] Setup Time 8 ns 11-9 2

T28: PICD[1:0] Hold Time 2 ns 1 1-9 2

T29: PICD[1:0] Valid Delay 2.1 10 ns 11-8 2, 3, 4

11-23

ELECTRICAL SPECIFICATIONS

NOTES:

1. Not 100% tested. Guaranteed by design/characterization.

2. 1ns can be added to the maximum TCK rise and fall times f or every 1MHz below 16MHz.

3. Referenced to TCK rising edge.

4. Referenced to TCK falling edge.

5. Valid delay timing f or this signal is specified into 150Ω terminated to 3.3V.

6. Non-Test Outputs and Inputs are the normal output or input signals (besides TCK, TRST#, TDI, TDO and

TMS). These timings correspond to the response of these signals due to boundary scan operations.

PWRGOOD should be driven hig h throughout boundar y scan testing.

7. During Debug Port operation, use the normal specified timings rather than the boundary scan timings.

Tab le 11-1 6. Boundary Scan Interface A.C. Specific atio ns

T# Parameter Min Max Unit Figure Notes

T30: TCK Frequency — 16 MHz

T31: TCK Period 62.5 — ns 11-7

T32: TCK High Time 25 ns 11-7 @2.0V, 1

T33: TCK Low Time 25 ns 11-7 @0.8V, 1

T34: TCK Rise Time 5 ns 11-7 (0.8V-2.0V), 1, 2

T35: TCK Fall Time 5 ns 11-7 (2.0V-0.8V), 1, 2

T36: TRST# Pulse Width 40 ns 11-15 1, Asynchronous

T37: TDI, TMS Setup Time 5 ns 11-14 3

T38: TDI, TMS Hold Time 14 ns 11-14 3

T39: TDO Valid Delay 1 10 ns 11-14 4, 5

T40: TDO Float Delay 25 ns 11-14 1, 4, 5

T41: All Non-Test Outputs Valid Delay 2 25 ns 11-14 4, 6, 7

T42: All Non-Test Outputs Float Delay 25 ns 11-14 1, 4, 6, 7

T43: All Non-Test Inputs Setup Time 5 ns 11-14 3, 6, 7

T44: All Non-Test Inputs Hold Time 13 ns 11-14 3, 6, 7

11-24

ELECTRICAL SPECIFICATIONS

Figure 11-7. Generic Clock Waveform

Tr= Rise Time

Tf= Fall Time

Th= High Time

Tl= Low Time

Tp= Period

Figure 11-8. Valid Delay Timings

Tx = Valid Delay

Tpw = Pulse Width

V = 1.0V for GTL+ signal group; 1.5V for 3.3V Tolerant, APIC, and JTAG signal groups

VHI = GTL+ signals must achieve a DC high level of at least 1.2V.

VLO = GTL+ signals must achieve a DC low level of at most 0.8V.

2.0V

0.8V 1.5V

Tf Tl

CLK

11-25

ELECTRICAL SPECIFICATIONS

Figure 11-9. Setup and Hold Timings

Ts= Setup Time

Th= Hold Time

V = 1.0V for GTL+ signal group; 1.5V for 3.3V Tolerant, APIC and JTAG signal groups

Figure 11-10. Lo to Hi GTL+ Receiver Ringback Tolerance

The Hi to Low Case is analogous.

α = Overshoot

τ = Minimum Time at High

ρ = Amplitude of Ringback

φ = Final Settling Voltage

VREF + 0.2

VREF − 0.2

Time

VREF

Clock

1.5 V Clk Ref

Vstart

0.3--0.8 V/ns

−ρ

Tsu +0.05ns

11-26

ELECTRICAL SPECIFICATIONS

Figure 11-11. FRC Mode BCLK to PICCLK Timing

LAG = T21 (FRC Mode BCLK to PICCLK offset)

Figure 11-12. Reset and Configuration Timings

Tt = T9 (GTL+ Input Hold Time)

Tu = T8 (GTL+ Input Setup Time)

Tv = T10 (RESET# Pulse Width)

Tw = T16 (Reset Configuration Signals (A[14:5]#, BR0#, FLUSH#, INIT#) Setup Time)

Tx = T17 (Reset Configuration Signals (A[14:5]#, BR0#, FLUSH#, INIT#) Hold Time)

T20 (Reset Configuration Signals (A20M#, IGNNE#, LINT[1:0]#) Hold Time)

Ty = T19 (Reset Configuration Signals (A20M #, IGNNE#, LINT[1:0]#) Delay Time)

Tz = T18 (Reset Configuration Signals (A20M#, IGNNE#, LINT[1:0]#) Setup Time)

11-27

ELECTRICAL SPECIFICATIONS

Figure 11-13. Power-On Reset and Configuration Timings

Ta = T15 (PWRGOOD Inactive Pulse Width)

Tb = T10 (RESET# Pulse W idth)

Tc = T20 (Reset Configuration Signals (A20M#, IGNNE#, LINT[1:0]#) Hold Time)

Figure 11-14. Test Timings (Boundary Scan)

Tr = T43 (All Non-Te st Inputs Setup Time)

Ts = T44 (All Non-Test Inputs Hold Time)

Tu = T40 (TDO Float Delay)

Tv = T37 (TDI, TMS Setup Time)

Tw = T38 (TDI, TMS Hold Time)

Tx = T39 (TDO Valid Delay)

Ty = T41 (All Non-Te st Outputs Valid Delay)

Tz = T42 (All Non-Test Outputs Float Delay)

11-28

ELECTRICAL SPECIFICATIONS

11.16. FLEXIBLE MOTHERBOARD RECOMMENDATIONS

Table 11 -17 provide s reco mmenda tions for design ing a “flex ible” m otherboa rd for suppor ting

future Pentium Pro processors. By meeting these recommendations, the same system design

should be able to support all standard Pentium Pro processors. If the voltage regulator module

is socketed using Header 8, a smaller range of support is required by the v oltag e regulator mod -

ule. See Section 17.2.3., “OverDrive® Voltage Regulator Module Definition” for information

on Header 8. These values are preliminary!

NOTE:

1. Values are per processor and are solely recomm endations.

The use of a zero-insertion force socket for the processor and the voltage regulator module

is recommended. One should also make every attempt to leave margin in the system where

possible.

Figure 11-15. Test Reset Timing

Tq = T36 (TRST# Pulse Width)

Table 11-17. Flexible Motherboard (FMB) Power Recommendations 1

Symbol Parameter Low end High end Unit Notes

VccP Full FMB Primary Vcc

Socketed VRM Primary Vcc 2.4

3.1 3.5

3.5 V

V5% tolerance over range

VccS FMB Secondary Vcc 3.3 3.3 V 5% tolerance

Vcc5 FMB 5V Vcc 5.0 5.0 V 5% tolerance

PMax FMB Thermal Design power 45 W

IccPFull FMB VccP Current 0.3 14.5 A

IccSFM B VccS Current 0 3.0 A

Icc5FM B Vcc5 Current 340 mA

CPHigh Frequency VccP

Decoupling 40 µF 40 1µF 1206 packages

CSHigh Frequency VccS

Decoupling 10 µF 10 1µF 1206 packages

TCFMB Operating Case

Temperature 85 °C

GTL+ Interface

Specification

12-1

CHAPTER 12

GTL+ INTERFACE SPECIFICATION

This section defines the new open-drain bus called GTL+. The primary target audience is de-

signers developing systems using GTL+ devices such as the Pentium Pro processor and the

82450 PC Iset. This sp ecification will also be useful fo r I/ O buffer des ign ers developing an I/O

cell and package to be used on a GTL+ bus.

This specification is an enhancement to the GTL (Gunning Transceiver Logic) specification.

The enhancements were made to allow the interconnect of up to eight devices operating at 66.6

MHz and high er us ing manu facturing tech niques t h at are s tandard in the micropro cess or i ndu s-

try. The specification enhancements over standard GTL provide better noise margins and re-

duced ringing. Since this specification is different from the GTL specificat ion, it is referred to

as GTL+.

The GTL+ specification def ines an open-drain b us with external pull-up resistors providing ter-

mination to a termination voltage (VTT). The specification includes a maximum driver output

low voltage (VOL) val ue, o utput dr iver edge rate requi remen ts , example AC timings, maximum

bus age nt loading (capacitance and package stub length), and a recei v er threshol d (V REF) that is

propo rt ional to the termin ation voltage.

The specification is given in two parts. The f irst, is the system specifi cation which describes the

system en vironment. The second, is the actual I/O specif ication, which describes the A C and DC

characteristics for an I/O transceiver.

Note that some of the critical distances, such as routing length, are given in electrical length

(time) instead of physical length (distance). This is because the system design is dependent on

the propagation time of the signal on a printed circuit board trace rather than just the length of

the trace. Dif ferent PCB materials, package ma terials and system construction result in different

signal prop agation velocities. Therefore a given physical length does not corresp ond to a fixed

electrical length. The distance (time) calculation up to the designer.

12.1. SYSTEM SPECIFICATION

Figure 12-1 shows a typical system that a GTL+ de vice would be placed into. The typical system

is shown with two terminations and multiple transceiver agents connected to the bus. The re-

ceivers have differential inputs connected to a reference voltage, VREF, which is generated ex-

ternally by a voltage divider. Typically, one voltage divider exists at each component. Here one

is shown for the entire network.

12-2

GTL+ INTERFACE SPECIFICATION

12.1.1. System DC Parameters

The following system DC parameter s apply to Figure 12-1.

Figure 12-1. Example Terminated Bus with GTL+ Transceivers

12-3

GTL+ INTERFACE SPECIFICATION

NOTES:

1. This ±2% tolerance is in addition to the ±10% tolerance of VTT, and could be caused by such factors as

voltage divider inaccuracy.

2. ZEFF = Z0(nominal) / (1+Cd/Co)1/2

Z0 = Nominal board im pedance; recomm ended to be 65Ω ±10%. Z0 is a functio n of the t race cross-sec-

tion, the distance to the reference plane(s), the dielectric constant, εr, of the PCB material and the dielec-

tric constant of the solder-mask/air for micro-strip traces.

Co = Total intrinsic nominal trace capacitance between the first and last bus agents, excluding the termi-

nation resistor tails. Co is a function of Z0 and εr. For Z0= 65Ω and εr = 4.3, Co is appro ximately 2.66 pF/in

times the network length (first agent to last agent).

Cd = Sum of the Capacitance of all devices and PCB stubs (if any) attached to the net,

= PCB Stub Capacitance +Socket Capacitance +Package Stub C apacitance +Die Capacitance.

3. To reduce cost, a system would usually employ one value of RT for all its GTL+ nets, irrespective of the

ZEFF of individual nets. The designer may start with the average value of ZEFF in the system. The value of

RT may be adjusted to balance the Hi-to-Lo and Lo-to-Hi noise margins. Increasing the value of RT tends

to slow the rising edge, increasing rising flight time, decreasing the Lo-to-Hi noise margin, and increasing

the Hi-to-Lo noise margin by lowering VOL. RT can be decreased for the opposite effects.

RT affects GTL+ rising edge rates and the “apparent clock-to-out” time of a driver in a net as follows: A

large RT causes the standing current in the net to be low when the (open drain) driver is low (on). As the

driver switches off, the small current is tur ned off, launching a relatively small positive-going wave down

the net. After a f e w trips back and f orth between the driver and the terminations (undergoing reflections at

intervening agents in the meantime) the net v oltage finally climbs to VTT. Because the wave launched ini-

tially is relatively sm all in amplitude (th an it would have been had RT been smaller a nd the standing cur-

rent larger), the overall r ising edge climbs toward V TT at a slower rate. Notice that this effect causes an

increase in flight time, and has no influence on the true clock-to-out timing of the driver into the standard

25Ω test load.

4. ZEFF of all 8-load nets must remain between 45-65Ω under all conditions, including variations in Z 0, Cd,

temperature, VCC, etc.

Table 12-1. System DC Parameters

Symbol Parameter Value Tolerance Notes

VTT Term ination Voltage 1.5V ±10%

VREF I nput Reference Voltage 2/3 VTT ±2% 1

RTTermination Resistance ZEFF (nom inal) See Note 2, 3

ZEFF Effective (Loaded) Network Impedance 45-65Ω4

12-4

GTL+ INTERFACE SPECIFICATION

12.1.2. Topological Guidelines

The board routing should use layout design rules consistent with high-speed digital design (i.e.

minimize trace length and number of vias, minimize trace-to-trace coupling, maintain consistent

impedance over the length of a net, maintain consistent impedance from one net to another, en-

sure sufficient power to ground plane bypassing, etc.). In addition, the signal routing should be

done in a Daisy Chain topology (such a s shown in F igure 12- 1) withou t any significan t stubs.

Table 12- 2 describes, more completely, some of these guidelines. Note that the c ritical distances

are measured in electrical length (propagation time) instead of physical lengt h.

12.1.3. System AC Parameters: Signal Quality

The system A C parameters f all into two cate gories, Signal Quality and Flight T ime. Acceptable

signal quality must be maintained ov er all operating conditions to ensure reliable operation. Sig-

nal Quality is defined by three parameters: Overshoot/ Undershoot, Settling Limit, and Ring-

back. These parameters are illustrated in Figure 12-2 and are described in Table 12-3.

Table 12-2. System Topological Guidelines

Symbol Parameter

Maximum Trace Length To meet a specific Clock cycle tim e, the maximum trace length between any

two agents must be restricted. The flight time (defined later) must be less than

or equal to the maximum amount of time which leaves enough time within one

clock cycle for the remaining system parameters such as driver clock-out delay

(TCO), receiver setup ti me (T SU), clock jitter and clock skew.

Maximum Stub Length All signals should use a Daisy Chain routing (i.e. no stubs). It is acknowledged

that the package of each device on the net imposes a stub, and that a practical

lay out using PQFP parts ma y require SHORT stubs , so a truly stubless netw ork

is impossible to achieve, but any stub on the network (including the device

package) should be no greater than 250 ps in electrical length.

Distributed Loads Minimum spacing lengths are determined by hold time requirements and clock

ske w. Maintaining 3" ±30% inter-agent spacing minimizes the v ariation in noise

margins between the various networks, and can provide a significant

improvement for the networks. This is only a guideline.

12-5

GTL+ INTERFACE SPECIFICATION

Figure 12-2. Receiver Waveform Showing Signal Quality Parameters

Table 12-3. Specifications for Signal Quality

Symbol Parameter Specification

Maximum Signal

Overshoot/Undershoot Maximum Absolute voltage a signal extends above V TT

or below VSS (simulated w/o protection diodes). 0.3V

(guideline)

Settling Limit The maximum amount of ringing, at the receiving chip

pad, a signal must be limited to before its next

transition. This signal should be within 10% of the

signal swing to its final value, when either in its high

state or low state.

±10% of

(VOH-VOL)

(guideline)

Maximum Signal

Ringback (Nominal) The maximum amount of ringing allowed for a signal at

a receiving chip pad within the receiving chips setup

and hold time window before the next clock. This value

is dependent upon the specific receiver design.

(Normally ringing within the setup and hold windows

must not come within 200 mV of VREF although specific

devices may allow more ringing and loosen this

specification. See Section 12.1.3.1., “Ringback

Tolerance” for more details.)

VREF ±200 mV

12-6

GTL+ INTERFACE SPECIFICATION

The overshoot/undershoot guideline is provided to limit signals transitioning beyond VCC or

VSS due to f ast signal edge rates. Violating the o vershoot/und ershoot guideline is acceptable, but

since excessiv e ringback is the harmful ef fect associated with ov ershoot/undershoot it will make

satisfying the ringback specification very difficult.

V iolations of the Settling Limit guideline are acceptable if simulations of 5 to 10 successive tran-

sitions do not show the amplitude of the ringing increasing in the subsequent transitions. If a sig-

nal has n ot s ettled clo se to it s final value before the next logic transi tion, th en th e timing delay

to VREF of the succeeding transition may vary slightly due to the stored reactive energy in the

net inherited from the previous transition. This is akin to ‘eye’ patterns in communication sys-

tems caused by inter -symbol interference. The resulting effect is a slight variation in flight time.

12.1.3.1. RINGBACK TOLERANCE

The nominal maximum ringback tolerated by GTL+ receivers is stated in Table 12-3, namely:

no closer to VREF than a ±200 mV overdrive zone. This requirement is usually necessary to

guarantee that a recei ver meets its specified minimu m setup time (TSU), since setup time usually

degrades as the magnitude of overdrive beyond the switching threshold (VREF) is reduced.

Exceptions to the nominal ov erdri ve requ irement can be made when it is kno wn that a particular

receiver’s setup time (as specified by its manufacturer) is relatively in sensitive (less than 0. 05

ns impact) to well-controlled ringing into the overdrive zone or even to brief re-crossing of the

switching threshold, VREF. Such “ringback-tolerant” receivers give the system designer more

design freedom, and, if not exploited, at least help maintain high system reliability.

To characterize ringback tolerance, employ the idealized Lo-to-Hi input signal shown in

Figure 12-3. The corresponding waveform for a Hi-to-Lo transition is shown in Figure 12-4.

The object of ringback characterization is to determine the range of values for the different pa-

rameters shown on the diagram, which would maintain receiver setup time and correct logic

functionality.

These parameters are defined as follows:

τ is the minimum ti m e th at t he i npu t must sp end, after crossing VREF at the High level, before it

can ring back, having overshot VIN_HIGH_MIN by at least α, while ρ, δ, and φ (defined below)

ar e a t some preset values, all without incr easing T SU by more than 0.05 ns. Analo gously for Hi-

to-Lo transitions.

It is expected that the larger the o ver shoot α, the smaller the amount of time, τ, needed to main -

tain setup time to within +0.05 ns of the nominal value. For a given value of α, it is likely that

τ will be the longest for the slowest input edge rate of 0.3V/ns. Furthermore, there may be some

dependence between t and lower starting voltages than VREF –0.2V (for Lo-to-Hi transitions)

for the reason described later in the Section on recei ver characterization. Analo gously for Hi-L o

transitions.

12-7

GTL+ INTERFACE SPECIFICATION

Figure 12-3. Standard Input Lo-to-Hi Waveform for Characterizing Receiver Ringback

Tolerance

Figure 12-4. Standard Input Hi-to-Lo Waveform for Characterizing Receiver Ringback

Tolerance

VREF + 0.2

VREF− 0.2

Time

VREF

Clock

1.5 V Clk Ref

Vstart

0.8 V/ns

0.3 V/ns

α10 ps rise/fall Edges

Tsu +0.05ns

VREF

VREF+ 0.2

VREF- 0.2

Time

Vstart

3.0 V/ns

0.3 V/ns

α10 ps rise /fall Edges

1.5 V Clk Ref

Clock

Tsu +0.05ns

12-8

GTL+ INTERFACE SPECIFICATION

ρ & δ ar e respectively , the amplitude and duration of squar e-wave ring back, below the thr eshold

voltage (VREF), that the receiver can toler ate without increasing TSU by mor e than 0.05 ns for a

given pair of (α, τ) values.

If, for any reason, the receiver cannot tolerate any ringback across the reference threshold

(VREF), then ρ would be a ne gat i v e n umber, and δ may be infinite. Otherwise, expect an in v erse

(or near-inverse) relationship between ρ and δ, where the more the ringback, the shorter is the

time that the ringback is allowed to last without causing the receiver to detect it.

φ is the final minimum settling voltage, relative to the r eference threshold (VREF), that the input

should return to after ringback to guarantee a valid log ic state at the inter na l flip-flop inpu t.

φ is a function of the input amplif ier gain, its differential mode offset, and its intrinsic maximum

level of differential noise.

Specifying the v alues of α, τ, ρ, δ, and φ is the responsibility of the receiv er v endor. The system

designer should guarantee that all signals arriving at such a receiver remain in the permissible

region specified by the vendor parameters as they correspond to those of the idealized square

wa v es of Figure 12-3 and Figure 12-4. F or instance, a sig nal with ringback inside the box d elin-

eated by ρ and δ can have a τ equal to or longer than the minimum, and an α equal to or larger

than the minimum also.

A receiver that does not tolerate any ringback would show the followi ng values for the above

parameters:

α > 0V, τ > Tsu, ρ = -200 mV, δ = undefined, φ = 200 mV.

A receiver which tolerates 50 mV of ringback would show the following values for the above

parameters:

α > 0V, τ = data sheet, ρ = -150 mV, δ = data sheet, φ > tens of mV (data sheet).

Finally, a receiver which tolerates ringback across the switching threshold would show the fol-

lowing values for the above parameters:

α > 0 V, τ = data sheet, ρ > 0 mV (data sheet), δ = data sheet, φ > tens of mV.

where δ would usually be a brief amount of time, yielding a pulse (or “blip”) beyond VREF.

12.1.4. AC Parameters: Flight Time

Signal Propagation Delay is the time between when a signal appears at a driver pin and the time

it arrives at a receiver pin. Flight Time is often used interchangeably with Signal Propagation

Delay but it is actually quite different. Flight time is a term in the timing eq uation that include s

the signal propagation delay, any effect s the system has on the T CO of the driver, plus any

adjustments to the signal at the receiver needed to guarantee the TSU of the receiver. More pre-

cisely, Flight Time is defined to be:

12-9

GTL+ INTERFACE SPECIFICATION

The time difference between when a signal at the input pin of a receiving

agent (adjusted to meet the receiver manufacturer’s conditions required for

AC specifications) crosses VREF, and the time that the output pin of the

driving agent crosses VREF were it driving the test load used by the

manufacturer to specify that driver’s AC timings.

An example of the simplest Flight Time measurement is shown in Figure 12-5. The receiver

specifi cation assumes that the signal maintains an edge rate greater than or equal to 0.3V/ns at

the r eceiver chip p ad in the o v erdrive regio n from V REF to VREF +200 mV fo r a rising edge and

that there are no signal quality violations after the input crosses VREF at the pad. The Flight Time

measurement is similar for a simp le Hi-to-Lo trans ition. Notice that timin g is measured at the

dri ver and recei v e r pins while signal integrity is observed at the receiver chip pad. When signal

integrity at the pad violates the guidelines of this specif ication, and adjustments need to be made

to flight time, the ad justed flight time obtained at the ch ip pad can b e assu med to have been ob-

tained at the package pin, usually with a small timing error penalty.

The 0.3V/ns edge rate will be addresse d later in this docume nt, since it is rela ted to the condi-

tions used to specify a GTL+ recei v er’s minimum setup time. What is meant b y edge rate is nei-

ther instantaneous, nor strictly average. Rather, it can best be described for a rising edge -- by

imaginin g an 0.3V/ns line crossing VREF at the same moment that the signal crosses it, and ex-

tending to VREF +200 mV, with the signal staying ahead (earlier in time) of that line at all times,

until it reaches VREF +200 mV. Such a requirem ent would alw ays yiel d s ign als wi th an average

edge rate >0.3V/ns, but which could have instantaneous slopes that are lower or higher than

0.3V/ns, as lon g as they do not cause a crossing of the in clined line.

Figure 12-5. Measuring Nominal Flight Time

12-10

GTL+ INTERFACE SPECIFICATION

If either the rising or falling edge is slower than 0.3V/ns through the overdrive region beyond

VREF, (i.e., does not alway s stay ahead of an 0 .3V/ns line), th en the f light time for a rising edge

is determined by extrapolating back from the signal crossing of V REF +200 mV to VREF using

an 0.3V/ns slope as indicated in Figure 12-6.

If the signal is not monotonic while traversing the overdrive region (VREF to VREF +200 mV

rising, or V REF to VREF - 200 mV falli ng), or ring s back into the o v erdr i v e re gion after cros sing

VREF, then flight time is determined by extrapolating back from the last crossing of VREF ± 200

mV us in g a li ne with a slo pe of 0.8 V/n s ( the m a xi mum al lowed ris in g edg e rat e ). T his yie ld s a

new VREF crossi ng point to be used for the flig ht time calculation. Figure 12-7 represen ts the

situation where the signal is non-monotonic after crossing VREF on the rising edge.

Figure 12-8 shows a falling edge that rings back into the overdrive region after crossing VREF,

and the 0.8V/ns line used to extrap olate flight time. Since str ict adherence to the edge r ate spec-

ification is not required for Hi-to-Lo transitions, and some driv ers’ falling edges are substantial-

ly faster than 0.8V/ns --at both the fast and slow corners--, care should be tak en when using the

0.8V/ns extrapolation. The extrapolation is invalid whenever it yields a VREF crossing that oc-

curs earlier than when the signal’s actual edge crosses VREF. In that case, flight time is defined

to be the longer of: the time when the input at the receiver crosses VREF initially, or wh en the

line extrapolated (at 0.8V/ns) crosses VREF. Figure 12-8 illus trates the situation where the ex-

trapolated value woul d be used.

Figure 12-6. Flight Time of a Rising Edge Slower Than 0.3V/ns

12-11

GTL+ INTERFACE SPECIFICATION

Figure 12-7. Extrapolated Flight Time of a Non-Monotonic Rising Edge

Figure 12-8. Extrapolated Flight Time of a Non-Monotonic Falling Edge

12-12

GTL+ INTERFACE SPECIFICATION

The maximum acceptable Fligh t T ime is determin ed on a net-b y-net b asis, and is usually dif fer -

ent for each unique dri v er-re cei ver p air. The maximum acceptable Flight T ime can be calculated

using the following equation (known as the setup time equation):

TFLIGHT-MAX < T PERIOD-MIN - (TCO-MAX +TSU-MIN +TCLK_SKEW-MAX +TCLK_JITTER-MAX)

Where, TCO-MAX is the maxi mum clock -t o-out delay of a d riving agen t, TSU-MIN is the mini-

mum setup time required by a receiver on the same net, TCLK_SKEW-MAX is the maximum an-

ticipated time dif feren ce between th e driver ’s and the receiver’s clock inputs, and TCLK_JITTER-

MAX is maxi mum anticipat ed ed ge-to- edge ph ase j itter. The above equation should be checked

for all pairs of devices on all nets of a bus.

The minimum acceptable Flight Time is determined by the following equation (known as the

hold time equati on):

THOLD-MIN < TFLIGHT-MIN +TCO-MIN - TCLK_SKEW-MAX

Where, TCO-MIN is the minimum cl ock-to-out del ay of the dri ving agent , THOLD-MIN is the min-

imum hold time required by the recei v er , and TCLK_SKEW-MAX is defined above. The Hold time

equation is i ndepen dent of clock jitt er, since data is released by the driver and is required to be

held at the receiver on the same clock edge.

12.2. GENERAL GTL+ I/O BUFFER SPECIFICATION

This specification identifies the key parameters for the driver, receiver, and package that must

be met to operate in the system environment described in the pre vious section. All specifications

must be met over all possible operating conditions including temperature, voltage, and semicon-

ductor process. This information is included for designers of components for a GTL+ bus.

12.2.1. I/O Buffer DC Specification

Table 12-4 contains the I/O Buffer DC parameters.

12-13

GTL+ INTERFACE SPECIFICATION

12.2.2. I/O Buffer AC Specification

Table 12-5 contains the I/O Buffer AC parameters.

NOTES:

1. Measured into a 25Ω test load tied to VTT = 1.5 V, as shown in Figure 12-11.

2. VREF = 2/3 VTT. (VTT = 1.5 V ±10%), VREF has an additional tolerance of ± 2%.

3. This parameter is for inputs without internal pull-ups or pull downs and 0 < VIN < VTT.

4. Total capacitance, as seen from the attachment node on the network, which includes traces on the PCB,

IC socket, component packa ge, driver/receiver capacitance, and ESD struc ture capacitance.

Table 12-4. I/O Buffer DC Parameters

Symbol Parameter Min Max Units Notes

VOL Drive r Output Low Voltage 0.600 V 1

VIH Receiver Input High Voltage VREF + 0.2 V 2

VIL Receiver Input Low Voltage VREF – 0.2 V 2

VILC Input Leakage Current 10 µA3

CIN, COTotal Input/Output Capacitance 10 pF 4

12-14

GTL+ INTERFACE SPECIFICATION

NOTES:

1. This is the maximum instantaneous dV/dt over the entire transition range (Hi-to-Lo or Lo-to-Hi) as mea-

sured at the driver’s output

while driving the Ref8N network, with the driver and its package model

located near the center of the network (see Section 12.4., “Ref8N Network”).

2. These are design targets. The acceptance of the buffer is also based on the resultant signal quality. In

addition to edge rate, the shape of the rising edge can also hav e a significant effect on the buffer’s perfor-

mance, therefore the drive r must also meet the signal quality c riteria in the next section. For example, a

rising linear ramp of at 0.8V/ns will generally produce worse signal quality (m ore ringback) than an edge

that rolls off as it approaches VTT even though it might have exceeded that rate earlier. Hi-to-Lo edge

rates may exceed this specification and produce acceptable results with a corresponding reduction in

VOL. For instance, a buffer with a falling edge rate larger than 1.5V/ns can been deemed acceptable

because it produced a VOL less than 500 mV. Lo-to-Hi edges must meet both signal quality and maximum

edge rate specifications.

3. The minimum edge rate is a design target, and slower edge rates can be acceptable, although there is a

timing impact associated with them in the form of an increase in flight ti me, since the signal at t he receiv er

will no longer meet the required conditions for TSU. Refer to Section 12.1.4., “AC Parameters: Flight

Time” on computing flight time f or more details on the eff ects of edge rates slower than 0.3V/ns.

4. These values are not specific to this specification, they are depen dent on the location of the driver along

a network and the system requirements such as the number of agents, the distances between agents,

the construction of the PCB (Z0, εr, trace width, trace type, connectors), the sockets being used, if any,

and the value of the termination resistors. Good targets for components to be used in an 8-load 66.6 MHz

system would be: TCO_MAX = 4.5 ns, TCO_MIN = 1 ns, TSU = 2.5 ns, and THD = 0.

5. This value is specified at the output pin of the device. TCO should be measured at the test probe point

shown in the Figure 12-11, but the delay caused by the 50Ω transmission line must be subtracted from

the measurement to achiev e an accurate value for Tco at the output pin of the device. For simulation pur-

poses, the tester load can be represented as a single 25Ω term ination resistor connected directly to the

pin of the device.

6. See Section 12.2.3., “Determining Clock-To-Out, Setup and Hold” for a description of the procedure for

determining the receiver’s minimum required setup and hold times.

Table 12-5. I/O Buffer AC Parameters

Symbol Parameter Min Max Units Figure Notes

dV/dtEDGE Output Signal Edge Rate, rise 0.3 0. 8 V/ns 1, 2, 3

dV/dtEDGE Output Signal Edge Rate, fall 0.3 -0.8 V/ns 1, 2, 3

TCO Output Cloc k to Data Time no spec ns Figure 12-12 4, 5

TSU Input Setup Time no spec ns Figure 12-13

Figure 12-14

4, 6

THOLD Input Hold Time no spec ns 4, 6

12-15

GTL+ INTERFACE SPECIFICATION

12.2.2.1. OUTPUT DRIVER ACCEPTANCE CRITERIA

Although Section 12.1.4., “AC Parameters: Flight Time” describes ways of amending flight

time to a receiver when the edge rate is lower than the requirements shown in Table 12-5, or

when there is excessi ve ringing, it is still preferable to av oid slow edge rates or excessi ve ringing

through good driver and system design, hence the criteria presented in this section.

As mentioned in note 2 of the previous section, the criteria for acceptance of an output driver

relate to the edge rate and the signal quality for the Lo-to-Hi transition, and primarily to the sig-

nal quality for the Hi-to-Lo transition when the device, with its targeted package, is simulated

into the Ref8n network (Figure 12-15). The edge rate portion of the AC specification is a good

initial target, but is insufficient for guaranteeing acceptable performance.

Since Ref8N is not the worst case network, and is expected to be modeled without many real

system effects (e.g., inter-trace crosstalk, DC & A C losses), the required signal quality is slightly

different than that specified in Section 12.1.3., “System AC Parameters: Signal Quality” of this

document.

The signal quality criterion for an acceptable driver design is that the signals produced by the

driver (at its fastest corner) at all Ref8N receiver pads must remain outside of the shaded areas

shown in Figure 12-9. Simulations must be performed at both device and operating extremes:

fast process corner at high VCC and low temperature, and slow process corner at low VCC and

high temperature, for both the rising and falling edges. The clock frequency should be at the de-

sired maximum (e.g. 66.6 MHz, or higher), and the simulation results should be analyzed both

from a quiescent start (i.e., first cycle in a simulation), and when p receded by at least one p revi-

ous transition (i.e. subsequent simulation cycles).

The boundaries of the keep-out area for the Lo-to-Hi transition are formed by a vertical line at

the start of the receiver setup window (a distance T SU’ from the next clock edge), an 0.3V/ns

ramp line passing through the intersection between the VREF +100 mV lev el (the 100 mV i s as-

sumed extra noise) and the beginning of the setup window, a horizontal line at VREF +300 mV

(which covers 200 mV of specified overdrive, and the 100 mV margin for extra noise coupled

to the waveform), and finally a vertical line behind the Clock at THD’. The keep-out zone for

the Hi-t o-Lo transition uses analo gous bo undaries in th e other direction. Rai sing V REF by 100

mV is assumed to be equi valen t to having 100 mV of extra noise coupled to the wa veform gi ving

it more downward ringback, such coupled noise could come from a variety of sources such as

trace-to-trace PCB coupling.

TSU’ is the receiver‘s setup time plus board clock driver and clock distribution skew and jitter,

plus an additional number that is inherited from the driver’s internal timings (to be described

next). Since the I/O buffer designer will most likely be simulating the d river circuit alone, cer-

tain delays that add to TCO, such as: on-chip clock phase shift, clock distrib ution ske w , and jitter ,

plus other data latch or JTAG delays would be missing. It is easier if these numbers are added

to TSU, yielding TSU’ making the dri v er simulation simp ler. For exam ple, assume TSU to be 2.8

ns, PCB clock gen eration and di stribution skew plus jitter to be 1 ns, and unmodeled delay s in

the driver to be typi cally about 0.8 ns, this yield s a total TSU’ = 4.6 ns.

12-16

GTL+ INTERFACE SPECIFICATION

Figure 12-9. Acceptable Driver Signal Quality

Figure 12-10. Unacceptable Signal, Due to Excessively Slow Edge After Crossing VREF

12-17

GTL+ INTERFACE SPECIFICATION

THD’ is the receiver’s hold time plus board clock driver and clock distribution skew minus the

driver’s on-chip clock phase shift, clock distribution skew, and jitter, plus other data latch or

JTAG delays (assuming these driver num bers are not included in the driver circuit simulation,

as was d one for setu p in the abo ve para graph). Note that THD’ may end up being a negati v e num-

ber , i.e. ahead o f the clock, rather than after it. That w ould be acceptable, since that is equ iv alent

to shifting the driver output later in time had these extra delays been added to the driver as op-

posed to setup and hold.

When using Ref8N to v alidate a dri v er design, it is recommended that all r ele v ant combin ations

of driver and receiver locations be checked.

As with other buffer technologies, such as TTL or CMOS, any given buffer design is not guar-

anteed to always meet th e requirements of all po ss ibl e s ys tem and netwo rk t opo l ogies . Meet i ng

the acceptance criteria listed in this document helps ensure the I/O buf fer can be u sed in a v ariety

of GTL+ applications, bu t it is the system designer’s responsibility to examine the performance

of the buf fer in the specific application to ensure that all GTL+ networks meet the signal quality

requirements.

12.2.3. Determining Clock-To-Out, Setup and Hold

This section describes how to determine setup, hold and clock to ou t timings.

12.2.3.1. CLOCK-TO-OUTPUT TIME, TCO

TCO is measured using the test load in Figure 12-11, and is the delay from the 1.5 V crossing

point of the clock signal at the clock input pin of the device, to the VREF crossing point of the

output signal at the output pin of the device. For simulation purposes, the test load can be re-

placed by its electrical equi v alent, which is a single 25 Ω resistor conn ected directly to the pack-

age pin and terminated to 1.5V.

In a produc tion test environment, it is n early imposs ible to m easure TCO directly at the output

pin of the dev ice, instead, the test is performed a f inite distance a way from the pin and compen-

sated for the finite distance. The test load circu it shown in Figure 12-11 takes this into acco unt

by making this finite distance a 50-Ω transmiss ion line. To get the exact timings at the output

pin, the propag ation delay along the transmission line must be subtracted from the measur ed val-

ue at the probe point.

12-18

GTL+ INTERFACE SPECIFICATION

TCO measur ement for a Lo-to-Hi sign al tr ans ition is s hown in Figure 12-12. The TCO measure-

ment for Hi-to-Lo transitions is similar.

Figure 12-11. Test Load for Measuring Output AC Timings

Figure 12-12. Clock to Output Data Timing (TCO)

12-19

GTL+ INTERFACE SPECIFICATION

12.2.3.2. MINIMUM SETUP AND HOLD TIMES

Setup time for GTL+ (TSU) is defined as:

The minimum time from the input signal pin crossing of VREF to the clock

pin of the receiver crossing the 1.5 V level, which guarantees that the input

buff er has captured new data at the input pin, given an infinite hold time.

Strictly speaking, setup time must be determined when the input barely meets minimum hold

time (see definition of hold time below). However, for current GTL+ systems, hold time should

be met well beyond the minimum required in cases where setup is critical. This is because setup

is critical when the receiv er is f ar remo v ed from the driver. In such cases, the signal will be held

at the receiver for a long time after the clock, since the change needs a long t ime to propagate

from the driver to the receiver.

The recommended pro cedure for the I/O b uffer designer to extract TSU is outlined below. If one

employs additional steps, it would be beneficial that any such extra steps be documented with

the results of this receiver characterizati on:

•The full receiver circuit must be used, comprising the input differential amplifier, any

shaping logic gates, and the edge-triggered (or pulse-triggered) flip-flop. The output of the

flip-flop must be m onitored.

•The receiver’s Lo-to-Hi setup time should be determined using a nominal input waveform

like the one shown in Figure 12-13 (solid line). The Lo-to-Hi input starts at VIN_LOW_MAX

(VREF - 200 mV) and goes to VIN_HIGH_MIN = VREF +200 mV, at a slow edge rate of

0.3V/ns, with the process, temperature, voltage, and VREF_INTERNAL of the receiver set to

the worst (longest TSU) corner values. Here, VREF is the external (system) reference

voltage at the device pin. Due to tolerance in VTT (1.5V, ±10%) and the voltage divider

generating system VREF from VTT (±2%), VREF can shift around 1 V by a maximum of

±122 mV. When determining setup time, the internal reference voltage VREF_INTERNAL (at

the reference gate of the diff. amp.) must be set to the value which yields the longest setup

time. Here, VREF_INTERNAL = VREF ±(122 mV +VNOISE). Where, VNOISE is the net

maximum differential noise amplitude on the component’s internal VREF d istribu tio n bus

(at the amplif ier’s referen ce inpu t g ate) comprising noise picked up by the connection from

the VREF package pin to the input of the amp.

•Analogously, for the setup time of Hi-to-Lo transitions (Figure 12-14), the input starts at

VIN_HIGH_MIN = VREF +200 mV and drops to VIN_LOW_MAX = VREF - 200 mV at the rate

of 0.3V/ns.

•For bot h th e 0.3V/n s edge rate and f ast er ed ge rat es (up to 0.8V/ns for Lo- to-Hi , and 3V/ ns

for Hi-to -Lo —dashed li n es i n F igure 12-13 and Figure 12-14), one mus t ens ure t hat l ower

starting voltages of the inp ut swing (VSTART in th e ran ge ‘VREF-200 mV’ to 0.5 V for Lo-

to-Hi transitions, an d 1.5 V to ‘VREF+200 mV’ for Hi-to- Lo transitions —dashed lines in

Figure 12-13 and Figure 12-14) do not require TSU to be made longer. This step is needed

since a lower starting voltage may cause the input differential amplifier to require more

time to switch, du e to having been in deeper saturation in the initial state.

12-20

GTL+ INTERFACE SPECIFICATION

Figure 12-13. Standard Input Lo-to-Hi Waveform for Characterizing Receiver Setup Time

Figure 12-14. Standard Input Hi-to-Lo Waveform for Characterizing Receiver Setup Time

Time

VREF

VREF + 0.2

VREF− 0.2

0.3 V/ns

Vstart

1.5 V/ns

1.5 V Clk Ref

Clock

Tsu

VREF

VREF + 0.2

VREF − 0.2

Time

1.5 V Clk Re f

0.3 V /n s

Vstart

3.0 V /n s

Clock

Tsu

12-21

GTL+ INTERFACE SPECIFICATION

Hold time for GTL+, THOLD, is defined as:

The minimum time from the clock pin of the receivers crossing of the 1.5 V

level to the receiver input signal pin crossing of VREF, which guarantees that

the input buffer has captured new data at the receiver input signal pin, given

an infinite setup time.

Strictly speakin g, hold time must b e determined when the in put barely meets minimum s etup

time (see definition of setup time above). However , for current GTL + systems, setup time is ex-

pected to be met, well beyond the minimum required in cases where hold is critical. This is be-

cause hold is critical when the receiver is very close to the driver. In such cases, the signal will

arri v e at the recei v er sho rtly after the clock, hen ce meeting setup time with com fortable mar gin.

The recommended procedur e for e x tracting THOLD is outlined below. If one employs additional

steps, it would be beneficial that any such extra steps be documented with the results of this re-

ceiver characterization:

•The full receiver circuit must be used, comprising the input differential amplifier, any

shaping logic gates, and the edge-triggered (or pulse-triggered) flip-flop. The output of the

flip-flop must be m onitored.

•The receiver’s Lo-to-Hi hold time should be determined using a nominal input waveform

that starts at VIN_LOW_MAX (VREF - 200 mV) and goes to VTT, at a fast edge rate of

0.8V/ns, with the process, temperature, voltage, and VREF_INTERNAL of the receiver set to

the fastest (or best) corner values (yielding the longest THOLD). Here, VREF i s the external

(system) reference voltage at the de vice pin. Due to tolerance in VTT (1.5V, ±10%) and the

voltage divider gen erating syste m VREF from VTT (±2%), VREF can shift around 1V by a

maximum of ±122 mV. When determining hold time, the internal reference voltage

VREF_INTERNAL (at the reference gate of the diff. amp.) must be set to the value which

yields the worst case hold time. Here, VREF_INTERNAL = VREF ±(122 mV +VNOISE).

Where, VNOISE is the net maximum differential noise amplitude on the component’s

internal VREF distribution bus (at the amplifier’s reference input gate) comprising noise

picked up by the connection from the VREF package pin to the input of the amp.

•Analogously, for th e hold time of Hi-to-Lo transitions , the input st arts at VIN_HIGH_MIN =

VREF +200 mV and drops to < 0.5 V at the rate of 3V/ns.

12.2.3.3. RECEIVER RINGBACK TOLERANCE

Refer to Section 12.1.3.1., “Ringback Tolerance” for a complete description of the defi nitions

and methodology for determin ing receiver ringback tolerance.

12-22

GTL+ INTERFACE SPECIFICATION

12.2.4. System-Based Calculation of Required Input and Output

Timings

Below are two sample calculations . The first determines TCO-MAX and TSU-MIN, while the sec-

ond determines THOLD-MIN. These equations can be used for any system by replacing the as-

sumptions listed below, with the actual system constraints.

12.2.4.1. CALCULATING TARGET TCO-MAX, AND TSU-MIN

TCO-MAX and TSU-MIN can be calculated from the Setup Time equation given earlier in Section

12.1.4., “AC Parameters: Flight Time”:

TFLIGHT-MAX < TPERIOD-MIN - (TCO-MAX + TSU-MIN + TCLK_SKEW-MAX +TCLK_JITTER-MAX)

As an e xample, for two iden tical agents located on o pposite ends o f a netw ork with a flight time

of 7.3 ns, and the other assumptions listed below, the following calculations for TCO-MAX and

TSU-MIN can be done:

Assumptions:

TPERIOD-MIN 15 ns (66.6 MHz)

TFLIGHT-MAX 7.3 ns (given flight time)

TCLK_SKEW-MAX 0.7 ns (0.5ns for clock driver)

(0.2 ns for board skew)

TCLK_JITTER-MAX 0.2 ns (Clock phase error)

TCO-MAX ?? ns (Clock to output da ta time)

TSU-MIN ?? ns (Required input setup time)

Calculation

7.3 < 15 - (TCO-MAX +TSU-MIN +0.7 +0.2)

TCO-MAX +TSU-MIN < 6.8 ns

The time remaining for TCO-MAX and TSU-MIN can be split ~60/40% (recommendation). There-

fore, in this example, TCO-MAX would be 4.0 ns, and TSU-MIN 2.8 ns.

NOTE

This a numerical example, and does not necessarily apply to any particular

device.

Off-end agents will have less distance to the farthest receiver, and therefore will have shorter

flight times. TCO values longer than the example above do not necessarily preclude high-fre-

quency (e.g. 66.6 MHz) operation, but will result in placement constrai nts for the device, such

as being required to be placed in the middle of the daisy-chain bus.

12-23

GTL+ INTERFACE SPECIFICATION

12.2.5. Calculating Target THOLD-MIN

To calculate the longest possible minimum required hold time target v alue, assume that TCO-MIN

is one fourth of TCO-MAX, and use the hold time equation given earlier. Note that Clock Jitter is

not a part of the equation, since data is released by the driver and must be held at the receiver

relative to the same clock edge:

THOLD-MIN < TFLIGHT-MIN +TCO-MIN - TCLK_SKEW-MAX

Assumptions

TCO-MAX 4.0 ns (Max clock to data time)

TCO-MIN 1.0 ns (Assumed ¼ of max)

TCLK_SKEW-MAX 0.7 ns (Driver to receiver skew)

TFLIGHT-MIN 0.1 ns (Min of 0.5” at 0.2 ns/inch)

THOLD-MIN ?? ns (Minimum signal hold tim e)

Calculation

THOLD-MIN < 0.1 +1.0 - 0.7

THOLD-MIN < 0.4 ns

NOTE

This a numerical example, and does not necessarily apply to any particular

device.

12.3. PACKAGE SPECIFICATION

This information is also included for designers of components for a GTL+ bus. The package that

the I/O transceiver will be pl aced into mu st adhere to two critical parameters. They are packag e

trace length, (the electrical distance fr om the pin to the die), an d package capacitance. The spec-

ifications for package trace length and package capacitance are not explicit, but are implied by

the system and I/O buffer specifications.

12.3.1. Package Trace Length

The System specification requ ires that all signals be routed in a daisy chain fashion, and that no

stub in the network exceed 250 ps in electrical length. The stub includes any printed circuit

board (PCB) routing to the p in of the package from the ‘Daisy Chain’ net, as well as a socket if

necessary , and the tr ace length of the package interconnect (i.e. the electrical length from the pin ,

through the p ackag e, across a bond wire if nec essar y, an d to the d i e) . For exa mp le, f or a PGA

package, which allows PCB routing both to and from a pin and is soldered to the PCB, the

12-24

GTL+ INTERFACE SPECIFICATION

maximum package trace length cannot ex ceed 250 ps. If th e PGA package is socketed, the max -

imum package trace length would be ~225 ps since a typical PGA socket is around 25 ps in elec-

trical length. For a QFP package, which typically requires a short stub on the PCB from the pad

landing to a via (~50 ps), the package lead frame length should be less than ~200 ps.

12.3.2. Package Capacitance

The maximum pac kage pin capacitance is a fu nction of the Inp ut/Output capac itan ce of the I/O

transceiver. The I/O Buffer specification requires the total of the package capacitance, output

driver, input receiver and ESD structures, as seen from the pin, to be less than 10 pF. Thus, the

larger the I/O transceiver capacitance, the smaller the allowable package capacitance.

12.4. REF8N NETWORK

The Ref8N network shown in Figure 12-15, which represents an eight-node reference network

(hence the name Ref8N), is used to characterize I/O drivers’ behavior into a known environ-

ment. This network is not a worst case, but a representati ve sample of a typical system environ-

ment. A SPICE deck of the network is also given.

12-25

GTL+ INTERFACE SPECIFICATION

Figure 12-15. Ref8N Topology

3.1 in.

1.5 volts

3.1 in.

1.8 nS/ft.

2.2 nS/ft.

0.5 in.

2.2 in.

3.1 in.

2.2 nS/ft

2.2 in.

2.2 nS/ft

2.2 in.

2.2 nS/ft.

72 ohms

2 pF

1.5 volts

42 ohms

1.8nS/ft.

0.5 in.

72 ohms

0.9 in.

2.4 nS/ft.

50 ohms

0.25 in.

2.4 nS/ft.

50 ohms

0.25 in.

42 ohms 2 pF

4 pF

6.5 pF

6.5 pF 6.5 pF

6.5 pF

4 pF

2.4 nS/ft.

50 ohms

0.25 in.

2.4 nS/ft.

50 ohms

0.25 in.

2.1nS/ft.

40 ohms

0.07 in.

1.4nS/ft.

66 ohms

0.105 in.

2.1nS/ft.

40 ohms

0.07 in.

1.4nS/ft.

66 ohms

0.105 in.

2.1nS/ft.

40 ohms

0.07 in.

1.4nS/ft.

66 ohms

0.105 in.

2.1nS/ft.

40 ohms

0.07 in.

1.4nS/ft.

66 ohms

0.105 in.

0.9 in.

0.9 in.0.9 in.

0.9 in.

1.02 nS/ft.

200 ohms

0.10 in.

1.02 nS/ft.

200 ohms

0.10 in.

1.02 nS/ft.

200 ohms

0.10 in.

1.02 nS/ft.

200 ohms

0.10 in.

2.4nS/ft.

75 ohms

2.4nS/ft.

75 ohms 2.4nS/ft.

75 ohms

2.4nS/ft.

75 ohms

3.08nS/ft.

42 ohms

3.08nS/ft.

42 ohms 3.08nS/ft.

42 ohms

3.08nS/ft.

42 ohms

REF8N Topology:

Plac e ASIC driver

to be tested here Replace with ASIC pkg model

12-26

GTL+ INTERFACE SPECIFICATION

12.4.1. Ref8N HSPICE Netlist

$REF8N, Rev 1.1

Vpu vpu GND DC(vtt)

rterm PU1 vpu (R=42)$ Pull-up termination resistance

crterm PU1 vpu 2PF $ Pull-up termination capacitance

TPU PU1 0 line1 0 Z0=72 TD=.075NS$ PCB link terminator to load 1

X1 line1 load1 socket$ Socket model

T1 load1 0 load1a 0 Z0=42 TD=230PS $ CPU package model

T2 load1a 0 CPU_1 0 Z0=200 TD=8.5PS$ Bondwire

CCPU_1 CPU_1 0 4PF $ CPU input capacitance

T3 line1 0 line2 0 Z0=72 TD=568PS$ PCB trace between packages

x2 line2 load2 socket$ Socket model

T4 load2 0 load2a 0 Z0=42 TD= 230ps$ CPU worst case package

T5 load2a 0 p6_2 0 Z0=200 TD=8.5ps $ Bondwire

CCPU_2 p6_2 0 4pf $ CPU input capacitance

T6 line2 0 line3 0 Z0=72 TD=568ps$ PCB trace between packages

T7 line3 0 load3 0 Z0=50 TD=50ps $ PCB trace from via to landing pad

T8 load3 0 asic_1 0 Z0=75 TD=180PS $ ASIC package

CASIC_1 asic_1 0 6.5PF$ ASIC input capacitance (die C)

T9 line3 0 line4 0 Z0=72 TD=403PS$ PCB trace between packages

T10 line4 0 load4 0 Z0=50 TD=50PS$ PCB trace from via to landing pad

T11 load4 0 asic_2 0 Z0=75 TD=180PS$ ASIC package

CASIC_2 asic_2 0 6.5PF$ ASIC input capacitance (die C)

T12 line4 0 line5 0 Z0=72 TD=403PS$ PCB trace between packages

T13 line5 0 load5 0 Z0=50 TD=50PS$ PCB trace from via to landing pad

T14 load5 0 asic_3 0 Z0=75 TD=180PS$ Replace these 2 lines

CASIC_3 asic_3 0 6.5PF$ with the equivalent model

$ for your package. (This model

$ should include the package

$ pin, package trace, bond wire and

$ any die capacitance that is not

$ already included in your driver

$ model.)

12-27

GTL+ INTERFACE SPECIFICATION

T15 line5 0 line6 0 Z0=72 TD=403PS$ PCB trace between packages

T16 line6 0 load6 0 Z0=50 TD=50PS$ PCB trace from via to landing pad

T17 load6 0 asic_4 0 Z0=75 TD=180PS$ ASIC package

CASIC_4 asic_4 0 6.5PF$ ASIC input capacitance

T18 line6 0 line7 0 Z0=72 TD=403PS $ PCB trace between packages

X3 line7 load7 socket$ Socket model

T19 load7 0 load7a 0 Z0=42 TD=230PS$ CPU worst case package

T20 load7a 0 p6_3 0 Z0=200 TD=8.5PS$ Bondwire

CCPU_3 p6_3 0 4PF $ CPU input capacitance

T21 line7 0 line8 0 Z0=72 TD=568PS $ PCB trace between packages

X4 line8 load8 socket $ Socket model

T22 load8 0 load8a 0 Z0=42 TD=230PS$ CPU worst case package

T23 load8a 0 p6_4 0 Z0=200 TD=8.5PS$ Bondwire

CCPU_4 p6_4 0 4PF $ CPU input capacitance

T24 line8 0 R_TERM 0 Z0=72 TD=75PS$ PCB trace to termination resistor

Rterm1 R_TERM vpu (R=42)$ Pull-up termination resistance

CRTERM1 R_TERM vpu (C=2PF)$ Pull-up termination capacitance

Rout bond asic_3.001

.subckt socket in out$ Socket model

TX out 0 jim 0 Z0=40 TD=12.25PS

ty jim 0 in 0 Z0=66 TD=12.25ps

.ENDS

3.3V Tolerant Signal

Quality Specifications

13-1

CHAPTER 13

3.3V TOLERANT SIGNAL QUALITY

SPECIFICATIONS

The signals that are 3.3V tolerant sho uld also meet signal quality specif ications to guarantee that

the components read data properly and to ensure that incoming signals do not affect the long

term reliability of the component. There are three signal quality parameters defined for the 3.3V

tolerant signals. They are Overshoot /Undershoot, Ring back and Settling Limi t. All three signal

quality parameters are shown in Figure 13-1. The Pentium® Pro Processor I/O Buffer Mod-

els—IBIS Format (on world wide web page www. intel.com) contain model s for simulating 3.3 V

tolerant signal distribution.

13.1. OVERSHOOT/UNDERSHOOT GUIDELINES

Overshoot (or undershoot) is the absolute value of the maximum voltage allowed above the

nominal high voltage or below VSS. The overshoot/undersh oot guideline limits transitions b e-

yond VCCP or VSS due to the fast signal edge rates. See Figure 13-1. The p rocessor can be dam-

aged by repeated overshoot events on 3.3V tolerant buffers if the charge is large enough (i.e. if

the overshoot is great enough). However, excessive ringback is the dominant harmful effect re-

sulting from overshoot or undershoot (i.e. violating the overshoot/undershoot guideline will

make satisfying the ringback specification difficult). The overshoot/undershoot guideline is

0.8V and assumes the absence of dio des on the input. These guidelines should be verified in sim-

ulations without the on-chip ESD protection diodes present because the diodes will begin

clamping t he 3 .3V t o le rant s i gnals b eginning at app rox imately 1. 5V above V CCP and 0.5V be-

low VSS. If signals are not reaching the clamping voltage, then this is not an issue. A system

should not rely on the diod es for overshoot/undershoot p rotection as th is will negatively affect

the life of the components and make meeting the ringback specification very difficult.

13-2

3.3V TOLERANT SIGNAL QUALITY SPECIFICATIONS

13.2. RINGBACK SPECIFICATION

Ringback refers to the amount of reflection seen after a signal has undergone a transition. The

ringback specif i cation is the voltage that the signal rings back to after achieving its farthest ex-

cursion. See Figure 13-1 for an illustration of ringback. Excessive ringback can cause false sig-

nal detection or extend the propaga tion delay. The ring back specif ication applies to the inp ut pin

of each receiving agent. Violations of the signal Ringback specification are not allowed under

any circumstances.

Ringback can b e simulated with or without the in put protection d io des that can be added to the

input buffer model. However, signals that reach the clamping voltage should be evaluated fur-

ther. See Table 13-1 for the signal ringback specifications for Non-GTL+ signals.

Figure 13-1. 3.3V Tolerant Signal Overshoot/Undershoot and Ringback

Tab le 13-1 . Signal Ringback Specifications

Transition Maximum Ringback (with input diodes present)

0→12.5V

1→00.8V

Se ttling Lim it

Rising-edge

Ringback Falling-edge

Ringback

Undershoot

Overshoot

Time

3.3V

Settling Limit

13-3

3.3V TOLERANT SIGNAL QUALITY SPECIFICATIONS

13.3. SETTLING LIMIT GUIDELINE

A Settling Limit defines the maximum amount of ringing at the recei ving pin that a signal must

be limited to before its next transition. The amount allowed is 10% of the total signal swing

(VHI-VLO) above and b elow its final value. A signal should b e within the settl ing limit s of its

final value, when either in its hig h state of low state, before it transitions again.

Signals that are not within their settling limit before transitioning are at risk of unwanted oscil-

lations which could jeopardize signal integrity . Simulations to verify Settling Limit may be done

either with or without the input protection diodes present. V iolation of the Settling Limit guide-

line is acceptable if simulations of 5-10 successive transitio ns do not show the amplitude of the

ringing in creas ing in the subsequent transitions.

Thermal

Specifications

14-1

CHAPTER 14

THERMAL SPECIFICATIONS

Table 11- 5 specifies the Pentium Pro processor po wer dissipation. It is high ly recommended that

systems be designed to dissipate at least 40W per processor to allow the same design to accom-

modate higher frequency or otherwise enhanced members of the Pentium Pro family.

14.1. THERMAL PARAMETERS

This section defines the terms used for Pentium Pro processor thermal analysis.

14.1.1. Ambient Temperature

Ambient temperature, TA, is the temperature of the ambient air surrounding the package. In a

system environment, ambient temperature is the temp erature of the air upstream fro m the pack-

age and in its close v icinity; or in an acti v e co oling system, it is the inlet air to the active cooling

device.

14.1.2. Case Temperature

To ensure functionality a nd reliability, the Pe ntium Pro processor is spec ifie d for proper op-

eration whe n TC (case temperature) is within the specified range in Table 11-5. Special care

is required when measuring the case temperature to ensure an accurate temperature measure-

ment. Thermocoup les are often used to measure TC. Befor e any temperature measurem ents, the

thermocouples must be calibrated. When measuring the temperature of a surface which is

at a different temperature from the surrounding ambient air, errors could be introduced in

the measurements if not handled properly. The measurement errors could be due to having a

poor thermal contact between the thermocoup le junction and the surface, heat loss b y radiation,

or by conductio n throug h thermocoup le leads. To minimize the measuremen t errors, the follow-

ing approach is recommended:

•Use a 35 gauge K-type thermocouple or equivalent.

•Attach the thermocouple bead or junction to the package top surface at a location corre-

sponding to the cente r of t he P ent i um P ro pro cess or die. (L ocati on A in Figu re 1 4-1 ) Usi ng

the center of the Pentium Pro processor die gives a more accurate measurement and less

variation as the boundary condition changes.

•Attach the thermocouple bead or junction at a 90° angle by an adhesive bond (such as

thermal grease or heat-tolerant tape) to the package top surface as shown in Figure 14-2.

When a heat sink is attached, a hole should be drilled through the heat sink to allow

probing the Pentium Pro processor package above the center of the processor die. The hole

diameter should be no larger than 0.150.”

14-2

THERMAL SPECIFICATIONS

Figure 14-1. Location of Case Temperature Measurement (Top-Side View)

Figure 14-2. Thermocouple Placement

2.46”

2.66”

1.23”

0.80”

CPU Die L2 Cache Die

Heat Spreader

Ceramic Package

AHeat Sink Thermal Interface

Material

Ceramic Package

Probe

14-3

THERMAL SPECIFICATIONS

14.1.3. Thermal Resistance

The thermal resistance value for the case-to-ambient, ΘCA, is used as a measure of the cooling

solution’s thermal performance. ΘCA is comprised of the case-to-sink thermal resistance, ΘCS,

and the sink-to-ambient thermal resistance, ΘSA. ΘCS is a measure of the thermal resistance

along the heat flow path from the top of the IC package to the bottom of the thermal cooling

solution. This value is strongly dependent on the material, conductivity, and thickness of the

thermal interface used. ΘSA is a measure of the thermal resistance from the top of the cooling

solution to the local ambient air. ΘSA valu es depen d on th e materi al, thermal conductivity, and

geometry of the therm a l cooling solution as well as on the airflow rates.

The param eters are defined by the following r elationships (See also Fi gure 14-3):

ΘCA = (TC - TA) / PD

ΘCA = ΘCS +ΘSA

Where: ΘCA = Case-to-Ambient thermal resistance (°C/W)

ΘCS = Case-to-Sink thermal resistance (°C/W)

ΘSA = Sink-to-Ambient thermal resistance (°C/W)

TC = Case temperature at the defined location (°C)

TA = Ambient temperature (°C)

PD = Device power dissipation (W)

Figure 14-3. Thermal Resistance Relationships

Ambient Air

ΘSA

Heat Sink Thermal Interface

Material

Heat Spreader

Ceramic Package

14-4

THERMAL SPECIFICATIONS

14.2. THERMAL ANALYSIS

Table 14- 1 below lists the case-to-ambient thermal resistances of the Pen tium Pro processor fo r

different air flow rates and heat sink heights.

Table 14-2 shows the TA required given a 29.2W processor (150 MHz, 256K cache), and a TC

of 85°C. Table 14-3 shows the TA required assuming a 40W processor. Table 14-2 and Table

14-3 were pr oduced by using the relationships of Section 14.1.3. , “Thermal R esistance” and the

data of Table 14-1.

NOTES:

1. All data taken at sea level. For altitudes above sea level, it is recommended that a derating factor of

1°C/1000 feet be used.

2. Heat Sink: 2.235” square omni-directional pin, aluminum heat sink with a pin thickness of 0.085”, a pin

spacing of 0.13” and a base thickness of 0.15”. See Figure 14-4. A thin layer of thermal grease (Thermo-

set TC208 with thermal conductivity of 1.2W/m-°K) was used as the interface material between the heat

sink and the package.

Table 14-1. Case-To-Ambient Thermal Resistance

ΘCA [°C/W] vs. Airflow [Li near Feet per Minute] and Heat Sink Height1

Airflow (LFM): 100 200 400 600 800 1000

With 0.5” Heat Sink 2— 3.16 2.04 1.66 1.41 1.29

With 1.0” Heat Sink 22.55 1.66 1.08 0.94 0.80 0.76

With 1.5” Heat Sink 21.66 1.31 0.90 0.78 0.71 0.67

With 2.0” Heat Sink 21.47 1.23 0.87 0.75 0.69 0.65

Figure 14-4. Analysis Heat Sink Dimensions

0.085” 0.130”

Height

0.150”

2.235”

14-5

THERMAL SPECIFICATIONS

NOTES:

1. At sea level. See Table 14-1.

2. Heat sink design as in Table 14-1.

NOTES:

1. At sea level. See Table 14-1.

2. Heat sink design as in Table 14-1.

Table 14-2. Ambient Temperatures Required at Heat Sink for 29.2W and 85° Case

TA vs. Airflow [Linear Feet per Minute] and Heat Sink Height1

Airflow (LFM): 100 2 00 400 600 800 1000

With 0.5” Heat Sink 2—-825364347

With 1.0” Heat Sink 210 36 53 57 61 62

With 1.5” Heat Sink 236 46 58 62 64 65

With 2.0” Heat Sink 242 49 59 63 64 66

Table 14-3. Ambient Temperatures Required at Heat Sink for 40W and 85° Case

TA vs. Airflow [Linear Feet per Minute] and Heat Sink Height1

Airflow (LFM): 100 2 00 400 600 800 1000

With 0.5” Heat Sink 2—— 3 182833

With 1.0” Heat Sink 2—1841475354

With 1.5” Heat Sink 218 32 49 53 56 58

With 2.0” Heat Sink 226 35 50 55 57 59

Mechanical

Specifications

15-1

CHAPTER 15

MECHANICAL SPECIFICATIONS

The Pentium Pro processor is packaged in a modified staggered 387 pin ceramic pin grid array

(SPGA) with a gold plated Copper-Tungsten (CuW) heat spreader on top. Mechanical specifi-

cations and the pin assignments follow.

15.1. DIMENSIONS

The mechanical specifications are provided in Table 15-1. Figure 15-1 shows the bottom and

side views with package dimensions for the Pentium Pro processor and Figure 15-2 shows the

top vi ew with dimensio ns. Figure 15-3 is the top vie w of th e Pentium P ro processor with V CCP,

VCCS, VCC5an d VSS lo catio ns sh own. Be sure to read Chapter 17, OverDrive® Processor

Socket Specification for the mechanical constraints for the OverDrive processor. Also, in-

vesti gate th e tools th at wil l be u sed for deb ug be f ore layin g out th e system . Intel ’ s tool s ar e

described in Chapter 16, Tools.

15-2

MECHANICAL SPECIFICATIONS

Figure 15-1. Package Dimensions-Bottom View

15-3

MECHANICAL SPECIFICATIONS

Figure 15-2. Top View of Keep Out Zones and Heat Spreader

Table 15-1. Pentium® Pro Processor Package

Parameter Value

Package Type PGA

Total Pins 387

Pin Array Modified Staggered

Package Size 2.66” x 2.46” (7.7 6cm x 6.25cm)

Heat Spreader Size 2.225” x 1.3” x 0.04” (5.65cm x 3.3cm x 0.1cm)

Weight 90 grams

1.30 ± 0.10"

2.225 ± 0.10"

2.66 ± 0.10"

0.195"

0.380"

1.025"

0.380"

2.46 ± 0.10"

HEAT SPREADER

Keep Out Zon es

15-4

MECHANICAL SPECIFICATIONS

15.2. PINOUT

Table 15-2 is the pin listing in pin number order. Table 15-3 is the pin listing in pin name order.

Please see S ection 11.8., “Signal Groups” to determine a s ignal’s I/O type. Bus signals are de-

scribed in Appendix A and the other pins are described in Chapter 11, Electrical Specifications

and in Table 11-2.

Figure 15-3. Pentium® Pro Processor Top View with Power Pin Locations

Top View

46 44 42 40 38 36 34 32 30 28 26 24 22 20 18 16 14 12 10 8 6 4 2

47 45 43 41 39 3 7 35 33 31 29 27 25 23 21 19 17 15 13 11 9 7 5 3 1

VccS

VccP

Vss

Vcc5

Other

47 45 43 41 39 3 7 35 33 31 29 27 25 23 21 19 17 15 13 11 9 7 5 3 1

2H2O

15-5

MECHANICAL SPECIFICATIONS

Table 15-2. Pin Listing in Pin # Order

Pin # Signal Name Pin # Signal Name Pin # Signal Name

A1 VREF0 B32 VCCP E7 A33#

A3 STPCLK# B36 VSS E9 A34#

A5 TCK B40 VCCP E39 D22#

A7 TRST# B42 VSS E41 D23#

A9 IGNNE# B44 VCCP E43 D25#

A11 A20M# B46 VSS E45 D24#

A13 TDI C1 A35# E47 D26#

A15 FLUSH# C3 IERR# F2 VCCP

A17 THERMTRIP# C5 BERR# F4 VSS

A19 BCLK C7 VREF1 F6 VCCP

A21 RESERVED C9 FRCERR F8 VSS

A23 TESTHI C11 INIT# F40 VSS

A25 TESTHI C13 TDO F42 VCCP

A27 D1# C15 TMS F44 VSS

A29 D3# C17 FERR# F46 VCCP

A31 D5# C19 PLL1 G1 A22#

A33 D8# C21 TESTLO G3 A24#

A35 D9# C23 PLL2 G5 A27#

A37 D14# C25 D0# G7 A26#

A39 D10# C27 D2# G9 A31#

A41 D11# C29 D4# G39 D27#

A43 D13# C31 D6# G41 D29#

A45 D16# C33 D7# G43 D30#

A47 VREF4 C35 D12# G45 D28#

B2 CPUPRES# C37 D15# G47 D31#

B4 VCCP C39 D17# J1 A19#

B6 VSS C41 D20# J3 A21#

B8 VCCP C43 D18# J5 A20#

B12 VSS C45 D19# J7 A23#

B16 VCCP C47 D21# J9 A28#

B20 VSS E1 A29# J39 D32#

B24 VCCP E3 A30# J41 D35#

B28 VSS E5 A32# J43 D38#

15-6

MECHANICAL SPECIFICATIONS

J45 D33# P8 VSS U1 AP0#

J47 D34# P40 VSS U3 RSP#

K2 VSS P42 VCCP U5 BPRI#

K4 VCCP P44 VSS U7 BNR#

K6 VSS P46 VCCP U9 BR3#

K8 VSS Q1 A9# U39 DEP7#

K40 VSS Q3 A7# U41 VREF6

K42 VSS Q5 A5# U43 D60#

K44 VCCP Q7 A8# U45 D56#

K46 VSS Q9 A10# U47 D55#

L1 RESERVED Q39 D51# W1 SMI#

L3 A16# Q41 D52# W3 BR1#

L5 A15# Q43 D49# W5 REQ4#

L7 A18# Q45 D48# W7 REQ1#

L9 A25# Q47 D46# W9 REQ0#

L39 D37# S1 A6# W39 DEP2#

L41 D40# S3 A4# W41 DEP4#

L43 D43# S5 A3# W43 D63#

L45 D36# S7 VREF2 W45 D61#

L47 D39# S9 AP1# W47 D58#

N1 A12# S39 D59# X2 VSS

N3 A14# S41 D57# X4 VSS

N5 A11# S43 D54# X6 VCCP

N7 A13# S45 D53# X8 VSS

N9 A17# S47 D50# X40 VSS

N39 D44# T2 VSS X42 VCCP

N41 D45# T4 VCCP X44 VSS

N43 D47# T6 VSS X46 VSS

N45 D42# T8 VSS Y1 REQ3#

N47 D41# T40 VSS Y3 REQ2#

P2 VCCP T42 VSS Y5 DEFER#

P4 VSS T44 VCCP Y7 VREF3

P6 VCCP T46 VSS Y9 TRDY#

Table 15-2. Pin Listing in Pin # Order (Contd.)

Pin # Signal Name Pin # Signal Name Pin # Signal Name

15-7

MECHANICAL SPECIFICATIONS

Y39 PRDY# AE1 RESERVED AJ39 VSS

Y41 RESET# AE3 ADS# AJ41 VCCP

Y43 DEP1# AE5 RS1# AJ43 VSS

Y45 DEP6# AE7 RS2# AJ45 VCCP

Y47 D62# AE9 AERR# AJ47 VSS

AA1 BR2# AE39 TESTHI AL1 VCCP

AA3 DRDY# AE41 PICD1 AL3 VSS

AA5 DBSY# AE43 BP2# AL5 VCCP

AA7 HITM# AE45 RESERVED AL7 VSS

AA9 LOCK# AE47 VREF5 AL9 VCCP

AA39 BPM1# AF2 VSS AL39 VCCP

AA41 PICD0 AF4 VSS AL41 VSS

AA43 PICCLK AF6 VSS AL43 VCCP

AA45 PREQ# AF8 VSS AL45 VSS

AA47 DEP5# AF40 VSS AL47 VCCP

AB2 VSS AF42 VSS AN1 VSS

AB4 VCCP AF44 VSS AN3 VCCP

AB6 VSS AF46 VSS AN5 VSS

AB8 VSS AG1 VCC5 AN7 VCCP

AB40 VSS AG3 UP# AN9 VSS

AB42 VSS AG5 RESERVED AN39 VSS

AB44 VCCP AG7 PWRGOOD AN41 VCCP

AB46 VSS AG9 RESERVED AN43 VSS

AC1 RESERVED AG39 RESERVED AN45 VCCP

AC3 HIT# AG41 LINT1/NMI AN47 VSS

AC5 BR0# AG43 LINT0/INTR AQ1 VCCP

AC7 RP# AG45 VREF7 AQ3 VSS

AC9 RS0# AG47 RESERVED AQ5 VCCP

AC39 BP3# AJ1 VSS AQ7 VSS

AC41 BPM0# AJ3 VCCP AQ9 VCCP

AC43 BINIT# AJ5 VSS AQ39 VCCP

AC45 DEP0# AJ7 VCCP AQ41 VSS

AC47 DEP3# AJ9 VSS AQ43 VCCP

Table 15-2. Pin Listing in Pin # Order (Contd.)

Pin # Signal Name Pin # Signal Name Pin # Signal Name

15-8

MECHANICAL SPECIFICATIONS

AQ45 VSS AW45 VCCS BA37 TESTLO

AQ47 VCCP AW47 VSS BA39 VSS

AS1 VID0 AY1 VCCS BA41 VCCS

AS3 VID1 AY3 VCCS BA43 VSS

AS5 VID2 AY5 VCCS BA45 VCCS

AS7 VID3 AY7 VCCS BA47 VSS

AS9 RESERVED AY9 VCCS BC1 VSS

AS39 TESTLO AY39 VCCS BC3 VSS

AS41 TESTLO AY41 VCCS BC5 VSS

AS43 TESTLO AY43 VCCS BC7 VSS

AS45 TESTLO AY45 VCCS BC9 VSS

AS47 RESERVED AY47 VCCS BC11 RESERVED

AU1 VCCS BA1 VSS BC13 TESTLO

AU3 VSS BA3 VCCS BC15 TESTLO

AU5 VCCS BA5 VSS BC17 VSS

AU7 VSS BA7 VCCS BC19 VCCS

AU9 VCCS BA9 VSS BC21 VSS

AU39 VCCS BA11 RESERVED BC23 VCCS

AU41 VSS BA13 TESTLO BC25 VSS

AU43 VCCS BA15 TESTLO BC27 VCCS

AU45 VSS BA17 VCCP BC29 VSS

AU47 VCCS BA19 VSS BC31 VCCS

AW1 VSS BA21 VCCP BC33 TESTLO

AW3 VCCS BA23 VSS BC35 RESERVED

AW5 VSS BA25 VCCP BC37 TESTLO

AW7 VCCS BA27 VSS BC39 VSS

AW9 VSS BA29 VCCP BC41 VSS

AW39 VSS BA31 VSS BC43 VSS

AW41 VCCS BA33 TESTLO BC45 VSS

AW43 VSS BA35 RESERVED BC47 VSS

Table 15-2. Pin Listing in Pin # Order (Contd.)

Pin # Signal Name Pin # Signal Name Pin # Signal Name

15-9

MECHANICAL SPECIFICATIONS

Table 15-3. Pin Listing in Alphabetic Order

Signal Name Pin # Signal Name Pin # Signal Name Pin #

A3# S5 A35# C1 D14# A37

A4# S3 ADS# AE3 D15# C37

A5# Q5 AERR# AE9 D16# A45

A6# S1 AP0# U1 D17# C39

A7# Q3 AP1# S9 D18# C43

A8# Q7 BCLK A19 D19# C45

A9# Q1 BERR# C5 D20# C41

A10# Q9 BINIT# AC43 D21# C47

A11# N5 BNR# U7 D22# E39

A12# N1 BP2# AE43 D23# E41

A13# N7 BP3# AC39 D24# E45

A14# N3 BPM0# AC41 D25# E43

A15# L5 BPM1# AA39 D26# E47

A16# L3 BPRI# U5 D27# G39

A17# N9 BR0# AC5 D28# G45

A18# L7 BR1# W3 D29# G41

A19# J1 BR2# AA1 D30# G43

A20# J5 BR3# U9 D31# G47

A20M# A11 CPUPRES# B2 D32# J39

A21# J3 D0# C25 D33# J45

A22# G1 D1# A27 D34# J47

A23# J7 D2# C27 D35# J41

A24# G3 D3# A29 D36# L45

A25# L9 D4# C29 D37# L39

A26# G7 D5# A31 D38# J43

A27# G5 D6# C31 D39# L47

A28# J9 D7# C33 D40# L41

A29# E1 D8# A33 D41# N47

A30# E3 D9# A35 D42# N45

A31# G9 D10# A39 D43# L43

A32# E5 D11# A41 D44# N39

A33# E7 D12# C35 D45# N41

A34# E9 D13# A43 D46# Q47

15-10

MECHANICAL SPECIFICATIONS

D47# N43 IERR# C3 RESERVED BC35

D48# Q45 IGNNE# A9 RESET# Y41

D49# Q43 INIT# C11 RP# AC7

D50# S47 LINT0/INTR AG43 RS0# AC9

D51# Q39 LINT1/NMI AG41 RS1# AE5

D52# Q41 LOCK# AA9 RS2# AE7

D53# S45 PICCLK AA43 RSP# U3

D54# S43 PICD0 AA41 SMI# W1

D55# U47 PICD1 AE41 STPCLK# A3

D56# U45 PLL1 C19 TCK A5

D57# S41 PLL2 C23 TDI A13

D58# W47 PRDY# Y39 TDO C13

D59# S39 PREQ# AA45 TESTHI A23

D60# U43 PWRGOOD AG7 TESTHI A25

D61# W45 REQ0# W9 TESTHI AE39

D62# Y47 REQ1# W7 TESTLO C21

D63# W43 REQ2# Y3 TESTLO AS39

DBSY# AA5 REQ3# Y1 TESTLO AS41

DEFER# Y5 REQ4# W5 TESTLO AS43

DEP0# AC45 RESERVED A21 TESTLO AS45

DEP1# Y43 RESERVED L1 TESTLO BA13

DEP2# W39 RESERVED AC1 TESTLO BA15

DEP3# AC47 RESERVED AE1 TESTLO BA33

DEP4# W41 RESERVED AE45 TESTLO BA37

DEP5# AA47 RESERVED AG5 TESTLO BC13

DEP6# Y45 RESERVED AG9 TESTLO BC15

DEP7# U39 RESERVED AG39 TESTLO BC33

DRDY# AA3 RESERVED AG47 TESTLO BC37

FERR# C17 RESERVED AS9 THERMTRIP# A17

FLUSH# A15 RESERVED AS47 TMS C15

FRCERR C9 RESERVED BA11 TRDY# Y9

HIT# AC3 RESERVED BA35 TRST# A7

HITM# AA7 RESERVED BC11 UP# AG3

Table 15-3. Pin Listing in Alphabetic Order (Contd.)

Signal Name Pin # Signal Name Pin # Signal Name Pin #

15-11

MECHANICAL SPECIFICATIONS

VCC5 AG1 VCCP AL47 VCCS AY45

VCCP B4 VCCP AN3 VCCS AY47

VCCP B8 VCCP AN7 VCCS BA3

VCCP B16 VCCP AN41 VCCS BA7

VCCP B24 VCCP AN45 VCCS BA41

VCCP B32 VCCP AQ1 VCCS BA45

VCCP B40 VCCP AQ5 VCCS BC19

VCCP B44 VCCP AQ9 VCCS BC23

VCCP F2 VCCP AQ39 VCCS BC27

VCCP F6 VCCP AQ43 VCCS BC31

VCCP F42 VCCP AQ47 VID0 AS1

VCCP F46 VCCP BA17 VID1 AS3

VCCP K4 VCCP BA21 VID2 AS5

VCCP K44 VCCP BA25 VID3 AS7

VCCP P2 VCCP BA29 VREF0 A1

VCCP P6 VCCS AU1 VREF1 C7

VCCP P42 VCCS AU5 VREF2 S7

VCCP P46 VCCS AU9 VREF3 Y7

VCCP T4 VCCS AU39 VREF4 A47

VCCP T44 VCCS AU43 VREF5 AE47

VCCP X6 VCCS AU47 VREF6 U41

VCCP X42 VCCS AW3 VREF7 AG45

VCCP AB4 VCCS AW7 VSS B6

VCCP AB44 VCCS AW41 VSS B12

VCCP AJ3 VCCS AW45 VSS B20

VCCP AJ7 VCCS AY1 VSS B28

VCCP AJ41 VCCS AY3 VSS B36

VCCP AJ45 VCCS AY5 VSS B42

VCCP AL1 VCCS AY7 VSS B46

VCCP AL5 VCCS AY9 VSS F4

VCCP AL9 VCCS AY39 VSS F8

VCCP AL39 VCCS AY41 VSS F40

VCCP AL43 VCCS AY43 VSS F44

Table 15-3. Pin Listing in Alphabetic Order (Contd.)

Signal Name Pin # Signal Name Pin # Signal Name Pin #

15-12

MECHANICAL SPECIFICATIONS

VSS K2 VSS AF6 VSS AW1

VSS K6 VSS AF8 VSS AW5

VSS K8 VSS AF40 VSS AW9

VSS K40 VSS AF42 VSS AW39

VSS K42 VSS AF44 VSS AW43

VSS K46 VSS AF46 VSS AW47

VSS P4 VSS AJ1 VSS BA1

VSS P8 VSS AJ5 VSS BA5

VSS P40 VSS AJ9 VSS BA9

VSS P44 VSS AJ39 VSS BA19

VSS T2 VSS AJ43 VSS BA23

VSS T6 VSS AJ47 VSS BA27

VSS T8 VSS AL3 VSS BA31

VSS T40 VSS AL7 VSS BA39

VSS T42 VSS AL41 VSS BA43

VSS T46 VSS AL45 VSS BA47

VSS X2 VSS AN1 VSS BC1

VSS X4 VSS AN5 VSS BC3

VSS X8 VSS AN9 VSS BC5

VSS X40 VSS AN39 VSS BC7

VSS X44 VSS AN43 VSS BC9

VSS X46 VSS AN47 VSS BC17

VSS AB2 VSS AQ3 VSS BC21

VSS AB6 VSS AQ7 VSS BC25

VSS AB8 VSS AQ41 VSS BC29

VSS AB40 VSS AQ45 VSS BC39

VSS AB42 VSS AU3 VSS BC41

VSS AB46 VSS AU7 VSS BC43

VSS AF2 VSS AU41 VSS BC45

VSS AF4 VSS AU45 VSS BC47

Table 15-3. Pin Listing in Alphabetic Order (Contd.)

Signal Name Pin # Signal Name Pin # Signal Name Pin #

Tools

16-1

CHAPTER 16

TOOLS

Incl uded he re is a discussion on the Pentium Pro processor I/O buff er models and a description

of the Intel recommended debug port implementation. A debug port is used to connect a debug

tool to a target system in order to provide run-time control over program execution, regis-

ter/memory/IO access and breakpoints. A variety of debug tools exist which provide run-time

control for th e Pentium Pro pro cessor; contact y our local Intel sales representative for a list of

tools vendors who support the Pentium Pro processor. For the discussion that follows, run-time

control tools will be referred to as In-Target Probes, or ITPs.

An ITP uses on-chip d eb ug features of the P entium P ro pro cessor to pro v ide pro gram e x ecuti on

control. Use of an ITP will not af fect the high speed operations of the CPU signals. This ensures

that the system can operate at full speed with an ITP attached.

This section describes the debug port as well as raising a number of technical issues that must

be taken into account when considering including an ITP in your Pentium Pro processor debug

strategy.

16.1. ANALOG MODELING

The Pentium Pro processor I/O buffer models are provided to allow simulation of the system

layout. Package and socket parasitics for each pin ar e provided along with the I/O b uffer mo dels.

A slow and a fast corner model are provided for both the GTL+ buffer and the CMOS buffer.

The fast model is useful for signal integrity analysis, while the slow model is useful for

maximu m f lig h t time calcu latio n s. Th ese models are av ailable in IB I S (I/O Buffer Inf o rm a-

tion Speci fication) forma t from World Wide Web site www.intel.com.

16.2. IN-TARGET PROBE FOR THE PENTIUM® PRO

PR OCE SSOR (ITP )

An In-Target Probe (ITP) for the Pentium Pro processor is a debug tool which allows access to

on-chip debug features via a small por t on the syste m board call ed the deb ug po rt. An ITP com-

municates to the Pentium Pro processor throu gh the deb ug port using a combination of hard ware

and soft ware. The software is typically an ap pl icat io n running on a host PC. Th e h a rdw a re con-

sists of a board in the host PC connected to the signals which make up the Pentium Pro proces-

sor's deb ug interf ace. Due to the nature of an ITP, the Pentium Pro processor may be controlled

without affecting any high speed signals. This ensures that the system can operate at full speed

with an ITP attached. Intel uses an ITP for internal debug and system validation and recom-

mends that all Pentium Pro processor-based system designs include a debug port.

16-2

TOOLS

16.2.1. Primary Function

The primary function of an ITP is to provide a control and query interface fo r up to four Pentium

Pro processor s in one cluster. With an IT P you can control progr am e x ecution and ha v e the abil-

ity to access processor re gisters, sy stem mem ory and I /O. Thus, yo u can start an d stop pr ogr am

execution using a variety of breakpoints, single-step your program at the assembly code level,

as well as read and write registers, memory and I/O.

16.2.2. Debug Port Connector Description

An ITP will connect to the P enti um Pro proces sor system thro ugh the debug port. Intel recom-

mended connectors, to mate an ITP cable with the debug port on your board, are available in

either a vertical or right-angle configuration. Both configurations fit into the same bo ard foot-

print. The connectors are manufactured by AMP Incorporated and are in their AMPMODU

System 50 line. Following are the AMP part numbers for the two connectors:

•Amp 30-pin shrouded vertical header: 104068-3

•Amp 30-pin shrouded right-angle header: 104069-5

NOTE

These are hi gh dens ity th rough h ole con nectors wi th pins on 0.05 0" b y 0.100 "

centers. Do not con fus e t hese wit h th e mor e common 0.100" by 0.10 0" center

headers.

16.2.3. Debug Port Signal Descriptions

Table 16-1 describes the debug port signals and provides the pin assignment. The mechanical

pinout is shown in Section 16.2.5.2., “Debug Port Connector”.

Table 16-1. Debug Port Pinout

Name Pin Description

RESET# 1 Reset signal from MP cluster to ITP. See signal note 1

DBRESET# 3 Ope n drain output from ITP to the system; should be tied into system

reset circuitry. This allows the ITP to reset the entire target system. See

signal note 2

TCK 5 Boundary scan signal from ITP to MP cluster

TMS 7 Boundary scan signal from ITP to MP cluster

TDI 8 Signal from ITP to first component in boundary scan chain of MP cluster

POWERON 9 From target Vtt to ITP (through a resistor). See signal note 3

TDO 10 Signal from last component in boundary scan chain of MP cluster to ITP

16-3

TOOLS

16.2.4. Signal Notes

In general, all open drain GTL+ outputs from the system to the debug port must be placed at a

proper logic level, whether or not the debug port is installed. GTL+ signals from the Pentium

Pro processor system (RESET#, PRDY#) should be terminated at the debug port, as shown in

Figure 16-1.

DBINST# 11 Indicates to user system that the ITP is installed (from ITP GND). See

signal note 4

TRST# 12 Boundary sc an signal from ITP to MP cluster

BSEN# 14 ITP asserts BSEN# while using Boundary Scan

PREQ0# 16 PREQ# signal from ITP to CPU 0

NOTE: PREQ0# and PRDY0# should be connected to the Pentium® Pro

processor which is first (of up to 4) to receive the TDI signal from the

debug port; the others should follow in the order of their receipt of TDI

PRDY0# 18 PRDY# signal from CPU 0 to ITP

PREQ1# 20 PREQ# signal from ITP to CPU 1

PRDY1# 22 PRDY# signal from CPU 1 to ITP

PREQ2# 24 PREQ# signal from ITP to CPU 2

PRDY2# 26 PRDY# signal from CPU 2 to ITP

PREQ3# 28 PREQ# signal from ITP to CPU 3

PRDY3# 30 PRDY# signal from CPU 3 to ITP

GND 2, 4, 6, 13,

15, 17, 19,

21, 23, 25,

27, 29

Signal ground

Figure 16-1. GTL+ Signal Termination

Table 16-1. Debug Port Pinout (Contd.)

Name Pin Description

16-4

TOOLS

16.2.4.1. SIGNAL NOTE 1: RESET#, PRDYX#

RESET# and PRDY# are GTL+ signals th at come from the Pentium Pro processor system to the

debug port; they are not driven by an ITP from the debug port. Add ing inches of transmiss ion

line on to the RESET# or PRDY# signals after they are past the f inal Pentium Pro processor bus

load does not change the timing calculations for the Pentium Pro processor bus agents.

16.2.4.2. SIGNAL NOTE 2: DBRESET#

The usual implementation for DBRESET# is to connect it to the PWR_GD open drain signal on

the 82450GX PCIset as an OR input to initiate a system reset. In order for the DBRESET# signal

to work properly, it must actually reset the entire target system. The signal should be pulled up

with a resistor that will m eet two cons ideration s: (1) the sig nal must be able to meet Vol of the

system and (2) it must allow the signal to meet the specified rise time (suggestion: 240 ohms).

When asserted by an ITP, the DBRESET# signal will remain asserted long enough for the sys-

tem to recognize it and gen erate a reset. A larg e capacitance should no t be present on this signal

as it may not b e charged up w ithin the allotted time.

16.2.4.3. SIGNAL NOTE 3: POWERON

The PO WER ON input to the debug port has two functions. (1) It is used by an ITP to determine

when the system is powered up. (2) The voltage applied to POWERON is internally used to set

the GTL+ threshold (or reference) at 2/3 VTT in order to determine the GTL+ logic level.

16.2.4.4. SIGNAL NOTE 4: DBINST#

Certain target system s use the boundary scan chain for their o wn purpo ses, such as manufactur -

ing test of connectivity. DBINST# is used to alert target systems that an ITP has been installed

and may need to be active on the boundary scan chain. It should be provided with a weak pull

up resistor.

16.2.4.5. SIGNAL NOTE 5: TDO AND TDI

The TDO signal coming out of each Pentium Pro processor has a 25 ohm driver and should be

pulled up to 3.3V using a resistor value of approximately 240 ohms. NOTE: When designing

the circuitry to reroute the scan chain around empty Pen tium Pro processor sock ets, care should

be taken so that t he multiple TDO p ull-up resist ors d o not en d up in parallel (s ee Figure 16-4).

The TDI line coming out of the debug port should be pulled up to 3.3V to 10K ohms.

16.2.4.6. SIGNAL NOTE 6: PREQ#

The PREQ# signal should be pulled up to 3.3V through a 10K ohm resistor.

16-5

TOOLS

16.2.4.7. SIGNAL NOTE 7: TRST#

If the TRST# si gn al is con nect ed to t he 8 245 4GX, i t shoul d b e pul le d down through a 470 ohm

resistor.

16.2.4.8. SIGNAL NOTE 8: TCK

*WARNING: A significant number of target systems have signal integrity issues with the TCK

signal. TCK is a high s pee d s ignal and m u st be routed accord ing ly ; m ake sure to observe p o wer

and ground plane integrity for this signal. Follow the guidelines below and assure the quality of

the signal when beginning use of an ITP to debug your target.

Due to the number of loads on the TCK signal, special care should be taken when routing it.

Poor routing can lead to multiple clocking of some agents on the debug chain, usually on the

falling edge of TCK. This causes infor mation to be lost through the chain and can result in bad

commands being issued to some agents on the bus. There are two known good routing

schemes for the TCK signal: daisy chain and star. Systems using other TCK routing schemes,

particularly thos e with “T ” or “Y” c onfigu ratio ns whe re the t race from the sourc e to th e “T” is long ,

invite signal integrity problems.

If the signal is more easily routed as a dai sy ch ain then it is rec om me nde d that a pull-up re si sto r

from TCK to 3.3V be placed at the physically most distant node of the TCK route (see

Figure 16-2). T his re si sto r s hould be b etween 62 an d 150 Ohms, depending on th e run len gth of

the TCK trace. Use Table 16-2 to select a value:

Table 16-2. TCK Pull-Up Value

Run Length Resistor

0 - 12" 150 ohms

12 - 15" 120 ohms

15 - 18" 100 ohms

18 - 21" 82 ohms

> 21" 62 ohms

Figure 16-2. TCK with Daisy Chain Configuration

Pentium®

Pro Pentium

Pro

16-6

TOOLS

If the signal is more easily routed in a star conf iguration, each leg that is greater than 8" in length

should be terminated with a resistor v alue R, where: R = (62 ohms) x (the number of le gs greater

than 8 inches). If all legs are less than 8", terminate only the longest leg with a 62 ohm resistor.

If some legs are shorter than 8" and some are longer than 8", terminate the legs longer than 8"

using the for mula desc ribed abo v e and i gnore the legs short er than 8". Ther e should be no mo re

than 4 legs to the star. For example, in F igure 16-3, the star has three legs, where the resistor R

value is the same for each leg of the star: 3 x 62 = 186 ohms.

16.2.4.9. SIGNAL NOTE 9: TMS

TMS should be routed to all components in the boundary scan chain in a daisy chain conf igura-

tion. Follow the daisy chain guidelin es speci fied for TCK in Sectio n 16 .2.4.8., “Si gnal Note 8 :

TCK”.

Figure 16-3. TCK with Star Configuration

Pentium

Pro

Pentium

Pro

Pentium

Pro

Pentium®

Pro

16-7

TOOLS

16.2.5. Debug Port Layout

Figure 16-4 shows the simplest way to layout the debug port in a multiprocessor system. In this

example, the four processors are the only components in the system boundary scan chain. Sys-

tems incorporating boundary scan for use other than for an ITP should consider providing a

method to partition the boundary scan chain in two distinct sections; one for system debug using

the ITP and the other for manufacturing or system test.

System debug using an ITP requires only that the Pentium Pro processors be in the boundary

scan chain. During system debug, routing boundary scan signals (particularly TCK and TMS)

solely to the Pentium Pro processors enhances the likelihood that the boundary scan signals can

be clocked at high speed. This will improve the performance of debug tools that must access

large amounts of data via boundary scan. (For example, MP systems that have up to four pro-

cessor in the chain will require four times as much boundary scan traff ic.) Additionally, remov-

ing all but the Pentium Pro processors from the boundary scan chain reduces the possibility for

errors in the chain when using an ITP for system debug.

If your system includes the use of boundary scan for test during normal system operation, then

you should consider including the QST3383 in your layout. This component is used to multiplex

the boundary scan lines in order to avoid contention between the system and an ITP. Using the

QST3383, the system boundary scan lines are routed directly to the system when an ITP is not

installed.

Howe v er, if the ITP is installed and is communicating with the Pentium Pro processors, the BS-

EN# signal will enable the multipl exer to pass the boundary scan lines from the debug port to

the system. Note: When an ITP is installed and communicating with the p rocessors, the TDI line

from the system boundary scan cont rol logic do es not pass thro ugh to the system, but is instead

tied back into the TDO line. Thus, while the ITP is communicating with the processors, it is not

possible for the system boundary scan control logic to access a processor via the boundary scan

chain.

16-8

TOOLS

Figure 16-4. Generic MP System Layout for Debug Port Connection

16-9

TOOLS

16.2.5.1. SIGNAL QUALITY NOTES

If system signals to the debug por t (i.e. TDO, PRDY[0-3]# and RE SET#) are used elsewhere in

the system, then dedicated drivers should be used to isolate the signals from reflections coming

from the end of the debug port cable. If the Pentium Pro processor boundary scan signals are

used elsewhere in the system, then the TDI, TMS, TCK, and TRST# signals from the debug po rt

should be isolated from the system signals with multiplexers as discussed in Section 16.2.5.,

“Debug Port Layout”.

Additionally, it is a general rule that no signals should be left floating. Thus, signals going from

the de b ug por t t o th e Penti um Pr o p rocesso r -b ased sy stem shoul d no t be left floati ng. If t he y ar e

left floating there may be problems when an ITP is not plugged in.

16.2.5.2. DEBUG PORT CONNECTOR

Figure 1 6-5 and Fi gure 16 -6 show how the d eb ug port conn ector s hould b e ins talled on a cir cuit

board. Note the w ay the p i ns are num bered on the co nn ector an d h ow the throug h h oles are laid

out on the board. Figure 16-6 shows a dotted line representation of the connector and behind it

the throu gh hol es as seen fr om the top s ide of the circui t boa rd (the sid e on which the con nector

will be placed). The through holes are sho wn so that you can match the pin numbers of the con-

nector to where the connector leads will fall on the circuit board. Although this may appear very

simple, it is surprising how often mistakes are made in this aspect of the debug port layout.

Figure 16-5. Debug Port Connector on Primary Side of Circuit Board

16-10

TOOLS

16.2.6. Using Boundary Scan to Communicate to the Pentium®

Pro Processor

An ITP communicates to the processors in a Pentium Pro processor system by stopping their ex-

ecution and sendin g/receiv ing messages ov er their boundary scan pins. As long as each Pentium

Pro processor is tied into the system boundary scan chain, an ITP can communicate with it. In

the simplest case, the Pentium Pro processor s are back to back in the scan chain, with the bound-

ary scan input (TDI) of the first Pentium Pro processor connected up directly to the pin labeled

TDI on th e debug port and t he boundary scan output of the last Pentium Pr o processor conn ected

up to the pin labeled TDO on the debug port, as shown in Figure 16-7.

Figure 16-6. Hole Layout for Connector on Primary Side of Circuit Board

Figure 16-7. Pentium® Pro Processor-Based System Where Boundary Scan is Not Used

Pentium®

Pro Pentium

Pro

16-11

TOOLS

While an ITP requires only that the Pentium Pro processors be in the scan chain, Figure 16-8

shows a more complex case. The order in which you place the components in your scan chain

is up to you. However, you may need to provide scan chain layout information to the ITP so it

kno ws where the CPUs are in the chain. Note that additional components should not be included

in the boundary scan chain unless absolutely necessary. Additional components increase both

the complexity of the circuit and the possibility for problems when using the ITP. If possible, lay

out the board such that the additional components can be removed from the scan chain for de-

bug.

Figure 16-8. Pentium® Pro Processor-Based System Where Boundary Scan is Used

Pentium

Pro

Pentium®

Pro

OverDrive®

Processor Socket

Specification

17-1

CHAPTER 17

OVERDRIVE® PROCESSOR SOCKET

SPECIFICATION

17.1. INTRODUCTION

Intel will offer future OverDrive processors for the Pentium Pro processor . This OverDri v e pro-

cessor will be based on a faster, future Intel processor core.

The future OverDrive processor for Pentium Pro processor-based systems is a processor up-

grade that will make all software run faster on an existing Pentium Pro processor system. The

OverDrive processor is binary compatible with the Pentium Pro processor. The OverDrive pro-

cessor is intended for use as a replacement upgrade for single and dual processor Pentium Pro

processor designs. The OverDrive processor will be equipped with an integral fan/heatsink and

retention clips. Intel plans to ship OverDri ve processors with a matched Voltage Re gulator Mod-

ule (OverDrive VRM).

To support processor upgrades, a Zero Insertion Force (ZIF) socket (Socket 8) and a Voltage

Regulator Module connector (Header 8) have been defined along with the Pentium Pro proces-

sor. Header 8 can be populated with an OEM Pentium Pro processor VRM or with the

OverDrive VRM which Intel plans to ship with the OverDrive processor as part of the retail

package.

The OverDrive processor will also support Voltage Identification as described in Section 11.6.,

“Vo ltage Identi ficat ion”. The fo ur Voltage ID ou tputs (VID0 -VID3) can be used to des ign a pro-

grammable power supply that will meet the power requirements of both the Pentium Pro and

OverDrive processors via the Header 8 described in this chapter, or on the motherboard. If you

plan to use VID to design a programmable supply for the OverDrive processor, please contact

Intel for additional information.

A single socket system should include Socket 8 and Header 8. When this system configuration

is upgraded, the Pentium Pro processor and its VRM are replaced with a future OverDrive pro-

cessor for Pentium Pro processor-based systems and its matching OverDrive VRM. The

OverDrive VRM is capable of delivering the lower voltage and higher current required by the

upgrade. Other voltage regulation configurations are described in Section 17.3.2., “Upgrade

Present Signal (UP#)”.

17.1.1. Terminology

Header 8: 40-pin Voltage Regulator Module (VRM) connector defined to contain the OEM

VRM and OverDrive VRM.

OverDrive processor: A future OverDrive processor for Pentium Pro processor-based systems.

17-2

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

OverDrive VRM: A VRM designed to provide the specific voltage required by the future

OverDrive processor for Pentium Pro processor-based systems.

Socke t 8 : 387-pin SPGA Zero Insertion Force (ZIF) socket defined to contain either a Pentium

Pro or OverDrive processor.

17.2. MECHANICAL SPECIFICATIONS

This section specifies the mechanical features of Socket 8 and Header 8. This section includes

the pinout, surrounding space requirements, and standardized clip attachment features.

Figure 17-1 below shows a mechanical representation of the OverDrive processor in Socket 8

and the OverDrive VRM in Header 8.

Figure 17-1. Socket 8 Shown with the Fan/heatsink Cooling Solution, Clip Attachment

Features and Adjacent Voltage Regulator Module

OverDri

Airspace

Voltage

Regulator

Module

Fan/Heatsink

Socket 8

Header 8

17-3

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.2.1. Vendor Contacts for Socket 8 and Header 8

Contact your local Intel rep resentati ve for a list of par ticipating Socket 8 and Header 8 sup pliers.

17.2.2. Socket 8 Definition

Socket 8 is a 387-pin, modified staggered pin grid array (SPGA), Zero Insertion Force (ZIF)

socket. The pinout is identical to the Pentium Pro processor. Two pins are used to support the

on-package fan/heatsink included on the OverDrive processor and indicate the presence of the

OverDri ve processor. The OverDri ve processor package is oriented in Socket 8 by the asymmet-

ric use of interstitial pins. Standardized heat sink clip attachment tabs are also def ined as part of

Socket 8 (Section 17.2.2.3., “Socket 8 Clip Attachment Tabs”).

17.2.2.1. SOCKET 8 PINOUT

Socket 8 is shown in Figure 17-2 along with the VRM connector (Header 8). Refer to Chapter

15, Mechanical S pecifications, for pin listings of the Pentium Pro processor. The OverDrive

processor pinout is id entical to the Pentium Pro processor. Descriptions of the upgrade spe-

cific pins are presented in Table 17-1. Note the location of pin A1 in relation to the cam shelf

position. If the socket has the cam shelf l ocated in a dif ferent position, then correct insertion

of the OverDrive processor may not be possible. See Section 17.2.2.2., “Socket 8 Space

Requirements”.

Figure 17-2. OverDrive® Processor Pinout

OverDri

17-4

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

NOTE:

1. Refer to Section 17.3., “Functional Operation of OverDriv e® Processor Signals” for a description of the

abov e signals.

17.2.2.2. SOCKET 8 SPACE REQUIREMENTS

The OverDri ve processor will be equipped with a fan/heatsink thermal management de vice. The

package en v elope dimensions fo r the Over Driv e processor with attach ed fan/heatsink are sho wn

in Figure 17-3. Clearance is required around the fan/heatsink to ensure unimpeded air flow for

proper cooling (refer to Section 17.5.1.1., “Fan/heatsink Cooling Solution” for details).

Figure 17-4 sho ws the Socket 8 space requiremen ts for the OverDri ve processor. All dimensions

are in inches.

Table 17-1. OverDrive® Processor Signal Descriptions

Pin Name1Pin # I/O Funct ion

Vcc5 AG1 Input +5V Supply required for OverDrive® processor fan/heatsink.

UP# AG3 Output This output is tied to Vss in the Ov erDrive processor to indicate

the presence of an upgrade processor. This output is an open in

the Pentium® Pro processor.

17-5

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

“Keep out zones,” also shown in Figure 17-4, have been established around the heat sink clip

attachment tabs to prevent damage to s urface mounted components during clip inst allation and

removal . The keep out zones extend upwards from the surface of the motherboard to the top of

the heat sink. The lateral limits of the k eep out zones e xtend 0.1 inch fr om the per imeter of each

tab.

Immovable objects must not be located less than 1.85 inches above the seating plane o f the ZIF

socket. Removable objects must also not be located less than the 1.85 inches above the seating

plane of th e ZIF sock et r equired for th e processor and f an/heatsink. T hese requir ements also ap-

ply to the area above the cam shelf.

As shown in Figure 17-4 it is acceptable to allow any device (i.e. add-in cards, surface mount

dev i ce, chassis etc.) to enter within the free space distance of 0.2" from the chip package if it is

not taller than the le vel of the heat sink base. In other words, if a component is taller than height

'B', it cannot be closer to the chip package than distance 'A'. This applies to all four sides of the

chip package (the handle side of the ZIF socket will generally meet this specification since its

width is typically larger than distance 'A' (0.2")).

Figure 17-3. OverDrive® Processor Envelope Dimensions

OverDri

2.46"

3.23"

0.58"

0.50"

1.45"

TOP VIEWEN D VIEW

SIDE VIEW

Pin A1

KEEP OU T ZO N ES

NOT SHOWN

17-6

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

For designs which use Header 8, the header itself can violate the 0.2” airspace around th e Over -

Drive processor package. A VRM (either Pentium Pro processor VRM or OverDrive VRM),

once installed in Header 8, and any components on the module, MUST NOT violate the 0.2”

airspace. Also, the header must not interfere with the i nstallation of the Pentium Pro or Over-

Drive processors, and must not interfere with the operation of the ZIF socket lever. Alternately,

Socket 8, and the installed processor must not interfere with the inst allation and removal of a

VRM in Header 8.

NOTE

Components placed close to Socket 8 must not impede access to and

operation of the handle of the ZIF socket lever. Adequate clearance must be

provided within the proximity of the ZIF socket lever to provide fingertip

access to the lever for normal operation, and to allow raising the lever to the

full open posit i on.

17-7

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.2.2.3. SOCKET 8 CLIP ATTACHMENT TABS

Standardized clip attachment tabs will be provided on Socket 8. These will allow clips to secure

the OverDrive processor to the socket to enhance shock and vibration protection. OEMs may

utilize the attachment tabs for their own thermal solutions. As an option, OEMs may use cus-

tomized attachment features pro viding that the additional f eatures do not interfere with the stan-

dard tabs used by the upgrade.

Details of the clip attachment tabs and overall dimensions of Intel qualified sockets may be ob-

tained from particip ating socket suppliers.

Figure 17-4. Space Requirements for the OverDrive® Processor

1.85" Total

Clearance

Above Soc ket 0.4" MIN

Surfa ce Mount

Component

Fan/Heatsink

OverDrive

Voltage

Regulator

Module

Package

Socket 8

Heat Sink clip

"Keep out Zone"

6 places

0.1"

NOTE:

Do Not Interfere

with ZIF Handle

Operation

Socket

Airspace

TPH

0.3"

Above

Fan

ALL

four

sides 0.2"

MIN

0.2"

MIN

17-8

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.2.3. OverDrive® Voltage Regulator Module Definition

Header 8 is a 2-ro w, 40-pin shrouded header designed to accommodate a Pentium Pro processor

VRM, OverDrive VRM, or a programmable VRM. The OverDrive VRM is used to convert the

standard 5.0V supply to the OverDrive processor core operating voltage. Integral OverDrive

VRM hold down tabs are included as part of the header definition for enhanced sho ck and vi-

bration protection.

OEMs who plan to design a custom VRM PC Board to fit into Header 8 should refer to the

AP-523 Pentium® Pro Pr ocessor Power Distrib ution Guidelines Application Note (Order Num-

ber 242764).

17.2.3.1. OVERDRIVE® VRM REQUIREMENT

When upgrading with an OverDrive processor, Intel suggests the use of its matched Voltage

Regulator Module, which Intel plans to ship with the OverDrive processor retail package.

If the OEM includes on-board v oltage reg ulation and the Header 8 for the OverDrive VRM, the

on-board v oltage reg ulator must be shut of f via the UP# output of the CPU. When the Ov erDriv e

processor is installed, and the UP# signal is driven LOW, the on-board VR must never power

on. This will ensure that there is no contention between the OverDrive VRM and the on-board

regulator.

17.2.3.2. OVERDRIVE® VRM LOCATION

It is recommended that Header 8 be located within approximately 1 inch of Socket 8 to facilitate

end user installation. For optimum electrical performance, the Header 8 should be as close as

possible to Socket 8. The location must not interf ere with the operation of the ZIF socket handle

or heatsink attachment clips. To allo w system design flexibility, Header 8 placement is optional,

but it is recommended that Header 8 NOT be placed on the same side of the ZIF socket as the

handle.

17.2.3.3. OVERDRIVE® VRM PINOUT

The Over Drive VR M pinou t and pin d escriptio n is presen ted in Figur e 17-5 and Table 17- 2,

respectively.

17-9

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

Figure 17-5. Header 8 Pinout

Pin # Signal Name Pin # Signal Name

A1 5Vin B1 5Vin

A2 5Vin B2 5Vin

A3 5Vin B3 5Vin

A4 12Vin B4 12Vin

A5 Reserved B5 Reserved

A6 Reserved B6 OUTEN

A7 VID0 B7 VID1

A8 VID2 B8 VID3

A9 UP# B9 PwrGood

A10 VccPB10 Vss

A11 Vss B11 VccP

A12 VccPB12 Vss

A13 Vss B13 VccP

A14 VccPB14 Vss

A15 Vss B15 VccP

A16 VccPB16 Vss

A17 Vss B17 VccP

A18 VccPB18 Vss

A19 Vss B19 VccP

A20 VccPB20 Vss

17-10

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

NOTE:

1. The OverDrive® Voltage Regulator Module requires both 5V and 12V. Routing for the 5V VRM supply

must support the full requirements of the OverDrive VRM given in Table 17-5 e ven if the 12V supply is

utilized for the OEM VRM.

17.2.3.4. OVERDRIVE® VRM SPACE REQUIREMENTS

Figure 17-6 describes the maxi mum OverDri v e VRM en v elope. No part of the Ov erDri ve VRM

will extend beyond the defined space.

Table 1 7-2. Header 8 Pin Reference

Pin Name I/O Usage Function

12Vin Input Required +12V±5% Supply

5Vin Input Required +5V±5% Supply1

Vss Input Required Ground Reference

OUTEN Input Optional When driv en high thi s input will enable the OEM VRM output

and float the Ov erDrive® VRM output. When this input is driven

low, the output of the OEM module will float and the OverDrive

VRM output will be enabled.

PwrGood Output Optional Power Good is driven high upon the VRM output reaching valid

levels. This output requires an external pull-up resistor (~10KΩ).

RES No connect Reserved for future use.

UP# Input Required This signal is held high via an e xternal pull-up resistor on the

open collector output of the Pent ium® Pro processor, and is

driven low by the grounded output of the OverDrive processor.

VccP Output Required Voltage Regulator Module core voltage output. Voltage level for

the OverDrive processor will be lower than for the Pentium Pro

processor.

VID3-VID0 Inputs Optional Used by the Pentium Pro processor VRM to determine what

output voltage to provide to the CPU. The OverDrive VRM does

not require these pins to be connected as it will be voltage

matched in advance to the OverD r ive processor. Refer to Table

11-1 for Voltage ID pin decoding.

17-11

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.3. FUNCTIONAL OPERATION OF OVERDRIVE® PROCESSOR

SIGNALS

17.3.1. Fan/Heatsink Power (VCC5)

This 5V supply provides po wer to the fan of the fan /heatsink assembly. See Table 17-4 for V cc5

specifications.

17.3.2. Upgrade Present Signal (UP#)

The Upgrade Present signal is used to pre vent oper ation of vo ltage regulator s providing a p oten-

tially harmful voltage to the OverDrive processor, and to prevent contention between on-board

regulation and the OverDrive V RM. UP# is an open collector output, held high using a pull-up

resistor on the motherboard tied to +5 Volts.

There are se veral system voltage regulation design options to support both the Pentium Pro pro-

cessor and its Ov erDrive processor. The use of the UP# signal for each case is described below:

— Case 1: Header 8 only

If the system is designed with voltage regulation from the Header 8 only, then the UP#

signal must be connected between the CPU socket (Socket 8) and the VRM connector

(Header 8). The Pentium Pro processor VRM should internally connect the UP# input

directly to the VRM OUTEN input. If the Pentium Pro processor is replaced with an

Figure 17-6. OverDrive® Voltage Regulator Module Envelope

P6T005

0.550 MIN 0.550 REF

0.090 REF

OverDrive VRM PCB

HEADER 8

DIMENSIONS IN INCHES

3.00 RE F

2.4

Total height

from

motherboard

to a n

immovable

object

0.80

Max Component

Height on front

of VRM PCB

0.14

Max Component

Height on back

of VRM PCB

1.8

Total space

fo r VR M /

Header 8

from

motherboard

3.10 Max VRM PCB Width

Minimum distance to VRM

components from motherboard

NOTE: The connector comprises a header mounted on the motherboard and a receptacle on the edge of the VRM P CB.

17-12

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

OverDrive processor and the O EM VRM is NOT replaced with the OverDrive VRM,

the original voltage regulator will never enable its outputs because the lower voltage

OverDrive processor could be damaged. Refer to Figure 17-7.

— Case 2: Header 8 AND alternate voltage source

If the system is designed with alternate voltage source and a Header 8 for future

upgrade support, then the UP# signal must be connected between Socket 8, Header 8,

and the alternate voltage source. The Pentium Pro processor voltage regulator should

use the UP# signal to disable the voltage output when detected low (indicating that an

OverDr ive processor has been installed). Th e Ov erDr ive VRM, when installed into the

Header 8 will use the UP# signal to enable its outputs (when detected low). When the

Pentium Pro processor is replaced with an OverDrive processor and the OverDrive

VRM is installed, the original voltage regulator must never enable its out puts because

the lower voltage OverDrive processor could be damaged. Refer to Figure 17-8.

Figure 17-7. Upgrade Presence Detect Schematic - Case 1

Figure 17-8. Upgrade Presence Detect Schematic - Case 2

Socket 8

UP#

+ 5 Volt

10 kΩ

Header 8

On-Board VR

Socket 8

UP#

+ 5 Volt

10 kΩ

Header 8

17-13

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

— Case 3: Alter nate voltage source only

If the system is designed with only a programmable voltage source using the VID3-

VID0 pins, then the UP# signal need not be used.

NOTE

The programmable voltage source needs to be able to provide the OverDrive

processor with it’s required power. Refer to Figure 17-9.

17.3.3. BIOS Considerations

Please refer to the Pentium® Pro Pr ocess or De veloper’s Manual, Volume 2: Prog r ammer’s Ref-

erence Manual (Order Number 242691) for BIOS requirements.

It is the responsibility of the BIOS to detect the type of CPU in the system and program the sup-

port hardware accordingly. In most cases, the BIOS does this by reading the CPU signature,

comparing it to kno wn signatur es, and, upon f inding a match, ex ecutin g the correspondin g hard-

ware initialization code.

The CPUID instruction is used to determine several processor parameters. Follo wing e xecution

of the CPUID instruction, bits 12 and 13 of the EAX register can be used to determine if the

processor is an OEM or an OverDri ve processor. An OverDri ve processor is present if bit 13=0

and bit 12=1.

NOTE

Contact your BIOS vendor to ensure that the OverDrive processor BIOS

requirements have been included.

Figure 17-9. Upgrade Presence Detect Schematic - Case 3

Socket 8

VID3-VID0

O n -Boa rd VR 4

17-14

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.3.3.1. OVERDRIVE® PROCESSOR CPUID

Following power-on RESET or the CPUID instruction, the EAX register contains the values

shown in Table 17-3.

17.3.3.2. COMMON CAUSES OF UPGRADABILITY PROBLEMS DUE TO BIOS

CPU signature detection has been a common cause of current upgradability problems due to

BIOS. A few precautions within the BIOS can help to eliminate future upgradability problems

with Pentium Pro processor-based systems. When programming or modifying a BIOS, be aware

of the impact of future OverDrive processors. The following recommendations should prevent

problems in the future:

•Always use the CPU signature and feature flags to identify the processor, including future

processors.

•Never use timing loops for delays.

•If an OverDrive processor is detected, report the presence of an “OverDrive processor” to

the end-use r.

•If an OverDrive processor is detected, don’t test on-chip cache sizes or organization. The

OverDrive processor cache parameters differ from those of the Pentium Pro processor.

•If an OverDrive processor is detected, don’t use the Pentium Pro processor model specific

registers and test registers. OverDrive processor MSRs differ from those of the Pentium

Pro process or.

•Memory Type Range Registers must be programmed as for a Pentium Pro processor.

17.4. OVERDRIVE® PROCESSOR ELECTRICAL

SPECIFICATIONS

This section describes the electrical requirements for the OverDrive processor.

NOTE

ZIF socket electrical parameters may differ from LIF socket parameters;

therefore, be sure to use the appropriate ZIF socket parameters for electrical

design simulations.

Table 17-3. OverDrive® Processor CPUID

Type [13:12] Family [11:8] M odel [7:4] Stepping [3:0]

163X

17-15

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.4.1. D.C. Spec if ica ti ons

17.4.1.1. OVERDRIVE® PROCESSOR D.C. SPECIFICATIONS

Table 17-4 lists the D.C. specifications for the Ov erDriv e processor that are either different from

or in addition to the Penti um Pro processor specifications.

NOTES:

1. This specification applies to the future OverDriv e® processor for

150 MHz

Pentium® Pro processor-based

systems.

2. This specification applies to the future OverDr ive processor for

166 & 180 MHz

Pentium Pro proces sor-

based systems.

3. This specification applies to the future OverDrive processor for

200 MHz

Pentium Pro processor-based

systems.

4. This is the

TARGET

OverDrive processor Voltage. It is recommended that the Voltage Identification be

used to deter mine processor voltage for programmable voltage sources and implement a voltage range

which adequately covers the OverDrive processor Target Voltage (~2.4-2.7V).

Table 17-4. OverDrive® Processo r D.C. Specifications

Symbol Parameter Min Typ Max Unit Notes

IccP Primary Icc Current 0.100 11.2

12.5

13.9

VccP Pri mar y Vcc Voltage 2.375 2.5 2.625 VccP = 2.5V±5% 4

IccS Secondary Icc Current 0 A

VccS S econdary Vcc Voltage 3.145 3.3 3.465 VccS = 3.3V ± 5%

Icc5FAN fan/heatsink Current 340 mA

Vcc5fan/heatsink Voltage 4.75 5 5.25 Vcc5 = 5V ± 5%

PMax Maximum Thermal Design

Power 21.4

23.8

26.3

26.7

29.7

32.9

17-16

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.4.1.2. OVERDRIVE® VRM D.C. SPECIFICATIONS

The D.C. specifications for the OverDrive VRM are presented in Table 17-5.

17.4.2. OverDrive® Processor Decoupling Requirements

No additional decoupling capacitance is required to support the OverDrive processor beyond

what is necessary for the Pentium Pro processor. Any incremental decoupling, both bulk and

high speed, required by the OverDrive processor wi ll be provided on t he processor package. It

is strongly recommended that liberal, low inductance decoupling capacitance be placed near

Socket 8 follo wing the gu idelines in note 1 of Table 11-4 and the AP-523 Pentium® Pr o Proces-

sor Power Dis tri b u tio n Gu id el ine s Applic ation Note (Order Number 242764 ). Capacitor v alues

should be chosen to ensure they eliminate both low and high frequency noise components.

NOTES:

1. This spec applies to the OverDrive® VRM for

150 MHz

Pe ntium® Pro processor -based sys tems.

2. This spec applies to the OverDrive VRM for

166 & 180 MHz

Pentium Pro proc essor- based systems.

3. This spec applies to the OverDrive VRM for

200 MHz

Pentium Pro processor-based systems.

4. Maximum total resistance from VRM output to CPU pins cannot exceed 2.1 mΩ. For example, a break-

down of the resistive path might be 0.45 mΩ for VRM header, 1.0 mΩ for motherboard pow er plane resis-

tance, and 0.65 mΩ for ZIF socke t.

Table 17-5. OverDrive® VRM Specifications

5Vin = 5V ± 5%, TCASE = 0 to 105º C

Symbol Parameter Min Max Unit Notes

VIL Control Signal Input Low Voltage -0.3 0.8 V

VIH Control Signal Input High Voltage 2.0 Vcc5+0.3 V

VOL Control Signal Output Low Voltage 0.4V V

VOH5 Control Signal Output High Voltage 2.4 Vcc5+0.3 V PwrGood

ICC5 5.0V Power Supply Current 0.100 7.0

7.8

8.7

A 1 VRM

2 input

3 current

ICC12 12.0V Pow er Supply Current 150 mA VRM input

current

IOUT VRM Output Current 11.2

12.5

13.9

LMB Total inductance between VRM output

and processor pins 2.5 nH

RMB Total resistance between VRM output

and processor pins 2.1 mΩ4

dicc/dt Worst Case Input (Icc5) Load Change 100 mA/µS

TVout Valid Input Supply to Output Dela y 10 ms

17-17

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.4.3. A.C. Specifications

Except for internal CPU core Clock frequency, the OverDrive pr ocessor will operate within the

same A.C. specifications as the Pentium Pro processor.

17.5. THERMAL SPECIFICATIONS

This section describes the cooling solution utilized by the OverDrive processor and the cool-

ing requirements for both the processor and VRM. Heat dissipation by the OverDrive proces-

sor will be no greater than the Pentium Pro processor, as described in Chapter 14, Thermal

Specifications.

17.5.1. OverDrive® Processor Cooling Requirements

The OverDrive processor will be cooled with a fan/heatsink cooling solution. The OverDrive

processor will operate properly when the preheat temperature, TPH, is a maximum of 50ºC

(TPH is the temperature of the air entering the fan/heatsink, measured 0.3” above the center of

the fan — See Figure 17-4). When the preheat temperature requ irement is met, the f an/h eatsink

will keep the case temperature, TC, within the specified range, provided airflow through the

fan/heatsink is unimpeded (see Section 17.2.2.2., “Socket 8 Space Requirements”).

It is strongl y recommended that testing be conducted to determ ine if the fan inlet temperatu re

requirement is met at the system maximum ambient operating temperature.

NOTE

The OverDri v e processor will operate properly when the preheat temperature,

TPH, is a maximum of 50°C (TPH is the temperature of the air entering the

fan/heatsink, measured 0.3” above the center of the fan — See Figure 17-4).

17.5.1.1. FAN/HEATSINK COOLING SOLUTION

A height of 0.4" airspace abo v e the f an/heatsink unit an d a distance o f 0.2” around all four sides

of the Ov erDrive processor is REQUIRED to ensure that the airflow through the fan/heatsink is

not blocked. The fan/heatsink will reside within the boundaries of the surface of the chip. Block-

ing the airflow to the fan/heatsink reduces the cooling efficiency and decreases fan life.

Figure 17-4 illustrates an acceptable airspace clearance above the fan/heatsink and around the

OverDrive processor package.

17.5.2. OEM Processor Cooling Requirements

The OEM processor cooling solution must not impede the upgradability of the system. For

example:

17-18

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

•If an OEM fan/heatsink is used, then electrical connections between the OEM fan/heatsink

and system must be through an end user separable connector.

•If an OEM fan/heatsink is used, removal of the assembly must not interfere with the

operation of the OverDrive processor, for example, by activating cooling failure protection

mechanisms employed by the OEM.

•Custom attachment features in addition to the features covered in Section 17.2.2.3.,

“Socket 8 Clip Attachment Tabs” must not interfere with attachment of the upgrade

retention clip s.

17.5.3. OverDrive® VRM Cooling Requirement s

The OverDrive Voltage Regulator Module will be shipped with a passive heat sink. Voltage

regulator case temperature must not exceed 105°C. The ambient temperature, TA, req ui re d

to prope rly cool th e VR M can be e stima ted from the following sec tion.

17.5.4. Thermal Equations and Data

The OverDrive Voltage Regulator Module requires that TC does not exceed 105°C. TC is mea-

sured on the surface of the hottest component of the VRM. To calcul ate TA v alues for the VRMs

at different flow rates, the following equations and data may be used:

TA = TC - (P × ΘCA)

Where, TA and T C = Ambient and Case temperature, respectively. (°C)

QCA = Case-to-Ambient Thermal Resistance (°C/Watt)

P = Maximum Power Consumption (Watt)

NOTES:

1. Specification for the OverDrive® Voltage Regulator Module. A Pentium® Pro processor OEM Module is

specific to the design and may differ.

2. This spec applies to the OverDrive VRM for

150 MHz

Pentium Pro processor-based systems.

3. This spec applies to the OverDrive VRM for

166 & 180 MHz

Pentium Pro proc essor- based systems.

4. This spec applies to the OverDrive VRM for

200 MHz

Pentium Pro processor-based systems.

Table 17-6. OverDrive® VRM Power Dissipation for Thermal Design

Parameter Typ 1Max 1Unit Notes

VRM P ower

Dissipation 6

6.7

7.5

6.5

7.0

Watts 2 OverDrive® VRM

TC, Max 105 °C Voltage Regulator Maximum Case Temperature

17-19

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.6. CRITERIA FOR OVERDRIVE® PROCESSOR

This section provides PC system designers with information on the engineering criteria required

to ensure that a system is upgradable. The diagrams and checklists will aid the OEM to check

specif ic criteria. Sev eral design tools are available through Intel f ield representatives which will

help the OEM meet the criteria. Refer to Section 17.6.1., “Related Documents”.

The criteria are divided into 5 different categories:

•Electrical Criteria

•Thermal Criteria

•Mechanical Criteria

•Functional Criteria

•End User Criteria

NOTES:

1. Airflow direction parallel to long axis of VRM PCB.

2. TCASE = 105°C, Power as per Table 17-6.

Table 17-7. OverDrive® Processor Thermal Resistance and Maximum Ambient

Temperature

Airflow - Ft./Min (M/Sec) 1

100

(0.50) 150

(0.75) 200

(1.01) 250

(1.26) 300

(1.52)

OverDrive® Processor TA, Max (°C) Fan/Heatsink requires Ambient of 50°C or less

regardless of external airflow.

Ov erDrive VRM ΘCA (°C/W) 9.8 8.3 6.8 6.4 6.0

The following specifications apply to the future OverDrive processor for

150 MHz

Pentium® Pro

processor-based systems:

OverDrive VRM TA, Max (°C)246 55 64 67 69

The following specifications apply to the future OverDrive process or for

166 & 180 MHz

Pentium Pro

processor-based systems:

OverDrive VRM TA, Max (°C) 41 51 61 63 66

The following specifications apply to the future OverDrive process or for

200 MHz

Pentium Pro proces sor-

based systems:

OverDrive VRM TA, Max (°C) 36 47 57 60 63

17-20

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.6.1. Related Documents

All references to related documents within this section imply the latest published revision of the

related document, unless specifically stated otherwise. Contact your local Intel Sales represen-

tative for latest revisions of the related documen ts.

Processor and Motherboard Documentation:

•Pentium® Pro Processor Devel oper ’s Manua l, Volume 3: Programmer ’s Reference Manual

(Order Number 242691)

•AP-523 Pentium® Pro Processor Power Distribution Guidelines Application Note (Order

Number 242764)

17.6.2. Electrical Crite r ia

The criteria in this section con centrates on the C PU and VRM, and covers pin to plane continu -

ity, signa l connections, si gnal timing and quality, and voltage transients.

17.6.2.1. OVERDRIVE® PROCESSOR ELECTRICAL CRITERIA

The electrical criteria for the OverDrive processor is split into three tables. Most of the criteria

refer directly to previo us sections of this document.

The criteria for the OverDrive processor that only apply to motherboards and systems which

employ a Header 8 are p resented in Table 17-8. See Table 17-10 for criteria that apply re gardless

of a Header 8.

17-21

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

The criteria for the Over Dri v e pr ocessor that only ap ply to motherbo ards and systems which do

not employ a Header 8 are presented in Table 17-9. See Table 17-10 for criteria that apply re-

gardless of a Header 8.

Table 17-8. Electrical Test Criteria for Systems Employing Header 8

Criteria Refer To: Comment

5Vin Tolerance

Header 8 Input Table 17-2 Measured Under the f ollowing Loading Conditions:

•Max Icc

at Steady-State

• Min Icc5 at Steady-State

• Fast Switch between Max and Min Icc5

Refer to Table 17-5 for OverDrive® VRM Icc5 specification.

Pentium® Pro proces sor

VccP Specification Table 11-4 Measured Under the following Loading Conditions:

•Max Icc

at Steady-State

• Min IccP at Steady-State

• Fast Switch between Max and Min IccP

Refer to Table 11-5 for Pentium Pro processor IccP

specification.

VRM RES pins Table 17-2 Must not be connected.

VRM control signals (5Vin,

Vss, PwrGood, UP#, VccP,

and VID3-VID0)

Table 17-2 Must be connected as specified.

OUTEN is optional.

VRM control input signal

quality Table 17-5 VRM control input signals must meet the D.C . specifications

of the VRM.

Maximum Total LMB Table 17-5 Inductance between VRM output

and CPU soc ket pins.

Maximum Total RMB Table 17-5 Resistance between VRM output

and CPU soc ket pins.

Table 17-9. Electrical Test Criteria for Systems Not Employing Header 8

Criteria Refer To: Comment

VccP

Primary CPU Vcc

Voltage

Table 17-4

including

note 4

Measured Under the following Loading Conditions:

•Max Icc

at Steady-State

• Min IccP at Steady-State

• Fast Switch between Max and Min IccP

Refer to Table 17-5 for OverDrive® processor IccP

specification.

17-22

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

The criteria for th e OverDri v e processor that apply to all motherboards and systems are present-

ed in Table 17-10.

17.6.2.2. PENTIUM® PRO PROCESSOR ELECTRICAL CRITERIA

Motherboards an d systems will be tes ted to the specifications of the Pentiu m Pro processo r in

Chapter 11, Electrical Specifications.

17.6.3. Thermal Criteria

17.6.3.1. OVERDRIVE® PROCESSOR COOLING REQUIREMENTS (S YSTEMS

TESTING ONLY)

The maximum prehe at temperature, TPH, for the Ov er Drive pro cessor must not b e greater than

specified in Section 17.5.1., “OverDrive® Processor Cooling Requirements”. TPH is the tem-

perature of the air enter ing the f an h eatsink an d is measured 0.3 inches (0.76 cm) abo v e the cen -

ter of the fan. Thermal testing should be performed at the OEM specified maximum system

operating temperature (not less than 32°C), and under worst case thermal loading. Worst case

thermal loading requ ires every I/O bus expansion slot to be filled with the lon gest typical add-

in card that will not violate the required clearance for airflow around the OverDrive processor

(refer to Section 17.2.2.2., “Socket 8 Space Requirements”). These add-in cards represent typi-

cal power dissipation per type and form factor (Full length PCI, VL, ISA, and 1/2 length PCI

dissipate 10 W; 3/4 length ISA dissipates 7.5W, 1/2 length ISA dissip ates 5W, and 1/4 length ISA

dissipates 3.3W).

Table 17-10. Electrical Test Cr iteria for all Systems

Criteria Refer To: Comment

VccS

Secondary CPU Vcc Voltage Table 17-4 Loading Conditions:

• Max IccS at Steady-State

• Min IccS at Steady-State

• Fast Switch between Max and Min IccS

Refer to Table 17-4 for Over Dr ive® processor IccS

specification.

Vcc5Table 17-4 Fan/Heatsink Voltage

Vcc continuity to Socket 8 Table 15-3 0.5Ω or less for any single pin from Socket 8 Vcc pins

to Vcc supply.

Applies to both primary and secondary pins and their

respective supplies.

Vss continuity to Socket 8 Table 15-3 0.5Ω or less for any single pin From Socket 8 Vss pins

to Vss supply.

RESERVED Pins Table 15-3 Must not be connected.

Input signal quality Chapter 13 &

Table 11-12 Must meet specification of the Pentium® Pro processor.

AC timing specifications Section 11.15. Must meet all A.C. specifications of the Pentium Pro

Processor.

17-23

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.6.3.2. PENTIUM® PRO PROCESSOR COOLING REQUIREMENTS

(SYSTEMS TESTING ONLY)

The Pentium Pro processor case temperature must meet the specifications of the Pentium

Pro process or. Thermal test ing sh ould be perform ed und er worst case therm al loadin g (Ref er to

Section 17.6. 3.1., “O verDrive® Processo r Cooling Re quirement s (Systems Testing Only) ”

for loading description), and with a cooling solution representative of the OEM’s cooling

solution. Re fer to Table 11-5 for the Pentium Pro processor c ase temperature specification.

17.6 .3.3. VOLTAGE REGULATOR MODU LES (SYSTEMS EMPLOYING A

HEADER 8 ONLY)

The case temperature of the v oltage regulator on the Over Dri ve VRM must not exceed the spec-

ification of Table 17-7.

17.6.4. Mechanical Crit eria

17.6.4.1. OVERDRIVE® PROCESSOR CLEARANCE AND AIRSPACE

REQUIREMENTS

Refer to Figure 17-4 for a drawing of the various clearance and airspace requirements.

Table 17-11. Thermal Test Criteria

Criteria Refer To: Comment

TPH Section 17.5.1. Air temperature entering the fan/heatsink of the

OverDrive® processor. Measured 0.3 inches (0.76

cm) above the center of the fan/heatsink.

Pentium® Pro processor Case

Temperature Table 11-5 TC must meet the specifica tions of the Pentium

Pro Processor . Measured with a cooling solution

representative of the OEM’s.

Voltage Regulator Case

Temperature Table 17-7

Table 17-12. Mechanical Test Criteria for the OverDrive® Processor

Criteria Refer To: Comment

Minimum airspace from top

surface of socket to any

object.

Figure 17-4 See “Total Clearance Above Socket” in Figure 17 -4.

Minimum airspace around all

4 sides of the OverDrive®

processor fan/heatsink.

Figure 17-4 Required from the CPU package side to the top of the

vertical clearance area. See “A” in Figure 17-4.

Minimum airspace around

heatsink clip tabs. Figure 17-4 Extend from the motherboard surface to the top of the

fan/heatsink. See “K eep Out Zones” in Figure 17-4.

17-24

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.6.4.2. OVERDRIVE® VRM CLEARANCE AND AIRSPACE REQUIREMENTS

Refer to Figure 17-6 for a drawing of the various clearance and airspace requirements of the

OverDrive VRM. Nothing must intrude into the space envelope, including airspace region, de-

fined in Figure 17-6 with the exception of Header 8 itself.

17.6.5. Functional Criteria

The OverDriv e pr ocessor is intend ed to replace the o riginal Pentium Pro pr ocessor. The system

must boot properly without error messages when the OverDrive processor is installed.

17.6.5.1. SOFTWARE CO MPA TIBILITY

System hardware and software that operates properly with the original Pentium Pro processor

must operate properly with the OverDrive processor.

17.6.5.2. BIOS FUNCTIONALITY

The BIOS must continue to operate corre ctly with the Ov erDrive pr ocessor installed in the sys-

tem. Always use the CPU Signature and Feature flags to identify if an OverDrive processor is

installed. Please refer to the Pentium® Pro Processor Developer’s Manual: Volume 3, Pr ogram-

mer’s Reference Manual (Order Number 242691) for the BIOS recommendations.

ZIF socket lever operation. Figure 17-4 Must operate from fully closed to fully open position with

no interference.

Table 17-13. Functional Test Criteria

Criteria Refer To: Comment

Software Compatibility No incompatibilities resulting from upgrade installation.

BIOS Functionality Section

17.3.3. • CPU Type Reported on Screen must be reported correctly

or not at all. Intel recommends reporting “OverDrive®

Processor”.

• Never Use Timing Loops.

• Do not test the cache, or use model specific registers

when the upgrade is detected.

• Program MTRRs as for a Pentium® Pro processor.

Table 17-12. Mechanical Test Criteria for the OverDrive® Processor (Contd.)

Criteria Refer To: Comment

17-25

OVERDRIVE® PROCESSOR SOCKET SPECIFICATION

17.6.6. End User Criteria

17.6.6.1. QUALIFIED OVERDRIVE® PROCESSOR COMPONENTS

To ensure processor upgradabilit y, a system should empl oy the following Intel-qualified Over-

Drive processor components. For a list of qualified components contact your Intel sales repre-

sentative, or if in the US, contact Intel FaxBACK Information Service at (800) 525-3019.

•Genuine Intel OEM CPU

•Socket 8, 387-hole ZIF

•Header 8, 40-pin shrouded (Systems and Motherboards employing Header 8 solution

only.) OR programmable voltage regulator capable of providing the voltage and current

required by the OverDrive processor.

17.6.6.2. VISIBILITY AND INSTALLATION

Socket 8 and Header 8 must be visible upon removal of the system cover. Otherwise, the OEM

must include diagrams or other indicators visible upon removal of the system cover or clear in-

structions in the user’s manual to guide the end user to the CPU socket and the VRM header.

Special tools, other than a screw driver, must not be requi red for an upgrade installation.

17.6.6.3. JUMPER CONFIGURATION

End user configured jumpers are not recommended. If design requires jumpers or switches to

upgrade the system, a detailed jumper description in the manual is required. The jumpers must

be easy to locate and set. Jumper identification should be silk-screened on the motherboard if

possible. Jumper tables on the inside of the system case are recommended.

17.6.6.4. BIOS CHANGES

BIOS changes or additional softwar e must not be required to upgrade the system with the Ov er-

Drive processor.

17.6.6.5. DOCUMENTATION

The system documentatio n must incl ude installatio n instructions , with illust rations o f the sys-

tem, Socket 8 and Header 8 location, and any heatsink clip’s operation and orientation instruc-

tions. Furthermore, there must be no documentation anywhere stating that the warranty is void

if the OEM processor is removed.

17.6.6.6. UPGRADE REMOVAL

The upgrade process mus t be reversible su ch that up on re-installatio n of the or iginal CPU, the

system must retain original functionality and the cooling solution must return to its original

effectiveness.

Signals Reference

A-1

APPENDIX A

SIGNALS REFERENCE

This appendix provides an alphabetical listing of all Pentium Pro processor signals. The tables

at the end of this appendix summarize the signals by direction: output, input, and I/O.

A.1. ALPHABETICAL SIGNALS REFERENCE

A.1.1. A[35 : 3]# (I/O )

The A[35:3]# signals are the address signals. They are driven during the two-clock Request

Phase by the request initiator. The signals in the two clocks are referenced Aa[35:3]# and

Ab[35:3]#. During both clocks, A[35:24]# signals are protected with the AP1# parity signal, and

A[23:3]# signals are protected with the AP0# parity signal.

The Aa[35:3]# signals are interpreted based on information carried during the first Request

Phase clock on the REQa[4:0]# signals.

For memory transactions as defined by REQa[4:0]# = {XX01X,XX10X,XX11X}, the

Aa[35:3 ]# sign als def ine a 236-b yte physical memory address space. The cacheable agents in the

system observe the Aa[35:3]# signals and begin an internal snoop. The memory agents in the

system o bserv e the Aa[3 5:3] # si gnals and be gin ad dress decode to d etermi ne if the y are r esp on-

sible for the transaction completion. Aa[4:3]# signals define the critical word, the first data

chunk to be tr ans ferred on the data b us . Cache l ine t rans acti ons us e the b u rs t order described in

Section 3.3.4.1., ‘Line Transfers” to transfer the remaining three data chunks.

For Pentium Pro processor IO transactions as defined by REQa[4:0]# = 1000X, the signals

Aa[16:3]# define a 64K+3 b y t e ph ysical IO space. The I O agents in th e system observe the sig-

nals and begin address decode to determine if they are responsible for the transaction comple-

tion. Aa[35:17]# are always zero. Aa16# is zero unless the IO space being accessed is the first

three bytes of a 64KByte address range.

For deferred reply transactions as defined by REQa[4:0]# = 00000, Aa[23:16]# carry the de-

ferred ID. This signal is the same deferred ID supplied by the request initiator of the original

transaction on Ab[23:16 ]#/DID[7:0]# signals. Pentium Pro processor b us agents that support de-

ferred replies sample the deferred ID and perform an internal match against any outstanding

transactions w aiting for def erred replies. Du ring a deferred rep ly, Aa[35:24]# and Aa[15:3]# ar e

reserved.

For the branch-trace message transaction as def ined by REQa[4:0]# = 0100 1 and for special and

interrupt acknowledge transactions, as defined by REQa[4:0]# = 01000, the Aa[35:3]# signals

are reserved and undefined.

A-2

SIGNALS REFERENCE

During the second clock of the Request Phase, Ab[35:3]# signals per form identical signal fun c-

tions for all transactions. For ease of description, these functions are described using new signal

names. Ab[31:24]# are renamed the attribute signals ATTR[7:0]#. Ab[23:16]# are renamed the

Deferred ID signals DID[7:0]#. Ab[15: 8]# are renamed th e eight-byte enable signals BE[7:0]#.

Ab[7:3]# are renamed the extended function signals EXF[4:0]#.

On the active-to-inactive transition of RESET#, each Pentium Pro processor bus agent samples

A[35:3]# signals to determine its power-on configuration.

A.1.2. A20M# (I)

The A20M# signal is the address-20 mask s ignal in the PC C ompatibility g r oup. If the A20M#

input signal i s asserted , the Pentium Pro processor mas ks physical address bit 20 (A20#) befo re

looking up a line in any internal cache and before driving a read/write transaction on the bus.

Asserting A20M# emulates the 8086 processor’s address wrap-around at the one Mbyte bo und-

ary. Only assert A20M# when the processor is in real mode. The effect of asserting A20M# in

protected mode is undefined and may be implemented differently in future processors.

Snoop requests and cache-line writeback transactions are unaffected by A20M# input. Address

20 is not masked when the processor samples external addresses to perform internal snooping.

A20M# is an as ynchro nous in put. Ho wever , to g uarantee recog niti on of thi s sign al foll o wi ng an

I/O write instruction, A20M# must be valid with active RS[2:0]# signals of the corresponding

I/O Write bus transaction. In FRC mode, A20M# must be synchronous to BCLK.

During acti ve RESET#, the Pentium Pro pr ocessor b egins sampling the A20M# , IGNNE# , and

LINT[1:0] values to determine the ratio of core-clock frequency to bus-clock frequency. See Ta-

ble 9-4. After the PLL-lock time, the core clock becomes stable and is lock ed to the e xternal bus

clock. On the active-to-inactive transition of RESET#, the Pentium Pro processor latches

A20M#, IGNNE#, and LINT[1:0] and freezes t he frequency ratio internally.

A.1.3. ADS# (I/O)

The ADS# signal is the address Strobe signal. It is asserted by the current bus owner for one

clock to indicate a new Request Phase. A new Request Phase can only begin if the In-order

Queue has less than the maximum number of entries defined by the power-on configuration

(1 or 8), the Request Phase is not being stalled by an active BNR# sequence and the ADS# as-

sociated with the pre vious Request Phase is sampled inacti ve. Along with the ADS#, the request

initiator driv es A[35:3]#, REQ[4:0]#, AP[1:0]#, and RP# signals for two clocks. During the sec-

ond Requ est Phase clock, ADS# must be inactiv e. RP# pro vides parity protection for REQ[4:0]#

and ADS# signals during both clocks. If the transaction is part of a bus locked operation,

LOCK# must be active with ADS#.

Ab[31:24]# Ab[23:16]# Ab[15:8]# Ab[7:3]#

ATTR[7:0]# DID[7:0]# BE[7:0]# EXF[4:0]#

A-3

SIGNALS REFERENCE

If the request i nit iator continues to own the bus after the first Request Phase, it can issue a new

request every three clocks. If the request initiator needs to release the bus ownership after the

Request Phase, it can deactivate its BREQn#/ BPRI# arbitration signal as early as with the acti-

vation of ADS#.

All bus agents observ e the ADS# activ ation to begin parity ch ecking, protocol checking, address

decode, internal snoop, or deferred reply ID match operations associated with the new transac-

tion. On sampling the asserted ADS#, all agents load the ne w transaction in the In -or der Queu e

and update internal counter s. The Error , Snoop , Response, and Data Phase of the transaction are

defined with respect to ADS# assertion.

A.1.4. AERR# (I/O)

The AERR# signal is the address parity error signal. Assuming the AERR# driver is enabled

during the power-on configuration, a bus agent can drive AERR# active for exactly one clock

during the Error Phase of a transaction. AERR# must be inactive for a minimum of two clocks.

The Error Phase is always three clocks from the beginning of the Request Phase.

On observing active ADS#, all agents begin parity and protocol checks for the signals valid in

the two Request Phase clocks. Parity is checked on AP[1:0]# and RP# signals. AP1# protects

A[35:24]#, AP0# protects A[23:3]# and RP# protects REQ[4:0]#. A parity error without a pro-

tocol vi olation is s ignalled by AERR# assertio n.

If AERR# observation is enabled during power-on configuration, AERR# assertion in a valid

Error Phase aborts the transaction. All bus agents remove the transaction from the In-order

Queue and update internal counters. The Snoop Phase, Response Phase, and Data Phase of the

transaction are aborted. All signals in these phases must be deasserted two clocks after AERR#

is asserted, ev en if the signals hav e been asserted before AERR# has been observed. Specif ically

if the Snoop Phase associated with the abor ted tran saction is driven in the n e xt clo ck, the snoop

results, including a STALL condition (HIT# and HITM# asserted for one clock), are ignored.

All bus agents mu st also begin an arbitration reset sequence an d d eassert BREQn#/BPRI# arbi-

tration signals on sampling AERR# active. A current bus owner in the middle of a bus lock op-

eration must keep LOCK# asserted and assert its arbitration request BPRI#/BREQn# after

keeping it inactive for two clocks to retain its bus ownership and guarantee lock atomicity. All

other agents, including the current bus owner not in the middle of a bus lock operation, must

wait at least 4 clocks before asserting BPRI#/BREQn# and beginning a new arbitration.

If AERR# observation is enabled, the Pentium Pro process or retries the transaction once. After

a single retry , the request initiator treats the error as a hard error and asserts BERR# or enters the

Machine Check Exception handler, as defined by the system configuration.

If AERR# observation is disabled during power-on configuration, AERR# assertion is ignored

by all b us agents except a central agent. Based on the Machine Check Architecture of the system,

the central agent can ignore AERR#, assert NMI to execute NMI handl er, or assert BINIT# to

reset the bus units of all agents and execute an MCE handler.

A-4

SIGNALS REFERENCE

A.1.5. AP[1:0]# (I/O)

The AP[1:0]# signals are the address parity signals. They are dri v en b y the request initiator dur-

ing the tw o Request Phase clocks alon g with ADS#, A[35 :3]#, REQ[4:0]# , and RP#. AP1# c ov-

ers A[35:24]#. AP0# covers A[23:3]#. A correct parity signal is high if an even number of

covered signals are low and low if an odd number of covered signals are low. This rule allows

parity to be high when all the covered signals are high.

Provided “AERR# drive” is enabled during the power-on configuration, all bus agents begin

parity checking on observ ing acti v e ADS# and determin e if there is a parity error. On observing

a parity error on any one of the two Request Phase clocks, the bus agent asserts AER R# during

the Error Phase of the transaction.

A.1.6. ASZ[1:0]# (I/O)

The ASZ[1:0]# signals are the memory address-space size signals. They are driven by the re-

quest initia tor d uring th e f irst Reque st Phase clock on t he REQa[ 4:3]# p ins. The AS Z[1:0]# sig -

nals are valid only when REQa[1:0]# signals equal 01B, 10B, or 11B, indicating a memory

access transaction. The ASZ[1:0]# decode is defined in Table A-1.

If the memory access is within the 0-to-(4GByte -1) address space, ASZ[1:0]# must be 00B. If

the memory access is within the 4Gbyte-to-(64GByte -1) address space, ASZ[1:0]# must be

01B. All observing bus agents that support the 4Gbyte (32 bit) addres s space must respond to

the transaction only when ASZ[1:0]# equals 00. All observing bus agents that support the

64GByte (36- bit) address space must respond to the transaction when ASZ[1:0]# equals 00B or

01B.

A.1.7. ATTR[7:0]# (I/O)

The ATTR[7:0]# signals are the attrib ute signals. They are dri v en b y the request initiator during

the second Request Phase clock on the Ab[31:24]# pins. The ATTR[7:0]# signals are valid for

all transactions. The ATTR[7:3] # are r eserved and u ndef ined. The ATTR[2:0] # are driven based

on the Memory R ange Register attributes and the Page Table attributes. Table A-2 de fi nes

ATTR[3:0]# signals.

Table A-1. ASZ[1:0]# Signal Decode

ASZ[1:0]# Description

0 0 0 <= A[35:3]# < 4 GB

0 1 4 GB <= A[35:3]# < 64 GB

1 x Reserved

A-5

SIGNALS REFERENCE

A.1.8. BCLK (I)

The BCLK (clock) signal is the Execution Control group input signal. It determines the bus fre-

quency. All agents drive their outputs and latch their inputs on the BCLK rising edge .

The BCLK sign al indirectly determines the Pentium Pro p rocessor’s internal clock frequency.

Each Pentium Pro processor derives its internal clock from BCLK by multiplying the BCLK fre-

quency by 2, 3, or 4 as defined and allowed by the power-on configuration.

All external timing parameters are sp eci fied with respect to the BCLK signal.

A.1.9. BE[7:0]# (I/O)

The BE[7:0]# signals are the b yte-enable signals. The y are dr i v en b y the request initiator during

the second Request Phase clock on the Ab[15:8]# pins. These signals carr y various information

depending on the REQ[4:0]# value.

For memory or I/O transactions (REQa[4:0]# = {10000B, 10001B, XX01XB, XX10XB,

XX11XB}) the byte-enable signals indicate that valid data is requested or being transferred on

the co r re spon di ng byte on th e 6 4 bit da t a bus. BE0 # in dica tes D [7 :0] # is valid, B E1# in di cat es

D[15:8]# is valid, ..., BE7# indicates D[63:56]# is valid.

For Speci al tr ans act io ns ((R EQa [4:0]# = 01000B) and (REQb[ 1: 0]# = 01B)), the BE[7:0]# si g-

nals carry special cycle encodings as defined in Table A-3. All other encodings are reserved.

Table A-2. ATTR[7:0]# Field Descriptions

ATTR[7:3]# ATTR[2]# ATTR[1:0]#

Reserved (0) Potentially

Speculatable

11 10 01 00

WriteBack WriteProtect WriteThrough UnCacheable

Table A-3. Special Transaction Encoding on BE[7:0]#

BE[7:0]# Special Cycle

0000 0000 Reserved

0000 0001 Shutdown

0000 0010 Flush

0000 0011 Halt

0000 0100 Sync

0000 0101 Flush Acknowledge

0000 0110 Stop Clock Acknowledge

0000 0111 SMI Acknowled ge

0000 1000 through 1111 1111 Reser ved

A-6

SIGNALS REFERENCE

For Deferred Reply, Interrupt Acknowledge, and Branch Trace Message transactions, the

BE[7:0]# signals are undefined.

A.1.10. BERR# (I/O)

The BERR# signal is the Error g roup Bus Error signal. It is asserted to indicate an unrecover able

error without a bus protocol violation.

The BERR# protocol is as f ollows: If an agent detects an un reco v erable error for which BERR#

is a valid error response and BERR# is sampled inactiv e, it asserts BERR# for three clocks. An

agent can assert BERR# only after observing that the signal is inactive. An agent asserting

BERR# must deassert the signal in two clocks if it observes that another agent began asserting

BERR# in the previous clock.

BERR# asse rtion conditio ns are de f in ed b y th e syst em conf i gurati on. Co nf igu ration o ption s en-

able the BERR# driv er as follo ws:

•enabled or disabled

•asserted option ally for internal errors along with IERR#

•optionally asserted by the request initiator of a bus transaction after it observes an error

•asserted by any bus agent when it observes an error in a bus transaction

BERR# sampling conditions are also defined by the system configuration. Configuration op-

tions enable the BERR# receiver to be enabled or disabled. When the bus agent samples an ac-

ti ve BERR# signal and if MCE is enabled, the Pentium Pro processor enters the Machine Check

Handler. If MCE is disabled, typically the central agent forwards BERR# as an NMI to one

of the processors. The Pentium Pro processor does not support BERR# sampling (always

disabled).

A.1.11. BINIT# (I/O)

The BINIT# signal is the bus initialization signal. If the BINIT# driver is enabled during the

po wer on configu ration, BINIT# is asserted to signal any b us condition that pre ven ts reliable fu-

ture information.

The BINIT# protoc ol is as follow s: If an agent detects an error fo r which BINIT# is a v alid error

response, and BINIT# is sampled inactive, it asserts BINIT# for three clocks. An agent can as-

sert BINIT# only after observing that the signal is inactive. An agent asserting BINIT# must

deassert the signal in two clocks if it observes that another agent began asserting BINIT# in the

previous c l ock.

If BINIT# obs ervat ion is enabled duri ng po wer-on conf igurat ion, and BINIT# is sampled assert -

ed, all bus state machines are reset. All agents reset their rotat ing ID for bus arbitration to th e

state after reset, and internal count information is lost. The L1 and L2 caches are not affected.

If BINIT# observation is disabled during power-on configuration, BINIT# is ignored by all bus

agents except a central agent that must handle the error in a manner appropriate to the system

architecture.

A-7

SIGNALS REFERENCE

A.1.12. BNR# (I/O)

The BNR# signal is the Block Next Request signal in the Arbitration group. The BNR# signal

is used to assert a bus stall by any bus agent who is unable to accept new bus transactions to

avoid an internal transaction queue overflow. During a bus st all, the current bus owner cannot

issue any new transactions.

Since multiple agents might need to request a bus stall at the same time, BNR# is a wire-OR

signal. In order to avoid wire-OR glitches associated with simultan e ous edge trans itions driven

by multiple drivers, BNR# is activated on specific clock edges and sampled on specific clock

edges. A valid bus stall involves assertion of BNR# for one clock on a well-defined clock edge

(T1), fol lowed by d e-assertion of BNR# for one clock on the ne xt clock edge (T1+1). BNR# can

fi rst be sampled on t he second clock edge (T1+1) and must alw ays be ig nored on the third clock

edge (T1+2). An extension of a bus stall requires one clock active (T1+2), one clock inactive

(T1+3) BNR# sequence with BNR# sampling points every two clocks (T1+1, T1+3,...).

After the RESET# acti ve-to-inactive transition, b u s agents migh t need to p erfo rm h ardw are in i-

tialization of their b us unit logic. Bus agents intending to create a request stall must assert BNR#

in the clock after RESET# is sampled inactive.

After BINIT# assertion, all bus agents go through a similar hardware initialization and can cre-

ate a request stall by asserting BNR# four clocks after BINIT# assertion is sampled.

On the first BNR# sampling clock that BNR# is sampled inactive, the current bus owner is al-

lowed to issue one new request. Any bus agent can immediately reassert BNR# (four clocks

from the previous assertion or two clocks from the previous de-assertion) to create a new bus

stall. This throttling mechanism enables indep endent control on every new request generation.

If BNR# is deasserted on two consecuti ve sampling points, ne w requests can be freely generated

on the bus. After receiving a new transaction, a bus agent can require an address stall due to an

anticipated transaction-queue overflow condition. In response, the bus agent can ass ert BNR#,

three clocks from active ADS# assertion and create a bus stall. Once a bus stall is created, the

bus remains stalled until BNR# is sampled asserted on subsequent sampling points.

A.1.13. BP[3:2]# (I/O)

The BP[3:2]# signals are the System Support group Breakpoint signals. They are out puts from

the Pentium Pro processor that indicate the status of breakpoints.

A.1.14. BPM[1:0]# (I/O)

The BPM[1:0]# signals are more System Support group breakpoint and performance monitor

signals. The y are outp uts fro m the Pen tium Pro pro cessor that indicate the status of b reakp oints

and programmable counters used for monitoring Pentium Pro processor performance.

A-8

SIGNALS REFERENCE

A.1. 15. BPRI# (I)

The BPRI# signal is the Priority-agent Bus Request signal. The priority agent arbitrates for the

bus by asserting BPRI#. The priority agent is always be the next bus owner. Observing BPRI#

acti ve causes the current symmetric o wner to stop issuing new requests, unless such requests are

part of an ongoing locked operation.

If LOCK# is sampled inactive two clocks from BPRI# driven asserted, the priority agent can

issue a ne w r equest within four clocks of asserting BPRI#. The p riority agent can further reduce

its arbitration latency to two clocks if it samples activ e ADS# and inacti ve LOCK# on the clock

in which BPRI# was driven active and to three clocks if it samples active ADS# and inactive

LOCK# on the clock in which BPRI# was samp led active. If LOCK# is samp led active, the pri-

ority agent must wait for LOCK# deasserted and gains bus ownership in two clocks after

LOCK# is sampled deasserted. The priority agent can keep BPRI# asserted until all of its re-

quests are completed and can release the bus by de-asserting BPRI# as early as the same clock

edge on which it iss ues the last request.

On observation of active AERR#, RESET#, or BINIT#, BPRI# must be deasserted in the next

clock. BPRI# can be reasserted in the clock after sampling the RESET# active-to-inactive tran-

sition or three clocks after sampling BINIT# acti ve and RESET# inactiv e. On AERR# assertion,

if the priority ag ent is in the m id dle of a bus-locked operation, BPRI# must be re-asserted after

two clocks, otherwise BPRI# must stay inactive for at least 4 clocks.

After the RESET# inactive transition, Pentium Pro processor bus agents begin BPRI# and

BNR# sampling on BNR# sample points. When both BNR# and BPRI# are observed inactive

on a BNR# sampling point, the APIC units in Pentium Pro processors on a common APIC bus

are synchronized. In a system with multiple Pentiu m Pro processor bus clusters sharing a com-

mon APIC bus, BPRI# signals of all clusters m ust be asserted after RESET# until BNR# is ob-

served inactive on a BNR# sampling point. The BPRI# signal on all Pentium Pro processor

buses must then be d easserted within 100n s of each other to acco mplish APIC b us synchroniza-

tion across all processors.

A.1.16. BR0#(I/O), BR[3:1]# (I)

The BR[3:0]# pins are the physical bus request pins that drive the BREQ[3:0]# signals in the

system. The BREQ[3:0]# signals are interconnected in a rotating manner to indi vidual processor

pins. #. Table A-4 gives the rotating interconnect between the processor and bus signals.

Table A-4. BR0#(I/O), B R1#, BR2#, BR3# Signals Rotating Interconnect

Bus Signal Agent 0 Pins Agent 1 Pins Agent 2 Pins Agent 3 Pins

BREQ0# BR0# BR3# BR2# BR1#

BREQ1# BR1# BR0# BR3# BR2#

BREQ2# BR2# BR1# BR0# BR3#

BREQ3# BR3# BR2# BR1# BR0#

A-9

SIGNALS REFERENCE

During po wer-up configuration, the cen tral ag ent m ust assert the BR0# bus signal. All symmet-

ric agents sample their BR[3:0]# pins on active-to-inactive transition of RESET#. The pin on

which the agent samples an active level determines its agent ID. All agents then configure their

pins to match the appropriate bus signal protocol, as shown in Table A-5.

A.1.17. BREQ[3:0]# (I/O)

The BREQ[3:0]# signals are the Symmetric-agent Arbitration Bus s ign als (called bus request).

A symmetric agent n arbitrates for the bus by asserting its BREQn# signal. Agent n drives

BREQn# as an output and receives the remaining BREQ[3:0]# signals as inputs.

The symmetric agents support distributed arbitration based on a round-robin mechanism. The

rotating ID is an internal state used by all symmetric agents to track the agent with the lowest

priority at the next arbitration ev ent. At po wer-on, the rotating ID is initialized to three, allowing

agent 0 to be the highest priority symmetric agent. After a new arbitration e v ent, the rotating ID

of all symmetric agents is updated to the agent ID of the symmetric o wner . This update giv es the

new symmetric owner lowest priority in the next arbitration event.

A new arbitration event occurs either when a symmetric agent asserts its BREQn# on an Idle

bus (all BREQ[3:0]# previously inactive), or the current symmetric owner de-asserts BR EQm#

to release the bus ownership to a new bus owner n. On a new arbitration event, based on

BREQ[3:0]#, and the rotating ID, all symmetric agents simultaneously determine the new sym-

metric owner. The sym metric owne r can park on the bus (hold the bus) provided that no oth er

symmetric agent is requesting its use. The symm e tri c owner parks by keeping its BREQn# sig-

nal active. On sampling active BREQm# asserted by another symmetric agent, the symmetric

owner de-asserts BREQn# as soon as possible to release the bus. A symmetric owner stops is-

suing new requests that are not part of an existing locked operation upon observing BPRI# ac-

tive.

A symmetric agent can not deassert BREQn# until it becomes a symmetric owner. A symmetric

agent can reassert BREQn# after keeping it inactive for one clock.

On observation of active AERR#, RESET#, or BINIT#, the BREQ[3:0]# signals must be deas-

serted in the next clock. BREQ[3:0]# can be r easserted in the clock after sampling the RESET#

acti ve-to-inacti v e transition or three clocks after sampling BINIT# acti ve and RESET# inacti ve .

On AERR# assertion, if bus agent n is in the middle of a bus-locked operation, BREQn# must

be re-asserted after two clocks, otherwise BREQ[3:0]# must stay inactive for at least 4 clocks.

Table A-5. BR[3:0]# Signal Agent IDs

Pin Sampled Active on RESET# Agent ID

BR0# 0

BR3# 1

BR2# 2

BR1# 3

A-10

SIGNALS REFERENCE

A.1.18. D[63:0]# (I/O)

The D[63:0]# signals are the data signals. They are driven during the Data Phase by the agent

responsible for driving the data. These signals provide a 64-bit data path between various Pen-

tium Pro processor b us agents. 32-b yte line transfers require f our data transfer clock s with v alid

data on all eight bytes. Partial transfers require one data transfer clock with valid data on the

byte(s) indicated b y acti v e b yte enables BE[7:0]#. Data signals not v alid for a par ticular transfer

must still have correct ECC (if data bus ECC is selected). If BE0# is asserted, D[7:0]# transfers

the least significant byte. If BE7# is asserted, D[63:56]# transfers th e most significant byte.

The data dri v er asserts DRDY# to indicate a v alid data transfer. If the Data Phase in v olv es more

than one clock the data driver also asserts D BSY# at the beginning of the Data Phase and de-

asserts DBSY# no earlier than on the same clock that it performs the last data transfer.

A.1.19. DBSY# (I/O)

The DBSY# signal is the Data-bus Busy signal. It indicates that the data bus is busy . It is asserted

by the agent responsibl e for dri ving the data during the Data Phase, provide d the Data Phase in-

volves more than one clock. DBSY# is as serted at the beginning of the Data Phase and may be

deasserted on or after the clock on which the last data is driven. The data bus is released one

clock after DBSY# is deasserted.

When normal read data is being returned, the Data Phase be gins with the Response Phase. Thus

the agent returning read data can assert DBSY# when the transaction reaches the top of the In-

order Queue and it is ready to return response on RS[2:0]# signals. In response to a write r equest,

the agent driving the write data must dr ive DBSY# active af ter the wr ite tr ansaction reach es the

top of the In-order Queue and it sees active TRDY# with inactive DBSY# indicating that the

target is ready to receive data. For an implicit writeback response, the snoop agent must as-

sert DBSY# active after the target memory agent of the implicit writeb ack asserts TRDY#. Im-

plicit writeback TRDY# assertion begins after the transaction reaches the top of the In-order

Queue, and TRDY# de-assertion associated with the write portion of the transaction, if any is

completed. In this case, the memory agent guarantees assertion of implicit writeback response

in the same clock in which the snooping agent asserts DBSY#.

A.1.20. DEFER# (I)

The DEFER# signal is the defer signal. It is asserted by an agent during the Snoop Phase to in-

dicate that the transaction cannot be guaranteed in-order completion. Assertion of DEFER# is

normally the responsibility of the addressed memory agent or I/O agent. For systems that in-

volve resources on a system bus other than the Pentium Pro processor bus, a bridge agent can

accept the DEFER# assertion respon sibility on behalf of the addressed agent.

When HITM# and DEFER# are both active during the Snoop Phase, HITM# is given priority

and the trans action m ust be co mpleted w ith im plicit w riteback respo nse. If HITM# i s inactive,

and DEFER# acti ve, the agent asserting DEFE R# must complete the transaction with a Deferred

or Retry response.

A-11

SIGNALS REFERENCE

If DEFER# is inactive, or HITM# is active, then the transaction is committed for in-order com-

pletion a nd snoop own ership is transfer red normal ly between t he requesti ng agent, the snoo ping

agents, and the response agent.

If DEFER# is active with HITM# inactive, the transaction commitment is deferred. If the defer

agent completes the transaction with a retry response, the requ esting agen t must retry the trans-

action. If the defer agent returns a deferred response, the requesting agent must freeze snoop

state transitions associated with the deferred transaction and issues of new order-dependent

transactions until the corresponding deferred reply transaction. In the meantime, the ownership

of the deferred address is transferred to the defer agent and it must guarantee management of

conflicting transactions issued to the same address.

If DEFER# is active in response to a newly issued bus-lock transaction, the entire bus-locked

operation is re-initiated regardless of HITM#. This feature is useful for a bridge agent in re-

sponse to a split bus-lock ed operation. It is recommended that the bridge agent e xtend the Snoop

Phase of the first transaction in a split lo cked operation until it can either g uarantee ownersh ip

of all system resources to enable successful completion of the split sequence or assert DEFER#

followed by a Retry Resp onse to abort the split seq uence.

A.1.21. DEN# (I/0)

The DEN# signal is the defer-enable signal. It is driven to the bus on the second clock of the

Request Phase on the EXF1#/Ab4# pin. DEN# is asserted to indicate that the transaction can b e

deferred by the responding agent.

A.1.22. DEP[7:0]# (I/O)

The DEP[7:0] # signals are the data b us ECC prot ection signal s. The y are dri ven during t he Data

Phase by the agent responsible for driving D[63:0]#. The DEP[7:0]# signals provide optional

ECC protection for the data bus. During power-on configuration, DEP[7:0]# signals can be en-

abled for either ECC checking or no checking.

The ECC error correcting code can detect and correct single-bit errors and detect double-bit or

nibble errors. Chapter 8, Data Integrity provides more information ab out ECC.

DEP[7:0]# provide valid ECC for the entire data bus on each data clock, regardless of which

bytes are valid. If checking is enabled, receiving agents check the ECC signals for all 64 data

signals.

A.1.23. DID[7:0]# (I/O)

The DID[7:0]# signals are Deferred Identif ier signals. They are transferred u sing A[23:16]# sig-

nals by the request initiator. They are transferred on Ab[23:16]# during the second clock of the

Request Phase on all transactions, b ut only defined for defe rrable transactions (DEN# asserted).

DID[7:0]# is als o t ransferred on Aa[23:16]# d uring th e first clock of t he Req uest Phase for De-

ferred Reply tranactions.

A-12

SIGNALS REFERENCE

The deferred iden tifier defines the token s upplied by the request initiato r. DID[7:4]# carry the

request initiators’ agent identifier and DID[3:0]# carry a transaction identifier associated with

the request. This configuration limits the bus specification to 16 bus masters with each one of

the bus masters capable of making up to sixteen requests.

Every def e rrable t rans acti on is sued on the Pen tiu m Pro proces s or bus which has not been guar -

anteed completion (has not successfully passed its Sn oop Result Phase) will have a unique De-

ferred ID. This includes all outstanding transactions which have not had their snoop result

reported, or ha ve had their snoop resu lts deferred. After a deferrable transaction passes its Snoop

Result Phase without DEFER# asserted, its Deferred ID may be reused. Similarly, the deferred

ID of a transaction which was deferred may be reused after the completion of the snoop windo w

of the deferred reply.

DID[7]# indicates the agent type. Symmetric agents use 0. Priority agents use 1. DID[6:4]# in-

dicates the agent ID. Symmetric agents use their arbitration ID. The Pentium Pro processor has

four symmetric agents, so does not assert DID[6]#. DID[3:0]# indicates the transaction ID for

an agent. The transaction ID must be unique for all transactions iss ued by an agent which have

not reported their snoop results.

The Deferred Reply agent transmits the DID[7:0]# (Ab[23:16]#) signals received during the

original transaction on the Aa[23 :16]# signals during the Deferred Reply transaction. This pro-

cess enables the original request in itiator to make an identifier match and wake up the original

request waiting for completion.

A.1.24. DRDY# (I/O)

The DRDY# signal is the Data Phase data-ready signal. The data dri v er asserts DRDY# on each

data transfer, indicating valid data on the data bus. In a mu lti-cycle data transfer, DRDY# can

be deasserted to insert idle clock s in the Data Phase. During a line transfer, DRDY# is activ e for

four clocks. During a partial 1-to-8 b y te transfer, DRD Y# is acti v e fo r one clock. If a data trans-

fer is exactly on e clock, then the entire Data Phase may consist of on ly one clock acti ve DR D Y#

and inactive DBSY#. If DBSY# is asserted for a 1-to-8 byte transfer, then the data bus is not

released until one clock after DBSY# is deass erted.

A.1.25. DSZ[1:0] # (I/ O)

The DSZ[1:0]# signals are the data-size signals. They are transferred on REQb[4:3]# signals in

the second cloc k of Re qu est Phase b y the req uesting age nt. Th e DSZ[1:0 ]# signals define the

data transfer capability of the requesting agent. For the Pentium Pro processor, DSZ#= 00,

always.

Table A-6. DID[7:0]# Encoding

DID[7]# DID[6:4]# DID[3:0]#

Agent Type Agent ID Transaction ID

A-13

SIGNALS REFERENCE

A.1.26. EXF[4:0]# (I/O)

The EXF[4:0]# signals are the Extend ed Function signals. The y are transferred on the Ab[7:3]#

signals by the req uest initiator during the second clock of the R equest Phase. The signals specify

any special functiona l requireme nt associated with the transaction based on the requestor mod e

or capability. The signals are defined in Table A-7.

A.1.27. FERR# (O)

The FERR# signal is the PC Compatibility group Floating-point Error signal. The Pentium Pro

processor asserts FERR# when it detects an unmasked floating-point error. FERR# is similar to

the ERROR# s ignal on the Intel387™ coprocessor. FER R# is included for compatibility wi th

systems using DOS-type floating-point error reporting.

A.1 .28. FLUSH# (I)

When the FLUSH# input signal is asserted, the Pentium Pro processor b us agent writes back all

internal cache lines in th e Mod ified state and invalidates all internal cach e lines. At the comp le-

tion of a flush oper ation, the Pentium Pro processor issues a Flush Acknowledge tr ansac tion to

indicate that the cache flush operation is complete. The Pentium Pro processor stops caching any

new data while the FLUSH# signal remains asserted.

FLUSH# is an asynchronous input. However, to guarantee recognition of this signal following

an I/O write i nstructio n, FLUSH# m us t b e valid along with RS[2:0]# in th e Response Phase of

the corresponding I/O Write bus transaction. In FRC mode, FLUSH# must be synchronous to

BCLK.

On the active-to-inactive transition of RESET#, each Pentium Pro processor bus agent samples

FLUSH# to de termine its power-on con figuration. See Table 9-4.

Table A-7. EFX[4:0]# Signal Definitions

EXF Name Extended

Functionality When Activated

EXF4# SMMEM# SMM Mode After enter ing SMM m ode

EXF3# SPLCK# Split Lock The first transaction of a split bus lock operation

EXF2# Reserved Res erved

EXF1# DEN# Defer Enable The transactions for which Defer or Retry Response is

acceptable.

EXF0# Reserved Reserved

A-14

SIGNALS REFERENCE

A.1.29. FRCERR(I/O)

The FRCERR signal is the Error group Functional-redundancy-check Error signal. If two Pen-

tium Pro processors are configured in an FRC pair, as a single “logical” processor, then the

checker processor asserts FRCERR if it detects a mismatch between its internally sampled out-

puts and the master processor’s outputs. The checker’s FRCERR output pin is connected to the

master’s FRCERR input pin.

For point-to-point connections, the checker always compares against the master’s outputs. For

bussed single-dri ver signa ls, the checker compares ag ainst the signal when the master is the only

allowed driver. For bussed multiple-driver Wire-OR signals, the checker compares against the

signal only if the master is expected to drive the signal low.

FRCERR is also toggled during the Pentium Pro processor’s reset action. A Pentium Pro pro-

cessor asserts FRCERR for approximately 1 second after RESET’s active-to-inactive transition

if it executes its built-in self-test (BIST). When BIST execution completes, the Pentium Pro pro-

cessor de-assert s FRCERR if BIST completed su ccessfully and con tinues to ass e rt FRCERR if

BIST fails. If the Pentium Pro processor does not execute the BIST action, then it keeps

FRCERR asserted for approximately 20 clocks and then de-asserts it.

Chapte r 9, Configuration describes how a Pen tium Pr o pro cessor can be con figured as a master

or a checker.

A.1.30. HIT# (I/O), HITM#(I/O)

The HIT# and HITM# signals are Snoop-hit and Hit-modified signals. They are snoop results

asserted by any Pentium Pro processor bus agent in the Snoop Phase.

Any bus agent can assert both HIT# and HITM# together for one clock in the Snoop Phase to

indicate that it requires a snoop stall. When a stall condition is s ampled, all bus agents extend

the Snoop Phase by two clocks. The stall can be continued by reasserting HIT# and H ITM# to-

gether every other clock for one clock.

A caching agent must assert HITM# for one clock in the Snoop Phase if the transaction hits a

Modif ied lin e, and the snoopi ng agent mu st perfor m an implicit writeback to up date main mem-

ory. The snooping agent with the Modif ied line makes a transition to Shared state if the original

transaction is Read Line or Read Partial, otherwise it transitions to In v alid state. A Deferred Re-

ply transaction may have HITM# asserted to indicate the return of unexpected data.

A snooping agent mus t assert HIT# for one clock durin g the Snoop Phase if the line does not hit

a Modified line in its writeback cache and if at the end of the transaction it plans to keep the line

in Shared state. Multiple caching agents can assert HIT# in the same Snoop Phase. If the request-

ing agent observes HIT# active during the Snoop Phase it can not cache the line in Exclusive or

Modified state.

On observing a snoop stall, the agents asserting HIT# and HITM# independently reassert the

signal after one inactive clock so that the correct snoop result is available, in case the Snoop

Phase terminates after the two clock extension.

A-15

SIGNALS REFERENCE

A.1.31. IERR# (O)

The IERR# signal is the Error group Internal Error signal. A Pentium Pro processor asserts

IERR# when it observes an internal error. It keeps IERR# asserted until it is turned off as part

of the Machine Check Error or the NMI handler in software, or with RESET#, BINIT#, and

INIT# assertion.

An internal error can be handled i n se veral ways ins ide the pro cessor based on its p ower -on con-

fi guration. If Machine Check Ex ception (MCE) is enabled, IERR# causes an MCE entry. IERR#

can also be directed on th e BERR# pin to indicate an erro r. Usually BERR# is sampled back b y

all processors to enter MCE or it can be redirected as an NMI by the central agent.

A.1.3 2. IGNNE# (I)

The IGNNE# signal is the PC Compatibility group Ignore Numeric Error signal. If IGNNE# is

asserted, the Pentium Pro processor ignor es a numeric erro r and continues to execute non-

control floating-point instructions. If IGNNE# is deasserted, the Pentium Pro processor freezes

on a non-control floating-point instruction if a previous instruction caused an error.

IGNNE# has no effect when the NE bit in control register 0 is set.

IGNNE# is an asynchronous input. However, to guarantee recognition of this signal following

an I/O write instruction, IGNNE# must be valid along with RS[2:0]# in the Response Phase of

the corresponding I/O Write bus transaction. In FRC mode, IGNNE# must be synchronous to

BCLK.

During active RESET#, the Pentium Pro processor begins sampling the A20M# , IGNNE# and

LINT[1:0] v alues to determine the ratio o f core-clock frequenc y to b us-clock frequenc y. See Ta-

ble 9-4. After the PLL-lock time, the core clock becomes stable and is locked to the extern al bus

clock. On the activ e-to-inacti ve transition of RESET#, the Pentium Pro processor latches the ra-

tio and freezes the frequency ratio internally.

A.1.33. INIT# (I)

The INIT# signal is the Execution Control group initialization signal. Activ e INIT# input resets

integer registers inside all Pentium Pro processors without affecting their internal (L1 or L2)

caches or their floating-point registers. Each Pentium Pro processor begins execution at the

power-on reset vector configured during power-on configuration regardless of whether INIT#

has gone inactive. The processor continues to handle snoop requests during INIT# assertion.

INIT# can be used to help performa nce of DOS e xtenders written for the Intel 8028 6 process or.

INIT# provides a method to switch from protected mode to real mode while maintaining the

contents of the intern al caches and floating-point state. INIT# can not be used in lieu of RESET#

after power-up.

On active-to-inactive transition of RESET#, each Pentium Pro processor bus agent samples

INIT# signals to determine its power-on configuration.

INIT# is an asynchronous input. In FRC mode, INIT# must be synchronous to BCLK.

A-16

SIGNALS REFERENCE

A.1.34. INTR (I)

The INTR signal is the Interrupt Request signal. The INTR input indicates that an external in-

terrupt has been generated. The interrupt is maskable usin g the IF bit in the EFLAGS register.

If the IF bit is set, the Pen tium Pro processor vectors to the interrupt hand ler after the current

instruction execution is completed. Upon recognizing the interrupt request, the Pentium Pro pro-

cessor issues a single Interrup t Acknowledge (INTA) bus transaction. INTR must rem ain active

until the INTA bus transaction to guarantee its recognition.

INTR is sampled on every rising BCLK edge. INTR is an asynchronous in put but recog nition

of INTR is guar anteed in a specif ic clock if it is asserted synchro nously and meets the setup and

hold times. INTR must also be deasserted for a minimum of two clocks to guaran tee its inacti ve

recognition. In FRC mode, INTR must be synchronous to BCLK. On power-up the LINT[1:0]

signals are used for power-on-configuration of clock ratios. Both these signals must be software

configured b y programming the APIC re gister space to be used either as NMI/INTR or LINT[1:0]

in the BIOS. Because APIC is enabled after reset, LINT[1:0] is the default configuration.

A.1.35. LEN[1:0]# (I/O )

The LEN[1:0]# signals are data-len gth sign a ls. They are transmitted using REQb[1:0]# sig nals

by the request initiator in the second clock of Request Phase. LEN[1:0]# define the length of the

data transfer requested by the request initiator as defined in Table A-8. The LEN[1:0]#, HITM#,

and RS[2:0]# signals together define the length of the actual data transfer.

A.1.36. LINT[1:0] (I)

The LINT[1:0] signals are the Execution Control group Local Interrupt signals. When APIC is

disabled, the LINT0 signal becomes INTR, a maskable interrupt request signal, and LINT1 be-

comes NMI, a non-maskable interr upt. INTR and NMI are backward co mpatible with the same

signals for the Pentium processor. Both signals are asynchronous inputs. In FRC mode,

LINT[1:0] must be synchronous to BCLK.

During acti ve R ESET#, the Pentium Pro pr ocessor continuously samples the A20M#, IG NNE#,

and LINT[1:0] values to determine the ratio of core-clock frequency to bus-clock frequency. Af-

ter the PLL-lock time, the core clock b ecomes stable and is locked to the e xternal b us clock. On

the activ e-to-inactiv e transition of RESET#, the Pentium Pro processor freezes the frequency ra-

tio internally.

Table A-8. LEN[1:0]# Signals Data Transfer Lengths

LEN[1:0]# Request Initiator’s Data Transfer Length

00 0-8 Bytes

01 16 Bytes

10 32 Bytes

11 Reserved

A-17

SIGNALS REFERENCE

Both of these signals must be software configured by programming the APIC register space to

be used either as NM I/INTR or LINT[1:0] in the BIOS. Because A PIC is enabled after reset,

LINT[1:0] is the default configuration.

A.1.37. LOCK# (I/O)

The LOCK# signal is the Arbitration group bus lock signal. For a locked sequence of transac-

tions, LOCK# is asserted from the first transaction’ s Request Phase through the last transaction’ s

Response Phase. A locked operation can be prematurely aborted (and LOCK# deasserted) if

AERR# or DEFER# is asserted during the first bus transaction of the sequence. The sequence

can also be prematurely aborted if a hard error (su ch as a hard failure response or AERR# asser-

tion beyond the retry limit) occurs on any one of the transactions during the locked operation.

When the priority agent ass erts BPR I# to arbitrate for bus ownership, i t waits until it observes

LOCK# deasserted. This enables symmetric agents to retain bus ownership throughout the bus

locked operation and g uarantee the atomicity of lock. If AERR# is asserted up to the retry limit

during an ongoing locked operation, the arbitration protocol ensures that the lock owner receiv es

the bus ownership after arbitration logic is reset. This result is accomplished by requiring the

lock owner to reactivate its arbitration request one clock ahead of other agents’ arbitration re-

quest. LOCK# is kept asserted throughout the arbitration reset sequence.

A.1.38. NMI (I )

The NMI signal is the Non-maskable Interrupt signal. It is t he state of the LINT1 signal when

APIC is disabled. Asserting NMI causes an interrupt with an internally supplied vector value of

2. An e xter nal inte rrupt-ac knowledge transactio n is not genera ted. If NMI is asserted duri ng th e

ex ecution of an NMI service routine, it rem ains pend ing an d is reco gnized after th e IRET is e x-

ecuted by the NMI service routine. At most, one asserti on of NMI is held pending.

NMI is rising-edge sensitiv e. Recognition of NMI is guaranteed in a specif ic clock if it is assert-

ed synchronously an d meets the setup and hold times. If asserted asynchronously, active an d in-

acti ve puls e widths must be a minimum of two clocks. In FRC mode, NMI must be synchr onous

to BCLK.

A.1.39. PICCLK (I)

The PICCLK signal is the Execution Control group APIC Clock signal. It is an input clock to

the Pentium Pro processor for synchronous operation of the APIC bus. PICCLK must be syn-

chronous to BCLK in FRC mode.

A.1.40. PICD[1:0] (I/O)

The PICD[1:0] signals are the Execution Control group APIC Data signals. They are used for

bidirectional serial message passing on the APIC bus.

A-18

SIGNALS REFERENCE

A.1.41. PWR_GD (I)

PWR_GD is driven to the Pentium Pro processor by the system to indicate that the clocks and

power supplies are within their specification.

This signal is used within the Pentium Pro processor to protect circuits against voltage sequenc-

ing issues. While the MTBF of a Pentium Pro processor is on the same order as previous pro-

cessors without the use of the PWR_GD pin, the use of this signal further increases the Mean

Time Between Failures (MTBF) of the Pentium Pro processor component.

This signal will not affect FRC operation.

A.1.42. REQ[4:0]# (I/O)

The REQ[4:0]# signals are the Request Command signals. They are asserted by the current bus

o wner in bo th clock s of the Request Phase. In the first clock, the REQa[4:0]# signals def in e the

transaction type to a level of detail that is sufficient to begin a snoop request. In the second clock,

REQb[4:0]# signals carry additional information to define the complete transaction type.

REQb[4:2]# is reserved. REQb[1:0]# signals transmit LEN[1:0]# (the data transfer length infor-

mation). In both clocks, REQ[4:0]# and ADS# are protected by parity RP#.

All receiving agents observe the REQ[4:0]# signals to determine the transaction type and par-

ticipate in the transaction as necessary, as shown in Table A-9.

Table A-9. Transaction Types Defined by REQa#/REQb# Signals

Transaction

REQa[4:0]# REQb[4:0]#

432 1 043210

Deferred Reply 0 0 0 0 0 x x x x x

Rsvd

(Ignore)

000 0 1xxxxx

Interrupt Acknowledge 0 1 0 0 0 DSZ# x 0 0

Special Transactions 0 1 0 0 0 DSZ# x 0 1

Rsvd

(Central agent

response)

010 0 0 DSZ# x1x

Branch Trace Message 0 1 0 0 1 DSZ# x 0 0

Rsvd

(Central agent

response)

010 0 1 DSZ# x01

Rsvd

(Central agent

response)

010 0 1 DSZ# x1x

I/O Read 1 0 0 0 0 DSZ# x LE N#

A-19

SIGNALS REFERENCE

A.1.43. RES ET# (I)

The RESET# signal is the Execution Control group reset signal. Asserting RESET# resets all

Pentium Pro processors to known states and invalidates their L1 and L2 caches w ithout writing

back Modified (M state) lines. RESET# must remain active for one microsecond for a “warm”

reset. For a power-on type reset, RESET# must stay active fo r at least one millisecond af ter Vcc

and CLK have reached their proper DC and AC specifications. On observing active RESET#,

all bus agent s must deassert their outputs within two clocks.

A number of bus signals are sampled at the active- to-inactive transition of RESET# for the pow-

er-on configuration. The configuration options are described in Chapter 9, Configuration and in

every signal descriptio n in this chapter.

Unless its outputs are tristated during po wer-on configuration, after active-to-inactiv e transition

of RESET#, the P entiu m Pro p rocesso r optional ly executes its built-in self-test (BIST) and be -

gins program execution at reset-vector 0_000F_FFF0H or 0_FFFF_FFF0H.

A.1.44. R P# (I/O)

The RP# signal is the Request Parity signal. It is dri ven by the request initiator in both clocks of

the Request Phase. RP# provides parity protection on ADS# and REQ[4:0]#. When a Pentium

Pro processor bus agent observes an RP# parity error on any one of the two Request Phase

clocks, it must assert AERR# in the Erro r Phase, pro vided “AERR# dri v e” is en abled dur ing the

power-on configuration.

I/O Write 1 0 0 0 1 DSZ# x LEN#

Rsvd

(Ignore)

110 0 x DSZ# xxx

Memory Read &

Invalidate ASZ# 0 1 0 DSZ# x LEN#

Rsvd

(Memory Write)

ASZ# 0 1 1 DSZ# x LEN#

Memory Code Read ASZ# 1 D/C#=

00 DSZ# x LEN#

Memory Data Read ASZ# 1 D/C#=

10 DSZ# x LEN#

Memory Write (may not

be retried) ASZ# 1 W/WB

#=0 1 DSZ# x LEN#

Memory Write (may be

retried) ASZ# 1 W/WB

#=1 1 DSZ# x LEN#

Table A-9. Transaction Types Defined by REQa#/REQb# Signals

Transaction

REQa[4:0]# REQb[4:0]#

432 1 043210

A-20

SIGNALS REFERENCE

A correct parity signal is high if an even number of covered signals are low and low if an odd

number of covered signals are lo w. This definition allo ws parity to be high when all covered sig-

nals are high.

A.1.45. RS[2:0]#(I)

The RS[2:0]# signals are the Response Status signals. They ar e driv en by the response agent (the

agent responsible for completion of the transaction at the top of the In-order Queue). Assertion

of RS[2:0]# to a non-zero value for one clock completes the Response Phase for a transaction.

The response encodings are sho wn in Table A-10. Only certain response combination s are valid,

based on the snoop result signaled during the transaction’s Snoop Phase.

The RS[2:0]# assertion for a transaction is initiated when all of the following conditions are met:

•All bus agents have observed the Snoop Phase completion of the transaction.

•The transaction is at the top of the In-order Queue.

•RS[2:0]# are sample d in the Idle state

The response driven depends on the transaction as described below:

•The response agent returns a hard-failure response for any transaction in which the

response agent observes a hard error.

•The response agent returns a Normal with data response for a read transaction with HITM#

and DEFER# deasserted in the Snoop Phase, when the addressed agent is ready to return

data a nd sa m p les inac tive DB SY#.

Table A-10. Transaction Response Encodings

RS[2:0]# Description HITM# DEFER#

000 Idle State. NA NA

001 Retry Response. The transaction is cancelled and must be

retried by the initiator. 01

010 Defer Response. The transaction is suspended. The defer agent

will complete it with a defer reply 01

011 Reserved. 0 1

100 Hard Failure. The transaction received a hard error. Exception

handling is required. XX

101 Normal without data 0 0

110 Implicit Wr iteback Response. Snooping agent will transfer the

modified cache line on the data bus . 1X

111 Normal with data. 0 0

A-21

SIGNALS REFERENCE

•The response agent returns a Normal without data response for a write transaction with

HITM# and DEFER# deasserted in the Snoop Phase, when the addressed agent samples

TRDY# active and DBSY# inactive, and it is ready to complete the transaction.

•The response agent must return an Implicit writeback response in the next clock for a read

transaction with HITM# asserted in the Snoop Phase, when the addressed agent samples

TRDY# active and DBSY# inactive.

•The addressed agent must return an Implicit writeback response in the clock after the

following sequence is sampled for a write transaction with HITM# asserted:

— TRDY# active and DBSY# inactive

— followed by TRDY# inactive

— followed by TRDY# active and DBSY# inactive

•The defer agent can return a Deferred, Retry, or Split response anytime for a read

transaction with HITM# deasserted and DEFER# asserted.

•The defer agent can return a Deferred or Retry response when it samples TRDY# active

and DBSY# inacti ve for a write transaction with HITM# deasserted and DEFER# asserted.

A.1 .46. RSP# (I)

The RSP# signal is the Response Parity signal. It is driv en by the response agent during assertion

of RS[2:0]#. RSP# provides parity protectio n for RS[2:0]#.

A correct parity signal is high if an even number of covered signals are low and low if an odd

number of covered signals are low. During Idle state of RS[2:0]# (RS[2:0]#=000), RSP# is also

high since it is not driven by any agent guaranteeing correct parity.

Pentium Pro processor bus agents can check RSP# at all times and if a parity error is observed,

treat it as a protocol violation error. If the BINIT# driver is enabled during configuration, the

agent observing RSP# parity error can assert BINIT#.

A.1.4 7. SMI# (I)

System Management I nterrupt is asserted asyn chro nou sly by system logic. On accepting a Sys-

tem Management Interrupt, the Pentium Pro processor saves the current state and enters SMM

mode. It issues an SMI Acknowledge Bus transaction and then begins program execution from

the SMM handler.

A.1.48. SMMEM# (I/O)

The SMMEM# signal is the System Management Mode Memory signal. I t is driv en o n the sec-

ond clock of the Request Phase on the EXF4#/Ab7# signal. It is asserted by the Pentium Pro

processor to indicate that the pro cessor is in System Management Mo de and is executing out of

SMRAM space.

A-22

SIGNALS REFERENCE

A.1.49. SPLCK# (I/O)

The SPLCK# signal is the Split Lock signal. It is d riv en in the second clock o f the Request Phase

on the EXF3#/Ab6# signal of the first transaction of a locked operation. It is driven to indicate

that the locked operation will consist of four locked transactions. Note that SPLCK# is asserted

only for locked operations and only in the first transaction of the locked operation.

A.1.50. STPCLK# (I)

The STPCLK# signal is the Stop Clock signal. When asserted, the Pentium Pro processor enters

a low p o wer state, the Stop Grant state. The pr ocessor issues a Stop Grant Ackno wledge special

transaction, and stops providing internal clock signals to all units except the bus unit and the

APIC unit. The processor continues to snoop bus transactions and service interrupts while in

Stop Grant state. When STPCLK# is deasserted, the processor restarts its internal clock to all

units and resumes execution. The assertion of STPCLK# has no effect on the bus clock.

STPCLK# is an asynchronous input. In FRC mode, STPCLK# must be synchronous to BCLK.

A.1.51. TCK (I)

The TCK signal is the System Support group Test Clock signal. TCK provides the clock input

for the test bus (also known as the test access port). Make certain that TCK is active before ini-

tializing the TAP.

A.1.52. TDI(I)

The TDI signal is the System Support group test-data-in signal. TDI transfers serial test data into

the Pentium Pro processor. TDI provides the serial input needed for JTAG support.

A.1.53. TDO (O)

The TDO signal is the System Support group test-data-out signal. TDO transfers serial test data

out from the Pentium Pro processor. TDO provides the serial output needed for JTAG support.

A.1.54. TMS (I)

The TMS signal is an additional System Support group JTAG-support signal.

A-23

SIGNALS REFERENCE

A.1.55. TRDY# (I)

The TRDY# si gnal is the target Ready signal. It is asserted by the target in the Response Phase

to indicate that the target is ready to receive write or implicit writeback data transfer. This en-

ables the request in itiator or the snooping agent to be gin the app ropriate data transfer. There will

be no data transfer after a TRDY# assertion if a write h as zero length indicated in the Request

Phase. The data transfer is optional if an implicit writeback occurs for a transaction which writes

a full cache line (the Pentium Pro processor will perform the implicit writeback).

TRDY# for a write transaction is driven by the addressed agent when:

•when the transactio n has a write or writeback data transfer

•it has a free buffer available to receive the write data

•a minimum of 3 clocks after ADS# for the transaction

•the transaction reaches the top-of-the-In-order Queue

•a minimum of 1 clock after RS[2:0]# active assertion for transaction “n-1”.

(After the transaction reaches the top of the In-order Queue).

TRDY# for an implicit writeback is driven by the addressed agent when:

•transaction has an implicit writeback data transfer indicated in the Snoop Resul t Phase.

•it has a free cache line buffer to receive the cache line writeback

•if the trans action also h a s a request initiated transfer, that the request initiated TRDY# was

asserted and then deasserted (TRDY# must be deasserted for at least one clock between the

TRDY# fo r the write and the TRDY# for the implicit writeback),

•a minimum of 1 clock after RS[2:0]# active assertion for transaction “n-1”.

(After the transaction reaches the top of the In-order Queue).

TRDY# for a write or an implicit writeback may be deasserted when:

•inactive DBSY# and act ive TRDY# are observed.

•DBSY# is observed inactive on the clock TRDY# is asserted.

•a minimum of three clocks can be guaranteed between two active-to-inactive transitions of

TRDY#

•the response is driven on RS[2:0]#.

•inactive DBSY# and active TRDY# are observed for a write, and TRDY# is required for

an implicit writeback.

A.1.56. TRST# (I)

The TRST# signal is an additional System Support group JTAG-support signal.

A-24

SIGNALS REFERENCE

A.2. SIGNAL SUMMARIES

The following tables list attributes of the Pent ium Pro processo r output, input, an d I/O signals.

NOTE:

1. Outputs are not checked in FRC mode.

Table A-11. Output Signals1

Name Active Level Clock Signal Gr oup

FERR# Low Asynch PC compatibility

IERR# Low Asynch Implementation

PRDY# Low BCLK Implementation

TDO High TCK JTAG

THERMTRIP# Low Asynch Implementation

Table A-12. Input Signals1

Name Active Level Clock Signal Group Qualified

A20M# Low Asynch PC compatibility Always2

BPRI# Low BLCK Pentium® Pro

processor bus Always

BR1# Low BLCK Pentium Pro

processor bus Always

BR2# Low BLCK Pentium Pro

processor bus Always

BR3# Low BLCK Pentium Pro

processor bus Always

BCLK High - Pentium Pro

processor bus Always

DEFER# Low BLCK P entium Pro

processor bus S noop Phase

FLUSH# Low Asynch PC compatibility Always2

IGNNE# Low Asynch PC compatibility Always2

INIT# Low Asynch Pentium Pro

processor bus Always2

INTR High Asynch PC compatibility APIC disa bled mode

LINT[1:0] High Asynch APIC APIC enabled mode

NMI High Asynch PC compatibility A PIC disabled mode

PICCLK High - APIC Always

PWR_GD High Asynch Implementation

PREQ# Low Asynch Implementation

A-25

SIGNALS REFERENCE

NOTES:

1. All asyncronous input signals must be synchronous in FRC

2. Synchronous assertion with active RS[2:0]# guarantees synchronization.

RESET# High BCLK Pentium Pro

processor bus Always

RS[2:0]# Low B CLK Pentium Pro

processor bus Always

RSP# Low BCLK Pentium Pro

processor bus Always

SMI# Low Asynch PC compatibility

STPCLK# Low Asynch Implementation

TCK High - JTAG

TDI TCK JTAG

TMS TCK JTAG

TRST# Low Asynch JTAG

TRDY# Low TCK Pentium Pro

processor bus Response Phase

Table A-13. Input/Output Signals (Single Driver)

Name Active Level Clock Signal Group Qualified

A[35:3]# Low BCLK Pentium® Pro

processor bus ADS#, ADS # + 1

ADS# Low BCLK Pen tium Pro

processor bus Always

AP[1:0]# Low BCLK Pentium Pro

processor bus ADS#, ADS # + 1

ASZ[1:0]# Low BCLK Pentium Pro

processor bus ADS#

ATTR[7:0]# Low BCLK Pen tium Pro

processor bus ADS#+1

BE[7:0]# Low BCLK Pentium Pro

processor bus ADS#+1

BR0# Low BCLK Pentium Pro

processor bus Always

BP[3:2]# Low BCLK Pentium Pro

processor bus Always

BPM[1:0]# Low B CLK Pentium Pro

processor bus Always

Tab le A-12. Input Signals1 (Contd.)

Name Active Level Clock Signal Group Qualified

A-26

SIGNALS REFERENCE

D[63:0]# Low BCLK Pentium Pro

processor bus DRDY#

DBSY# Low BCLK Pentium Pro

processor bus Always

DEN# Low BCLK Pentium Pro

processor bus ADS# + 1

DEP[7:0]# Low BCLK Pentium Pro

processor bus DRDY#

DID[7:0]# Low BCLK Pentium Pro

processor bus ADS#+1

DSZ[1:0]# Low BCLK Pentium Pro

processor bus ADS#+1

DRDY# Low BCLK Pentium Pro

processor bus Always

EXF[4:0]# Low BCLK Pentium Pro

processor bus ADS#+1

FRCERR High BCLK Implementation Always

LEN[1:0]# Low BCLK Pentium Pro

processor bus ADS#+1

LOCK# Low BCLK Pentium Pro

processor bus Always

REQ[4:0]# Low BCLK Pentium Pro

processor bus ADS#, ADS # + 1

RP# Low BCLK Pentium Pro

processor bus Always

SMMEM# Low BCLK Pentium Pro

processor bus ADS# + 1

SPLCK# L ow BCLK Pentium Pro

processor bus ADS# + 1

Table A-13. Input/Output Signals (Single Driver)(Contd.)

Name Active Level Clock Signal Group Qualified

A-27

SIGNALS REFERENCE

Tab le A- 14. Input/Output Signa ls (Mult iple Driver)

Name Active Level Clock Signal Gro up Quali fi ed

AERR# Low BCLK Pentium® Pro

processor bus ADS# + 3

BNR# Low BCLK Pentium Pro

processor bus Always

BERR# Low BCLK Pentium Pro

processor bus Always

BINIT# Low BCLK P entium Pro

processor bus Always

HIT# Low BCLK P entium Pro

processor bus Always

HITM# Low BCLK Pentium Pro

processor bus Always

PICD[1:0] High PICCLK APIC Always

Index

INDEX-1

INDEX

A20M# signal . . . . . . . . . . . . . . . . . . . . . .3-23, A-2

Absolute Maximum Ratings . . . . . . . . . . . . . .11-13

Address

Parity-error signal . . . . . . . . . . . . . . . . . . . . A-3

Signals . . . . . . . . . . . . . . . . . . . . . . . .3-13, A-1

Address Parity signals . . . . . . . . . . . . . . .3-13, A-4

Address Strobe signal . . . . . . . . . . . . . . .3-13, A-2

Address-20 mask signal. . . . . . . . . . . . . . . . . . A-2

Addressed Agent responsibilities. . . . . . .5-7, 5-13

Addressed Agent, definition. . . . . . . . . . . . . . . .1-6

ADS# signal . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Advanced Programmable Interrupt Controller,

See APIC

AERR# signal. . . . . . . . . . . . . . . . . . . . . .3-18, A-3

Driving policy . . . . . . . . . . . . . . . . . . . . . . . .9-3

Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3

Agent

Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Symmetric. . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Agent ID. . . . . . . . . . . . . . . . . . . . . . . . . . .4-1, 4-4

Airflow . . . . . . . . . . . . . . . . . . . . . . . . .14-4, 17-19

Ambient Temperature . . . . . . . . . . . . . . . . . . .14-1

Analog Modeling . . . . . . . . . . . . . . . . . . . . . . .16-1

APIC Clock signal . . . . . . . . . . . . . . . . . . . . . A-1 7

APIC Data signals . . . . . . . . . . . . . . . . . . . . . A-17

APIC (Advanced Progra mmable Interrupt

Controller) . . . . . . . . . . . . . . . . . . . .3-11

A.C. Specifications . . . . . . . . . . . . . . . . . .11-2 2

Cluster ID . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5

D.C. Specifications . . . . . . . . . . . . . . . . . . .11-9

Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

AP[1:0]# signals. . . . . . . . . . . . . . . . . . . . . . . . A-4

Arbitration

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

Arbitration Phase . . . . . . . . . . . . . . . . . . . .3-5, 4-1

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

Architecture Overview . . . . . . . . . . . . . . . . . . . .2-1

Asserted, definition of. . . . . . . . . . . . . . . . . . . . .3-1

Asynchronous . . . . . . . . . . . . . . . . . . . . . . . . .11-9

ASZ[1:0]# signals. . . . . . . . . . . . . . . . . . . . . . . A-4

Attribute signals . . . . . . . . . . . . . . . . . . . .3-13, A-4

ATTR[7:0]# signals. . . . . . . . . . . . . 3-13, 3-16, A-4

Auto Halt . . . . . . . . . . . . . . . . . . . . . . . 11-2, 11-15

A.C. Specifications. . . . 11-18–11-28, 12-4, 17-17

A.C. Specification, I/O buffer . . . . . . . . . . . . .12-13

A[35:3]# si gnals . . . . . . . . . . . . . . . . . . . . . . . . A-1

BCLK (Bus Clock) input signal. . . 3-10, 11-18, A-5

BERR# Signal . . . . . . . . . . . . . . . . . . . . . . . . . .8-8

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8

BERR# signal. . . . . . . . . . . . . . . . . . . . . 3-22, A-6

Driving policy. . . . . . . . . . . . . . . . . . . . . . . . 9-3

Observation policy. . . . . . . . . . . . . . . . . . . . 9-4

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

BE[7:0]# signals . . . . . . . . . . . . . . . . . . . . . . . . A-5

BIL (Bus Invalidate Line) Transaction. . . . . . . . 7-3

BINIT# Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

BINIT# signal . . . . . . . . . . . . . . . . . . . . . . . . . 3-22

Driving policy. . . . . . . . . . . . . . . . . . . . . . . . 9-4

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

BIOS. . . . . . . . . . . . . . . . . . . . . . . . . . 17-13, 17-24

BIST (Built-in self test) . . . . . . . . . . . . . . . . . . 10-9

BIST (built-in self test) . . . . . . . . . . . . . . . . . . 3-23

Configuration. . . . . . . . . . . . . . . . . . . . . . . . 9-3

Block Next Request signal . . . . . . . . . . . 3-12 , A-7

BLR (Bus Locked Read) Transaction. . . . . . . . 7-3

BLW (Bus Locked Write) Transaction . . . . . . . 7-3

BNR# signal . . . . . . . . . . . . . . . . . . . . . . . 4-2, A-7

Sampling. . . . . . . . . . . . . . . . . . . . . . . 4-5, 4-14

Boundary Scan, See JTAG

BPM[1:0]# signals. . . . . . . . . . . . . . . . . . 3-24, A-7

BPRI# signal. . . . . . . . . . . . . . . . . . . . . . . 4-2, A-8

BP[3:2]# signals . . . . . . . . . . . . . . . . . . . 3-24, A-7

Brackets {}, definition of . . . . . . . . . . . . . . . . . . 3-3

Branch trace message . . . . . . . . . . . . . . . . . . . 5-9

Branch Trace Message Transaction. . . . . . . . . 5-9

Breakpoint signals . . . . . . . . . . . . . . . . . 3-24, A-7

BREQ[3:0]# signals . . . . . . . . . . . . . . . . . 4-2, A-9

BRIL (Bus Read Invalidate Line) Transaction . 7-3

BRL (Bus Read Line) Transaction . . . . . . . . . . 7-3

BRP (Bus Read Part-line) Transaction. . . . . . . 7-3

BR[3:0]# pins . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

Buffer Types . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9

Built-in self test (BIST) . . . . . . . . . . . . . . . . . . 3-23

Configuration. . . . . . . . . . . . . . . . . . . . . . . . 9-3

Burst order, definition of . . . . . . . . . . . . . . . . . . 3-9

Bus

Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Configuration options. . . . . . . . . . . . . . . 9-1

Arbitration

Protocol overview . . . . . . . . . . . . . . . . . 4-1

Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10

Description . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Error policy

Configuration . . . . . . . . . . . . . . . . . . . . . 9-4

Excha nge . . . . . . . . . . . . . . . . . . . . .4-1 1, 4-18

Priority . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

Symmetric . . . . . . . . . . . . . . . . . . . . . . 4-13

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Functional description . . . . . . . . . . . . . . . . . 3-1

Lock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

INDEX

INDEX-2

Lock signal

Protocol rules . . . . . . . . . . . . . . . . . . . .4-18

Operations . . . . . . . . . . . . . . . . . . . . .5-1, 5-13

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Protocol. . . . . . . . . . . . . . . . . . . . . . . . .3-4, 4-1

Phases . . . . . . . . . . . . . . . . . . . . . . . . . .3-4

Release. . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

Request assertion. . . . . . . . . . . . . . .4-16, 4-18

Request pins. . . . . . . . . . . . . . . . . . . . . . . . A-8

Request signals . . . . . . . . . . . . . . . . . . . . . A-9

Signals

Coherency-related. . . . . . . . . . . . . . . . . .7-2

Stall. . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2, A-7

States

Internal . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

Transactions. . . . . . . . . . . . . . . . . . . . . . . . .5-1

Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

Bus Error signal (BERR#) . . . . . . . . . . . . . . . . A-6

Bus Initialize signal (BINIT#) . . . . . . . . . . . . . . A-6

Bus Interface Unit. . . . . . . . . . . . . . . . . . . . . . . .2-7

Bus Lock signal . . . . . . . . . . . . . . . . . . . . . . . A-17

Bus Operations . . . . . . . . . . . . . . . . . . . . . . . . .7-2

Bus owner, definition of . . . . . . . . . . . . . . . . . . .1-7

Bus Topology. . . . . . . . . . . . . . . . . . . . . . . . . .11-1

Bus Transactions . . . . . . . . . . . . . . . . . . . . . . . . 7-2

BWL (Bus Write Line) Transaction. . . . . . . . . . .7-3

BWP (Bus Write Part-line) Transaction . . . . . . .7-3

BYPASS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7

Bypass Register. . . . . . . . . . . . . . . . . . . . . . . . 10-8

Byte Enable

Special transaction encoding . . . . . .3-17, A-12

Byte Enable signals . . . . . . . . . . . . . . . . .3-13, A-5

Cache Protocol. . . . . . . . . . . . . . . . . . . . . . . . . .1-2

Cache protocol. . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Ca se Te mpe ra ture . . . . . . . . . . 11 - 15, 11-28, 14-1

Voltage Regulator Module . . . . . . . . . . . .17-18

Central Agent responsibilities. . . . . . . . . . . . . . .5-8

Central Agent, definition of. . . . . . . . . . . . . . . . .1-6

Central Transactions

Non-memory. . . . . . . . . . . . . . . . . . . . . . . . .5-7

Chunk size, definition of. . . . . . . . . . . . . . . . . . .3-9

Circle symbol, in timing diagram . . . . . . . . . . . .3-2

CLAMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7

Clock

Configuration . . . . . . . . . . . . . . . . . . . . . . . .9-9

Frequencies . . . . . . . . . . . . . . . . . . . . . . . .9-10

Clock Distribution. . . . . . . . . . . . . . . . . . . . . . .11-5

Clock Ra ti o. . . . . . . . . . . . . . . . . . 9- 9 , 11-5, 11-19

Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-18

Clock-to -Output Time. . . . . . . . . . . . . . . . . . . 1 2 -17

CMOS Buffer . . . . . . . . . . . . . . . . . . . . . . . . . .16-1

Coherency . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2

Snoop Phase . . . . . . . . . . . . . . . . . . . . . . . 4-2 1

Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . .11-16

Compatibility note. . . . . . . . . . . . . . . . . . . . . . . .1-8

Configuration options . . . . . . . . . . . . . . . . . . . . 9-1

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Naming of transactions . . . . . . . . . . . . . . . . 7-3

Cooling, See Thermal

CPUID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14

Criteria for IPSL

Electrical . . . . . . . . . . . . . . . . . . . . . . . . . 17-20

End User. . . . . . . . . . . . . . . . . . . . . . . . . 17-25

Functional . . . . . . . . . . . . . . . . . . . . . . . . 17-24

Mechanical . . . . . . . . . . . . . . . . . . . . . . . 17-23

Thermal. . . . . . . . . . . . . . . . . . . . . . . . . . 17-22

Daisy Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

Data

Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

Transactions . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Transfer

Request initiated . . . . . . . . . . . . . . . . . 4-42

Response initiated . . . . . . . . . . . . . . . . 4-42

Snoop initiated. . . . . . . . . . . . . . . . . . . 4-42

Valid. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Data Phase. . . . . . . . . . . . . . . . . . . . . . . .3-5, 4-33

Bus signals . . . . . . . . . . . . . . . . . . . . . . . . 4-33

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

Protocol. . . . . . . . . . . . . . . . . . . . . . .4-33, 4-42

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

Data-bus Busy signal . . . . . . . . . . . . . . . . . . . A-10

Data-bus ECC signals . . . . . . . . . . . . . . . . . . A-11

Data-length signals. . . . . . . . . . . . . . . . . . . . . A-16

Data-ready signal . . . . . . . . . . . . . . . . . . . . . . A-12

Data-size signals . . . . . . . . . . . . . . . . . . . . . . A-12

DBSY# s ignal . . . . . . . . . . . . . . . . . . . . 3-21, A-10

Deasserted, definition of. . . . . . . . . . . . . . . . . . 3-1

Debug Port . . . . . . . . . . . . . . . . . 11-8, 16-1–16-11

Debug Port Connection . . . . . . . . . . . . . . . . . 16-8

Debug Port Connector . . . . . . . . . . . . . . . . . . 16-9

Debug Port Signal Notes . . . . . . . . . . . . . . . . 16-3

Decoupling . . . . . . . . . . . . . . . . . . . . . .11-3, 17-16

Defer signal . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

Defer-enable signal . . . . . . . . . . . . . . . . . . . . A-11

Deferred ID signals. . . . . . . . . . . . . . . . . . . . . 3-13

Deferred identifier signals. . . . . . . . . . . . . . . . A-11

Deferred Reply

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Deferred Reply Transaction . . . . . . . . . . . . . . 5-12

Deferred response . . . . . . . . . . . . . . . . . . . . . 4-32

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Deferring Agent . . . . . . . . . . . . . . . . . . . . . . . 5-12

DEFER# signal. . . . . . . . . . . . . . . . . . . 3-19, A-10

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

DEN# signal . . . . . . . . . . . . . . . . . . . . . 3-17, A-11

DEP[7:0]# signals. . . . . . . . . . . . . . . . . 3-21, A-11

INDEX-3

INDEX

Derating Curve. . . . . . . . . . . . . . . . . . . . . . . .11-21

Device ID Register. . . . . . . . . . . . . . . . . . . . . . 10- 8

Diagnostic signals . . . . . . . . . . . . . . . . . . . . . .3-24

Diagram conventions . . . . . . . . . . . . . . . . . . . . .3-1

DID[7:0]# signals . . . . . . . . . . . . . . . . . . . . . . A-11

Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . .15-1

Dispatch/Execute Unit . . . . . . . . . . . . . . . . . . . .2-5

DRDY# signal. . . . . . . . . . . . . . . . . . . . .3-21, A-12

DSZ[1:0]# signals. . . . . . . . . . . . . . . . . . . . . . A-12

Dynamic Execution . . . . . . . . . . . . . . . . . . . . . .2-3

D.C. Specifications. . . .11-14–11-17, 12-3, 17-15

D.C. Specification, I/O Buf fer. . . . . . . . . . . . .12-12

D[63:0]# signals . . . . . . . . . . . . . . . . . . .3-21, A-10

E (Exclusive) line state. . . . . . . . . . . . . . . . . . . .7-2

ECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2

ECC Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . .8-7

Effective Impedance. . . . . . . . . . . . . . . . . . . . . 12- 3

Electrical IPSL Criteria. . . . . . . . . . . . . . . . . .17-20

Electrical, See AC and DC Specifications

Error

Checking policy. . . . . . . . . . . . . . . . . . . . . . .9-3

Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23

Error Classification. . . . . . . . . . . . . . . . . . . . . . .8-2

Error Phase . . . . . . . . . . . . . . . . . . . . . . . 3-5, 4-20

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18

Exclusive line state . . . . . . . . . . . . . . . . . . . . . . . 7-2

Execution Control group input signal (BCLK ) . . A-5

Execution control signals . . . . . . . . . . . . . . . . .3-10

EXF[4:0]# signals. . . . . . . . . . . . . . . . . .3-17, A-13

Extended Function signals. . . . . . . . . . .3-13, A-13

Extended Functions . . . . . . . . . . . . . . . . . . . . .3-17

Extended Request signals . . . . . . . . . . . . . . . .3-13

External

Access, definition of . . . . . . . . . . . . . . . . . . .7-1

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

EXTEST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7

Failure

Hard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-32

Fan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17-17

Fatal Errors . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11

FERR# signal. . . . . . . . . . . . . . . . . . . . .3-23, A-13

Fetch/Decode Unit . . . . . . . . . . . . . . . . . . . . . . . 2-4

Flexible MotherBoard. . . . . . . . . . . . . . . . . . . 11-2 8

Flight Time . . . . . . . . . . . . . . . . . . 11-1, 12-4, 12-8

Floating-point error signal . . . . . . . . . . . . . . . A-13

Flush Acknowledge Transaction . . . . . . . . . . .5-11

Flush Transaction. . . . . . . . . . . . . . . . . . . . . . .5-10

FLUSH# input signal . . . . . . . . . . . . . . . . . . . .3-11

FRC . . . . . . . . . . . . . . . . . . 9-5, 11-6, 11-9, 11-20

FRCERR signal . . . . . . . . . . . . . . . . . . .3-22, A-14

Frequency . . . . . . . . . . . . . . . . . . . . . . .9-9, 11-18

Functional redundancy checking (FRC)

Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

Functional Redundancy Checking, See FRC

Functional-redundancy-check error signal . . . A-14

Ground signals . . . . . . . . . . . . . . . . . . . . . . . . 3-25

GTL+. . . . . . . . . . .11-1, 11-4, 11-9, 11-16–11-20,

12-1–12-27

GTL+ Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

GTL+ I/O Buffer Specification. . . . . . . . . . . . 12-12

Gunning Transceiver Logic, See GTL+

Halt Transaction . . . . . . . . . . . . . . . . . . . . . . . 5-10

Hard failure. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Hard-error Response . . . . . . . . . . . . . . . . . . . . 8-7

Heat Sink . . . . . . . . . . . . . . . . . . 14-4, 17-3, 17-17

Heat Sink Clips. . . . . . . . . . . . . . . . . . . . . . . . 17-7

Heat Spreader . . . . . . . . . . . . . . . . . . . . . . . . 15-1

High-frequency signal communication . . . . . . . 1-4

HIGHZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

Hit-modified signal . . . . . . . . . . . . . . . . . . . . . A-14

HITM# signal . . . . . . . . . . . . . . . . . . . . 3-19, A-14

HIT# signal . . . . . . . . . . . . . . . . . . . . . . 3-19, A-14

Hold Time. . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21

I (Invalid) line state . . . . . . . . . . . . . . . . . . . . . . 7-1

IBIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1, 16-1

ID Agent. . . . . . . . . . . . . . . . . . . . . . . . . . .4-1, 4-4

Rotating. . . . . . . . . . . . . . . . . . . . . . . . .4-1, 4-4

IDCODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

IEEE 1149.1, See JTAG

IERR# Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

IERR# signal. . . . . . . . . . . . . . . . . . . . . 3-22, A-15

IGNNE# signal . . . . . . . . . . . . . . . . . . . 3-23, A-15

Ignore Numeric Error signal . . . . . . . . . . . . . . A-15

Implicit writeback . . . . . . . . . . . . . 4-32, 4-35, 5-14

Implicit writeback response . . . . . . . . . . .5-13, 7-3

Inactive, definition of. . . . . . . . . . . . . . . . . . . . . 3-1

Incident Wave Switching . . . . . . . . . . . . . . . . 11-1

Initialization signal . . . . . . . . . . . . . . . . . . . . . A-15

INIT# input signal . . . . . . . . . . . . . . . . . 3-11, A-15

In-order Queue (IOQ) . . . . . . . . . . . . . . . . . . . . 3-6

Pipelining configuration. . . . . . . . . . . . . . . . 9-4

Response Phase. . . . . . . . . . . . . . . . . . . . 4-25

Instruction Pool. . . . . . . . . . . . . . . . . . . . . . . . . 2-1

In-Target Probe . . . . . . . . . . . . . . . . . .16-1–16-11

Intel Platform Support Program . . . . .17-19–17-25

Internal access, definition of. . . . . . . . . . . . . . . 7-1

Internal error. . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Internal Error signal . . . . . . . . . . . . . . . . . . . . A-15

Internal signals . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Interprocessor communication pins . . . . . . . . 3-10

INDEX

INDEX-4

Interrupt Acknowledge Transaction . . . . . . . . . .5-8

Interrupt Request signal. . . . . . . . . . . . . . . . . A-16

INTR signal . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

Intrinsic trace capacitance . . . . . . . . . . . . . . . .12-3

Invalid line state . . . . . . . . . . . . . . . . . . . . . . . . . 7- 1

IOQ, see In-order Queue

I/O Agent, definition of . . . . . . . . . . . . . . . . . . . .1-6

I/O Buffer Models . . . . . . . . . . . . . . . . . . . . . . .13-1

I/O transaction . . . . . . . . . . . . . . . . . . . . . . . . . .3-8

I/O Transactions. . . . . . . . . . . . . . . . . . . . . . . . . 5-6

Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-18

JTAG . . . . . . . . . . 10-1–10-10, 11-8, 11-9, 11-23,

11-27, 16-4–16-11, A-22

JTAG-support signal . . . . . . . . . . . . . . A -22, A-23

JTAG, See Also Test Access Port

Keep Out Zones. . . . . . . . . . . . . . . . . . . . . . . .15- 3

L2 Decoupling . . . . . . . . . . . . . . . . . . . . . . . . .11-4

Latched bus protocol . . . . . . . . . . . . . . . . . . . . .3-2

Latency, long . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

Layout, GTL+. . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

LEN[1:0]# signals. . . . . . . . . . . . . . . . . . . . . . A-16

Line

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .7-1

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Valid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2

Line data transfer. . . . . . . . . . . . . . . . . . . . . . . .3-9

LINT[1:0] signals . . . . . . . . . . . . . . . . . .3-11, A-16

Local Interrupt signals . . . . . . . . . . . . . . . . . . A-16

LOCK# signal. . . . . . . . . . . . . . . . . 3-12, 4-2, A-17

Low power . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2

M (Modified) line state . . . . . . . . . . . . . . . . . . . .7-2

Maximum Ratings . . . . . . . . . . . . . . . . . . . . . 11-1 2

MCA Hardware Log . . . . . . . . . . . . . . . . . . . . . .8-7

Mechanical. . . . . . . . . . . . 15-1, 17-2, 17-4, 17-17

IPSL Criteria . . . . . . . . . . . . . . . . . . . . . . .17-23

Memory

Address-space size signals . . . . . . . . . . . . A-4

Transaction. . . . . . . . . . . . . . . . . . . . . . . . . .3-8

Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

Descriptions. . . . . . . . . . . . . . . . . . . . . . .6-3

Memory Agent

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .1-6

Responsibilities during implicit writeback

response . . . . . . . . . . . . . . . . . . . . . . . .5-14

Memory Range Register signal encoding . . . .3-16

Memory Read Transaction. . . . . . . . . . . . . . . . .5-5

Memory type range register (MTRR) . . . . .1-2, 6-1

Memory Write Transaction . . . . . . . . . . . . . . . . 5-5

Memory (Read) Invalidate Transaction . . . . . . 5-5

MESI protocol. . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Modified line state. . . . . . . . . . . . . . . . . . . . . . . 7-2

MTRR (memory type range register) . . . . .1-2, 6-1

Multiprocessor

Configuration. . . . . . . . . . . . . . . . . . . . . . . . 9-1

Multi-processor. . . . . . . . . . . . . . . . . . . .11-7, 11-8

Multiprocessor System. . . . . . . . . . . . . . . . . . . 1-4

Multiprocessor system . . . . . . . . . . . . . . . . . . . 1-2

NMI signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

No data response . . . . . . . . . . . . . . . . . . . . . . 4-32

No-Connects. . . . . . . . . . . . . . . . . . . . . . . . . 11-12

Nominal Impedance . . . . . . . . . . . . . . . . . . . . 12-3

Non-maskable Interrupt (NMI) signal . . . . . . . A-17

Non-memory Central Transactions. . . . . . . . . . 5-7

Normal data response . . . . . . . . . . . . . . . . . . 4-32

Notational conventions, see Signal/Diagram

Conventions . . . . . . . . . . . . . . . . . . . 3-1

Observing Agent responsibilities . . . . . . . . . . . 5-8

Operation, definition of . . . . . . . . . . . . . . . . . . . 3-4

Optional data transactions . . . . . . . . . . .5-12 , 5-13

Original requestor. . . . . . . . . . . . . . . . . . . . . . 5-13

Out-of-order execution . . . . . . . . . . . . . . . . . . . 6-1

Output Driver Acceptance Criteria . . . . . . . . 12-15

Output tristate

Configuration. . . . . . . . . . . . . . . . . . . . . . . . 9-2

OverDrive Processor . . . . . . . . . . . . . . . . . . . 17-1

Overdrive Processor Signals . . . . . . . . . . . . 17-11

OverDrive® Electrical Specifications . . . . . . 17-14

Overshoot. . . . . . . . . . . . . . . . . . 11-20, 12-5, 13-1

Ownership

From Busy state . . . . . . . . . . . . . . . . . . . . 4-17

From Idle state . . . . . . . . . . . . . . . . . . . . . 4-16

Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3

Package Specification, GTL+. . . . . . . . . . . . 12-23

Package Trace Length . . . . . . . . . . . . . . . . . 12-23

Parity . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20, 8-2

Error-checking policy. . . . . . . . . . . . . . . . . . 9-3

Parity Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 8-7

Partial transfer . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

Part-line aligned transfer . . . . . . . . . . . . . . . . . 3-9

PC Compatib ility signals. . . . . . . . . . . . . . . . . 3-23

Pentium Pro OverDrive Processor,

see OverDrive Processor

Pentium Pro processor

System environment . . . . . . . . . . . . . . . . . . 1-5

Performance Monitor signals . . . . . . . . . 3-24, A-7

Phase, definition of. . . . . . . . . . . . . . . . . . .1-7, 3-4

PICCLK signal . . . . . . . . . . . . . . . . . . . 3-11, A-17

INDEX-5

INDEX

PICD[1:0] signals . . . . . . . . . . . . . . . . . .3-11, A-17

Pin Listing in Pin # Order . . . . . . . . . . . . . . . . .15-5

Pinout. . . . . . . . . . . . . . . . . . . . . . . . . . .15-4 , 17-3

Voltage Regulator Module . . . . . . . . . . . . .17-8

Pipelined transactions . . . . . . . . . . . . . . . . . . . .3-6

PLL decoupling . . . . . . . . . . . . . . . . . . . . . . . .11-4

Power. . . . . . . . . . . . . . . 11-2, 11-15, 11-28, 15-4

Power Distribution Modeling . . . . . . . . . . . . . .16-1

Power Management. . . . . . . . . . . . . . . . . . . . . 11- 2

Power signals. . . . . . . . . . . . . . . . . . . . . . . . . .3-25

Power-on reset vector configuration . . . . . . . . .9-5

PRELOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7

PREQ# signal. . . . . . . . . . . . . . . . . . . . . . . . . .3-24

Priority

Bus exchange. . . . . . . . . . . . . . . . . . . . . . .4-1 3

Priority agent . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Arbitration protocol rules. . . . . . . . . . . . . . .4-17

Priority-agent Bus Request signal . . . . . .3-12, A-8

Probe-Mode Port, see Debug Port

Propagation Delay . . . . . . . . . . . . . . . . . . . . . .12-8

PWRGOOD . . . .11-11, 11-20, 11-27, 17-9, 17-21

Ratio, See Clock Ratio

Read

Transaction. . . . . . . . . . . . . . . . . . . . .4-34, 5-5

Read data transfers

Back-to-back. . . . . . . . . . . . . . . . . . . . . . . . 4-38

Ref8N Network. . . . . . . . . . . . . . . . . . . . . . . .12-24

Release

Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

Request

Generation . . . . . . . . . . . . . . . . . . . . . . . . .4-20

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13

Stall

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . .4-4

States . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

Request command signals. . . . . . . . . . . . . . . A-18

Request initiated data transfer

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Request Initiator responsibilities . . . 5-7, 5-8, 5-12

Request Parity signal. . . . . . . . . . . . . . .3-13, A-19

Request Phase. . . . . . . . . . . . . . . . 3-5, 3-19, 4-18

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Protocol rules . . . . . . . . . . . . . . . . . . . . . . .4-20

Qualifiers. . . . . . . . . . . . . . . . . . . . . . . . . . .4-20

Requesting agent

Responsibilities during implicit writeback

response . . . . . . . . . . . . . . . . . . . . . . . .5-14

Requesting Agent, definition . . . . . . . . . . . . . . .1-6

Request-initiated data transfer. . . . . . . . . . . . .4-33

REQ[4:0]# signals . . . . . . . . . . . . . . . . . . . . . A-18

Reserved Memory Write Transaction. . . . . . . . .5-6

Reserved pins . . . . . . . . . . . . . . . . . . . . . . . .11-12

Reset . . . . . . . . . . . . . . . . . . . 11-19, 11-21, 11-26

Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

RESET# input signal . . . . . . . . . . . . . . 3-10, A-19

Response agent . . . . . . . . . . . . . . . . . . . . . . . 4-25

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Response initiated data transfer

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Response parity signal . . . . . . . . . . . . . . . . . . A-21

Response Phase . . . . . . . . . . . . . . . . . . .3-5, 4-25

Bus signals . . . . . . . . . . . . . . . . . . . . . . . . 4-26

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

Protocol. . . . . . . . . . . . . . . . . . . . . . .4-26, 4-31

Response signals . . . . . . . . . . . . . . . . . . . . . . 3-20

Response Status signals . . . . . . . . . . . . . . . . A-20

Retire Unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Retry response . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Ringback. . . . . . . . . . . . . 11-20, 11-25, 12-5, 13-2

Rotating ID . . . . . . . . . . . . . . . . . . . . . . . . .4-1, 4-4

RP# signal . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19

RSP# signal . . . . . . . . . . . . . . . . . . . . . 3-20, A-21

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

RS[2:0]# signals . . . . . . . . . . . . . . . . . . 3-20, A-20

Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

RUNBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

S (Shared) line state. . . . . . . . . . . . . . . . . . . . . 7-1

SAMPLE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

SEC-DED-S4ED. . . . . . . . . . . . . . . . . . . . . . . . 8-7

Self snooping, definition . . . . . . . . . . . . . . . . . 3-19

Settling Limit. . . . . . . . . . . . . . . . . . . . . .12-5, 13-3

Setup Time . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19

Shared line state. . . . . . . . . . . . . . . . . . . . . . . . 7-1

Shutdown Transa ction . . . . . . . . . . . . . . . . . . 5-10

Signal

Alphabetical listing . . . . . . . . . . . . . . . . . . . A-1

Coherency-related. . . . . . . . . . . . . . . . . . . . 7-2

Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 3-10

Reference . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Summaries . . . . . . . . . . . . . . . . . . . . . . . . A-24

Signal Groups. . . . . . . . . . . . . . . . . . . . . . . . . 11-9

Signal Notes. . . . . . . . . . . . . . . . . . . . . . . . . . 16-3

Signal Quality . . . . . . . . . . . 12-4, 13-1, 16-3, 16-9

SMI Acknowledge Transaction. . . . . . . . . . . . 5-11

SMM (System Management Mode) . . . . . . . . 3-17

SMMEM signal . . . . . . . . . . . . . . . . . . . . . . . . A-21

SMMEM# signal . . . . . . . . . . . . . . . . . . . . . . . 3-17

Snoop

Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Responsibility

Transferring . . . . . . . . . . . . . . . . . . . . . 5-15

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

Stall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14

Snoop initiated data transfer

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Snoop Phase . . . . . . . . . . . . . . . . . . . . . .3-5, 4-21

INDEX

INDEX-6

Bus signals . . . . . . . . . . . . . . . . . . . . . . . . .4-21

Completion . . . . . . . . . . . . . . . . . . . . . . . . .4-25

Definition of. . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Normal . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22

Protocol de scription . . . . . . . . . . . . . . . . . .4-22

Protocol rules . . . . . . . . . . . . . . . . . . . . . . .4-24

Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

Stall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-25

Stalled. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23

Valid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-25

Snoop-hit signal . . . . . . . . . . . . . . . . . . . . . . . A-14

Snoop-initiated data transfer . . . . . . . . . . . . . .4-35

Socket8 . . . . . . . . . . . . . . . . . . . . . . . .17-1–17-19

Software-programmable options . . . . . . . . . . .9-10

Special transactions. . . . . . . . . . . . . . . . . .3-8, 5-9

Speculative execution . . . . . . . . . . . . . . . . . . . .6-1

SPLCK# signal. . . . . . . . . . . . . . . . . . . .3-17, A-22

Split lock signal . . . . . . . . . . . . . . . . . . . . . . . A-22

Square symbol, in timing diagram . . . . . . . . . . .3-2

Stop Clock Acknowledge Transaction . . . . . . .5-11

Stop Clock signal . . . . . . . . . . . . . . . . . . . . . . A-22

Stop Grant . . . . . . . . . . . . . . . . . . . . . .11-2, 11-15

STPCLK# signal. . . . . . . . . . . . . . . . . . .3-11, A-22

Stub Length . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4

Symmetric

Agent . . . . . . . . . . . . . . . . . . . . . . . . . 3-12, 4-1

Arbitration ID . . . . . . . . . . . . . . . . . . . . . .9-6

Arbitration protocol rules . . . . . . . . . . . .4-16

Bus Request signal . . . . . . . . . . . . . . . .3-12

Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

States . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Bus exchange. . . . . . . . . . . . . . . . . . . . . . .4-1 3

Bus owner. . . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Ownership state . . . . . . . . . . . . . . . . . . . . . . 4- 4

Symmetric-agent arbitration bus signals . . . . . A-9

Sync Transaction . . . . . . . . . . . . . . . . . . . . . . . 5-11

Synchronous . . . . . . . . . . . . . . . . . . . . . . . . . .11-9

System design, ease of . . . . . . . . . . . . . . . . . . .1-4

System environment . . . . . . . . . . . . . . . . . . . . .1-5

System Managemen t Mode Memory signal. . A-2 1

System Management Mode (SMM) . . . . . . . . .3-17

TAP Controller State s . . . . . . . . . . . . . . . . . . .10-3

TAP Instruction Register . . . . . . . . . . . . . . . . .10-4

TAP Instructions. . . . . . . . . . . . . . . . . . . . . . . .10-6

Target Agent, definition . . . . . . . . . . . . . . . . . . .1-6

Target Ready signal. . . . . . . . . . . . . . . . . . . . A-23

TCK signal . . . . . . . . . . . . . . . . . . 3-24, 10-2, A-22

TDI signal. . . . . . . . . . . . . . . . . . . 3-24, 10-2, A-22

TDO signal. . . . . . . . . . . . . . . . . . 3-24, 10-2, A-22

Terminology clarification . . . . . . . . . . . . . . . . . .1-6

Tes t Acc ess Por t (T AP) . . . . . . . 10-1–10-10, A-22

Test clock signal. . . . . . . . . . . . . . . . . . . . . . . A-22

Test Load. . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18

Test Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-12

Test-data-in signal . . . . . . . . . . . . . . . . . . . . . A-22

Test-data-out signal . . . . . . . . . . . . . . . . . . . . A-22

Thermal . . . . . . . . . . . . . . . . . . . . . . . .14-1, 17-17

IPSL Criteria . . . . . . . . . . . . . . . . . . . . . . 17-22

Voltage Regulator Module. . . . . . . . . . . . 17-18

THERMT RIP#. . . . . . . . . . . . . . . . . . .11-10, 11-11

3.3 V Tole rant . . . . . . . . . . . . . . . . . . . .1 1 -9, 11-20

Time-Out Counter. . . . . . . . . . . . . . . . . . . . . . 8-12

Time-out Errors. . . . . . . . . . . . . . . . . . . . . . . . . 8-6

TMS signal . . . . . . . . . . . . . . . . . .3-24, 10-2, A-22

Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

Topological Guidelines . . . . . . . . . . . . . . . . . . 12-4

Tracking transactions . . . . . . . . . . . . . . . . . . . . 3-6

Transaction

Coherency-related. . . . . . . . . . . . . . . . . . . . 7-2

Definition of. . . . . . . . . . . . . . . . . . . . . .1-6, 3-4

Delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

Naming convention . . . . . . . . . . . . . . . . . . . 7-3

Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Responses . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

Special . . . . . . . . . . . . . . . . . . . . . . . . .3-8, 5-9

Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Transaction response encodings . . . . . . . . . . 3-21

Transfer

Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

Snoop responsibility . . . . . . . . . . . . . . . . . 5-15

Transient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

TRD Y# sig n al . . . . . . . . . . . . . . . . . . . . 3-20, A-23

Deassertion protocol . . . . . . . . . . . . . . . . . 4-31

TRST# signal . . . . . . . . . . . . . . . .3-24, 10-2, A-23

2H2O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4

UC (uncacheable) memory type. . . . . 6-2, 6-3, 7-2

Uncacheable memory type. . . . . . . . . 6-2, 6-3, 7-2

Uncacheable, speculatable, write-combining

memory type. . . . . . . . . . . . . . . . . . . 6-3

Undershoot. . . . . . . . . . . . . . . . . . . . . . . 12-5, 13-1

Unprotected Bus Signals . . . . . . . . . . . . . . . . . 8-6

Unused Pins. . . . . . . . . . . . . . . . . . . . . . . . . 11-12

Upgrade, See Overdrive Processor

UP#. . . . . . . . . . . . 17-4, 17-8, 17-9, 17-11, 17-21

USWC (uncacheable, speculatable,

write-combining) memory type . . . . . 6-3

Valid line, definition of. . . . . . . . . . . . . . . . . . . . 7-2

VID, see Voltage Identification Pins

Voltage Identification Pins . . . . 11-12, 11-13, 17-1

Voltage Regulator Module, See VRM 8

Voltages . . . . . . . . . . . . . . . . . . 11-7, 11-14, 11-17

VREF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

VRM 8. . . . . . . . . . . . . . . 17-2, 17-8, 17-18, 17-23

INDEX-7

INDEX

Waveforms. . . . . . . . . . . . . . . . . . . . . . . . . . .11-24

WB (writeback) memory type. . . . . . . 6- 2, 6-4, 7-2

Wired-OR glitch . . . . . . . . . . . . . . . . . . . . . . . . .3-3

WP (write-protected) memory type . . 6-2, 6-4, 7-2

Wr it e Tr a n saction. . . . . . . . . . . . . . . . . . . 4- 3 3, 5-5

Writeback memory type . . . . . . . . . . . 6- 2, 6-4, 7-2

Write-protected memory type. . . . . . . 6- 2, 6-4, 7-2

Write-through memory type . . . . . . . . 6-2, 6-3, 7-2

WT (write-through) memory type . . . . 6-2, 6-3, 7-2

Zero Insertion Force Socket. . . . . . . . . . . . . . .17-3

Table of Contents

Intel Pro 200 MHz User Manual

Related Manuals