Digital PDFs

EK-580AA-TM-001

July 2000

401 pages

Original

19MB

view download

OCR Version

14MB

view download

Document:	DECsystem 5800 System Technical User's Guide
Order Number:	EK-580AA-TM
Revision:	001
Pages:	401
Original Filename:

OCR Text

KRR KRR A XX XK XXX AHR X KKK

XXX

XX X

XXX XXX XK XX XAXKKK

X XXX XX 000X XN XXX XX XXX XRNNINNNNKNK

KRR XXX XX XK XXX XXX XXX KKK

KX KX AR K KRAXXXRKRKKKKX

XX RHXXXEXX XXX XX XXX XXX XX XXX

IOOOXR KKK AR XXX KKK

X
XXX
XXXXX

KXXXXKXX
XAXXXARXXN

XAAXXXXXXXX

b$.9.0.9.8.4.¢.4.449
¢4
KXAXXXAAXAXKXKXKX

KXXXXKXKXKXKXKKKXK
[00000096046
8.604 004

KXXXHAXXXXXXXXXKXXNKX
XXXXXXNEXKXXKXX
XXX
XKX
XX

[0 808690060009 646640004.9¢¢]
PO ED PO ITIE 4090000000000049
04

P 9.0.0.0
084260
0.006 0000000
0009
00
DO 008069900089 ¢004008494090 9904
b O0008
0008080
00
0 8046060
80
600001
0
KXXX
KKK
KU
KX AARXKX
XL
AKK KKK
XX
KKK KK
K
KK

XXXRXXXXAXKXXXAXXAXXXXXXXKXRKXXXKXIXXX
XXKXAXXX XXX XXX XXX RXXAXKXX KKK X XXX XXKXKK
PO PP000008
000000
00
600
08
0000¢00
000080
0
04
XXXAXXK XXX
XRK
XRXXK XXXAR
XX XXX X KKK
XKL
AKX XXX X
KKK
KEXXKXKXE
XXX XXX AXA
XX AR AKX XK
RXA
X XKAXXX
XXX
XX KK KKK
RSP OO E 0P000000
0 0300009
00
008008
00
08000
00000000

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXX

DECsystem 5800 System
vechnical User’'s Guide
Crder Number

EX-S580AA TM-001

This manua' serves as a reference on how to wnte software to this machine
and covers the information needed (o do lieid-'eve! repair or programmng

customized to the CPU It inCludes information en tnterrupts, error handing,
and detaied theory of cperation

bigh=! Cquipment Corporation

First Printing, July 1980

The in‘ormation in this document 1s subject to change without notice and shouid not

be construed as a commitment by Digial Equipment Corporation.

Digttal Equipment Corporation assumes no responsibilty for any errors that may
appear in this document.

The software. if any, described in this document s furnished under a license and may

be used or copied only in accordance with the terms of such icense. No responsibiity
1s assumed for the use or reliabilty of software or equipment that 1s not supphed by
Digtat Equipment Corporation or its affihated companies
Sopynght €1990 by Dignal Equipment Corporation
All Rights Reserved.
A
Pnnted in US

The tollowing are trademarks of Digtal Equipment Corporation

DEBNA
DEC
DEC LANcontrolier
DECnet
DECUS

PDP
ULTRIX
UNIBUS

VAXciuster
VAXELN
VMS

VAX
VAXE!

MIPS 1s a registered trademark of MIPSCO. Ine

This document was prepared using VAX DOCUMENT. Version 1.1

Contents
PREFACE

CHAPTER1

xix

THE DECSYSTEM 58C0 SYSTEM OVERVIEW

1-1

DECSYSTEM 5800 INTRODUCTION

1-2

DECSYSTEM 5800 CONFIGURATIONS

1-3

DECSYSTEM 580C SYSTEM ARCHITECTURE

1-4

TYPICAL SYSTEM

1-6

1.5

DECSYSTEM 5800 (FRONT VIEW)

1-8

DECSYSTEM 5800 (REAR VIEW)

1-9

SUPPORTED VAXBI ADAPTERS AND OPTIONS

1-10

1.8

XMI BACKPLANE AND CARD CAGE

1-11

VAXBI BACKPLANE AND CARD CAGE

1-13

1.4

VAXS: EXPANDER CABINET

1-14

111

TK70 TAPE DRIVE

1-15

112

1/O CONNECTIONS

1-16

113

POWER SYSTEM

1-17

1.14

COOLING SYSTEM

1-19

Contents

CHAPTER 2
2.1

2.2

THE XMi

2-1

XMl OVERVIEW

2-2

211

XMI System Block Diagram Description

2-2

212

XMl Comer

2-4

2.1.3

XMl Data Trangactions

2.1.4

XMl interrupt Transactions

2.1.5

Arbitration

2-10

216

Bus Integrity

2-1

XM ADDRESSING

2-12

2.21

XMI Memory Space

2-13

222

XMi VO Space

2-13

2221

XM Private Space « 2-14

2222

XM! Nodespace « 2-14

2223

YO Adapter Address Spoce » 2-15

ARBITRATION CYCLES

2-16

XMi CYCLES

2-18

241

Function Codes

2-18

2.42

Command Cycles

2-19

2421

Command Fieid = 2-20

2422

Mask Field » 2-21

2423

Length Field « 2-22

2424

Address Fieid » 2-23

2425

Node Spacifier Fieid « 2-24

2.43

Write Data Cycles

244

Good Read Data (GRD) and Corrected Read Data

2-25

Response (CRD) Cyciles

2-25

Locked Response Cycle (LOC)

2-26

2456

Read Error Response Cycle (RER)

2-26

2.4.7

The Nuli Cycle

2-26

245

2-9

XMi TRANSACTIONS

2-27

2.5.1

Read Transactlon

2-27

25.2

interiock Read Transaction

2-28

253

Write Mask Transaction

2-29

254

Unlock Write Mask Transaction

2-30

255

Interrupt and identify Transactions

2-30

2.5.6

Implied Vector Interrupt Transactions

2-31

Contents

25.7

2.7

2.8

Transaction Examples
2571
Singie Daia Cycls Reads « 2-32
2572
Multiple Data Cycle Reads » 2-34
2573
Longword and Quadword Writes « 2-37
2574
Multiple Data Cycle Writes « 2-37

2-32

XMI INITIALIZATION

2-38

26.1

Causas of an Initialization

2-38

262

PowerUp

2-39

26.3

System Resget

2-40

26.4

Node Reset

2-40

KW REQISTERS

2-41

XM! ERRORS

2-42

2.8.1

Error Conditions
2811

Panty Error « 2-42

2812
2813
2814

inconsistent Panty Error » 242
Transaction Timeout « 2—42
Seguence Error » 2-43

2-42

282

Error Handling

2-44

2.8.3

Error Recovery

245

284

Error Reporting

2-45

KNS58A/A INTERFACE MODULE

KN5BA/A INTERFACE MODULE FEATURES

3-2

3.2

PRIVATE VO ADDRESS SPACE MAP

MAINTENANCE PROCESSOR

3-6

231

CVAY Hardwars Roetort Seauenca

-8

33.2

Cilock Chip

3-6

CHAPTER 3

SYSTEM SUPPORT CHIP (SSC)

3-7

3.4.1

3-7

SSC Funetions

EEPROM

3-8

Contenis

3.5.1

EEPROM Arccess

3-8

3-9

SECOND-LEVEL CACKE
3.6.1
Second-Level Cache Description
3.6.2
Controdling the Second-Level Cache

3-10

3.7

XM CORNER.-TO-KNS8A/A INTERFACE
3.7.1
The XCPGA Chlp
3.7.2
The XCPGA Write Buffer
3.7.3
Duplicate Tag Store
3.7.4
XM Interrupt Operation
3.75
implied Vector Interrupts (IVINTR)

3-15
3-19
3-21
3-22
3-23
3-25

KNZBA/A INTERFACE MODULE REGISTERS

3-27

3.8.1

3-14

XMI Registers and Control and Status Register 1
Characieristics
CONTROL AND STATUS REGISTER 1 (CSR1)
SYSTEM YYPE (SYSTYPE)
SSC BASE ADDRESS REGISTER (SSCBR)
SSC CONFIGURATION REGISTER (SSCCR)
HDAL BUS TIMEOUT CONTROL REGISTER (CBTCR)
TIME OF YEAR CLOCK REGISTER (TODR)
CONSOLE SELECT REGISTER (CONSEL)
CONSOLE RECEIVER CONTROL AND STATUS

3-27
3-20

337
3-39

-4
347

(RXCS)

3-50

CONSOLE RECEIVER DATA BUFFER (RXDB)
CONSOLE TRANSMITTER CONTROL AND STATUS

351

(TXCS)

3-53

CONSOLE TRANSMITTER DATA BUFFER (TXDB)
yD SYSTEM RESET REGISTER (ORESET)
TIMER CONTROL REGISTER 0 (TCRO)

3-56

TIMER INTERVAL REGISTER 0 (TIR0)

360

TIMER NEXT INTERVAL REGISTER 0 (TNIRO)
TIMER INTERRUPT VECTOR REGISTER 0 (TIVRO)

361

TIMER CONTROL REGISTER 1 (TCR1)

3-83

TIMER INTERVAL REGISTER 1 (TIR1)

558

TiMcH NEXT INTERVAL REGISTER 1 (TNIR1)
TIMER INTERRUPT VECTOR REGISTER 1 (TIVR1)
CSR1 BASE ADDRESS REGISTER (CSR1BADR®
s mes
I AMATE As
APOMURFEAN
Me
CSR+ ADDRESS GECODE MASK REGISTER

(CSR1ADMR)

” 40

EEPROM SASE ADDRESS REGISTER (E:P.UR)

EEPROM ADDRESS DECCDE MASK REGISTER

3-55
357

3-862

3-69

(EEADMR)

3-72

DEVICE REGISTER (XDEV)
BUS ERROR REGISTER (XBER)

3-73

3-75

FAILING ADDRESS REGISTER (XFADR;
XK GENERAL PURPOSE REGISTER (XGPR)
CONTROL AND STATUS REGISTER 2 (CSR2)
vi

3-85

3.9

INITIALIZATICn, SELF-TEST, AND BOOTING
3.9.1
3.9.2

Inktiglization Overview
inkialization Details

3921
3022
3923
3924

WMemory Configuration
3831
Selection of Interleave « 3-102
3932
Memory Testing and the Bitmap * 3-103

3-107

39.4

DWMBA Configurstion

3-104

3.8.5

inkialized State

3-105

39.6

Resterting or Bootstrapping the Operating System
3961
Operating System Restart « 3-106

3962

39621

3.1

CHAPTER 4

4.1

4.2

_______

3-106

Operating System Bootswap + 3-107

Bootstrap Support Routines in the Console » 3-108

3.9.7

Console Use of Address Space

3-108

39.8

Booistrap of the VAX Diegnostic Supervisor (VAX/DS) __
3981
Parameters Passed to the Boot Primitive « 3-110
3982
Parameters Passed to the Bootblock Program « 3-112
3983
Parameters Required by the Boot Primitive » 3-112

3-110

3884

3.10

Restan Sequence « 3~-98
Node Reset + 3-100
Halt Interrupt » 3-101
Emrors » 3-101

39.3

‘

Centents

Considerations for Tape Drives « 3-112

INTERPROCESSOR COMMUNICATION THROUGH THE CONSOLE
PROGRAPR

313

3.10.1

Required Communications Paths

3-113

3.10.2

Console Communications Area

3-115

3.10.3

Send!ng & Message o Another Processor

3-123

KNSBA/A INTERFACE MODULE ERROR HANDLING

3-125

3.11.1

Parity Generation and Checking for Error Detection

3-126

3.11.2

Error Interrupt Service Routines

3-126

3.11.3

KNSSBA/A Interface Module Error Matrix

3-128

KNSBA/B CPUMODULE

4-1

KN58A/B CPU MODULE FEATURES

4-2

R3000 CPU

4-4

4.2.1

R3000 Registers

vil

Contents

4.22

Coprocessor 0 (CP0) Registers

TLB ENTRYHI REGISTER (ENTRYHI)

TLB ENTAVLO REGISTER (ENTRYLO)
TLB INDEX REGISTER (INDEX)
TL8 RANDOM REGISTER (RANDOM)
R3000 STATUS REGISTER (STATUS)
CAUSE REGISTER (CAUSE)
EXCEPTION PROGRAM COUNTER REGISTER (EPC)
CONTEXT REGISTER (CONTEXT)
RAD VIRTUAL ADDRESS REGISTER (BADVADDR)
PROCESSOR REVISION IDENTIFIER REGISTER

(PRID)
R3000 Pipetine Architecture
Data Types

4-10
&1
415
4-18
419
&-20

425

instruction Set

4-22
4-22
4-23

4.2.6

Memory Management

4-26

427

Memory Mapping

4-28

423
424

4251
4252
4253
4254
4255

Load and Store Instructions « 4-24
Computationa! Instructions * 4-24
Jump and Branch Instructions » 4-25
Coprocessor instructions « 4-25
Special Instructions « 4-25

4261
4262

Translation Lookaside Bufter « 4-26
R3000 Operating Modes * 4-25

4271

4272

428
4.29

4.3

R3000 Boot PROM Mapping * 4-29

YO Mapping Example. Reading a Register Associated with 11O
Adapter 7 » 4-29

Interrupts
Exceptions

R3010 FPA
FPA Registers
4.3.1
4311

4312

Floating-Point Genera! Registers (FGRs) = 4-34

4-30
4-31

4-33
4-33

Floating-Point Registers (FPRs) « 4-34

Floating-Point Contro! Registers (FCRs) « 4-34
4313
4-35
FPA CONTROL/STATUS REGISTER (FCR31)
4-37
FPA WAPLEMENTATION/REVISION REGISTER (FCRO0)

4.3.2

433

434

4.3.5

4.4

viil

FPA Formsts

Coprocessor Operation
4331
4332

Load, Store, and Move Operations « 4-39
Floating-Point Operations * 4-39

4333

Exceptions » 4-39

instruction Set Ovarview
R3010 Pipeiine Architecture

R3020 WRITE BUFFERS

4-38

4-39
4-40

4-41

Contents

4.5

4.6

CHAPTER S5

4.4.1

Write Butier Flugh

4-41

44.2

Write Buffer Byte Gathering

4-42

4.4.3

Write Butier Parity

4-42

FIRST-LEVEL CACHE MEMORY

4-43

4.5.1

Firet-Leve! Cachable References

4-43

45.2

First-Level Cache Organlzetion

4-44

4.5.3

Iniilalizing the Firgt-Level Cache

4-45

454

First-Level Cache Address Translation

4-46

4.5.5

First-Level Cache Data Block Allocation

4-47

456

First-Level Cache Behavior on Writes

4-47

4.5.7

Firgt-Level Cache Coharency

4-48

458

First-Level Cache Error Detection

4-48

INTERFACE LOGIC

4-49

4.6.1

The IIDAL Bus

4-49

46.2

Read Operation

4-49

46.3

Write Operation

4-49

46.4

Interrupt Acknowiledge Operation

4-50

4.6.5

Lock Transactions

4-50

4.6.6

DMA on the IIDAL Bus

4-50

46.7

idle

4-51

MS62A MEMORY MODULE

5-1

5.1

MODULE FEATURES

5-2

TECHNICAL DESCRIPTION

5-3

SELF-TEST AND INITIALIZATION

5-4

STARTING ADDRESS AND INTERLEAVING

5-5

5.4.1

Starting and Ending Addresses

5-5

54.2

interieaving

Contents

CONTROL AND STATUS REGISTERS
58

BUS ERROR REGISTER (XBER)

5-9

STARTING AND ENDING ADDRESS REGISTER

(SEADR)

8-12

(MECEA)

8-21

MEMORY CONTROL REGISTER 2 (MCTL2)

5-22

TCY TESTER REGISTER (TCY)

5-24

INTERLOCK FLAG REGISTER (IFLGN)

5-25

MEMORY CONTROL REGISTER 1 (MCTL1)
MEMORY ECC ERROR REGISTER (MECER)
MEMORY ECC ERROR ADDRESS REGISTER

5.6

5-¢

DEVICE REGISTER (XDEV)

5-14
3-18

ERROR HANDLING AND COMMAND RESPONSES

5-27

5.6.1

Read Errors

5-27

562

Full Write Errors

5-27

5.6.3

Partial Write Errors

5-28

CHAPTER6 DWMBA XMI-TO-VAXBI ADAPTER

6-1

6.1

DWMBA OVERVIEW

6-2

6.2

CPU TRANSACTIONS

6.2.1

General Operation

6-5

6.2.2

VAXBI VO Space Reads

6-5

6.2.3

VAXBI VO Space Writes

6-6

6.2.4

interrupts

6-7

6.3

6241

XM! IDENT to VAXB! IDENT « 6-7

6242

XM! IDENT with DWMBA Adapter Pending Interrupt « 6-7

6243

Passive Release of VAXBI Interrupts « 6-7

DMA TRANSACTIONS

6-8

6.3.1

VAXBI-to-XMI Memory Space Reads

6.3.2

VAXBI-to-XMI Memory Space interlock Reads

6-10

6-9

6.3.3

VAXBI-to-Xhl Memory Writes

6-10

6.3.4

VAXBI-Generated interrupts

6-10

Contents

6.4

6.5

DWMBA XHMI-TO-VAXBI ADAPTER RERISTERS
6-14
615

FAILING ADDRESS REGISTER (XFADR)
RESPONDER ERROR ADDRESS REGISTER (AREAR)
ERROR SUMMARY REGISTER (AESR)
INTERRUPT MASK REGISTER (AlAR)

6-2%
6-22
6-23
6-28

WAPLIED VECTOR INTERRUPT
DESTINATION/DIAGNOSTIC REGISTER (AIVINTR)

6-33

DIAG 1 REGISTER (ADGY)

6-34

CONTROL AND STATUS REGISTER (BCSR)

6-37

ERROR SULIARY REGISTER (BESR)
INTERRUPT DESTINATION REGISTER (BIDR)
TEOUT ADDRESS REGISTER (BTIM)
VECTOR OFFSET REGISTER (BVOR)

640
6-45
646
647

VECTOR REGISTER (BVR)

648

DIAGNOSTIC CONTROL REGISTER 1 (EDCR1)

649

RESERVED REGISTER
DEVICE REGISTER (DTYPE)

6-51
6-52

INTERRUPTS
6.5.1
DWMBA XMi-t0-VAXBI Adapter Vactor Formats and
Requirements
6511
6512
6513

6-54

XMI Bus Vector Format « 6-55
Ofisettable Bus Vectors « 6-55
VAXBI Node Vectors » 5-55

interrupt Levels and Vectors

6-56

6.5.3

Types of Interrupts

6-56

6.5.4

6.7

6-83

6.5.2

6531
6532

6.6

6-11

DEVICE REGISTER (XDEV)
BUS ERROR REGISTER (XBER)

DWMBA-Generated Interrupts « 6-56
VAXBI-Generated Intermupts = 6-57

XM! IDENT to VAXDB! IDENT
6-58
6541
XMI to VAXBI IDENT « 6-58
6542
XM! to VAXB! IDENT (DWMBA Interrupt Pending) » 6-58

ERROR REPORTING

6-59

6.6.1

VAXBI Errors

6-59

6.6.2

DWMBA Errors

6-59

6.6.3

DWMBA XMI-to-VAXB! Adapter Error Response Matrix

___

6-60

DWMBA INITIALIZATION, SELF-TEST, AND BOOTING

6-67

6.7.1

DWMBA inRialization

667

6.7.2

DWMBA Self-Test and Diagnostics

6-68

6721

Loopback » 668

6722

Self-Test » 6-68

Contents

CHAPTER 7
7.1

POWER AND COOLING SYSTEMS

7-1

POWER SYSTEM

7-1

7.1.1

Input Power

7-2

7.1.2

H7206 Power and Logic Unit

7-2

7.1.3

H7214 Power Ragulator

7-2

7.1.4

H7215 Power Regulator

7-3

7.1.5

XTC Power Sequencer

7-3

7151

XMI Resst Timing Control Logic « 7-3

7152

TOY Circuits » 7-3

71453
7.1.6

7.2

Console Line Driver and Receiver = 7-3

Power System Signals

7-4

CODLING SYSTEM

7-5

CONSOLE ENTRY POINTS

A-1

RESET - POWER-UP CONSOLE ENTRY - ENTRY 0

A-1

PROMEXEC - EXEC NEW PROGRAM - ENTRY 1

A-1

EXIT - REENTER CONSOLE - ENTRY 2

A-1

REINIT_CONSOLE - REINITIALIZE THE COMSOLE - ENTRY 3

A-1

CONDITIONAL_BOOT - INVOKE POWER-UP ACTION - ENTRY 4

A-2

REBOOT - REBOOT THE SYSTEM - ENTRY S

A-2

OPEN - OPEN A FILE - ENTRY 6

A-2

A7.1

filename

A-2

A7.2

flags

A-3

APPENDIX A

READ - READ FROM A FILE - ENTRY 7

A-3

WRITE - WRITE TO A FILE - ENTRY 8

A-3

Contents

A10

IOCTL - DEVICE-SPECIFIC 1/0 OPERATION - ENTRY 9

A1l

CLOSE - CLOSE AN OPEN FILE - ENTRY 10

A-4

A12

LSEEK - POSITION WITHIN A FILE - ENTRY 11

A13

GETCHAR - INPUT A SINGLE CHARACTER - ENTRY 12

PUTCHAR - OUTPUT A SINGLE CHARACTER - ENTRY 13

A-C

A15

SHOWCHAR - OUTPUT A SINGLE CHARACTER - ENTRY 14

A-5

A16

GETS - GET LINE OF INPUT - ENTRY 15

A-5

A17

PUTS - DISPLAY A LINE OF OUTRUT - ENTRY 16

A-5

A18

PRINTF - PRINT FORMATTE! VALUES - ENTRY 17

A19

FLUSH_CACHE - FLUSH PROCESSOR CACHE - ENTRY 28

A20

CLEAR_CACHE - CLEAR PART OF THE PROCESSOR CACHE -

ENTRY 29

A21

SET.MP - SAVE PROGRAM CONTEXT - ENTRY 30

A22

LONGJMP - RESTORE PROGRAM CONTEXT - ENTRY 31

A-7

A23

UTLBMISS_EXCEPT . CONSOLE UTLB MiSS VECTOR - ENTRY 32

A-7

A24

A25

GETENV - GET VALUE OF AN ENVIRONMENT VARIABLE - ENTRY

A-7

SETENV - SET VALUE OF AN ENVIRONMENT VARIABLE - ENTRY
34

A-7

Contents

A26

ATOB . CONVERT ASCH TO BINARY - ENTRY 35

A-7

A27

STRCMP - COMPARE TWO STRINGS - ENTRY 36

A-8

A28

STRLEN - FIND STRING LENGTH - ENTRY 37

A-8

A29

STRCPY - COPY A STRING - ENTRY 38

A-8

A3"

STRCAT - CONCATENATE TWO STRINGS - ENTRY 39

A-8

A.31

PARSE - PARSE A SIMPLE COMMAND - ENTRY 40

A-9

A32

PARSE_RANGE - PARSE AN ADDRESS RANGE - ENTRY 41

A-9

827

ARGVIZE . PARSE STRING INTO TOXENS - ENTRY 42

A-9

HELP - PRINT HELP FROM A COMMAND TABLE - ENTRY 43

A-10

A35

DUMPCMD - INVOKE CONSOLE DUMP COMMAND - ENTRY 44

A-10

A36

SETENVCMO - iNVOKE CONSOLE SETENV COMMAND - ENTRY 45

A-10

A37

UNSETENVCMD - INVOKE CONSOLE SETENYV COMMAND - ENTRY

A38

A39

A-11

PRINTENVCMD - INVOKE CONSOLE PRINTENV COMMAND ENTRY 47

A-11

GENERAL_EXCEPT - CONSOLE GENERAL EXCEPTION VECTOR -

ENTRY 48

A40

A41

xiv

A-11

CLEAR_NOFAULT - CLEAR CONSOLE FAULT HANDLERS - ENTRY

A-11

NOT_IMPLEMENTED - UNIMPLEMENTED FUNCTICN - ENTRY 52

aA-11

Contents

A42

HALT_INTERRUPT - SERVICE HALT INTERRUPT - ENTRY 54

A-12

A43

ENTER_MAINTMODE - ENTER MAINTENANCE MODE - ENTRY 86

A-12

A44

START_MAINT - START CODE ON THE MAINTENANCE
PROCESSOR - ENTRY 97

A-12

A.45

PROM DEVICE DRIVERS

A-13

A.45.1

bootp - BOOTP protocol Ethernet driver

A-13

A.45.2

ra- MSCP disk driver

A-13

A.45.3

mop - BOP protocol Ethernat driver

SEn

&
R

A-13

A.85.4

(ims - MS5CF tape anver

A-13

A.85.5

tty - conscle terminal pont

A-14

-P

R P S

INDEX

EXAMPLES
31
&1

Flushing Second-Level Cache

3-14

1O Raapping

4-29

e i

]

FIGURES
1-1

DECsystem 5801 System Architecture

1-4

1-2

Typical DECsystem 5800 System

1-6

DECsystem 5800 (Fromt View)

1-8

DECsys'em 5800 Syste«’ (Rear View)

1-9

1-5

VAXBI! Adapters

1-10

i-6

DECsyeotem 5800°2 ¥A2!

-1

1-7

DECsystem 5800's VAXBI

1-13

1-8

VAXBI Expander Cabinet

1-14

1-9

TK70 Tape Drive

1-15

1-10

Consoie and Terminal Connectors

1-16

-1

Power System (Rear View)

1-17

i-12

Alrflow Pattern

1-19

2-1

XMl System Block Diagram

2-2

XMI Node Block Diagram Showing the XMI Corner

2-4

2-3

XMI Memory and /O Address Space

2-12

2-4

XMI 110 Space Address Allocation

2-13

2-5

XMI Arbitration Block Diagram

2-16

2-6

Data Transaction Command Cycle Format

2-19

Contents

2-7

Interrupt Trangaction Command Cycle Format

2-19

2-8

Pask Fleld Bit Assignments

2-21

2-8

Node Specifier Fletd

2-24

2-10

Read Transaction

2-32

2-11

interiock Read Transaction to & Locked Location

2-33

2-12

Multiple Deta Cycls Reads Command Cycle

2-34

2-13

Read
Data Cycles

2-34

2-14

Read Data Cycles with HOLD

2-35

2-15

Hexword Read with Single Correctable Read Error

2-36

2-16

Hexword Data Return with Uncorrectiable Read Error

2-36

Longword anc Quadword Writes

2-37

Multipte Dain Cycle Writes

2-37

2-19

XMI Initiatization Flowchan

2-20

Falled Octaword Write Trangaction

rrLris

2-17

2-18

KNS8A
A Intertace Module Block Diagram

3-7

XMi Corner-t0-iNSB8A/A Interiace

Private 1/0 Address Space Map

Second-Level Cache Block Diagram

Cache Address Line Contemtg DuringaCacheReed
Cache Address Line Contents During a Second-Level Cache Fili
Second-Level Cache Addressing
XCPGA Block Diagram

3-9

interprocessor (VINTR Generation Address Example

3-10

Initialization Flowchart

Restan Parameter Block Format

3-12

Bootblock Format

3-13

CCA Layout, Part 1

3-14

CCA Layout, Pant 2

3-15

Lavout of Xkl Node Butfers
K N58A/B CPU Module Block Diagram
R3000 Registers
instruction Formats

Virtual Memory for Kernel and User Modes
R3000 Memory Mapping

FPA General-Purpoge Registers

Single-Precision Floating-Point Foimiat
Double-Precision Floating-Point Format

Cache Organization
First-Level Cache Organization

Cache Entry
Cache Address Transiation
DWMBA XMli-to-VAXBI Adapter Block Diagram
XMl Bus Vector Format
UNIBUS Vector Format
VAXBI Node Bus Vector Format
nvi

Contents

TABLES
1-1

XMi Slots

1-12

1-2

input Voltage

1-17

1-3

Power Supply Avalieble for VAXBI Options

1-18

2-1

Usable XMI Bandwidth

2-2

Data Transactions Supponed by ihe XMl

2-3

XA Terms

2-4

XM Interrupt Transactions

2-5

XMI Arbitration Lines

2-6

XM| Nodespace Addresses

2-7

XM Functiun Codes

2-8

XMl Command Codes

2-9

X! Transaction Lengin Codes

2-10

XMI Transactions

2-11

XM! Registers

Mapping of CPU Operations 1o XMi Transactions
Datalled CPU Read Oparation to XM! Man
Mapping of XMI Trangactions to KNSBA/A Intertace Module

Operations
XM! Regisiers iof ihe KNSBAVA imteriace Module
Abbreviaticns for Bit Type

Registers in XMI Private Space
KNSBA/A Interface Module Initisl Register States
Boot Parameters Loaded into GPRs
input Parameters Required by the Boot PrimRive

Output Parameters Required by the Boot Primitive

3-11

CCA Fields

312

Buffer Fields

3-13

Second-Level Cache Data Parity Errors

3-14

Second-Level Cache Tag/Valid Bit Parity Errors

315

XMi Bus Timeout Errors

3-16

XM| Bus Parity Errors

3-17

Maln Memory Correctable Errors

TSILLLLY

3-10

#main Memory Uncorrectable Errors

Coprocessor 0 Registers
Byte Speclfications for Load and Store Instructions
R30C0 External Hardware inierrupis
Iinterrupt Acknowledge Vectors

R3000 interrupt Levels 3, 4, and 5

Cache Entry Flelds
M3S62ZA RMemory Module Control and Status Registers
XMi-to-vAXBI Command Transiations

xvili

R
) DA

Contents

VAXBI-to-XM!I Command Translations

6-9

DWWMBA Errors During DMA Transactiong (VAXBI to XMl Memory)

XMl Registers on the DWMBA/A Moduie

611

XM! Registers on the OWMBA/B Module

6-12

VAXBI Registers

6-13

DWRMBA Adapter Interrupt Levels and Vectors

6-66

Xl Errors During DMA Trangactions (VAXBI to XMI Memory)
6-61

Xadi Errorg During CPU 1/0 Transactions (XMI to VAXBI)
.

6-62

6-10

DWMBA Errorg During CPU I/0 Transactions (XMI to VAXBI)

6-1

VAXBI Errors During DA Transactions (VAXBI to XMi Memory)

6-64

6-12

VAXBI Errors During CPU VO Trangactionsg (X#MI TO VAXBI)

6-65

7-1

Power System Signals

7-4

Preface

intended Audience
This manual is written for Digital customer service engineers installing
and repairing in the field and for OEMs who are writing specialized
applications, such as their own operating systems.

Document Structure
This manual has seven chapters.
Chapter 1 gives vou a basic introduction to the DECsystem 5800

system and its parts.

Chapter 2 tells you about the XMI bus and protocol.
Chapter 3 explains the KNSEA/A interface module, and Chapter 4
explains the KNS58A/B CPU module, the two modules that comprise a
DECsystem 5800 processor.

Chapter 5§ explains the MS62A memory module.
Chapter 6 tells you about the DWMBA and its DWMBA/A module
and DWMBA/B module
Chapter 7 explains the components of the power system and the
cooling system.
The Index= provides additional reference support.

Preface

Associated Documents
Other documents in the DECsyst-m 5800 documentation set include:
Title

Order Number

DECsystem 5800 Installation Guide

E£K-580AA-IN

DECsystem 5800 Owner's Manual
DECsystem 5800 Optrons and Me.

EK-580AA-OM
"~ tnce

EK-580AA-MG

You may also find the following documents useful:
Title

Order Number

CIBCA User Guide

EK-CIBCA.UG

DEBNI installation Guide

EK-DEBNI-IN

Guue to Ethernet Communication Services

AA-NL22A-TE

Guida to Languages and Programming for

AA-MLO4A-TE

RISC Processors

Gudde to Networking for RISC Processors

AA-MLBBA-TE

Guide to System Environment Setup

AA-NL1BA-TE

H3000 DIGITAL Ethernet Transceiver
installation Manual

EK-H4000-IN

H9657-EU installaton Guide

EK-VBIEU-IN

HSC Instakiation Manual

EK-HSCMN-IN

introduction to System and Network

AA-MLBOA.TE

Management for RISC Processors
KDB5S0 Disk Controller User's Guide

EK-KDBS0-UG

RAB82 Disk Drive User's Gude

EK-ORAB2-UG

RA90 Disk Drive User's Guide

EK-ORA90-UG

SA70 Enclosure User Guide

EK-SA70E-UG

5C008 Star Coupler User's Guide

EK-SC008-UG

Technical Summary for RISC Processors

AA-MM35A-TE

TK70 Streaming Tape Drive Owner's Manual

EK-OTK70-OM

TU8B1/TA81 and TUB1 PLUS Subsystem

EK-TUAB1-UG

User's Guide
VAXB! Optioris Handbook

EB-32255-46

VAX Diagnostic Architecture Reference
Manual

EY-3459E-DP

VAX Diagnostic Supervisor User's Guide

AA-FK66A-TE

VAX Systems/DECsystems Systems and

£C-10413.46

Options Catalog

EXEXXXOOOO

R R

XK OGO

R A K

XK KU

E KR R

XXX KA KR XK KX KX KX RO

KRR

KA XXX

XXX ORI

XXONN0OUOOONDI
X XX XXX XX

b0 6. 99.6.60¢.¢.066¢00¢600¢6¢646960000¢000060¢¢¢494]
P OGO

LSSEIINEEITEDCECE
L L0000
e tod

HHHXXKNGBOOGGE
RGO
KKGGOOOOGOTRR RN
BP0 00000810080 0 Eeeesseesessdeseeoss
el
HES A G000

e 000040000909
0900¢8004]

FOEP SN0 0000009000008 048000808000 0481

M
K KKK
K
K KK IO
KOO0

XM
XX KK E RN NURO000DIYYY
DO 80

ERE 0000900.0.6.6000840408.04

KK
VOO
X K XK XK KR AAKX

p.0.9.0.06.0.6.600.60.046.00¢0¢4¢00¢

F0.0.0.0.6.00.010.0.0.¢.¢.6.8.0.6666606]
p8.8.6.6.6.0.6.6.00.¢.6¢09¢¢0¢4¢06]
RREKEX KRGO

}6.9.9.0.0.4.4.6.9.4.6.0.4.0.6¢
9

10.4.9.0.6.5.0.4.0.5.6.0.4.¢4

h05.9.€.8.9.4.0.¢.0.4.¢9

§8.0.9.8.0.6.9.0.¢94
KXXAXKXKX
HXXXXXX

XXAXK

XXX
X

X
XXX
XXXXX

XXAXXXX

XXAUAXXAX

AXARXAAXRXARXX
XAXAAXAXXXKXX
XXXXXXXXXXXXXXX

XAXAXXUXXXXAXAXXX
},8,9.0.6:6.0.9.8.9.8.9.9.9.6.¢..¢
¢4
1,0.0.8.9.94.9.9.6.0.6.9¢.4.9.6.6¢464
KXXXAXKUXELXXKKXXXXXAAXXX

XAXAXXAX
XX XXX XXXAAKXXXK
ARXX
09.0.0.9.0.6,60.¢00.98¢8000¢60608¢$44
P800 000008900600808968864
06¢4¢4

p0.0.0.0.600080060.6¢¢66.06800966046.844

HAXXX
XX XXX
XKXXX
XX KRR NA AX
XXX AL

PO24000
000004800
064060606080 848¢444
8
XARAXK XXX KK UXAKAKARX XXX K XXX XK XKXAXXAX
D 30808000869 80906000408¢0 8608808045 0¢04]
AAKEX
AN HXK ARAXKXX
XXX KX KKK KKK XAXX KKK L
AXKX
XEXXXAUKX KX KKXEAAX XXX KXK XK AXXXKA AR KX KX XXX KX KKKANX
P0G 08800000608000608080080600004600.0586466890080]

20000
4006 80000008
60060
000000888 0809880900080
000
[00.0.8.0.8.00 00409069690¢66438806858864099080466900460084
DS

000000480080 00008880.08068¢090906969¢46060048¢998
01

The DECsystem 5800 System Overview

This chapter describes the system packages and system components and
notes the 'ocation of components in the cabinet.
This chapter includes the following sectionr
DECsystem 5800 Introduction

DECsvstem 5800 Configurations
DECsystem 5800 System Architecture
Tvpical System

DECsystem 5800 (Front View:

DECsystem 5500 (Rear View)

Supported YAXBI Adapters and Options
XMI Backplane and Card Cage
VAXBI! Backplane and Card Cage
VAXBI Expander Cabinet

TR70 Tape Dnive
'O Connections

Power System
Cooling System

The DECsystem 5800 System Overview

1.1

DECsystem 5800 introduction
The DECsystem 5800, a general purpose computer system based
on a reduced instruction set computer (RISC) CPU, is designed
for growth and can be configured for many different applications.
The DECsystem 5800 can support many users ia a time-sharing
environment.

The DECsystem 5800 does the following:

Supports a full set of ULTRIX-32 applications

Functions as a stand-alone system or as the node of a network

Allows for expansion of processors, memory, and 'O

Implements multiprocessing where all processors have equal access to
memory

Uses the VAXBI bus as the IYO interconnect

Uses a high-bandwidth internal system bus (XMD) designed for
multiprocessing

*
o

Interleaves memory bank accesses in a user-definable sequence
Performs automatic self-test on power-up, reset, reboot, or system
initialization

The DECsystem 5800 System Overview

1.2

DECsystem 5800 Configurations
The DECsystem 5800 system family has configuration packages
that differ in the number of processors and amount of memory.

Refer to the VAX Svstems/DECsystems Systems and Options Catalog for

the available configurations.

Each configuration has a 60-inch system cabinet that includes one 14-slot
high-bandwidth internal system bus backplane (XMD) and one 12-slot
VAXBI backplane.

1-3

The DECsystem 5800 System Overview

DECsystem 5800 System Architecture
The DECsystem 8800 system supports multiprocessing with up
to four KNSSA processors. The system uses a high-speed system

bus called the XMI bus to interconnect its KNSSA processors end
its MS82A memory modules. All VO devices connect to the VAXBI
bus.

Figure 1-1

DECsystem 5800 System Architecture

CPy ~ooue

l":

Varony

mMo~ace

"""’“"

Up 10 4 Proosascns

wioSvAXEs

Up o 2% Moyles

VAXE: £ xpance’ Cap '

OWMBA'B

VAXS

TBXTO-M|

[DEBN: M|

1DWwBI2

vAX8

)

—
o 21k vd

)

o ‘
!
P \

! /

(=) | é? : bé
TERMINA, S

EYHERNE

1-4

—-

{

DWVEAR

x08a8s-C|

|CBCA BA

K. ES B

Disks

STAR
COUPRLER

meb 0883 9C

The DECsysten: 5800 System Overview

The XMI bus is the DECsystem 5800 system bus; the VAXBI bus supports

the /O subsystem. The XMI bus is a 64-bit system bus' that interconnects
the central processors, memory modules, and VAXBI /O adapters.

The VAXBI and XMI buses share similar but incompatible connector and
module architecture. Both the VAXBI and XMI buses use the concept of
a node. A node is a single functicnal unit that consists of one or more
modules.

The XMI bus has three types of nodes: processor nodes (KNG8A), memory

nodes (MS62A memory modules), and the XMl-to-VAXBI L'C sdapters
(DWMBA).
A processor node, called a KN58A, is a two-board set. It consists of a
KNS8A/A interface module and a KNS8A/B CPU module. The KN58A/B

CPU module is the processor's computational engine and contains a MIPS?

R3000 CPU chip, an R3010 floating-point chip, R302u .

"te buffers, and

primary cache. The KN58BA/A interface module provides ¢ means by
which the KN58A/B CPU module accesses the XMI bus & :d contains a
CVAX chip, a second-level cache, a system support chip (. 3C), and XMI
interface logic. The module also participates in the system self-test.

Processors communicate with main memory over the XMI bus. The system
supports multiprocessing with up to four processors. One processor is
designated as the boot processor according to its physical location in the
card cage and that processor handles all system communication. The other
processors (if any? are called secondary processors. The processor node
number corresponds to the number of the XMI slot holding the KN58A/A
interface module.

A memory node is an MS62A memory module. Memory is a global
resource equally accessible by all processors on the XMI bus. Each MS62A
memory module has 32 Mbytes of memory, consisting of MOS 1-Mbit
dynamic RAMs, ECC logic, and control logic. The system supports up to
eight MS62A memory modules (256 Mbytes of memory). The memonies

are interleaved by the console on power-up. The default can be changed by
console command.

An XMI-to-VAXBI adapter, called a DWMRBA, is a two-board adapter
that transfers data between these two buses. The DWMBA/A module is
installed on the XMI bus; it is cabled to the DWMBA/B module on the

VAXBI bus. The system supports up to five VAXBI buses. Every VAXBI

bus on this system must have a DWMBA adapter. Therefore, systems with
two VAXBI channels have two DWMBA/A modules on the XMI bus, and
each VAXBI channel has a DWMBA/B module. Systems with more than
one VAXBI require a VAXBI expander cabinet. System error messages ana
self-test results refer to the pair of DWMBA niodules as XBI.

! The XMI bus has a 64-nanosecond bus cycle, with 8 maximum throughput of 100 Mbytes per second.
2 MIPS 1s 8 registered trademark of MIPSCO, Inc

1-5

The DECsystem 5800 System Overview

1.4 Typical System

‘
& main cabinet with a TK70
A typical DECsystem 5800 system, has
le terminal and printer,
conso
a
:ape drive and optional RA disks
mentation. The system may
an accessories kit, and a set of docu
have additional tape or disk drives.

Figure 1-2 Typical DECsystem $800 System
SYSTEM

CABINET

OPTIONAL

STORAGE

DEVICE

VT300 SERIES
TERMINAL

LA7S

PRINTER

msb-025° 80

-6

The DECsystem 5800 System Overview

Figure 1-2 shows a typical system.

The main cabinet houses a TK70 tape drive, up to eight RA disks
(optional), the XMI card cage (which contains the nrocessors and
memories), VAXBI card cages, the control panel s itches, status
indicators, and restart controls.
The TK70 tape drive in the main cabinet is used for installing
operating systems, software, and some diagnostic:.

The optional RA disk drive(s) in the main cabinet are used for
installing operating systems and software and are used for local
storage and archiving.

The optional disk drive cabinet provides additional local storage
and archiving.

The console terminal is used for console and system management
operations.

DECsystem 5800 hardware information kit that ships with the
system includes:

—

DECsystem 5800 Installation Guide

—

DECsvstem 5800 Ouner’s Manual

—

DECsystem 5800 Console Patch TK50 (tape)

—

DECsystem 5800 Console TK50 (tape)

See the Preface for a complete list of system documentation and
associated documents.

-7

The DECsystem 5800 System Overview

DECsystem 5800 (Front View)

The TK70 tape drive and conirol panel are on the front of the
system cabinet, accessible with the doore closed. With the front
door open, Digital customer service engineers can access the
VAXBI and XMI card cages, the cooling system, the RA disk(e), if
present, and power regulators.
Figure 1-3

DECsystem 5800 (Front View)

T0 TAPE DRIVE o {
CONTROL PANs.

POWER REGULATORS

—]

VAXB!

XMk CARD CAGE

GARD CAGES

COOL NG

SYSTEM

POWE
B ENT

LOGIC BON =208

TRANSK ORME B
130+ SYSTEMS

L Diss
(OPTIONA,©
mad 0833 9C

These components are visible from the inside front of the cabinet (see
Figure 1-3 for their location).
TK70 tape drive

Control panel
Power regulators

Two VAXBI card cages hardwired together to form a single VAXBI
channel. Only one VAXBI is perniitted in the main cabinet. Additional
VAXBIs require an expander cabinet.

XMI card cage

Cooling system (one of the two blowers is visible)
Transformer (on 50 Hz systems only)
Power and logic box (H7206)

RA disks (if installed)

1-8

The DECsystem 5800 System Overview

1.6

DECsystem 5800 (Rear View)
With the rear door open, Digital customer service eugineers can

access the power regulators; powor sequencer module (XTC);
cooling system; power and logic box; RA disk(s), if present; AC
power controller; Ethernet and console terminal connectors; and
the VO bulkhead space.

Figure 1-4

DECgystem 5800 System (Rear View)

—-"—fi

A; l l

H- xicPOwER

—

SEQUENCE R MODULE

POWER _§i
REGULATORS
L————J
o

CARD CAGE

AL AR

—
cooms

vas

CARD CAGES

£ THEANE 1 AND

CONSOLE TE RMINAL

CONNE
C

TORS

SvSTtim
—fj{—

POWER aND

LOGIC BOX (MT206
—

DISKS

(OPTIONAL

AC POWER

conTROuER

(ha0s,

raly D6 §

These components are visible from the rear of the cabinet tsee Figure 1-4):
*

Fuve field-replaceable power regulators

Power sequencer module (XTC) located on the back of the TK70 tape
drive and control panel unit

1/Q bulkhead space

The panel covering the XMI and VAXBI areas is the /O bulkhead
panel and provides space for additional VO connections.

Cooling system, with open gnid over a blower

VAXBI and XMI adapter bulkhead cables

Ethernct and console terminal connectors

Power and logic box (H7206)

RA diskis) (if installed)

AC power controller (H405)

The DECsystem 5800 System Overview

1.7

Supported VAXBI Adapters and Options
The system supports the use of the following VAXBI adapters:
CIBCA, DEBNI, DHB32, DMB3S2, KDBSO0, TBK70, TUSIE, and
DWMBA.

Figure 1-5

VAXBI Adapters
VAXBI Expander Cabinet

‘

DWWEAB
-

<rwmsv

\
N

TOK70M oeau:-fl omax | |owaae

n
f

@ food,

TEAMINA. S

]

wopsoc|jcacasa) | kiESI8

E§
B

DSKS

S§TAR

2oupien

—r—
ETHERNET

~b.0252.89

See the VAX Systems/DECsysterns Systems and Options Catalog for a
complete list of VAXBI adapters available for the DECsystem 5800 and the
VAXBI Options Handbook for detailed information on each VAXBI adapter.

1-10

The DECsystem 5800 System Overview

1.8

XM! Backplane and Card Cage
The XMI high-speed system bus interconnects processors and
memory modules. It has a maximum bandwidth of 100 Mbytes per
second and supports up to four processore. The 14-slot XMI card
cage houses XMl-to-VAXBI adapters, processors, and memories.

Figure 1-6

DECsystem 5800's XMi

XM CARD CAGE

f\\

CPu modue

CPU modue

wrigtace

werace

MO0 %

mod. e

Mooy
v

;

=
v

mab-0254 80

1-11

The DECsystem 5800 System Overview

The XMl is a limited-length, pended synchronou= bus with centralized
arbitration. The XMI bus can procesas several transactions simulianecusly,
makiug efficient use of the bus bandwidth. The bus includes the XMl
backplane, the electrical environment of the bus, the protocol that nodes
use on the bus, and the logic to impiement this protocol.

The XMI backplane and 14-slot (nodes 1 through E) card cage are located
in the upper third of the cabinet on the right s'de, as viewed from the front
of the cabinet. A clea: latched door protects the componenis housed in the
XMI card cage and helps to direct the airflow « ver the modules. Indicator
lights on the XMI modules can be viewed throv ¢h this clear front door.

Each slot of the XMI ecard cage is hardwired to a 4-bit node 1D code that
corresponds to tne physical slot number in th> card cage. The nodz ID
number of the module is its slot position. The nodes are numbered 1

through E (hex) from right to loft, as you view the card cage from the front
of the cabinet.

For information on installing modules in the XMI card cage, see the

DECsys:em 5800 Options and Maintenance manual. For in-depth technical
informaticn, see the appropriate chapter of this manual.

O
O
0
©

ek
b
-

N
- o

Mem
Mem

KNSBA'A, Mem

Mem

KNSBAVA, 1/0, Mem

Mem

KNS8A/B, Mem

KNSBA/A, KNSBA/B, 110, Mem

KNSBA/A KN5BA/B, 1O, Mem

KNSSA'A, KNSBA/B, 11O, Mem
W

KNSBAVA, 110, Mem

Permissible Modules’

Node

Slot

XMI Slots

Table i-1

KNS8A/B, 1D, Mem

KNS8A/B, 110, Mem

110, Mam

'Key to permissible medules:
KNSEA/A = Interfar, ~aodule

KNSBAB = CPU Module
Mem = MS62A Memaory Module

IO = DWMBA

1-12

The DECsystem S800 System Overview

VAXBI Backplane and Card Cage
The VAXBI is the 1’0 interface. The VAXBI card cages house
modules that connect the system to the Ethernet, multiple
terminals, and other peripherals.

Figure 1-7

DECsystem 5800's VAXBI

vAXa

=
TR
T W 1 DEBN

wmvaR |l | o-Bx

DB
C)

]

‘

]

Q@ Lo
,O
j
'

TERMNA.S

Oisks

—
{cBCABAL|

m.ES
B

STAR

COULP.ER

S
cmy
W
£ THEANE "

mab025s
89

The VAXB! bus is a high-performance 32-bit bus that is the system’s
VO interface. The system cabinet contains one logical VAXBI chanrel,
comprised of two 6-slot card cages. The VAXBI card cages are located in
the upper third of the cabinet on the left side, as viewed from the front
of the cabinet. A clear latched door (closed for normal operation) protects

the componentis housed in the VAXBI card cages and helps to direct the
airflow over the modules. A VAXBI expander cabinet can also be added to
the system as described in Section 1.10. See the DECsystem 56800 Options
and Maintenance manual for more information on the VAXBI card cages.

1-13

The DECsystem 5800 System Overview

110

VAXBI Expander Cabinet
A VAXBI expander cabinet can be ordered to increase ihe system's
VAXBI /O slots. One to four VAXBI cages can be added (o a system.

Figure 1-8

VAXBI Expander Cabinet

—31COOLING
ASSEMBLY

—g——

154 CM
(60 5 W)

17O 4 POWER

SUPPLY UNITS

1 TO 4 VAXB!

CARD CAGES

AC POWER
SuPPLY

L—

786CM

(30 IN)

——

mab0161
88

A VAXBI expander cabinet (see Figure 1-8! allows you to attach additional
VAXBI channels, each with its required DWMBA/B.
The cabinet holds one to four VAXBI card cages, each with its own
power supply. Two blowers cocl the cabinet, and an AC power controller
completes the power system.

1-14

The DECsystem 5800 System Overview

1.11

TK70 Tape Drive
The TK70 tape drive is mounted at the front of the system oabinet
in the upper left corner.

Figure 1-8

TK70 Tape Drive

FRONT

map-0°75
68

The TK70 tape drive is used for:
*

Installing or updating software

Loading diagnostics

Interchanging user data

Updating the contents of the EEPROM

1-15

The DECsystem 5800 System Overview

1.12

/0 Connections
VO connections are installed on the bulkhead connections tray and
the /0 conneciion pancl. The V0 tray is located in the rear of the
cabinet, above the cooling eystem and below the power reguliators,
and covers the XMl and VAXBI backplanes. The VO panel is just
below the right-hend side of the VO tray and houses the Ethernet
and console terminal ports.

Figure 1-10

;

Console and Terminal Connectors

REAR

BULKHEAD
TRAY

TERMINAL

PORT

==l
T
1

|
5|
4

CONSOLE

|
l

H 110 PANEL
L

<> —&TM+¢ gg&gnner
&

89
mgD-025%6

1-16

The DECeystem 3800 System Overview

1.13

Power System
The power system consists of an AC power controller (H405E/F)
with circuit breaker, the power and logic boz (H7208), and five
power regulators for the XMl and VAXBI backplanes.

Figure 1-11

POWER

Power System (Rear View)

REGULATORS

—

POWER AND
LOGIC BOX (HT206!

AC POWER
CONTROLLER
{HGO5EF)

med 0253 89

Table 1-2

input Voitage

tAodel No.

[ ]

Nominal

Phase

H405-E

208V

H405-F*

380V

H405-F

416V

*Change tap for 380V (nominal} aparation

1-17

The DECsystem 5800 System Overview

Most of the power system is visible from the rear of the cabinet. An AC

power controller with circuit breaker is in the lower right corner. The
power and logic box is just above the AC power controller. Across the top
of the cabinet are the power regulators for the XMl and VAXBI card cages.

Power is supplied by two H7215 power regulators and three F'7214 power
regulators. One H7215 and one H7214 supply the power to the VAXBI,
one H7215 and two H7214s supply the power to the XMI. See Table 1-3.
Table 1-3

Power Supply Avallable for VAXBI Oplions

DC Voltags

Avaliable VAXBI Current

Note

+5V

B60 A

Main logic

+5VBB

Connected 10 +5V

Not battery backed up

+12V

40A

RS-232

24 A

RS-232

=52V

200A

ECL logic

~2V

70A

ECL fogic

Two power connections are on the back face of the power controller and are
fuse-protecied. When the system is powered down, the de"ices e*tached at
these switches are also powered down. Three reon lights on the H405-E
AC power controller (60 Hz systems only) indicate the presence of the
3-phase voltages at the input to the power controller.

1-18

The DECsystem 5800 System Cverview

1.14

Cooling System
The cooling system consists of two ble ~ers, an airflow eensor, a
tomperature sensor, and an airflow path through the card cages
and up to the power regulators.

Figure 1-12

Alrfiow Pattermn

POWER
REGULATORS

CARD CAGES

BLOWERS

REAR

FRONT

EXTERNAL

FRONT VIEW

INTERNAL

SIDE VIEW

meb-0008-89

The cooling system is designed to keep system components at an optimal
operating temperature. It is important to keep the front and rear doors
free of obstructions, leaving a clear space of 39.4 inches (1 meter) from the
cabinet, to maximize air intake.

The blowers, located in the lower half of the cubinet, draw air in through
the doors and push air up through the VAXBI and XMI card cages. The
airflow continues through the top of the card cages, through the power
regulators, and out the top of the front and rea: doors. A fan cools the
power and logic box.

The system has safety detectors for the cooling system: an airflow sensor
and a temperature sensor installed above the power regulators in the
top of the cabinet. Extreme conditions activate theie detectors. The
temperature sensor shuts off the power at the AC power controller if the
unit experiences extreme temperatures. If the system has airflow seriously
blocked for an extended period of time, then the airflow sensor will shut
off power.

1-19

OO KN KK
XN KR XK KOO0 KK KOO0
WO
X KX KX
NTH
MNICRNOONI
GOON
K NGOBGENNNO
KN000ONO

1 0000.0700000.000000¢800000000 0860000880t e e e
HRHXHEX KK HH K IOOOHER KGR KGO X KKICON YRR H
008
0004¢4
Pttt Pttt Nt TR TR0009004000
e

IGO0

8000

RN KEXY

0000000008 000604l o0
E SO0
PSS 0000086000006 6000000008 00808 064001

XXX KOOSO
OO

KUK KRRXKRELRKRKNNK

XICOOCOO T

KRERXRKIC00KX

080,
808
6890099
fAL L0000400000008
. RREKOGGOUOUREGoannnyY
SERAAEG 53 FAFLI LIS U

WF UL

PRI

OO KR
FEDOCGGOONNNNOMR
p O 000000 EE R 000060000041

b $.0.6.00.60.00 4000860668004
b0.6.90:0.0.8:0.0.0.5.64.0.00:060694
PS04 ¢8.0.0.04,646.0308.084

X
XXX

h.9.4.9.9.¢

XUKAXXX

KXXAXARKXX
h.0.0.9.4.9.444.944

UEXRXXKXEXKAKXXK

KEHKXAKAKAXKLXXX
r 0. 0.6.6.8.6.6.98.044¢8444
PG 8068080800 900804]

pO.8.8.0.6.0.6.4.6.9068504098¢44
XXX AKX KKK KX XXX RAKKX KKK KK

KKK LARKKK
KKXXH
XX XXX
XAAREXAX
D080°04.9.8.0.90.0.0.06.¢.9.06¢0¢
4004

09.9.0.84.8496,06060.000080804500083
)670.0.0.8.0.004.640¢540¢8.06096980300]

00
.009
66¢9.090400¢08
.00.900
6960004
D0.0:0:4

P .0:0.06.¢.00.60.86.0$68450399 6834884802404

AR AKXAK UK LUK LK XX KER A XK UK UK K XU AKX AKKK
AU KXXANAX
XA XK UK KR KUK ARLHE
KXHKH
XX AKX ALK
HAKRX
0
0088080 1004800¢01
000080
0000098008
P 0T84 060800
KHEKKODUK KUK KA UK AKX R XKL KKK AKX XK KKK AKX KARAK
P 0608808000 6006 8000080008 80¢90680388800e444]

0800004
00004
80808
P 0.8.6.0.0.60 00000800040 ¢000990888
PO 4408000000008 08006.000080686098¢8000882488080048804]

08104
P 8.500.0000.400 040666440988 ¢86480000008.004000808¢0

The XMl

Thie chapter describes the XMI, which includes a backplane and bus
interconnect, protocol, and logic.

This chapter includes the following sections:

‘

XMI Overview

XMI Addressing

Arbitration Cycles

XMI Transactions

XMI Initislization

XMl Registers

XMI Errors

¢« XMI Cycles

The XM

2.1

XM Overview
The XRI is the primary interconnect for the DECsystem 8800
eystem. The XMI supporis muitiple processors, multiple memory

modules, and multiple /0 adapters. Figure 2-1 shows a fourprocessor DECsyetem 6800 system.

2.1.1

XMl System Block Diagram Description
Flgure 2-1

XM System Block Dlagram

r‘—_!?l
CPL ~oo.
@

Vamony

mMIrae

;

Upro4 Processe's

up102% Moyes

UCT0 S VARR s

—
rreb 0688 9C

2-2

The XMI

The XMI consists of the electrical environment of the XM1 bus, the pretocol
observed by a node on the bus, the backplane, and the logic used to
implement the protocol.
The XMI bus is limited length, pended, and synchronous with centrakized
arbitration. Several transactions can be in progress at a given time,
allowing highly efficient use of the bus bandwidth. Arbitration and data
transfers can occur simultaneously. The bus supports:
¢

Quadword-, octaword-, and hexword-length reads to memory

Quadword- and octaword-length memory writes

Longword-length read and write operations to L/O space

The longword operations implement byte and word modes required by
certain IO devices. The XMI has a 64 ns bus cycle. The XMl has a
bandwidth of 100 Mbytes per second; however, the usable bandwidth
depends on transaction length (see Table 2-1).
Table 2-1

Usable XMI Bandwidth

Oporstion

Bandwidth (Mbytss/seconds)

Longword (4 bytes) Read

3125

Quadword (8 bytes) Read

62.50

Octaword (16 bytes) Read

83.30

Hexword (32 bytes) Read

100 00

Longword Write

3125

Quadword Write

6250

Octaword Write

8330

The XM

2.1.2

XMt Corner
The XMl uges similar, but incompatible, connector and module
technology as the VAXBI bus and, like the VAXBI, XMl modules
have an area wiih predefined etch with custom components, which
serves as the interface between the module and the XMI bus. This
predefined etch and components is called the XMI1 Corner.

Figure 2-2

XMi Node Block Diagram Showing the XMl Corner

Corner

XCi

XMI

G
i
RE

[

Node-

Specific

ogic

¢oocksX i

lg—

conTRC.

xC.0Cx

——

mab-0374-89

2-4

The XMi

The XMI Corner has a predefined etch and parts placement. The custom
components in the XMI Corner are called XLATCH and XCLOCK. Both
components are implemented in CMOS and interface node-specific logic to
the XMI Corner components over the XMI Corner interface (XCI) bus. The
XMl Corner, in turn, interfaces directly to the XMI bus. (See Figure 2-2.)

Each node has a set of three clock signals, which are distributed radially
te each node from a central source on the backplane. These clocks
are received by the XCLOCK chip, which then provides a set of clock
waveforms (XCI clocks) to the node-specific logic and the required control
lines (XL lines) for the seven XLATCH chips. The XLATCH chips provide
the interface to all the XM! lines except those directly interfaced to the
XCLOCK chip.

The XMi

2.1.3

XMiData Transactions
The XMI supports various data transactions, as shown in Table 2-2.

Tebie 2-2

Data Trengactions Supporied by the X

Traneaction

Langth

VO Space

Read

Longword

imeriock Read

Write Masked

Unilock Write

2-6

kormory Spaceo

Quadword

Octaword

Hexword

Longword

Quadword

Octaword

Hexword

Longword

Quadword

Octaword

Longword

Quadword

Octaword

The XMI

The following terms are used to describe XMI transactions:
Teble 2-3

XM! Terms

Term

Description

Node

A hardware device that connects to the XM! backplane.

Transter

The smallest quantum of work that occurs an the XMI. Typical
examples of transters are the command cycle of a read and the
command cyies with the following data cycles of a write.

Transaction

The logical task baing parformed (such as a read) A transaction
18 composed of one or more transfers. As an example o! a
transaction, the read consists of a8 command transter followed,
some time later, by a return data transier.

Commander

The node tha! initiated the transaction in progress. For example,
the commander nitiates & read transaction while th» responder
(data source) intiates the read data transter. The responder
1s not the commander for the read data transter because the
transter was requested by the commander node

Responder

Transmter

The node that responds 10 the commander n a transaction.

The node that 18 sourcing the information on the bus. For
example. dunng a read transaction the commander 1s the
transmater during the command transfer but i1s the recever
during the return data transfer.

Recewar

The node that ts the target dunng a transfer

Naturally aligned

Describes a daia quanity whose address could ba speciied &s
an ofiset, from the beginning of memory, of an integral number
of dala glements of the same size The lower bits of a naturally
aligned data dem are zerou. All XMI wrtes transfer a naturally
algned block of data

Wraparound read

An octaword or hexword read whers read data 1s returned
with the specifically addressed quadword first, sndependent of

atignment The remaining data in the naturally aligned block
of gata containing the addressed quadword 1S returned in
subsequent transfars

2-7

The XMI

Reads cause the transfer of data froin the responder to the commander.
Writes cause the transfer of data from the commander to the responder.
Longword commands transfer 4 bytes while quadword, octaword, and
hexword commands transfer 8, 16, and 32 bytes, respectively.
Interlocked variations of read commands are intended to do the same thing
as the regular reads, but they also invoke a mutual exclusion mechanism
where a lock flag associated with the location is set. Unlock writes
cause the clearing of the lock flag. During periods when a location is
locked, subsequent interlock reads to that location result in the responder
returning a "locked" response instead of read data.
All writes are masked and are accompanied by a set of mask bits that
specify which bytes of dats are to be written. Any arbitrary pattern of
bytes can be written with a write mask.
Longword-length transactions may only be used in IO space (A<29> = 1).
Quadword-, octaword-, and hexword-length transactions may only be used
in memory space (A<29> = 0).

Addresses for memory and /O space are given in Section 2.2.1 and
Section 2.2.2.

2-8

The XMI

XMI Interrupt Transactions
The XMI supports three types of interrupt transactions, listed in
Table 2-4.

Table 2-4

XM Interrupt Transactions

Type

Mnomonic

interrupt Request

INTR

(dentity (interrupt Acknowledge)

DENT

imphed Vector Interrupt

IVINTR

The INTR and iDENT transactions implement device interrupts. An 1O
node issues an INTR transaction to a processor to interrupt the processor
at a specified interrupt priority level (IPL). The processor responds to
the INTR by issuing an IDENT transaction to the interrupting VO node,
soliciting an interrupt vector.

An INTR transaction can be broadcast to multiple processor nodes. The
first processor to respond with IDENT receives the interrupt vector. All
other processors, upon seeing the IDENT directed to the interrupting
device, cease their interrupt-pending condition. If IDENTS are issued
simultaneously by two or more processors, the first to gain the bus will
service the interrupt while the other(s) force a software passive release.
The IVINTR transaction implements single-cycle interrupt transactions
where the interrupt priority and the interrupt vector value are implied
by bits in the interrupt type field. The IVINTR transaction implements
interprocessor interrupts (IPL = 14 (hex), vector = 80 (hex)) and write

error interrupts (IPL = 1D (hex), vector = 60 (hex)). Since the value of
the interrupt vector is indicated by the value of the IPL field, IVINTR
transactions do not require a corresponding interrupt acknowledge cycle.
See Section 2.5.5 and Section 2.5.6 for more information on interrupt
transactions.

2-9

The XMi

2.1.5

Arbitration
The XMI protocol includes arbitration because, at any time, any or all of
the nodes may desire the use of the XMI. Arbitration determines
which node gains the XM] when more than one rode requests the XMl
simultaneously.

Table 2-5

XM Arbitretion Lines

Name

Use

XMI CMD REQ L

inittates XM! transactions

XM! RES REQL

Returns data

XMl GRANT L

Indicates which node has been granted the XMi buse for
the nexi cycle

The DECsystem 5800 supports an XMI bus of 14 nodes. Arbitration cycles
occur in parallel with data transfer cycles, since the XMI has a set of lines
dedicated to arbitration. These lines are listed in Table 2-5.
Whan a node desires ownership of the bus, it asserts one of its two request

iines (XMI CMD REQ L or XMI RES REQ L) that are connected to the
central arbiter The XMI CMD REQ L line i8 usec. by nodes to initiate
XMI transactions (that is, act as a commander) while the XMI RES REQ
L line is used by nodes to return data to a commander (that is, act as
a responder). The XMI arbiter maintains two independent round-robin
queues, one for each request type. The responder requests are given
higher priority than commander requests.
See Section 2.3 for more information on arbitration.

2-10

The XMI

. 2.1.6 Bus Integrity
The XMI bus contains a number of features to enhance the integrity and
reliability of the bus.

The features of the XMI that enhance bus integrity and reliability are:
¢

All bus information transfer lines are pariiy protected.

Bus confirmation signals are ECC protected.

XMI protocol permits detection and recovery of almost all single-bit
errors on the information transfer lines and bus confirmation signal
lines.

XMI protocol defines timeout conditions that are used to detect
failures.

2-11

The XMi

2.2

XMI Addressing
The XMI supports memory with a gigabyte (2° bytes) of address
space. This memory space is divided into the physical memory
space and U0 space, shown ia Figure 2-3.

Figure 2-3

XM Memory and VO Address Space

Byte Address
0000 0000

Physical Memory Space

(512 Mbytes)
1FFF FFFF

2000 0000
'O Space
(512 Mbytes)

3FFF FFFF
mab-0368-89

2-12

The XMI

2.2.1

XMiMemory Space
A/D<29> selects between the memory and VO space. A/D<29> = 0 selects
physical memory space, while A/D<29> = 1 selects /O space.
The upper two bits of an XMI address are used to define transfer size.

2.2.2

XMIVO Space
XMI VO space is divided into private space, nodespace, and eight IO
adapter address space regions.

Figure 2-4 XMI /O Space Address Aliocation
Sze

Byte Address
2000 0000

2180 0000

XMi Private Space

24 Mbytes

2200 0000

2400 0000

XMi Nodespace

VO Adapter 1 Address Space

32 Mbytes

3A00 0000

VO Adapter C Address Space

2600 0000
2800 0000
2A00 0000
3600 0000
3800 0000

3C00 0000

3E00 0000
3FFF FFFF

16 x 512 Kbytes

VO Adapter 2 Address Space
VO Adapter 3 Address Space
VO Adapter 4 Address Space
Reserved
VO Adapter B Addrass Space

32 Mbytes
32 Mbytes
32 Mbytes
192 Mbytes
32 Mbytes

'O Adapter D Address Space

32 Mbytes

VO Adapter E Address Space
Resarved

32 Mbytes
32 Mbytes
32 Mbytes
mab-0368
89

2-13

The XI

22241

XeAl Private Spece
References to XiMI private space are serviced by resources local to a node,

such 25 local device CSRs and boot ROM. The references are not broadcast
on the XM]. X\l private space is a 24-Mbyte address region containing
the resc¢ address.
2222

The DECsystem 5800 XMI nodespace is a collection of 14 512-Kbyte
regions located from 2188 0000 to 21F7 FFFF. Each XMI node is allocated
one of the 512-Kbyte regions for its control and status registers. The
starting address of the 512-Kbyte region associated with a given node is
computed as 2180 0000 + Node 1D * 80000.
Teble 2-6

2-14

XM Nodespace Addresses

Siot

Node

Nodespace

VO Adepter Space

2188 0000 -~ 218F FFFF

2200 0000 - 23FF FFFF

2190 0000

2197 FFFF

2400 0000 -

25FF FFFF

2198 0000

219F FFFF

2600 0000

27FF FFFF

21A0 0000 - 21A7 FFFF

2800 0000 - 29FF FFFF

21A8 0000

21AF FFFF

21B0 0000

21B7 FFFF

21B8 0000 - 21BF FFFF

21C0 0000

21C7 FFFF

21C8 0000

ZiCFFiFF

21D0 0600

21D7 FFFF

2iDB 0000 -

21DF FFFF

3600 0000 - 37FF FFFF

21E0 0000

21E7 FFFF

3800 0000

39FF FFFF

21EB 0000

21EF FFFF

3A00 0000

3BFF FFFF

21F0 0000

21F7 FFFF

3C00 0000

3DFF FFFF

The XM!

VO Adapter Address Space
/O adapter address space consists of eight 32-Mbyte address regions used
to access VAXBI /O adapters. Longword cig.l. .eferences directed to a
VAXBI's O adapter address space v.ii be reissued on that VAXBI bus.

XMI transactions are translated into a corresponding VAXBI transaction.
The VAXBI address of the transaction is computed from XMI addresses as
2000 0000 + offset, where offset is the difference between the XMI address
and the start of the appropriate DWMBA/A module's address space. XMI
devices can only access VAXBI O space, as VAXBI memory space is not
accessible to nodes on the XML

To calculate the address of the first register in nodespace (the DTYPE
register):

The base address of 'O space is 2000 0000 (hex).

Bits<28:25> correspond to the XM! node number, which is the same as
the slot number except that node numbers are in hexadecimal while
slot numbers are in decimal. The XMI nodes typically allocated to
DWMBA adapters are as follows:
~maom

2223

- the VAXBI in the system cabinet

- the first VAXBI in an expander cabinet; usually leftmost
- the second VAXBI in an expander cabinet; usually center-left
- the third VAXBI in an expander cabinet; usually center-right
- the fourth VAXBI in an expander cabinet, usually rightmost

PBits<l€:13> correspond to the VAXBI node number. For the VAXBI
inside the system cabinet, the nodes are usually numbered 1 to 12. For
the VAXBIs in a VAXBI expander cabinet, consult the system-specific
configuration chart.

For example, the leftmost slot in the VAXBI in the system cabinet, usually
VAXBI node 12 would be connected to XMI node E. The DTYPE register
for the VAXBI option in that slot would be addressed as 3C01 8000.

'O addresses associated with /O adapters 0, 1, 2, and 3 are accessed
via ksegl. /O addresses associated with 1O adapters 4, 5, 6, and 7 are

accessed via kseg2. See Section 4.2.7.2 for more information and an
example.

2-15

The XMi

2.3

Arbitration Cycles
The XMI protocol includes arbitration because, at any time, any
or all of the nodes may desire the use of the XMI. Arbitration
determines which node gains the XMI when more than one node
requests the XMI simultaneously. Arbitration cycles occur in
parallel with data transfer cycles, since the XMI has a set of
arbitration-dedicated lines.

Figure 2-5

XMl Arbliration Block Diagram

XKMLHOLD
L
XM SUP L

XM CMD REQ|IIL

NODE

XMI RES REQ|1)L

XMi GRANT{1] L

——4

@<
L]

‘

CENTRAL
ARBITER

‘

XMi CMD REQ{14] L

NODE

XMI RES REO{14) L

XM! GRANT{14] L
meb-0367-83

2-16

The XAt

The XMI protocol architecturally supports up to 16 XMI nodes. However,
the DECsystem 5800 implementation supports 14 nodes. Each node on
the XMI bus has a hexadecimal identification number (1 through E) called
the node ID, which is provided by the node's hard-wired XMI NODE
ID<3:0> H lines. The physical slot number equals the node ID. Slot 1 is
the rightmost slot in the XMl card cage when viewed from the front of the
cabinet.

Any or all nodes may desire the use of the XMI at any given time.
Arbitration cycles occur in parallel with data transfer cycles by using
a set of lines dedicated to arbitration. The XMI CMD REQ L line, the
XMI RES REQ L line, and the XMI GRANT L line go between the central
arbiter and each node. The XMI CMD REQ L line is used by nodes to
initiate XMI transactions (to act as a commander), while the XMI RES
REQ L line is used to return data to a commander (to act as a responder).
The XMI arbiter maintains two independen*, round-robin queues, one for
each of the request types. The responder requests have a higher priority
than commander requests.

During any given cycle, all nodes have the opportunity to request the bus.
The arbiter receives all the requests, decides which node will be granted
the bus, and uses that node’s XMI GRANT L line to tell the node that it
has been selected. In the next cycle, the selected node begins its transfer.
The XMI has two additional arbitration control signals, XM! HOLD L
and XMl SUP L. XMI SUP L suppresses all commander requests but
allows responder requests to continue to be serviced. Assertion of XMI
HOLD L guarantees that the current XMI transmitter will be granted
ownership of the bus in the next cycle, independent of the value of any

other outstanding requests. The XMI HOLD L signa!l is used for multicycle
transfers, allowing the current transmitter to keep ownership of the bus
for consecutive cycles.

A node can temporarily blnck the start of additional XM transactions by
asserting the XMI SUP L signal should it have difficulties in keeping up
with bus traffic, such as a memory queue becoming full or a CPU backing
up on cache invalidate operations due to XMI writes.
The XMI arbitration scheme consists of three priority classes:
¢

Hold, which has the highest priority and guarantees that the current
transmitter will be granted the bus in the next cycle.

Responder requests, the next highest priority.

Comniander requests, the lowest priority.

Within the responder and commander classes, priority is distributed in a
round-robin manner.

2-17

The XMl

2.4

Kl Cycles
The purpose of an XMI cycle ie determined by four cignal lines on
the XMI backplane, XRMI F<3:0> L.

2.4.1

Function Codes
The XMI uses four | nes to encode the function being performed on the
bus. Table 2-7 lists the function codes.
Tabile 2-7

X0 Function Codes

XAl Fe3:05 L

Logic Levele

2-18

Function

Mnemonic

NULL cycle

NULL

Command cycle

CcMD

Write Data cycle

WDAT

Reserved (decoded as NULL)

Lock Response

LOC

Read Error Response

RER

Reserved {decoded as NULL)

Reserved (decoded as NULL)

Good Read Data 0

GRDO

Good Read Data 1

GRD1

Good Read Data 2

GRD2

Good Read Data 3

GRD3

Corrected Read Data 0

CRDO

Corrected Read Data 1

CRD1

Corrected Read Data 2

CRD2

Corrected Read Data 3

CRD3

The Xl

24.2

Command Cycles
During XMI command cycles, commander nodes initiate XMl
transactions. The commander drives ita commander ID on XMl
[D<5:0> L. and drives command information on D<83:0> L, as shown
in Figure 2-8 and Figure 2-7.

Figure 2-6

Data Trangsaction Command Cycle Format

o 29

Mask

MBZ

Address

L_. Length

L—- Command

&
mob-0383

Figure 2-7

interrupt Transaction Command Cycle Format

Must Be Zero (MB2,

Node Specifier

L—— Command
0364
88

The command cycle has the command fields discussed in the following
subsections:
Command field
Mask field

Length field

Address field
Node Specifier field

2-19

The XMI

24.2.1

Command Fleld
The Command field is XMI D<63:60> L. The Com.nand field specifies the
transaction being initiated in the command cycle. (See Table 2-8.)
Table 2-8

XMI Command Codes

HeA D<«63:60>
L
Logic Levels

2-20

Commend

nemontc

Resersed

Read

READ

Interiock Read

IREAD

Reserved

Uniock Wrte Mask

UWMASK

Write Mask

WMASK

Interrupt

iINTR

identdy

IDENT

Reserved

Reservad

Reserved

Implied Vector Interrupt

IVINTR

The XMI

24.2.2

kagk Fleld

The Mask field is XMI D<47:43> L. The Mask field supplies byte-level
mask information for the XMl Write Mask and Unlock Write Mask
transactions. During nonwrite transactions this field is a "don't care,”
but proper parity is still generated. (See Figure 2-8.)
The maximum length of a write transaction is an octaword, which requires
16 mask bits in the upper longword of the command. The mask bits define
which bytes of the following write data cycles are to be written to the

specified locations. For longword- and quadword-length writes, the unused
mask bits (D<47:36> L and D<47:40> L, respectively) are unspecified and
are ignored by responders, other than to check parity.

Flgure 2-8

#aask Fisld Bit Assignments

3I5

1511413121019

° 71

‘

oS l o4 | b3 J b2 A b

First QW

Second QW

(# octaword transaction)

maby 0266 89

2-21

The XMI

24.23

Length Fleid
The Length field is XMI D<31:30> L. The Length field is used to define the
number of words in the XMI data transfer. Table 2-9 shows the Length
field coding. Longword-length transactions are only used in /O space.
Quadword-, octaword-, and hexword-length transactions are only used in

memory space. Hexword lengths are only used for Read or Interlock Read
transactions.

Table 2-9

XMi Transaction Length Codes

(-]
0<31:30> L
Logic Levels

2-22

Size

Hexword

Longword

Quadword

Octaword

The XMi

2424

Addrees Fleld

The Address field, XMI D<29:0> L, defines the address of an XMI read or
write transaction. The number of significant bits in the address d>pends
on the transaction type and length.

Quadword and octaword write transactions are assumed to be naturally
aligned, allowi.g the lower bits of the address to be "don’t care.” Reads

require that the lower bits be significant because memory does wraparound
reads. All wrapped reads need to identify the quadword to be transferred

first.

For longword-length transactions, XMI D<1:0> L are only significant for a
VAXBI word-mode or byte-mode transaction in VO space. XMI D<1> L is
required for word mode and bits<1:0> are required for byte mode.

The relationship between the high and low words, the state of bit<1>, and
the data bits is:

XMI D<1> = 1 = high word = D<31:16>
XMI D<1> = 0 => low word = D<15:0>

The data returned on the opposite word of the one specified will have
correct parity, but its data is unspecified.

For a longword-oriented device, bitc1> is ignhored as an address bit and s
full longword of data is returned for a read operation.

2-23

The XM

2425

Node Specitier Fleld

The Node Specifier field is XMI D<15:0> L. During command cycle
interrupt transactions (INTR, IDENT, IVINTR), the Node Specifer
field is used to specify the source or destingtion of an interrupt. (See
Figure 2-7.) The relationship between bits in the Node Specifer field and
the source/destination of an interrept transaction is shown in Figure 2-9.
The DECsystem 5800 uses nodes 1 through E.

Figure 2-9

164 13

Node Specifier Fleld

100

I L Node 0
Nods 1

Node 2

Node 3
Node &

e
. Node 5

Node 6
Node 7
Node 8
Node 9

Node A

Node B
Node C

Node D
Node E
Node F

2-24

msd 0365 89

The XM

243

Write Data Cycles
A function code of 0010 identifies an XMI write data cycle. Write data
cycles immediately follow the XMI command cycle during an XMI write
transfer. Duning this cycle, the commander drives its ID ¢n XM! ID<5:0>
L and drives write data on D<63:0> L. The full 64 bits of data are used

during quadword-length or larger writes. For longword-length writes, only
the lower longword D<31:0> L is used and the value of the upper longword
is unspecified. In either caie, the full 64 bits are used when checking XMl
P<2:0> L

24.4

Good Read Data (GRD) and Corrected Read Data Response (CRD)
Cycles
Function codes 1000 through 1111 are used to identify return data in
response to & Read. Interlock Read, or IDENT transaction. The Good Read
Data response (GRDn, codes 1000-1011) indicates that the quadword of
data is error-free. The Corrected Read Data response, CRDn, codes 1100~
1111) indicate that the corresponding quadword of data stored in memory
contained a single-bit error which was successfully corrected using ECC
prior to shipment on the XMI Bot* types of read data responses contain
a sequence ID l.cated in XMI F<1:0> L, which is used to identify when a

read data cyvcle has been lost due to an XM parity error.
During a read data response cycle, the responder drives the commander’s
ID on XMI ID<50> L and read data on D<63.0> L. All 64 bits of data are
used during quadword- and octaword-length reads. For longword-length
reads. only the lower longword (D<31:0> L) is used. In this case, the value
of the upper longword is unspecified In either case, the full 64 bits are
used when checking XMI P<2:0> L.

2-25

The XM

2.4.5

Locked Response Cycle (LOC)
The Locked Response indicates that the location specified in an Interlock

Read transaction was already locked. During this cycle the responder

drives 0100 on XMI F<3:0> L and the commander's ID on XMI 1D<5:0>
L. The value of the data bits, D<63.0> L, is unspecified but must be
consistent with P<2:0> L. A Locked Response signals the termination of
an Interlock Read transaction. When issued, it is alweys the first and only
read response to the transaction.

2.4.6

Read Error Response Cycle (RER)
The Read Error Response indicates that a Read, Interlock Read, or IDENT
transaction completed unsuccessfully due to an error condition at the
responder node. The Read Error Response is used for an uncorrectable
memory error or a reference to a nonexistent location on the VAXBI.
During this cycle the respender drnves 0101 on XMI F<3:0> L and the
commander’s 1D on XMI 1D<5.0> L. The value of the data bits, D<63:0>
L. is unspecified but must be consistent with XMI P<2:0> L.. A Read Error
Response signals the termination of the transactio., and no further read
responses are provided.

2.4.7

The Null Cycle
A null cycle is an unused XMI cvele as no node has requested the bus. The
null cycle is ignored by all XMI responders.

2-26

The XMi

2.5

XM Transactions
XM! transactions are listed in Table 2-10.

Table 2-10

25.1

XM Transactions

Name

nemonic

Read

READ

interlock Read

IREAD

Write Mask

WMASK

Uniock Write Mask

UWMASK

Interrupt

INTR

identiy

IDENT

implied Vector Interrupt

IVINTR

Read Transaction
The Read transactions (READ) are used to transfer a longword, quadword,
octaword, or hexword of data from the responder to the commander. A

Read transaction is initiated by a commander dnving the XMI address and

function lines to represent a longword read, quadword read, octaword read,
or hexword read. The Read command cycle is decoded by all responder
nodes. The node that recognizes its own address latches that address and
command. This node is the responder.

When the responder has the requested data, it initiates a return
data transfer. Multiple transfers may he necessary to transfer all the
quadwords in a given cctaword or hexword transaction. The commander
monitors the bus traffic waiting for its return data, and then latches the
information. The commander issues its own ID in the ID field during the
command cycle. The responder returns this same ID with the return read
data so that the commander can recognize the return read data it had
requested.

Longword-length transactior.s can only be used in YO space while
quadword-, octaword-, and hexword-length transactions can only be used
in memory space.

2-27

The XM

2.5.2

interlock Read Transaction
An Interlock Read (IREAD) transaction, combined with a corresponding

Unlock Write transaction, permits mutually exclusive access to memory
space locations.

The IREAD transaction works in memory space. This transaction gains
access to a shared object in memory. The exact effect of the Interlock Read
depends on the state of the memory’s lock bit. Quadword-, octaword-, and
hexword-length transactions are used in memory space.
If the memory is already locked, memory responds to IREAD with a
Locked Response, and no data is returned. This tells the commander that
the shared memory structure is not available at this time. The commander
respotids to the locked response by repeating the IREAD.
If the memory is not locked, memory locks itself to further IREADs upon
receipt of an IREAD and provides the data contained in the addressed
locations(s) to the commander. Unlocking the memory requires an
UWMASK transaction.

The use of Interlock Read transactions in YO space is implementation

dependent. Most 'O locations treat an Interlock Read like a regular
READ. Only longword-length transactions can be used in 'O space.

2-28

The XMI

2.5.3

Write Mask Transaction
Write Mask (WMASK) transactions transfer data from the commander to

the responder.
WMASK transactions transfer quadwords or octawords from the

commander to the memory-space responder, such as the MS62A memory
module. The commander gains the XMI and sends a command cycle
specifying the type of transaction (a longword Write Mask, quadword
Write Mask, or an octaword Write Mask), a byte Write Mask, and the
desired address. The commander immediately follows this with one or two
cycles of write data. All nodes on the XMI decode the address, and the
node that recognizes the address becomes the responder.
The responder accepts the command, address, and data and performs

the requested write. The mask field that accompanies each command
and address has 16 bits. Each bit corresponds to a byte of data in the
associated one or two quadwords. If the bit is zero, then that byte is not
written; if the bit is one, then that byte is written.

All cache-resident nodes on the XMI are required to monitor write traffic
and perform cache invalidates if the XMI write "hits" a block stored in
cache.

The XMI has the concept of a “cache invalidate” transaction that does

not result in an update of main memory. A commander can perform an

invalidate operation by issuing either a quadword Write Mask or octaword
Write Mask command with the mask field equal to all zeros. The size

of the region to be invalidated is specified in the Length field. Since an
invalidate operation is a degenerate ca.e of 8 Write Mask transaction, it
obeys all the Write Mask transaction requirements, including supplying
the appropriate write data cycles consistent with the transaction length.
As the write data will be discarded by the responder. the value of XMI
D<63:0> L during these cycles is unspecified but is consistent with XMl
P<1:0> L.

2-29

The XM!

2.5.4

Unlock Write Mask Transaction
The Unlock Write Mask (UWMASK) transaction, combined with a

corresponding Interlock Read transaction, is used to relinquish the locked
memory location after an interlock read.
After a node successfully gains the lock in memory and finishes the
required access to the shared structure, it then relinquishes the lock by
performing 8 UWMASK transaction to the memory with appropriate data.
The memory, which has been monitoring the bus traffic, reacts to the
Unlock Write by unlocking memory and writing the data in the request.
If an Unlock Write Mask transaction is directed to a location that is not
currently locked, the responder performs the - “te operation.
Unlock Write Mask transactions to /0 space .-e implementation
dependent and can only be longword length.

2.5.5

interrupt and ldentify Transactions
Ar.. /O device can send an interrupt to one or more processor nodes. A
processor eventually issues an ldentify and then performs the necessary
gervice routine.

Any of the YO adapters on the XMI can send out an Interrupt (INTR)
transaction to one or more CPU nodes, as designated by a destination
mask. One of the processors eventually issues an Identify (IDENT) at a
selected level <7:4> and chooses one interrupting node to send it to. That

processor then clears the /O interrupt but other I/O interrupts (if any)
remain in parallel to maintain the CPU interrupt request. An interrupt
vector is eventually sent to the CPU, which then performs the necessary

service routine and then sends out another IDENT or other transaction.
Interrupting nodes do not need to reissue their interrupts after one

node/level is serviced. Each CPU monitors the XMI for IDENTS issued
by another node. An IDENT issued by ~ne CPU to an interrupting device
causes the other processor nodes to clear their corresponding interruptpending flag. An interrupting node is not allowed to have more than one
interrupt Jutstanding at a given level.

If more than one processor issues an IDENT for the same interrupt, the
first processor node to win the XMI processes the interrupt and the other
CPUs clear their corresponding interrupt-pending flags and abort the
IDENT by taking a software passive release.

2-30

The XMi

2.5.6

Implied Vector Interrupt Transactions
The Implied Vector Interrupt (IVINTR) is a single-cycle transfer used
to implement VAX interprocessor interrupts and write error interrupts
where the interrupt priority and interrupt vector are implied by the type
of interrupt.

Interprocessor interrupts are issued at IPL 16 (hex) with a vector of 80

(hex). Write error interrupts are issued at IPL 1D (hex) with a vector of G0
(hex). Since the value of the interrupt vector is indicated by the value of

the Type field, IVINTR transactions do not require a corresponding IDENT

(identify or interrupt acknowledge cycle).

The IVINTR transaction contains a 4-bit Type field used to specify the

type of interrupt. Only two bits are used: <16> specifies an interprocessor
interrupt, while <17> specifies a write error interrupt. The IVINTR
transaction also contains a 16-bit Node Specifier field {one bit per node)
indicating which nodes are to be interrupted. Interprocessor interrupt
transactions can be directed to more than one node. Write error interrupt
transactions are directed to only one node.

2-31

The XiMI

2.5.7

Transaction Examples
Examples are found in the following subsections:

25.71

Single Data Cycle Reads

Multiple Data Cycle Reads

Longword and Quadword Writes

Multiple Data Cycle Writes

Single Data Cycle Reads
The four types of single data cycle reads are:
¢

Longword Read

Longword Interlock Read

Quadword Read

Quadword Interlock Read

The following symbol conventions are used in the transaction figures that
follow.

ACK = acknowledge: ARB = arbitration winner; DATN = data n, CMD =
command; CMDR = commander; CRDN = corrected read data n; FUNCT
= function; GRDN = good read data n; RESP = responder; WDAT = write
data; WRTM = write mask.

Figure 2-10

Read Transaction

FUNCT

CMD

DATA

READ

CMDR

CONF
ARB

GRDO

DATA
: CMDR

ACK
CMDR

- ACK
RESP
mab-0850-90

The Read transactions consist of a command transfer foiiowed by a
return data transfer, as shown in Figure 2-10. The two transfers are
the command (FUNCT = CMD) and the read data response (FUNCT =
GRD0). The commander arbitrates for the bus in cycle 0 and wins. In
cycle 1, it drives the function, command, address of the read, and its own

2-32

The XMl

Figure 2-11

interiock Read Transaction to @ Locked Location

FUNCT

,CMD

DATA

| READ '

' CMDR

ARB

i CMDR.

CONF

. ACK

’
‘

Loc

| CMDR

ACK

' RESP 80
mab-085

ID (for later use to identify the returning data). In ¢ cle 3, the responder
confirms receipt of the information.

Some variable time later, in this example at cycle 4, the return data
transfer begins with the responder arbitration for the bus. Having won it,
the responder drives the function, the date, and the commander’s ID i
cycle 5. The status of the returning data is specified in the read response
function code, either Good Read Data, Corrected Read Data, or Read Error
Response. The commander monitors the bus, checking for an 1D match
during read data cycles to indicate that the read data is meant for that
commander.
If the particular transaction requested had been an Interlock Read, and if
the memory was already interlocked, the commander would have provided
a Locked Respor:se in place of the returned data. (See Figure 2-11.)

2-33

The XM

2572

RMultiple Date Cycle Reads
The four types of multiple data cycle reeds are:
¢

Octaword Read

Octaword Interlock Read

Hexword Read

Hexword Interlock Recd

Figure 2-12

Multipie Deta Cycle Reaos Command Cycle

FUNCT

CMD

DATA

READ

CMDR

CONF

ARB

ACK

CMDR
rrab> 0842 90

Figure 2-13

Read Data Cycles

FUNCT

GRDO

GRD!

DATA

DATO

DAT!

CMDR

CONF
ARB

CMDR

ACK
RESP

ACK

RESP
med-0853-00

The four multiple data cycle read transactions move either 16 bytes

(octaword) or 32 bytes (hexword) of data from the responder to the
commander. Figure 2-12 is the command transfer of the transaction.
The Interlock Read checks the state of the lock bit in the memory and
qualifies the request, based on its state. This illustration applies to both
octaword and hexword reads.

2-34

The XMI

Figure 2-14

Read Data Cycles with HHOLD

FUNCT

DATA
1D

CONF

ARB

' GRDO | GRD?|

{ CMDR' CMDR.

;

| DATO | DATY .
|

RESP

HOLD'

ACK ' ACK

Figure 2-13 is a diagram of the return data transfer applicable to octaword
reads, moving four longwords of data. The function field of the bus in cycle

1 indicates "good read data 0" with the 1D field identifying the intended
receiver (the transaction commander). Cycle 4 is a Good Read Data 1
cycle. Each eycle provides a new quadword of read data wkile the 1D

remains unchanged.
Read data may be returned in consecutive cycles through the use of HOLD,
as shown in Figure 2-14. The transmitter asserts HOLD in cycle one to
ensure tiiat it maintains the use of the bus until it completes the transfer.
HOLD is the highest priority arbitration line and guarantees use for a
maximum of four consecutive cycles. The confirmation is returned to the
responder two cycles after the command cycle.

Bus usage during a hexword read with a single correctable read error is
st vn in Figure 2-15.
Figure 2-16 illustrates the events during a return data of hexword length
containing an uncorrectable read error. When memory encounters an
uncorrectable read error, it returns 8 Read Error Response and suppresses
further read responses for that transaction.

2-35

The XMi

Figure 2-15

Hexword Read with Single Correctable Read Error

FUNCT

‘

{

DATA

CONF
ARB

| GRDO | GRD: | GRD2|

DATO | DATY |oat2 |

CMDR! CMDR| CMDR;

| RESP HOLD | KOLD |

ACK

GRD3 |

CMOR

|DAT3

|ACK |ACK |
RESP |

| ACK |
|

meb 0655 80

Figure 2-16

Hexword Data Return with Uncorrectable Read Error

CUNCT

GRDO

GRDY

RER

DATA

'DATO

DAT1

'CMDR

CMDR

CONF
ARB

2-36

CMDR

" ACK
RESP

HOLD

‘

ACK

The XMi

2573

Longword and Quadword Writes
Longword and quadword writes can be either Write Mask or Unlock Write
Mask transactions.

Figure 2-17

Longword and Quadword Writee

FUNCT

CMD

WDAY

DATA

WRTM DATA

CWDR

CONF
ARB

CMDR

ACK

HOLD

Longword and quadword writes move the number of bytes specified by the
Mask field The commander arbitrates for the XMl bus and, upon winning
it, drives the appropriate write command, the intended address, the data
mask, its own ID, and asserts HOLD to signal that it will need the next
cycle as a Write Data cycle. It then provides the write data but no ID field,
having identified itself in the command cycle. Cycles 3 and 4 show the
confirmation from the responder.
2574

MuRipie Date Cycle Writes

The multiple data cycle writes are the octaword Write Mask and the
octaword Unlock Wnite Mask transactions.

Figure 2-18

RMuiciple Data Cycle Writes

FUNCT

CMD

WDAT

DATA

WRTM

DATO

DATY

CMDR

CONF
ARB

ACK
CMOR

HOLD

ACK

HOLD

NOTE: The write data mus! immediately follow the command
80
ab-0888
cycle with no intervaming null cycles.

Multiple data cycle writes identify the first cycle of the transfer with the
desired write length. HOLD is asserted while successive cyles provide new
data.

2-37

god.arenodesal

Nsreufon-dtsest

XsBeER!<S.TF> DLaserCOied

se!.staysXBER<STF>

stXBLasaAeyrtsDed stSLoeaifEy-tseD.t

aserted.LBADXMi

DTYPE; withloadedXDEV

2-38

cXlBeERa<rSsT;F>

Fi2XIFnlgito-iuwalc1Mirzhat9eiront

The XAl

2.6.1

Causes of an Initialization
Three causes of XMl initialization are:

2.6.2

Power-down/power-up

System reset

Node reset

Power-Up
On power-up, the XM!I AC LO L, XMI DC LO L, and XMI RESET L lines
are sequenced to provide initialization of all nodes in the system (see
Figure 2-19).

During normal power-up, 8 node cannot access XMI-accessible memory
space locations until the deassertion of XMl AC LO L. However, memory
nodes clear memory lecations following the deassertion of XMI DC LO L
if a cold start is indicated. During a system reset sequence, it is possible
for the resetting node to access memory prior to the deassertion of XMl
AC LO L, but no other node can access memory prior to the deassertion of
XMIACLOL.

During brownout power conditions, XMI AC LO may essert and later
deassert without an assertion of XMI DC LO L. XMl AC LO L remains
asserted for a period of time after the deassertion of XMI DC LO L,
allowing a node's internal initialization signals to be removed before a
power restart interrupt is raised.

XMI DC LO L warns of the impending loss of DC power and is used for
initialization on power-up. DC power and the XMI clock become valid
before the deassertion of XMI DC LO L. XMI DC LO L is asserted after
the assertion of XM1 AC LO L, allowing the power-fail routine to save
processor state in memory and to hait. The result of any XMi transaction
in progress when XMI DC LO L asscrts is indeterminate.

XMI DC LO L asserts before the loss of DC power so that nodes such as
disk controllers can stop certain activities before the removal of power.

In a power outage, first AC power is lost, then (if not restored quickly), DC
power falls below acceptable levels, asserting first XMI AC LO L and then
XMIDCLOL

The XMI

2.6.3

System Reset
A power-down/power-up sequence can be emulated through the use of
the XMI RESET L line, which causes the sequencing of XMl AC LO
L and XMI DC LO L in the same way as a true power-down/power-up
sequence. This allows all nodes in the system to be returned (or "reset”) to
their power-up state without cycling the power supplies. The XTC power
sequencer is also used to carry out the reset sequence.
The XTC power sequencer monitors the XMI RESET L line and drives the
XMI AC LO L, XMI DC LO L, and XMI RESET L lines. Upon detection
of an asserted XMI RESET L line, the XTC begins the reset sequence. If
XM! RESET L is asserted while XMl AC LO L and XMI DC LO L are
deasserted, the XTC asserts XMI AC LO L first, then XMI DC LO L,
and finally deasserts XMI DC LO L. In response, all XMI nodes perform
self-test and initialization. When the RESET line is deasserted, the
reset module deasserts XMI AC LO L, completing the emulation of the
power-dowrn/power-up sequence.

2.6.4

Node Reset
A single node in a system can be reset without resetting the entire system
by writing a one to the Node Reset bit (NRST) in the XMI Bus Error
Register of that particular node. The node is inaccessible for the duration
of its initialization and XMI BAD L is asserted. Accessing the node during
self-test may cause a self-test failure. Software drivers that share a node
must agree in advance that a node needs to be reset and lock the selection
of that node.

2-40

The XM

2.7

XMI REGISTERS
This section summarizes the registers required for all XMI nodes.
Each XMI node is required to have a set of two or three registers in a
specified location within the node's nodespace, as shown in Teble 2-11.

Descriptions of the XMI registers for the CPU are given in Chapter 3, and
other module-specific XM1 register descriptions are given in the chapters
on the XM! options.
Table 2-11

X0Al Registers

Raglater

fdnemonic

Addrese

Kode Requiremante

Device Register

XDEV '

88 ? + 0000 0000

Ali nodes

Bus Error

XBER

88 + 0000 0004

All nodes

XFADR

B8 + 0000 0008

Commanders only

Failing Address
Regsster

'X in the mnemonic indicates that this s an XMI register.

?BR = base address of a node, which is the address of the first location in nodespace

2-41

2.8

XM Errors
The XMI bus detects all single-bit transmission-related ervors
on XMI D, XMI F, XMI ID, XMI P, and XMI CNF lines. The XMI
protocol permits XMI commanders to recover from all traneient

memory epace read/write ronsaction errors ac well as firom most
/O space read/write transaction errors.

2.8.1

Error Conditions

28144

Pariy Emor
To detect single-bit errors, all nodes monitor parity of the bus. Any XMI
receiver detecting bad parity ignores the cycle and returns a NO ACK
confirmation.

28.1.2

inconglstent Parity Error
Under certain error conditions, some nodes might detect bad parity while
others compute proper parity. If the intended target of the transaction

computes good parity, then the cycle may be ACKed (and assumed good
by the commander), even if other nodes ignore the cycle due to bad panity.
For XMI memory-space write transactions, this class of error may result
in cache coherency problems due to cached processors failing to perform
cache invalidates. For XMI IVINTR transactions, some destinations of
the IVINTR transaction may not receive the interrupt. All other XMI
transactions are insensitive to this class of error.
28.1.3

Trangaction Timgout
The XMI protocol specifies that a timeout of 16 milliseconds be used

by commanders to detect transaction feilure. Responders ensure that
transactions do not exceed these timeout values.

Response Timeout—During an XMI Read, Interlock Read, or IDENT
transaction, if 8 commander does not receive all read responses
within a certain number of cycles after the transaction is issued,
the transaction is considered to have failed. This does not imply that a
responder has "died” since XMI receivers ignore cycles with bad parity
and response timeouts can occur as a result of ignored cycles.

2-42

Retry Timeout—An XM] commander needs to reissue an XMI
transaction if it receives a NO ACK or a Locked Response. If the
commander has not successfully completed the transactien within the
timeout period, the transaction has failed.

The XMI

28.1.4

Sequence Ervor
Many transactions require that XMI cycles occur in a certain sequence.
When the cycles occur out of sequence, the transaction is in error.

Read, Interlock Read, and IDENT transactions use sequence IDs
embedded in the read data responses (GRDn, CRDn, RER—the sequence
ID for RER is implicitly 0). The required order for read responses is 0, 0,
0...1, and 0...3 for longword (including IDENT), quadword, octaword, and
hexword length transactions, respectively. For example, if the commander
detects data returned out of sequence (such as GRD0, GRD2, GRD3), then

it NO ACKs the out-of-order read response (GRD2) and the additional read
response (GRD3) for that transaction.

Correct sequencing of write transactions is determined by the location
of the write data cycles relative to the write command cycle rather than
using sequence IDs. The write command cycle and associated write data
cycles must occur in contiguous timeslots. If a responder detects missing
data cycles in a write transaction, the incorrect cycle (and subsequent
write data cycles) are NO ACKed. Figure 2-20 shows examples of failing
octaword write transactions.

Figure 2-20

Falied Octaword Write Transaction

tdiasing Firat Deta Cycle:
FUNCT

CMD

DATA

WRTM XXXX

XXXX

CONF

WDAT

ACK

NOACK

Missing Second Data Cycle:
FUNCT

CMD

WDAT

XXXX

DATA

WRTM DATA

XXXX

CONF

ACK

NOACK
eb-0550
80

2-43

The XMI

2.8.2

Error Handling
XMI commanders and responders react to error conditons as follows:

Receivers that detect bad parity ignore the cycle.
Responders suppress any write trangactions containing a sequence
or parity error; that is, none of the date at the re‘erenced location is
modified as the entire write transaction is ignured.

Responders receiving a NO ACK confirmation to a read response do

not transmit further read respanses associated with that transaction
within 10 XMI cycles of the NO ACK.

Memory nodes do not set a lock bit unless all read responses associated
with an Interlock Read transaction receive an ACK confirmation.

Me.nory nodes do not clear a lock bit unless all write data cycles
associated with the Unlock Write Mask transaction are properly
received.
Cached processors detecting an inconsistent parity error either flush
their caches or perform a machine check.

2-44

The XMI

2.8.3

Error Recovery
Error recovery involves one or more reattempts of the failed transaction

before reporting @ hard error. A failed XMI transaction is retried under
the following circumstances:
e

All transactions receiving a NO ACK confirmation for the command
cycle are retried. The NO ACK can result from either a reference
to nonexistent memory locations (NXM) or from bus parity errors.
Transactions failing the retry are assumed to be to an NXM.

Failing XMI Write transactions are retried.

XMI IDENT transactions receiving a response timeout are retried.
Since this may result in a8 lost interript vector, the consequences are
implemented by software.

2.8.4

Failing XMI VYO space Write Mask or ‘Jnlock Wnte Mask transactions
are retried.

Failing DWMBA LI/O space Read or Interlock Read transactions
receiving a response timeout are NOT retried since some /O devices
might have read side effects.

Error Reporting
The XMI bus prctocol supports two mechanisms that signal error
conditions to processors if normal transaction-level error reportng cannot
be used.
Normal transaction-level error reporting mechanisms include NO ACK,

Read Error Response (RER), and timeout. The mechanisms that signal

error conditions to processors if normal transaction-level error reporting
cannot be used are:
¢

Write error interrupt—This transaction is directed to one or more
CPU nodes, resulting in each targeted CPU taking an INT 3 to

R3000 (XCPGA asserts MEMERR_L) error interrupt. The CPU then
identifies the source of the write error interrupt.

XMI FAULT—When XMI FAULT is asserted, all XMI CPUs take an
INT 3 to R3000 (XCPGA asserts MEMERR_L) error interrupt .

An example of a write error interrupt is if the DWMBA is unable %
complete either an XMI-to-VAXB! windowed write operation or a VAXBIto-XMI windowed write operation. Then the DWMBA issues a write error
IVINTR transaction to the nodes designated in the DWMBA AIVINTR
destination register.

2-45

XxXXXXXXfiKXXXXXXXXXXXXXXXXXXXKXXXXKXXXKXXXKXXXRXXXX
XXXKXXXKXXXXXXXXXXXKXXXXXXXXXRXXXXXXXXXKXXXXXXXXX
XXX KKK KKK
XAOK
O
XXX OO
GC
OGOOXX
VRN X R KIOKK KX XK OO0

XKL RE XA XX KKXR

XXX

XXXXX

ho000404

. 4.6.9.9.6.9.¢9.4
XUXXXXXXXXK

KUXHHXKXXXXXXK

P86904096969690

KAARAAXLXHXAXAKKAK
1 $.0:3.0.6.0.9.2.0.9.08 969994

08¢
P4.6.0.0.0.9.64.0.8:¢.4.0.08.90
HAXXXXXXXKXKEXKEXKXKAXKXK

8500
868884
D010:6.0.990.000.998.0

WA X KKK ARRARK AKX XX AXAALK
KEKUKX KK KA KARKEXR KK XK EXAKKHRKKK

WROOEH KUK HRA XK A KKK KA KK KX UKAKAXK
6
sl
00
e e s betod
bbe00
PTO 016 0.600008

K
K
AXAAXK
AR
KK KHXEXX
XX
XXX KKK
XXX KKKX
ehd
o0 9040000000080 800000ttt
803
90
80e08
00
000080
00
006 000896
9000
PO 0
KXX
XX
KKEXKKK
X
KX
CEH
KK
KKK
KIO
XXX
X
AR
X
XAK
AXEAXK
sty
s
et
s
O 000 00004000000t eoettdsbisss
res
00t
et s et
000
e et
Y0 0701097000900000000
D900 001997009909 0008 0000000080800 000008e08000 000
e e el
0t
o0see
000099
1010701070'07010107070 0.4 009 4.0.90
208
0
88000020
000
00800e8
008
OO0 PSP 080000

KN5S8A/A Interface Module

This chapter describes the KN38A/A interface module, the module that
provides the interface between the KNS8A/B CPU module and the XMl
bus. It describes the operation of the major components of the KN58A/A
interface modu'e such as the CVAX, the second-level cache, and the XMl
interface. Topics on overall KN58A/A interface module operation such as
initialization and error handling are also discussed.
This chapter includes the following sections:
Module Features
Private O Address Space Map
Maintenance Processor

System Support Chip (SSC)
EEPROM

Second-Level Cache
XMI Comner-to-KN5S8A/A Interface
Module Registers

Initialization, Self-Test, and Booting

Interprocessor Communication through the Console Program
Error Handling

3-1

KNSSA/A Interface Module

KNS58A/A Interface Module Features
The KNBSA/A interface module has four functional sections (see
Figure 3-1): the maintenance processor section, the second-level
cache, the XMI interface, and support logic for the KNSSA/B CPU
module.

Figure 3-1

KNSBA/A Interface Module Block Diagram

LEVEL Lw«

CVAX

2ND

CACHE
258 B

.
Tc:.;rom
KN&S:‘B

Connectors

CVAX

i
|

Is;gc;E
S
«

DUP

oreRract | | ssc
'3

XCLOCK

—X

lescnou

ToFrom

System Console

X
i

S—

CORNER

XLATCH x 7

&
1

|A<310>

—_—

anos

{

3-2

-7

CDAL

XCi

LATBUF

meb-050"
89

KNSSA/A interface Module

The maintenance processor section includes:

A CVAX processor chip that handles the maintenance and diagnostic
functions of the KN58A/A interface module. It is disabled whenever
the KN58A/B CPU module is running.

A clock chip that synchronizes the RDY, ERR, and RESET signals for
the KN58A/A interface module.
The second-level cache is for instruction and data storage for the KN58A/B
CPU module. The second-level cache is 256 Kbytes, organized with 4096
tags. The cache is write-through and direct-mapped. If a processor read
misses an entry in the cache, or if the entry is invalid, the XMI interface
gate array reads the data from main memory. The cache is filled 32 bytes
at a time; the first longword read satisfies the processor’s read request.
The XMI interface includes:
Two octaword write buffers that decrease bus and memory controller

bandwidth needs by packing writes into larger, more efficient blocks
prior to sending them to main memory.

Cache fill logic that loads the second-level cache with one hexword of
data for each memory read that misses cache.
XMI write monitoring logic that uses a duplicate tag store to detect
when another XMI node writes a8 memory location that is cached on
this processor. Then the XMI interface gate array invalidates the
corresponding entry in the cache.
Full set of error recovery and logging capabilities
Support logic for the KN58A/B CPU module includes:

A maintenance read-only memory {(ROM) that contains the code
for imtialization, executing maintenance mode commands, and
bootstrapping the system.

An electrically-erasable, programmable ROM (EEPROM) that
contains system parameters and console patches. You can modify
the parameters with the set-nv console command. Patching console
and diagnostic code in the ROMs is accomplished by reading the
patches into a special area of the EEPROM.
A system support chip (SSC) that includes support for external ROM.
EEPROM, console terminal UARTS, bus reset logic, interval timer,
programmable timers, time-of-year (TOY) clock, bus timeout, and halt
arbitration logic.

KNSSA/A Interface Module

Figure 3-2

Private /O Addiess Space Map

BYTE ADDRESS
2000 0000
2000 0004

2000 3FFF
2004 0000

SIZE
CSR1

4 BYTES

RESERVED

258 KBYTES

SELF-TEST/CONSOLE/BOOT CODE
IMPLEMENTED IN

2007 FFFF
2008 0000

2008 FFFF
2009 0000

2009 FFFF

200A 0000
2008 FFFF
200C 0000

2010 FFFF
2011 0000
2011 0004

2102 FFFF
2013 0000
20130004

2013 FFFF
2014 0000

2014 Q3FF
2014 0400
2014 O7FF

2014 0800
2100 FFFF
2101 0000

2101 FFFF
2102 0000

2102 FFFF
2103 0000
217F FFFF

258 KBYTES

TWO (2) 128KB X 8 PROMS

CONSOLE PATCHES/BOOT CODE
IMPLEMENTED IN
TWO (2) 32KB X 8 EEPROMS

64 KBYTES

RESERVED

86 KBYTES

R3000 CONSOLE ROM

128 KBYTES

NON-HALT PROTECTED
SELF TEST/CONSOLE/BOOT CODE

512 KBYTES

(DOUBLE-MAPPED ADDRESSES - SAME ROMS
200F FFFF
2010 1000

APPROX

AS ACCESSED BY 2004 000D to 2008 FFFF)

RESERVED

32 KBYTES

iINTERLOCK REGISTER (KNSBA/B)

4 BYTES

RESERVED

APPROX
128 KBYTES

INTERLOCK ADDRESS REGISTER (KN58A/B)

4 BYTES

RESERVED

APPROX
1206 KBYTES

$SC CSRS

1 KBYTE

SSC BATTERY BACKED UP RAM

1 K8YTE

RESERVED

APPROX
14 8 MBYTES

INTERPROCESSOR
IVINTR GENERATION “VIRTUAL" REGISTERS

64 KBYTES

WRITE ERROR
IVINTR GENERATION "VIRTUAL® REGISTERS

64 KBYTES

RESERVED

APPROX
775 MBYTES
msb-0570-80

KNSRA/A Interface Module

3.3

Maintenance Processor
The maintenance processor section consists of a CVAX chip and &
clock chip. The CVAX supports a subset of the VAX instruction set
and data types. It also supports VAX memory management.

3.3.1

CVAX Hardware Restart Sequence
The CVAX enters the hardware restart process upon the occurrence of one
of several events:

Following an XMI power-up sequence.

Following an XMI system reset sequence, an “emulated’ power-up

sequence that is initiated by asserting the XMI RESET L line. This
can be accomphshed by writing to IPR55 (IORESET).
e

When node reset (XBER<30>) is set from the XMI.

When HALTs are enabled and a CTRL/P is generated by the console or
node HALT (XBFR<29>) is set from the XMI.

When the hardware or kernei sot ware environment becomes severely
P
e A
AL
L N
T T
i
3
corrupted
and
the CVAX
cannct
zentinue
normal processing.

When a HALT instruction is executed in kerne! mode.

When the hardware restart process begins, the CVAX executes a microcode
restart sequence and passes control to console code beginning at physical
address 2004 0000 (hex). The current value of the PC is stored in IPR42
(SAVPC). The PSL, MAPEN<0>, and the restart code are saved in IPR43

{SAVPSL). The current atack pointer is saved in the appropriate internal

register. The PSL is set to 041F 0000 (hex), and the current stack pointer
is loaded from the interrupt stack pointer. The restart process sets the
initial state of the CVAX. Section 3.9 contains more detailed information
on initialization.

3.3.2

Clock Chip
The clock chip handles the synchronization of RDY, ERR, and RESET for
the KN58A/A interface module.

€S Functions

KNSBA/A interface Module

KNSBA/A Interface Module

3.5

EEPROM
The EEPROM stores parameters for initialization of the KNB8A/A

interface module and patches to the ROM code, which does console
emulation, module eelf-tests, and boot code.

3.5.1

EEPROM Access
The EEPROM can be read with byte, word, or longword references and is
coordinated by the SSC. If the READ is word or longword, the SSC reads a
byte at a time from the EEPROM and returns the full word or longword to
the CVAX chip. All the ROM and EEPROM can be accessed by the R3000,
but the CVAX cannot access the one 128K x 8 ROM on the KNS8A/B CPU
module.

Console (initialization) code sets the ROM Size field in the SSC
Configuration Register (SSCR<22:205) to the 1-Mbyte block 2004 0000
to 2012 FFFF (hex). The halt protect field (SSCR<18:16>) is set to map
the 512-Kbyte block from 2004 0000 to 200B FFFF (hex). This double
maps the ROM and EEPROM to provide halt-protected and unprotected
images of the contents. Writes to the ROM portion of this address space
result in a machine check.
Console code also sets the EEPROM Address Deccde Mask Register
(EEADMR) and the EEPROM Base Address Register (EEBADR).
Writes to the remainder of the EEPROM address space must follow these

rules:

Write only a byte of data at a time. The write data must be driven on
CDAL<7:0>.

The two low address bits for the EEPROM are provided by CSR1<1:0>
(EEALR). These bits must be set to the proper state before the
EEPROM write is issued.

A front panel switch provides write enable protection for the EEPROM
by controlling the XMI UPDATE EN H line. The state of this line is

read as SSCCR<5> (FPEEUE). Console code confirms that this bit is
set before updating the EEPROM.

EEPROM updates are controlled by console software. Console code
sets SSCCR<6:4>, the EEPROM enable field, to 101 just before th.
write and then clears the ficld immed:ate. / following the update.

Console code delays the return prompt until an internal counter
expires o prevent accesses immediately after a write.

KNSSA/A interface Module

3.6

Second-Level Cache

The second-level cache is a 258-Kbyte, direct-mapped, write-

through cache with a 180-ns cycle time. All memory space read

references made by the R3000 chip except Interlock Reads are
stored in the second-level cache.

Flgure 3-3

Second-Level Cache Block Diagram

SECOND-LEVEL CACHE
TAG STORE (RAM and 2154)
64 BYTE BLOCK. 32 BYTE SUB-BLOCK

SECONT LEVEL CACHE
DATA STORE (RAM)
256 KBytes
PARITY 64K 1 Y {4}

35 3z

2T 26 25

AL B

AR )

BLOCK
[

Mivi

IBYYEd | P)

BYTE2 | P}

BYTEY | P|

BYTEC

B4k 2 4

64k 2 8

64n 1 4

(TR

TAG

|PC

(2: %

Privi TAG POl

[roa}—{ctab—
Ac17 5>

MO
TAG

Ac28 18>

Acd 2>

TAG
wud

TAG
axx®

INDE X

SUB

Ac1?86»

‘

DATA
(3 05
PAH
<3 0>

DAL <21 0>

msb-0500-89

KNSSBA/A Interface Module

3.6.1

Second-Level Cache Description
The 256-Kbyte, direct-mapped, second-level cache supplements the 128Kbyte first-level cache on the KNS8A/B CPU module. The second-level

cache is located on the IIDAL bus and is partitioned into 64-byte blocks
that are subdivided into two 32-byte (hexword) sub-blocks. Both the
data and tag stores are protected with parity. An entire 64-byte block
is invalidatzd on a device write to memory. A duplicate tag store is
maintained by the XCPGA interface to reduce unnecessary IIDAL bus
invalidate traffic.

The second-level cache memory array is & direct mapped 64K x 36-bit
array that stores up to 256 Kbytes of data. The data is physically stored
in eight 64K x 4-bit and four 64K x 1-bit static MOS RAM chips. A parity
bit is included with each byte.
The cache tags are stored in four 2K x 9 cache address comparator chips

that contain 4096 tag entries. This write-through cache is updated if there
is a cache hit during a write transaction. If the longword being wri.ten
into memory has not been cached, only main memory is written; that ‘s,
there is no “allocate on write.”

Each of the 4096 tag entries maps two hexwords in the cache. There is
one valid bit for the entire 64-byte block and one valid bit for each 32-byte
sub-block.
Whenever an Invalidate transactiun occurs on the XMI, or when an XMl

memory write transaction is iniliated by another node, the duplicute tag
store performs a tag lookup. If the data for that location is cached. then
the duplicate tag store logic immediately clears the appropriate valid bit
of the cache tag and generates a second-level cache invalidate request. An
XMI quadword write to a cached location in XMI memory results in an
entire 64-byte block being invalidated in the cache.

The 16-bit second-level data cache address lines directly address the
data within the cache memory array. The data cache address lines are
driven with the address latched for the DAL lines as shown in Figure 3—4.
During cache fill operations, they are driven by latched DAL lines as
shown in Figure 3-5.

Figure 3-4

Cache Address Line Contents During 2 Cache Read

LATCHED DAL <17 2>
med-0497-89

3-10

KNSSA/A interface Module

Figure 3-5

Cache Address Line Contents During a Second-Level Cache
Fill

LATCHED DAL <17 5>

<4 >

Bits<2:0> are XORed with a straight 3-bit up counter to select the
longword within the eight-longword cache allocate block. These bits
always start with the addressed longword. They are wrapped within a
quadword, and the quadwords wrapped within an octaword to fill the

hexword sub-block. For example, if the bits initially address 0228, they
will wrap around in the foliowing order: 0228, 022C, 0220, 0224, 0238,
023C, 0230, 0234.

311

KNSBA/A Interface Module

Figure 3-6 shows how the lower bits of the DAL physical address are used
to access the cache tag addresses that are compared with the physical
address on the DAL. The DAL address bits arc also used to drive the data
store address lines for addressing the data cache RAMs.

Figure 3-6

Second.-Level Cache Addressing

1IDAL Physical Address

18 17

¢ tag :Bw'm

oaes

Index

4086 Cache Tags

[ A<176>
|-+ 28
Tag

Tag Address Bits

18}vilve

Array

Address

| Ac17 2>|—
Data Cache

Adaress

64 Byte Cache Block

Two vaid

HW @1

bis

HW 82

msb 0499 89

Each of the 4096 entnies in the tag store contains an 11-bit tag address, a
valid bit, and a parity bit, combined with a separate RAM containing two
valid bits. There is a tag address {or each 64-byte block within the cache
data RAMS, and a (logical) valid bit that is actually two bits to support
single-bit error detection for each 32-byte hexword within the block. The
cache tag arr-v is addressed by the physical address from the IIDAL. A
comparator generates a hit signal if the data is both resident and valid
within the cache data RAMs.

3-12

KNS8A/A Interface Module

An R3000 read that results in a second-level cache miss will cause the
1IDAL/XMI interface to begin a hexword read transaction to update the
cache The first quadword fetched contains the longword requested by
the CPU'; the remaining seven longwords comprise the cache fiii of the
second-level cache only. During memory writes, a cache hit results in
both the cache and the main memory being written. This is controiled by
the second-level cache logic which inhibits the write enables to the cache
RAMs if the write location was not cached.

313

KNSSA/A Intertace Module

3.6.2

Controlling the Second-Level Cache
The second-level cache is controlled by the Control and Status Register 1
(CSR1).
The second-level cache is flushed by the following sequence:
1

Read and store the contents of CSR1 in a temporary memory location
(TEMP).

Perform back-to-back store operations to CSR1 so that the first
longword write writes back TEMP to CSR1 with FMISS (CSK1<18>)

and FCI (CSR1<20>) set and the second longword write writes back

TEMP with FMISS and FCI cleared.

The second-level cache is enabled by first flushing the cache (above) and
then performing BIT CLEAR of FMISS (CSR1<18>).

CAUTION: The second-level cz.che must always be flushed immediately before
enabling.

1t is disabled by performing BIT SET of FMISS (CSR1<18>).

Exampie 3-1

Flushing Second-Leve! Cache

h>
#include <regdef
/*.

define CSR.1

address and MASK with CSR1< CI> and CSRI«FMISS> =gt

#define CSR1 Jxp120COQCC
¢define MASK Gx0Ci4GCOC
flush_scCache:
.set

norecrder

sC,

(CSRl)

read CSRI

14
or

81,
sC,

MASK
sl

¢
#

load FCI-FMISS mask
set FCI and FMISS bits

not

sl,

and
sw

sl,
80,

80
(CSR1)

¢ clear FCI and FMISS bits
¢ flush second-level cache

sl,

(CSR1l}

zerc,

nop

.set

3-14

recrder

(CSR1)

¢ purges previous ‘sw’

reenable second-level

from R3020 write buffer
cache

KNS8A/A Interface Module

3.7

XiMi Corner-to-iKN58A/A Interface
The KN5BA/A interface module’s XMI Corner is a predefined
interface to the XMI bus. Refer to Chapter 2 for a discussion of
the XMI.

Figure 3-7

XaAl Corner-to-KNSBA/A Interiace

HIDAL

".‘

‘

—
DUPLICATE

_
|
i

STORE

.____‘.__.

‘
"

o TLA% £ >

XCPGA

g
!

|
{

‘
T

‘/

XC!

1 XCLOCK and

XM! CORNER

7 XLATCHES

;

{

meb 050460

|7
v

3-15

KNS8A/A interface Module

The KN58A/A interface module generates the following XMI transaction
types:

Hexword memory reads

Quadword memory interlock reads

Quadword memory write masks

QOctaword memory write masks

Quadword memory unlock write masks

Longword /O reads

Longword l/O write masks

Longword I/O unlock write masks

Write error IVINTRs

Interprocessor IVINTRs

IDENTS (in response to R3000 interrupt acknowlege)

The KN58A/A interface module responds to the following XMI
transactions:

Longword nodespace reads

Longword nodespace write masks

Interrupts

In addition, the KN58A/A interface module monitors all memory writes for

cache invalidates.

The duplicate tag store logic and the XCPGA chip provide the functionality
required to interface the R3000 CPU to the XMI Corner.

3-16

KNSSA/A Interface Module

Table 3-1

WMapping of CPU Operations to X Transactions

CPU Operation

Resulting X2l Transaction

Memory Space Relerences

Read (misses both caches)

Hexword Read

interiock Read (forced to miss both caches)

Quadword Interlock Read

Write Mask

No XM transaction generated

Data is loaded in the

XCPGA write bufter. # this is an XCPGA write bufier miss,

then the "oki* XCPGA write butfer date is flushed to mawn
memory with etther a Quadword or an Octaword Write
Mask.
Unlock Write Mask (forced to miss the
XCPGA write buffer)

Quadword Unlock Wrte Mask

1O Space Relerences

Read (forced to miss both caches)

Longword Read

Interiock Read (forced to miss both caches)

Longword Interlock Read

Write Mask (forced 10 miss the XCPGA write

Longword Write

bufter)

Unlock Wrte Mashk (forced 1o miss the
XCPGA write bufter)

Longword Unlock Write Mask

Miscellaneous References
interrupt Acknowiedge

XMI IDENT (assuming that an XMI interrup! 1s pending and
no SSC (only for R3000 IRQ 1) or IP IVINTR (R3000 IRQ
2) interrupts are panding)

10 Space Write 10 IVINTR Generation

XMi IVINTR

Space

3-17

KNSSA/A Interface Module

Teble 3-2

Detalled CPU Read Operation to XMI Mep
DAL

Second-

Lavel

Command

Length

Ceche

Tranzection

Caches

Read

None

Fill

Read

Miss

HW Read

Fill

Read-Lock

Force

QW Read

No Fil

Miss

Lock

Teble 3-3

Mapping of Xl Transactions to KNSSA/A interface Module Operations

XMi Operation

Resulting KNSSA/A interface Module Operation

XMI Wrntes (all typas) from other nodes

Perform duplicate tag store lookup. Hf & hit, load invahdate queue

XMI Wrntes (ail types) from the same node

ft CSR2<10> i set, perform duphcate tag store lookup H a hit,
oad invaldate queue and perform an invalidate on the HIDAL at the

and perform an invaliate on the HDAL at the next opportunity

next opportunity.

XMI Writes to XMi Private Nodespace

Write the appropriate CSR.

XMI Reads to XM! Private Nodespace

Respond with the appropnate CSR data

XM! interrupt

Set the appropriate interrupt pending bit and post interrupt request
to tha R3000 on IRQ<3.0> lines

XM Interprocessor IVINTR

Set the IP IVINTR pending bt and post an R3000 IRQ 2 interrupt
request

XMI Write Error IVINTR

Set XBER<25> and post a hard error INT3 interrypt

XMI Partty Error Detected

Set XBER«<23> and post a soft error interrup! at leve! 3
cache

XMI IDENT

Ciear the appropriate INTR pending bnt

XMi Fautt Asserted

Set XBER<25> and post a hard error INT3 interrupt

3-18

inconsistent, also set XBER<24> and disable the second-leve!

KN58A/A Interface Module

371

The XCPGA Chip
The XCPGA is a gate array that eerves as the interface between
the XMI bus and the KNSS8A/A interface module's IIDAL bus.

Figure 3-8

XCPGA Biock Diagram

;L
o1
N

CONTROLLER
(XCC)

@
WRITE

‘

—

COMMANDER

BUFFER

(WB)

g—

XMi

[

HOAL

INTERCONNECT|

CONTROLLER
{iC)

;

READ

|Cya—p| NTERFACE
|ol QUEUE
LOGIC
(RO
!

« >
.

RESPONDEFI

CONTROLLER
(XRC)

DAL

INTERCHIP

INVALIDATE
QUEUE
(1Qy

INTERFACE |@—b:
i

\
[
.

<)
msb-0503 8¢

3-19

KNSSA/A Interface Module

Figure 3-8 is a block diagram of the XCPGA chip. The following is a
description of each block:
The XMI Commander Controller (XCC) performs the control functions
of the XMI commander. These consist of bus arbitration, issuance of
command/address and data, and control of retumning read data.

The XMI Interface Logic (XL) is the date path logic needed to interface
to the XMI. It contains the 64-bit input and output registers and
multiplexers. It also contains all XMl registers and the XMl inter. :pt
and invalidate support logic.

The XMI Responder Controller ({RC) performs the control functions of
the XMI responder. These consist of CSR reads and writes.
The XCPGA Write Buffer (WB) is used to combine longword writes from
the IIDAL to octaword XMI write transactions, reducing XMl bus traffic.
The Read Queue (RQ) stores up to four quadwords from each read
command issued to tae XMI. The queue is unloaded, one longword at a
time, for placement on the 11DAL bus.

The Invalidate Queue (IQ) stores up tc eight invalidate addresses to be
sent to the second-level cache located on the HIDAL bus.

The DAL Interchip Interconnect Controller (IC) performs the
control functions of tne interface to the i\DAL. It handles both master and
slave functions.

The IIDAL Interchip Interface Logic (IL) is the data path logic needed
to interface to the I1IDAL bus. It also implements the 32 interrupt-pending
bits.

3-20

KNSSA/A interface Module

3.7.2

The XCPGA Write Buffer
The XCPGA Write Buffer (WB) contains two octaword write buffers used
to gather writes from the R3000, reducing XMl bus traffic. The XCPGA
write buffer also causes fewer bytes to be written to memory by allowing

the most recent write reference to the same location to overwrite earlier
ones. Read requests bypass the XCPGA write buffer if the address does
not fall within the hexword boundary of the presently active octaword.
The XCPGA write buffer accumulates data in one octaword buffer until a
memory write address falls outside the natural octaword boundary. Then
the second octaword buffer starts to fill while the first is emptied with an
XMI write transaction.

‘

The KN58A/A interface module automatically flushes the XCPGA write

buffer in response to the following conditions:
1

In response to a write that misses the currently active write buffer.
The current write buffer is flushed while the new write is accepted by
the alternate buffer.

Before performing an XMI /O space read or write reference, except for
XMI private space references. However, writes to IVINTR generation
space do cause a flush of the write buffer.

Before performing an Interlock Read or Unlock Write reference.

Before issuing an XMI read to a hexword location that includes the

data contained in the write buffer. The write buffer contents are
flushed to main memory and then the XMI read is issued. Reads that
“miss” the write buffer do not force a write buffer flush.

3-21

KNS58A/A Interface Moduls

3.7.3

Duplicate Tag Store
A duplicate tag store is located on the multiplexed XCI bus. It contains
a duplicate copy of the 4096 tag entries in the second-level cache located
on the IIDAL bus. The duplicate tag store tracks the primary tag store on
allocates by monitoring XMI read transactions. Whenever an XMI memory
space read is initiated by this node (an XMI read has to occur whenever
a second-level cache fill is performed), it allocates the cache block that
corresponds to the read address.
The duplicate tag store also monitors all XMI write transactions and
performs a duplicate tag store lookup. 1f a "hit" occurs and the write
was not from this node, then the tag is invalidated and the address is
loaded into an 8-entry invalidate queue implemented in the XCPGA.
Cache invalidates are not performed in response to a KN58A/A interface
module’s own writes since the write-through -econd-level cache always
contains the most recent data. A KN58A/A interface module can be forced
to look up and conditionally invalidate data on all XMI memory writes

(including those generated by itself) by setting CSR2<10>, the Enable
Self-Invalidates (ESI) bit.

When an entry has been loaded into the invalidate queue, the 1IDAL
interface logic arbitrates for the 1IDAL bus and performs an invalidate
of the full 64-byte block in which the write address was located. The use
of a duplicate tag store reduces 1IDAL traffic to on:ly necessary invalidate

transactions. After performing an invalidate, the XCPGA checks for any
additional invalidates that may have accumulated while the previous
invalidate was being serviced. If another invalidate request exists, then

the XCPGA services it prior to releasing the 1IDAL bus.
The KN58A/B CPU module provides the KN58A/A interface inodule an
opportunity to be granted the 1IDAL bus between every bus operation

to perform an invalidate, ensuring a "no stale data” race condition with
the invalidate logic. Since it is possibie for the XMI bus to issue writes

quickly enough to overflow the KNS8A/A interface module’s invalidate
queue, the second-level cache is disabled (CRS1<18> (FMISS) is set), an
error bit (CSR2<29> (1QG)) is set, and £ soft-error interrupt {Level 1A) is
generated. While the IQO bit is set, the invalidate queue is held cleared
and FMISS stays set. Cache Disable is also generated by CRS2<31,30,26>
(VPE, TPE, and DTPE) and XBER<4> (IPE).
The soft-error interrupt routine that handles the 1QO error must do the
following to return the system to normal operation:

3-22

Flush both caches.

Clear the IQO bit.

Enecble the second-level cache.

KNSB8A/A Interface Module

3.74

XMI interrupt Operation
The XMI has an INTR and an IDENT command. Only /0 devices cen

generate interrupts to interrupt one or more CPU nodes, as designated by
a destination mask.

The KNS58A/A interface module’s XMI receiver logic monitors each XMi
cycle. If it detects an interrupt command targeted to its node 1D, it sets
the interrupt-pending bit corresponding to the interrupt level (IPL 17,
16, 15, or 14) and the interrupting node's node ID (E, D, C, B, 4, 3, 2, or
1). The interrupt logic then posts an interrupt request at the appropriate
level. Since the XCPGA has only four interrupt request lines (one for each
level). the eight interrupt-pending bits at each level are ORed together to
form a set of four composite interrupt requests, one for each level.

Eventually the R3000 drops its IPL low enough to recognize the interrupt.
The R3000 then issues an interrupt acknowledge which is translated by
the XCPGA into an XMI IDENT. There can be up to eight outstanding
XMI interrupts at any given level (one from each of the maximum of eight
devices that can interrupt). The KN58A/A interface module gives priority
to the highest node ID request within a given level.

’

Each CPU monitors the XMI for IDENT transactions. When an IDENT is
detected, the interrupt-pending bit at the corresponding level and node is

cleared, assuring that multiple interrupt-fielding nodes will not attempt to

service the same interrupt. Once the first CPU sends an IDENT to a given
node at a given level, all nodes clear the corresponding interrupt-pending
bit. After the transmission of the IDENT, the interrupting device returns

an interrupt vector to the CPU. The CPU then executes the appropriate
interrupt service routine.

3-23

KNSBA/A Interface Module

The interrupt-pending bits are controlled as follows:
All KN58A/A interface modules targeted by an XMI interrupt

unconditionally set the corresponding interrupt-pending bits.
All KN58A/A interface modules unconditonally reset the corresponding
interrpt-pending bit whenever an IDENT is transmitted on the
XMi. For the KN58A/A interface module generating the IDENT,
the interrupt-pending state is cleared before the KN58A/A interface
module knows that it has successfully transmiited the IDENT to
the irterrupting node as it takes two cycles after the IDENT for
the confirmation to be returned. The XMI interface stores the
IDENT command so that, if the IDENT transmission fails, it can
be reattemp:ed. The interrupt-nending bits are not reexamined after a
failed IDENT.

The XMl interface arbitrates for the bus and, when granted, drives
several null eycles to ensure that the interrupt-pending bits are
quiesent during generation of the IDENT command. These null cycles
are used to allow the interrupt-pending bits to becomsz stable since the
bits can only change state in response to an XMI transaction. After
the required number of null cycles, the interrupt-pending bits are
sampled and used to generate the proper IDENT destination field.
It is possible that two nodes will attempt to service an interrupt at

about the same time, as more than one CPU can be interrupted for
a single interrupt condition. Cnly one processor wirns the bus and
transmits the IDENT. In response to the IDENT, all processors reset
their corresponding interrup:-pending bits. It is possible, however,
that a second CPU will issue an interrupt acknowledgment befcre its
interrupt-pending bit resets. The second CPU module, once granted
the XMI, drives che required number of null cycles, samples the
interrupt-pending bits, finds rone set, releases the bus, and issues an
ERR response to the CPU. The operating system should dismiss the
ERR assertion as a passive release. ULTRIX uses a "read nofault’
function to read the interrupt vector.
It is possible that during the time between receipt of an R3000 IRQ
2 XMl interrupt and the generation of the corresponding IDENT
that an interprocessor interrupt (IP) IVINTR could be received, as IP
IVINTRs interrupt et R2000 IRQ 2 Then the XMl logic performs the
same XMI arbitration/null procezs in response to the CPU’s interrupt
acknowledge except, when the interrupt-pending bits are sampled, it
will find the [? IVINTR bit set. Instead of sending an XMI IDENT
1t returns a vector of 80 (hex) to the CPU. Since no IDENT was

transmitted, the interrupt-pending bit at R3600 IRQ 2 is still set, and
after servicing the IP IVINTR, the CPU services the XMl dewice

3-24

KNSSA/A Interface Module

3.7.5

implied Vector interrupts (IVINTR)
The IVINTR is & single-cycle XMl transaction used to implement
interproceseor interrupts (IP) and write error (WE) interrupts.
For both WE and IP iaterrupte, the interrupt priority level and
interrupt vector are implied by the type of interrupt.

Figure 3-8

Interprocessor IVINTR Generation Address Example
DESTINATION MASK

1514 1312

2101

1110

001" 00

O0O0O0CGCTYT OO

CO0

NSNS\
S

2101 2090 ('O address for IP IVINTR that targets nodes D. 7. and 4)
msd 0616 80

3-25

KNSSA/A Interface Module

The KN58A/A interface module can generate and respond to IP and
WE IVINTRs. WE IVINTRs are issued by YO nodes that are unable to
complete an I/O write transaction ("disconnected’ transfers on the XMI).
The KN58A,
\ interface module has a fixed range of 'O space addesses in
XMI private space that, when written to, cause the generation of an XMI
IVINTR transaction. The XMI interface handles the tranaction as if it
were a write for error reporting.

NOTE: The write that generates the IVINTR must be generated by a store
byte-type instruction. 8B (Store Byte) is recommended.
The IVINTR generation address ranges are:

2101 0000 to 2101 FFFF for IP IVINTR

2102 0000 to 2102 FFFF for WE IVINTR

For both types of IVINTRs, A<15:0> are used as the XMI destination mask

to indicate which nodes(s) are targeted by the IVINTR. Figure 3-9 gives
an example of the address needed to send an IP IVINTR to XMI nodes 4,
7.and D.

The receipt of an 1P IVINTR with a destination mask that has the
corresponding node ID bit set causes the XMI interface logic to set an
internal IP IVINTR pending bit and generate an IRQ 2 device interrupt
to the CPL. When the CPU acknowledges an IRQ 2 interrupt, the XMI
interface checks the IP IVINTR pending bit and, if set, returns a vector
of 80 (hex) The XMI interface logic resets the IP IVINTR pending bit

during the XMi null eycles that precede each IDENT to ensure that no IP
IVINTRs are “lost.”

The receipt of a WE IVINTR with a destination mask that has the
corresponding node ID bit set causes the XMI interface logic to set
XBER«<25> (WED and generate an INT3 interrupt to the CPU. The CPU
vectors directly to 60 (hex) in the SCB for the interrupt. XBER<25> is
cleared by an interrupt service routine prior to servicing the write error
interrupt. Software then polls all XMI devices to determine which device
sent the WE IVINTR.

3-26

3.8

KNSSA/A interface Module

KN58A/A Interface Module Registers

The KNSBA/A interface module registers consiet of registers
in XMI private space and XMI required registers.

3.8.1

XMi Registers and Control and Status Register 1 Characteristics
The KN58A/A interface module’'s XMI registers have the following
characteristics:
1

The Mask bits are ignored on writes to the KN58A'A interface

module’s Control and Status Registers 1 and 2. The CPU always
performs a full longword write.

Interlocks are supported. The interlock mechanism is explained in
Section 4.6.5.

‘

The XMl responder queue is r 'ly one deep so the KN58A/A interface
module will NO ACK subseg' :nt CSR refcrences until the read data

for the queued CSR read has seen returned.
Table 3-4

XMI Registers for the KNSSA'A interface Module

éAnemonic

Address

XM Device

XDEV

BB+ 00

XMi Bus Error

XBER

8B + 04

XWMI Faiing Address

XFADR

BB + 08

XMI GPR

XGPR

BB + 0C

Contro! and Status #2

CSR2

BB + 10

Note: "BB’ = base address of a node, which is the address of the first
location in nodespace (2180 0000 + (80000 x NODEID)).
Table 3-5

Abbrevistiona for BR Type

Abbraviation

Dafinkion

inmalized to logic level zero

intialized to logic leve! one

inmalized to either logic stale

Raad only

Readmrtte

RW1C

Read/cleared by writing a 1

3-27

KNSSA/A Interface Module

Table 3-6

Registers in X Private Spece

Mnemonic

Address'

KNSSA/A Interface Module

CSA1

2000 00007

Control/Status #1

R3000 Console ROM

200C 0000 to 2008 FFFF

KN58A/A ROM

2004 0000 to 200F FFFF

KNSSA/A EEPROM

Location

2008 0000 1o 2008 FFFF?

Interlock Register

INTREG

2011 0000

KNSBA/B CFU module®

interiock Address

INTADR

2013 0000

KN58A/B CPU module’

SSC Base Address

SSCBR

2014 0000

SSC

SSC Conhiguration

SSCCR

2014 0010

SSC

iDAL Bus Timeout Control

CBTCR

2014 0020

SSC

Console Select

CONSEL

2014 0030

SsC

Time of Year

TODR

2014 006C

§sC

Console Recewer Control Status

RXCS

2014 0080

SsC

Console Recewe: Data Buffer

RXD8

2014 0084

SSC

Console Transminter Control Status

TXCS

2014 0088

SSsC

Conscle Transmitter Data Buffer

TXDB

2014 008C

SsC

1O System Reset

IORESET

2014 00DC

SsC

Timer Controtl Register 0

TCRo

2014 0100

SsC

Timer interval Register 0

TIRO

2014 0104

SSC

Timer Next Interval Register O

TNiIRO

2014 0108

SsC

Timer interrupt Vector Register 0

TIVRO

2014 010C

SsC

Timer Controi Register 1

TCR1

2014 0110

8SSC

Timer Interval Register 1

TIR1

2014 0114

SSC

Timer Next Interval Register 1

TNIR1

2014 0118

SSC

Timer Interrupt Vactor Register 1

TIVR1

2014 011C

SSC

CSR1 Base Address

CSR1BADR

2014 0130

SSC

CSR1 Address Decode Mask

CSR1ADMR

2014 0134

SSC

EEPROM Base Address

EEBADR

2014 0140

SSC

EEPROM Address Decode Mask

EEADMR

2014 0144

SSC

SSC internal RAM

2014 0400 to 2014 O7FF

IP IVINTR Generation

IPIVINTRGEN

2101 0000 to 2101 FFFF

WE IVINTR Generation

WEIVINTRGEN

2102 0000 to 2102 FFFF

'Addresses shown are IDAL physical addresses. To convert these to R3000 virtua! addresses, substiute the
leading "2" with a "d". For example, address 2000 0000 in IIDAL physical space becomes b000 0000 1n R3000
virtual address space.

Address and range are determined during processor initiahization by using CSR1BADR, CSR1ADMR, EEBADR,
and EEADMR.

3Sae Section 4.6.5.

3-28

KNSBA/A Interfacs Module Registers
Control end Status Register 1 (CSR1)

Control and Status Register 1 (CSR1)
CSR1 provides KNSBA/A interface module and KN58A/B CPU module control
and status. Since most bits in CSR1 power up in an indeterminate state,
console code initializes CSR1 very early in the power-up sequence.

ADDRESS

2000 0000 (External logic)

3' 30D MW 2N ANJ{RXNW WIS G300

[

NOODE iID

L Front Pane! Boot Disable

Front Panel EEPROM Update Enable

XMI ACLO
Sel-Test Loop

EEPROM Write Adr<0>
FEPROM Wnte Adr<1>

Delayed Lockout Enable (DLCKOUTEN)
L— KNS8A/A Sell-Test Passed

L— Reserved

L KN58AB Timeout Enable - LED D5 (TIMOTE)
L. KN582 B Self-Test Passed - LED D4
L L— Enable intc o Timer - LED D3 (EINTMR)

Reset Invahgate FIFOs - LED D2 (RINVAL)

L Force Second-Lavel Cache Hit (FHIT)

L— Force Second-Level Cache Miss (FMISS)

| Force Bad Second-Level Tag Partty (FBTP)
— Force Cache Invaidate (FCI)

— Second-Level Cache Panty Update Disable (CPUD)

L Force Party Select (FPSEL)

i Force Cache Eneble (FCACHEEN)

- R3000 Enable - LED D1 (R3000E)

L. Reserved
. KN5B8A/B inval FIFO Fuli (IFIFOFL)

L KNSBA/B Timeout (TIMOT)

L Interrupt Leval Ona (INTR1)
L- interval Timer (INTMR)

Second-Level Cache Hit Status (LATHIT)

“— Console Not Secure (CNS)

3~-2%

KMS58A/A Interface Module Registers
Control and Status Register 1 (CSR1)

bit<31>

—
Name:

Console Not Secure

Mnemonic:

None

Type.

RO, 1

Console Not Secure reflects the received state of the XM1 CON
SECURE L line that is driven frem the Xhi backplane. When this
bit is deasserted (reads as a 1), the console is not securc.

bit<30>

Name:

Second-Level Ceche Hit Status

Mnemonic.

LATHIT

Type:

RO, X

LATHIT is used by cache coherency diagnostics running out of 'O
space (that is, the on-board ROM) to determine if a cache hit has
occurred. LATHIT is first cleared by writing a zero to CSR1<10>

(DLCKOUTEN) and then releasing the clear by writing a one to the

same location. The next cache hit (meaning TAG address and VALID
bit match) causes LATHIT to be set. Once set, this bit remains set
until explicitly cleared by writing a zero to CSR1<10>.

bit<29>

Name

interval Timer

Mnemonic.

INTMR

Type

RO. X

INTMR reflects the state of the SSC's Intervai Timer Interrupt pin.
When clear, indicates that the interval timer is disabled.

bit<28>

Name:

interrupt Level One

Mnemonic.

INTR1

Type:

RO. 1

INTR] reflects the state of Interrupt Level One. When clear, indicates
that an interrupt is pending on the I1 IRQ 1 line.

bit<27>

Name:

KN58A/B Timsou!

Mnemonic.

TIMOT

Type.

RO, X

When set, indicates that the KN58A/B CPU module diagnostics have
not disabled the timeout logic within the timeout period.

KNSBA/A interface Module Registers
Control and Status Reglster 1 (CSR1)

bit<26>

MName

invalidate FIFO Fu!!

Mnemonic:

IFIFOFL

Type:

RO, 1

When set, indicates that the first-level cache invalidate FIFO has
overflowed.
Error Flag Aseerted: R3000 INT4

Additional Status Stored: None

Action: DECsystem 5800 hardware disables the first-level cache
invalidate FIFO. To assure cache coherency, the first-level cache is
flushed by software. Software then clears the Invalidate FIFO Full
status flag.

bit<25>

Name.

Read/Write CNTRL P Pending

Mnemonic.

CNTAPP

Type

AW, X

Set when a console CTRL/P command (halt interrrupt) is issued. The
KN58AB CPU module services the interrupt.

bit<24>

Name

R3000 Enable - LED D1

Mnemonic.

R3000E

Type

RW.0

This bit controls communication between the CVAX and the R3000.
When clear, the CVAX is enabled and the R3000 is disabled. When set,
control is passed to the R3000, disabling the CVAX. When set, this bit
also illuminates status LED D1 on the KN58A/A interface module. See
CSR1 <16:12> for descriptions of the bits associated with status LEDs
D2 through D6.

KNS8A/A Interface Module Registers
Contral and Status Register 1 (CSR1)

bit<23>

Name:

Force Cache Enable

Mnemonic.

FCACHEEN

Type:

RW. X

Setting FCACHEEN causes the second-level cache to remain active
after error conditions. When cleared, certain errors will disable the
cache.

bit<22>

Name:

Force Party Select

Mnemonic:

FPSEL

Type

RW, X

When FPSEL is set, the KN58A/A interface module does not generate
parity for the XMI P<2:0> L lines but, instead, drives Force Parity
<2:0> (CSR2<6:4>). FPSEL is used only during diagnostic testing;
remains cleared during normal system operation.

bit<21>

Name:

Second-Leve! Cacha Party Update Disable

Mnemonc.

CPUD

Type

RW. X

When CPUD is set, the second-level cache does not update its fata
parity RAMs. Bad parity can be forced by first writing cache while
CPUD is set. Then, after clearing CPUD, subsequent writes to cache
have correct/incorrect parity, depending on the data pattern written.
When CPUD is set, IIDAL parity checking is disabled for second-level

cache references, allowing operating system and diagnostic software to
capture data from a second-level cache location that contains a parity
error.

bit<20>

Hame:

Force Cache Invalidate

Mnemonic:

FCI

Type

AW, X

When FCI is set, the entire second-level cache and duplicate tag store

are held invalidated. The cache should be first disabled by setting
Force Miss, bit <18>, before setting FCI. See Section 3.6.2 for more
information on controlling the second-level cache.

KNS8A/A Interface Module Registers
Control end Stetus Register 1 (CSR1)

bit<19>

Name.

Force Bad Second-Leve! Tag Party

Mnemon:

FBTP

Type:

RW, X

When FBTP is set, the parity enable (PE) line on each of the secondlevel cache tag chips is asserted during operations that write the tag,
forcing bad parity to be written by the tag chips for the current tag
entry. Subsequent reads of the tag entry cause parity errors.

bit<i8>

Name:

Force Second-Level Cache Miss

Mnemonic.

FMISS

Type:

RW. 0

When FMISS is set, the second-level cache and XMI interface behave
as though a cache miss occurred, regardless of the state of the tag and
valid bits. Setting both FHIT CSR1<17> (FHIT) and FMISS results in
the disabling of both cache and XCPGA, which should be avoided.
FMISS is also set by various error conditions that generate cache
disable. The error conditions must be removed before FMISS can be
cleared. Cache disable is inhibited when CSR1<23>=1 (FCACHEEN),
as this is used for diagnostic purposes only (that is, cache remains
active after error conditions).

Operating system software is required to flush the second-level cache
(CSR1<FCI>) before resetting FMISS to ensure that the cache state

is consistent when the cache is reenabled. This is required since
the KN58A/A interface module performs cache fills while FMISS is
asserted but does not update the cache on CVAX writes that "hit"
(that is, write-throughs are disabled), which could cause the state
of the cache to become inconsistent while FMISS is asserted. See
Section 3.6.2 for more information on controlling the second-level
cache.

bite<17>

Name:

Force Second-Level Cache Ha

Mnemonic:

FHIT

Type.

RW, X

When FHIT is set, the second-level cache and XMI interface behave as
though a cache hit occurs for each memory-space reference regardless
of the state of the tag and valid bits. Associated XMI writes are
suppressed and only the cache location will be updated. /O space
references are disabled as FHIT causes the XCPGA chip to ignore
CVAX transactions. To maintain the FHIT functionality regardless of
errors, the CSR1<23> (FCACHEEN) is also set. Setting both FMISS
and FHIT results in the disabling of both cache and XCPGA, which
shouid be avoided.

KNS58A/A Interface Modu.. Registers
Control and Status Register 1 (CSR1)

bit<16>

Name:

Resat Invalidate FIFOs - LED D2

fnemonic:

RINVAL

Type:

W, X

Whenever IFIFOFL (CSR1<26>) is set, software resets the KN5S8A/B
CPU module invalidate FIFOs by clearing and then setting RINVAL.
RINVAL is also used to hold the invalidate FIFO3 reset while a firstevel instruction cache flush is in progress. Software sets RINVAL
just before a first-level cache flush and clears it just after the flush is
complete. When set, this bit also illuminates status LED D2 on the
KN58A/A interface module.

bit<15>

Name-

Enadle Interval Timer - LED D3

Mnemonic:

EINTMR

Type

AW, K

Wken set, allows the R3000 interval timer to interrupt the R3000.
When clear, disables the R3000 interval timer. When set, this bit also
illuminates status LED D3 on the KN58A/A interface module.

bitc14>

Name:

KNS8A/A Self-Test Passed - LED D4

Mnemonic.

None

Type

RW, X

When set, indicates the successful completion of the KN5BA/A selftest diagnostics. When set, iliuminates the self-test pass LED on the
KN58A/B module and status LED D4 on the KN58A/A module.

bit<13>

Name:

KNS58A’A Timeout Enable - LED D5

pMramonic:

TIMOTE

Type:

AW, X

When set, enables the KN58A/B CPU module timeout logic. When
clear, disables the KN58A/B CPU module timeout logic. TIMOTE
must be set for proper operation of the KN58A/B CPU module
DMA mechanism. Before control is passed to the KN58A/B CPU
module, software enables the timeout logic by first setting EINTMR

(CSR1<155), and then TIMOTE. Diagnostics clear this bit during
power-up routines to prevent timeouts. When set, this bit also
illuminates status LED D5 on the KN58A/A interface module,

KNSBA/A Interface Mocule Registers
Control and Status Register 1 (CSR1)

bit<i2>

bit<i1>

Name.

Resarved

Mnemonic.

None

Type.

RW, X

Name:

Sel-Test Pass LED

Mnemonic:

STPLED

Type

RW. 0

STPLED drives the seif-test pass LED (D8) on the KN58A/A interface
module. 1t is set following the successful completion of self-test.

bit<10>

Name

Delayed Lockout Enable

Mnemonic.

DLCKOUTEN

Tyoe

RW, X

DLCKOUTEN enables an optional delay between the time that the
XCPGA chip asserts LOCKOUT until XMI LOCKOUT is asserted.
DLCKOUTEN is also used to clear the LATHIT latch (CSR1<30>)
dunng ce-he testing. The two functions of DLCKOUTEN are never
used at the same time.

bits<9:8>

Name

EEPROM Write Address <1 0>

Mnemonic

EEWADR

Type

RW, X

The KN58A/B CPU module provides write data on 1IDAL<7:0>.
EEWADR gives the prograramer the ability to write the data to any
byte address within the EEPROM since the EEPROM data path is a
byte wide.

Before updating an EEPROM location, the software must first load
the correct byte address into EEWADR<1:0>. Ther the write to the
EEPROM can be started.

KN58A/A Interface Module Registers
Control and Status Register 1 (CSR1)

bit<7>

Name:

Sell-Test Loop

Mnemonic:

STL

Type:

When STL is set, the ¥N58A continually reruns its self-test sequence.
STL is driven by an /O pin and can be used to implement a
manufacturing "burn-in" test. This bit is "low true.”
o

bit<6>

Name:

XMI AC LO

Mnemonic:

XACLO

Type:

XACLO shows the state of the XMI AC LO L line. The KN58A should
not access main memory until the bit is a one, indicating that XMl AC
LO L is deasserted.

bit<5s

Name:

Front Panel EEROM Update Enable

pdnemonc:

FPEEUE

Type

FPEEUE shows the received state of the XMI BOOT EN L line that is

driv_n by the front panel switch.

bit<d>

Name

Front Panei Boot Disable

Mnemonc.

FPBD

Type

FPBD shows the received state of the XMI BOOT EN L line that is

driven by tne front panel switch.
TR

bits<3:0>

Name

Node ID

Mnomone

NID

Type

NID contains the node ID as received from the XM! backplane

3-3%

KNSBA/A Interface Module Registers
System Type (SYSTYPE)

System Type (SYSTYPE)
SYSTYPE s a 32-bit register imp mented in the KNS8A/A interface module
ROM. It can only be accessec locally Other devices on the XMI determune
the nature ot a node by reading its XM! Device Register (XDEV).

ADDRESS

2004 0004 (EEPROM)
3

SYS TYPE

16 %

AEV LEVEL

[

RESEAVED

[}

LICENSE 10
med-0581 @&

bits<31:24>

Name

Syster. T, v

Mremonc

SYS TYPE

Typx

SYS TYPE is 05 (hex: for the KN58A/A interface module.

bits<23:16>

Name

Revision Levs'

Mnemonic

REV LEVEL

Type

REV LEVEL shows the revision level of the KN58A/A interface module
console code. REV LEVEL is enceded in the form x.¥ where x is
encoded into <23:20> and v is encoded into <19:16>. Therefore, a
console revision of 2.1 would be encoded as 21 (hex) while & console
revision of 2.10 would be 2A (hex).

bits<15:8>

Name

Reserved

Mnemonic

None

Type

Reserved

KNSBA/A Interface Module Registers
System Type (SYSTYPE)

bits<7:0>

Name

License 'danthier

Mnemomc.

LICENSE 10

Type:

LICENSE ID is set to 01 (hex) to allow the processor to be part of a
timeshuring system. LICENSE 1D is set to 02 (hex) to be part of a
fileserver system.

KNSBA/A Interface Module Registers
SSC Base Address Register (SSCBR)

SSC Base Address Register (SSCBR)
SSCBR controls the base address of a 2-Kbyte block of the local VO space

that includes the baftery-backed-up RAM, the registers for the programmable
timers, the CSR1 and EEPROM Address Decode Match and Mask Registers,
the Diagnostic LED Register, the IDAL Bus Timeout Register, and diagnostic
registers that aliow several IPRs lo be accessed by means of VO page
addresses.

ADCDRESS

2014 0000 (SSC)
3130 .928

MB2ZE

[TIKT:)

SSC Base Address (SSCbA!

WMUST 8E ZERD (MBD) .!
med-0808-90

bits<31:30>

Name:

Reserved

Mnemonic.

None

Type:

RW. 0

Reserved; must be zero.

bit<29>

Nama:

Reserved

Mnemonic.

None

Type:

RW, 1

Reserved; must be one.

bits<28:11>

Name:

SSC Base Address

Mnemonic:

SSCBA

Type:

SSCBA controls the base address of the 2-Kbyte block and is set to
2014 6000 (hex) by console code during processor initialization.

KNSBA/A Interface Module Registers
SSC Base Address Reglster (SSCBR)

bits<10:0>

Name:

Resarved

Mnemonc:

None

Typs:

RW. 0

Reserved; must be zero.

KNSBA/A Interface Module Reglsters
8SC Ceontfiguration Register (SSCCR)

SSC Contiguration Register (SSCCR)
SSCCR controls the initialization parameters for the console serial line,

programmable timers, ROM, EEPROM, TOY clocks, and CSR1. Its finvware
initialized conterds are 0160 A007 (hex).

ADDRESS

2014 0010 (SSC)
N

RNITRBIMNDIW

WNWWR

6?6

L CSA
Enebe

({CSR1 EN)

EEPROM Enable
(EEPROM EN)

Auxisary Baud Select
Console Terminal Baud Rate Selec!
(CYBAUD SELECT)
= Control/P Enatre (CTP)
L.

——

ROM Hait Protect Adoress Space Suze Seec
{HALT PROT SPACE;

ROM Aduress Space S:ze Seict (ROM SIZE SEL)

L— ROM Speed (RSP)
interrupt Prorty Love: Select (IPL LVL SEL)
interrupt Vector Disabie (VD)

Banery Low (BLO)

bit<31>

Name

Battery Low

Mnemonc:

BLO

Type:

RW1C

vb-0%0-80

BLO is set if the battery voltage goes below threshold while the module
is powered down. Once set, BLO can only be cleared by software
writing a zero to it. If set, the TOY clocks are cleared on KN5SSA/A
interface module reset.

bits<30:28>

Name:

Reserved

Mnemonic:.

None

Type:

RW, 0

Reserved; must be zero.

KNS8A/A Interface Module Registers
§SC Configuration Register (SSCCR)

bit<27>

Name

Interrupt Vecior Disable

Mnemonic:

Type:

RW. 0

When IVD is set, the conscie serial line and programmable timers do
not respond to interrupt acknowledge cycles.

bit<26>

Name:

Reserved

dnemonic:

None

Type:

RW, ¢

Reserved; must be zero.

bits<25:24>

Name.

interrupt Prority Level Select

Mnemonic:

IPL LVL SEL

Type:

RW. 0

IPL LVL SEL specify the IPL level of interrupt acknowledge cycles
that the console serial line and programmable timers respond to. On
the KN58A/A interface module, this field is set to 01 (R3000 IRQ 1) by
console code.

bit<23>

Name

ROM Speed

Mnemonic.

RSP

Type.

RW. 0

RSP selects the ROM access time. 0=350 ns; 1=250 ns. This bit is
normally cleared.

bits<22:20>

Name:

ROM Address Space Size Select

Mnemonic.

ROM SIZE SEL

Type:

AW, 0

ROM GIZE SEL controls the size of the range of addresses to which
the ROM responds. ROM SIZE SEL is always 111, yielding an address
range of 1 Mbyte (2004 0000 to 2013 FFFF),

KNSSA/A Interface Module Registers
SSC Configurstion Register (SSCCR)

bit<19>

Name:

Reserved

Mnemonic:

None

Type:

RW, 0

Reserved; must be zero.
o

blite<18:16>

)
T
O
e
R

Name:

ROM Hah Protect Address Space Size Select

Mnemonic:

HALT PROT Space

Type:

During processor initialization, the console code sets this field to 110.
This sets the halt protect address space to 512 Kbytes (addresses 2004
0000 to 200B FFFF).

KNSBA/A Interface Module Registers
§SC Configuration Reglster (SSCCR)

bit<15>

Name:

Control/® Enable

fdnemonic.

CTP

Type:

RW, 0

When CTP is set and halts are enabled (XMI CON SECURE reset),
a CTRL/P typed at the console causes the CVAX to be halted if it is
enabled and the R3000 to be interrupted at INT 5 if it is enasbled.
When CTP is clear and halts are enabled (XMI CON SECURE reset),
& BREAK typed at the console causes the CVAX to be halted if it is
enabled and the R3000 to be interrupted at INT 5 if it is enabled.

Name:

Console Terminal Baud Rate Select

Mnemonic:.

CT BAUD SELECT

Type.

RW, 0

CT BAUD SELECT use the following codes to select the console baud
rate:

CT BAUD SELECT<14:12>
14

Baud Rato

300

600

1200

2400

4800

9600

19200

38400

KNSBA/A Interface Module Reglsters
SSC Configuretion Register (SSCCR)

bit<11>

Name:

Resarved

Mnemonic.

None

Type:

RW, 0

Reserved; must be zero.
I

bits<10:8>

Name:

Auniliary Baud Select

Mnemonic:

None

Type:

AW, 0

Unused; read as written.

bit<7>

Name:

Reserved

Mnemonic:

None

Type:

RW, 0

Reserved; must be zero.

bits<6:4>

Name:

EEPROM Enable

Mnemonicc

EEPROM EN

Type:

AW, 0

EEPROM EN is set to 000 (binary) by console code during processor
initialization. *Vhen set to 101 (binary), updates to the EEPROM are
enabled.

bit<3>

Name:

Reserved

Mnemonic:

None

Type:

RW, 0

Reserved; must be zero.

bits<2:0>

Namae:

CSR1 Enable

Mnemonic.

CSR1EN

Type:

RW. 0

CSR1 EN enables CSit1 when set to 111 (binary) by a processor
initialization.

KNS8A/A Interface Module Registers

HDAL Bus Timeout Control Register (CBTCR)

IIDAL Bus Timeout Control Register (CBTCR)
CBTCR controls the amount of time (timeout) allowed 10 elapse before an
HDAL bus cycle is aborted. This prevents unanswered CVAX read o7 write
accesses or interrupt acknowiedge cycles (IDENT) from hanging the system
longer than the timeout interval.

ADDRESS

2014 0020 (SSC)

wmBz

BUS TIMEOUT INTERVAL

I-— DAL Bus Timeout (BTO)

bit<31>

Name

DAL Bus Timeout

Mnemonc:

BTO

Type:

RCigared on W, 0

mab-0509-90

BTO is set when the bus ti'neout interval (CBTCR<23:0>) has expired
during a CPU read, write, cr interrupt acknowledge cycle.

bits<30:24>

Name:

Reserved

Mnemonic:

None

Type:

RW. 0

Reserved; must be zero.

bits<23:0>

Name:

Bus Timeout interval

Mnemonic:

None

Type:

RW, 0

Bus Timeout Interval gives the desired timeout period. The available
range of 1 to FFFFFF (hex) corresponds to a selectable timeout
range of 1 microsecond to 16.77 seconds in 1 microsecond increments.
Writing a zerc to this field disables the bus timeout function.

KNSBA/A Interface Module Registers
Time of Year Clock Reglster (TODR)

Time of Year Clock Register (TODR)
TODR is uscd to measure the duration of power failures.

ADDRESS

2014 0020 (SSC)
»

Tima of Year
G- 086260

bits<31:0>

Name:

Time of Year Since Setting

Mnemonic:.

TODR

Type:

TODR contains an unsigned 32-bit integer that specifies the number
of 10 ms intervals that have elapsed since the last setting. TODR is
maintained during a power failure by the XMI TOY BBU PWR line on
the XMl kackplane.

KNS8A/A Interface Module Reglsters

Console Select Register (CONSEL)

Console Select Register (CONSEL)
The CONSEL register is used to select which console lines are attached to
the console transmit and receive register.

ADDRESS

2014 0030 (SSC)
3

210

MUST
BE ZERO (MBZ)

Console Select <2> (CONSEL<2>) —J
Swutus LED D7 (SLED?)

Consola Ssisct <1> (CONSEL<1>)

Consola Select <0> (CONSELD>)
met-G511.60

bits<31:4>

Name

Reserved

Mnemonic.

hone

Type.

Reserved. must be zero.
P,

bit<2>

Name

Status LED D7

tnemonc:

SLED7

Type

AW, 0

SLED7 powers up cleared, which causes LED D7 to be off. Writing a
one to this bit turns LED D7 on.

KNSBA/A Interface Module Reglisters
Console Select Register (CONSEL)

bite<3I>» and <1:0>

Name

Console Select<2:0»

Mnamonic:.

CONSEL<2:0>»

Type:

RW, 0

The CONSEL field selects the operational mode for the console
attached to the congole transmit and receive register. The modes
are as follows:

CONSEL<2:0>
1

Ditve

RECY
04

Oate

tlode

AUX

Power-up state
All 12il on power-up state

XAl

AUX

Loopback at XMI XMIT
driver input

XMVAUX

Unused

Yeos

AUX

XMVAUX

Unused

Yes

XMl

XMIAUX

Boot processor state

Yes

XMUVAUX

Unused

Yes

XMUAUX

Loopback on XMI

It is possible to receive data on XMI CON RECV without having the
XMI CON XMIT driver enabled. This mode is used when no CPU
becomes the boot processor on power-up. all nodes monitor the XMl
console lines for further commands.

KNSBA/A Interface Module Registers

Console Recelver Control and Status (RXCS)

Console Receiver Control and Status (RXCS)
The RXCS controls and reports the status of incoming data on the console
senal line.

ADDRESS

2014 0080 (SSC)
EN

WMUST BE ZERO (MB2)

e¢3

MBZ

Reostver Done (RX DONE) -J l

Recaiver Interrupt Engbie (AX IE)

bits<31:8>

Name:

Reserved

Mnemonic.

None

Type

Name

Recaiver Done

Mnemonic.

RX DONE

Type

RO.0

mab 0505 &0

Reserved; must be zero.

vite7>

RX DONE is set when an entire character has been received and is
ready to be read from RXDB<7:0> (RBUF). RX DONE is automatically

cleared when RXDB<7:0> is read.
bit<6>

Name:

Receiver Interrupt Enable

Mnemonic:

RX IE

Type:

RW. 0

If RX DONE and RX IE are both set, a program interrupt is requested.

bits<5:0>

Name:

Reserved

Mnemonic.

None

Type

Reserved; must be zero.

KNS8A/A Interface Module Registers
Console Recelver Data Bufter (RXDB)

Console Receiver Daia Buifer (RXDB)
RXDB butters incoming serial-line data and captures error information. Emor
conditions remain until the next character is received, at which point the arror
bits are updated.

ADDRESS

2014 0084 (SSC)
16 18 14 15 12 V1

MUST BE ZERO (MB2)

Error (ERR) _.| l
Overrun Ermor (OVR ERA)
Framing Error (FRM)

Reocsived Break (RCV BRK)
Recerved Data Bits (RBUF)
mab 0506 80

bits<31:16>

Name

Resarved

Mnemonic.

None

Type

Reserved; must be zero.

bit<15>

Name'

Error

pramonec:

ERR

Tyvpe:

RO. 0

ERR is set if either bit<14> or <13> is set. ERR is clear if both bits
are clear. ERR does not generate a program interrupt.
biteid>

Name

Owverrun Emror

Mnemontc:

OVR ERR

Type:

RO, 0

OVR ERR is set if a previously received character was not read before
being overwritten by the present character.

3-51

KNSBA/A Interface Module Registers
Console Recelver Data Butfer (RXDB)

bit<13>

Name:

Framing Eror

Mnemonic:

FRM ERR

Typa:

RO, 0

FRM ERR is set if the present character did not have a valid stop bit.
R

bit<12>

Name:

Reserved

Mnemonc:

None

Type:

EERETRORTS

Reserved; must be zero.

bit<ii>

Name:

Received Broagk

Mnemonic.

RCV BRK

Type:

RO. 0

RCV BRK is set following the receipt of a CTRL/F character and
remains set until the register is read.

bits<10:8>

Name

Reserved

Mnemonc.

None

Ty »

Reserved; must be zero.

bits<7:0>

Namae:

Received Data Bis

Mnemonic:

RBUF

Type:

The RBUF field contains the last character received from the console.

3-52

KNSSA/A interface Module Registers
Congole Transmitter Control and Status (TXCS)

Console Transmitter Control and Status (TXCS)
TXCS controls and reports the status of outgoing data on the console sénial
line.

ADDRESS

2014 0088 (SSC)
9

e788

MUST BE ZERO (MBZ)

3210

¥ vd

Trargmitter Raady (TX RDY) -—j l
Transmutiar intsrrupt Enable (TX IE)

Matintenancs (MAINT)
Transrmit Break (XMIT BRK)

’
mab- 0607-80

bits<31:8>

Name

Reserved

Mnemonic:

MNone

Type:

Reserved; must be zero.

bit<7>

Name

Transmitter Ready

Mnemonic.

TX RDY

Type:

RO.1

TX RDY is cleared when TXDB<7:0> (TBUF) is loaded and is set when

TBUF can receive another character.

bit<6>

Name

Transmitter Interrupt Enable

Mnemonc:

TX IE

Type:

RAY

If both TX RDY and TX IE are set, a program interrupt is requested.

3-53

KNS8A/A Interface Module Regyisters
Console Transmitter Control and Status (TXCS)

bits<5:3>

Name:

Reserved

dnemonic:

None

Type:

Reserved; must be zero.

blit<2>

Name:

Maintenance

Mnemonc:

BMAINT

Type:

RW.,0

MAINT facilitates a maintenance self-test. When MAINT is set, tiie
external serial output is set to MARK and the serial output is used as
the serial input (a loopback).
e

bitei>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<D>

Name

Transmit Break

Mnemonic.

XMIT BRK

Type:

RW.0

When XMIT BRK is set, the serial output is forced to the SPACE
condition. While XMIT BRK is set, the transmitter cperates normally,
but the output line remains lew so that software can transmit dummy
characters to time the break.

KNSBA/A Interface Module Reglsters
Console Transmitter Date Buffer (TXDB)

Console Transmitter Data Buffer (TXDB)
TXOB bufters outgoing data on the console serial line.

ADDRESS

2014 008C (SSC)
MUST BE ZERO (MB2)

Tranamit Data Bis (TBLIF) ———l
maR-0500€0

blte<31:8>

Name:

Researved

Mnemonic.

None

Type

Reserved; must be zero.

bits<7:0>

Name

Transmit Data Bits

Mnemonic:

TBUF

Type

wOo

TBUF loads the character to be transmitted on the console sernal line.

KN58A/A Interface Module Registars
VO System Reset Register (IORESET)

/O System Reset Register (IORESET)
IORESET forces a system reset.

ADDRESS

2014 00DC (SSC)
3

1ORESET
mad- 030160

bits<31:0>

Name:

VO Reset

Mremonic:

IORESET

Type:

When IORESET is written, the SSC asserts IORESET L which forces
a system hardware reset.

KNSBA/A Interface Module Reglsters
Timer Control Register 0 (TCRO)

Timer Control Register 0 (TCRO)
TCRO controls timer 0.

ADDRESS

2014 0100 (5SC)
»

676643210

MUST BE ZERO (MB2)

I-— Error (ERR)

nterrupt (INT) —j |
interrupt Enabile (IE)

Single (SGL)
Tranater (XFR)

Stop (STP)
Run {RUN)
ma>-0812.60

bit<31>

Name:

Error

Mnemonic:

ERR

Type.

RW1C 0

ERR is set whenever the Timer Interval Register overflows and INT is
already set, indicating a missed overflow. Writing a 1 to this bit clears
it.

bits<30:8>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<7>

Name:

interrupt

Mnemonic:

INT

Type:

RAWIC, 0

INT is set whenever the Timer Interval Register overflows. If IE is set
when INT is set, an interrupt is posted at R3000 IRQ 0. Writinga 1 to
this bit clears it.

KN58A/A Interface Module Regislers
Time: Control Register 0 (TCRO)

bit<6>

Name.

interrupt Enable

Mnemonic:

Tyvpe:

RAN, O

When IE is set, the timer interrupts at R3000 IRQ 0 when INT is set.

bit<5>

Name:

Single

Mnemonic:

SGL

Type:

RW, 0

Setting SGL causes the Timer Interval Register to increment by one if
the RUN bit is cleared. If RUN is set, then writes to SGL are ignored.
SGL is always read as zero.

bli<d>

Name:

Transfer

Mnemonic:

XFR

Type:

RW., 0

Setting XFR causes the Timer Next Interval Register to be copiea into
the Timer Interval Register. Always read as zero.

bit<3>

Name:

Resarved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<2>

Name:

Stop

Mrnemonic:

STP

Type:

AW, 0

STP determines whether the timer stops after an overflow. If STP
is set at overflow, RUN is cleared by the hardware at overflow and
counting stops.

KN3BA/A Interface Module Registers
Timer Contro! Reglster 6 (TCRO)

bit

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<0>

Name:

Run

Mnemonic:.

RUN

Type:

AW, 0

When RUN is set, the Timer Interval Register is incremented once
every microsecond. INT is set when the timer overflows. If STP is
set at overflow, RUN is cleared by the hardware at overflow and
counting stops. When RUN is clear, the Timer Interval Register is not
incremented automatically.

KNS8A/A Interface Module Registers
Timer Interval Register 0 (TIRO)

Timer Interval Register 0 (TIRO)
TIR0 contains the ilerval coumt for timer 0.

ADDRESS

2014 0104 (SSC)
3

Tner Intervel Regmter
mzd-0513-80

bits<31:0>

Name:

Timer interval Register 0

Mnemonic:

TIRO

Type:

RO. 0

When TCR0<0> (RUN) is one, the register is incremented once every
microsecond. When the counter overflows, TCR0<7> is set, and
an interrupt is posted at R3000 IRQ 0 if TCRO0<6> is set. Then, if
TCRO0<2> is zero, TCR0<0> is cleared and counting stops.

KNSSA/A interface Module Reglsters
Timer Next interval Reglster 0 (TNIRO)

Timer Next Interval Register 0 (TNIRO)
TNIRO is for timer 0.

ADDRESS

2014 0108 (SSC)
»

]

Timar Next intarval Ragrater
b 0514 80

bits<31:0>

Name:

Timer Next Interval Register 0

Mnemonic.

TNIRO

Type

AW, 0

TNIRO contains the value that is written into TIRO after an overflow
or in response to TCR0<4> (XFR).

3-61

KNS8A/A Interface Module Registers
Timer Interrupt Vector Register 0 (TIVRO)

Timer Interrupt Vector Register 0 (TIVRO)
TIVRO is used by timer 0. Although they ail occur at the same IPL, interrupts
from the console sgrial line have prorty over imerrupts from the timers, and

timer 0 has priority over timar 1.

ADDRESS

2014 010C (8SC)
3

109

MUST BE ZERO (MB2)

21v0

interrupt Vector sz
mab 081880

bits<31:10>

Name:

Reserved

Mnemonic.

None

Type

RW. 0

Reserved; must be zero.

bits<9:2>

Name:

Interrupt Vector

Mnemon

Type

AW, 0

When TCR0<6> (1E) and TCRO0<7> (INT) transition to a one, an
interrupt is posted at R300C IRQ 0. When a timer's interrupt
is acknowledged, the contents of IV are passed to the CVAX and
TCRO<7> is cleared. Interrupt requests are also cleared by clearing
TCRO0<6> or TCR0<7>.

bits<1:0>

Name.

Resarved

Mnemonic:

None

Type:

AW, 0

Reserved; must be zero.

KNSBA/A interface Module Registers
Timer Control Register 1 (TCR1)

Timer Control Register 1 (TCR1)
TCR1 controls timer 1, which is used by the congole code.

ADDRESS

2014 0110 (SSC)
N

786886

MUST BE ZERO (MB2)

L— Error (ERR)

3210

Interrupt (INT) i-l
Iniarrupt Enabie (IE)

Singis (SGL)
Trangter (XFR)

Stop (STP)
Run (RUN)
80
mab-0512

bit<31>

Name.

Error

Mnemonic:.

ERR

Type.

RWI1C, 0

ERR is set whenever the Timer Interval Register overflows and INT is

already set, indicating a missed overflow. Writing a 1 to this bit clears
it.

bits<30:8>

Name:

Resarved

Mnemonic:

None

Typs

Reserved; must be zero.

bit<7>

Name:

Interrupt

Mnemonic.

INT

Type:

RWIC 0

INT is set whenever the Timer Interval Register overflows. If IE is set
when INT is set, an interrupt is posted at E3000 IRQ 0. Writinga 1 to

this bit clears it.

KNSBA/A Interface Module Registers

Timer Control Register 1 (TCR1)

bit

MName:

Intariupt Enable

Mnemonic:

Type:

AW, 0

When IE is set, the timer interrupts st R3000 IRQ 0 when INT is set.
RN

bit<S>

Name:

Single

Mnemomc.

SGL

Type:

RW, 0

Setting SGL causes the Timer Interval Register to increment by one if
the RUN bit is cleared. If RUN is set, then writes to SGL are ignored.
SGL is always read as zero.

bited>

Name

Transter

Mnemonic.

XFR

Type

AW, 0

Setting XFR causes the Timer Next Interval Register to be copied into
the Timer Interval Register. Always read as zero.

bit<3>

Name

Raserved

Mnemonic.

None

Type

Reserved; must be zero.

bit<2>

Name:

Stop

Mnemonic:

STP

Type:

RW, 0

STP determines whether the timer stops after an overflow. If STP
is set at overflow, RUN is cleared by the hardware at overflow and
counting stops.

KNSBA/A Interface Module Registers
Timer Control Register 1 (TCR1)

—

bit

Name:

Reserved

iMnemonic:

None

Type:

Pp—

Reserved; must be zero.

P
bit<0>

Name:

Run

Mnemonic:.

RUN

Type:

RW. 0

——

KN58/
/A Interface Module Registers
Timer Interval Reglster 1 (TIR1)

Timer Interval Register 1 (TIR1)
TIR1 contains the interval count for timer 1, which is used by console code.

ADDRESS

2014 0114 (SSC)
[}

Timar Interval Regmter
med-05613-90

bits<31:0>

Name:

Timer interval Regrster 1

Mnemonic.

TIR1

Type:

RO. 0

When TCR1<0> (RUN) is one, the register is incremented once every
microsecond. When the counter overflows, TCR1<7> is set, and
an interrupt is posted at R3000 IRQ 1 if TCR1<6> is set. Then, if

TCR1<2> is zero, TCR1<0> is cleared and counting stops.

KNSBA/A Interface Module Registers
Timer Noxt Interval Reglater 1 (TNIRY)

Timer Next Interval Register 1 (TNIR1)
TNIR1 is for timer 1, which is used by conso'e code.

ADDRESS

2014 0118 (SSC)
3

Tunar Next irterval Regietsr
meh-0514.80

bits<31:0>

Mame:

Timer Naxt Interval Register 1

Mnemonic.

TNIRO

Type:

AW, 0

TNIR1 contains the value that is written into TIR1 after an overflow
or in response to TCR1<4> (XFR).

KNSBA/A Interface Module Registers
Timer interrupt Vector Reglster 1 (TIVR1)

Timer Interrupt Vector Register 1 (TIVR1)
TIVR1 is used
by timer 1, which is used by console code.

ADDRESS

2014 011C (SSC)
MUST BE ZERO (MB2)

bits<31:10>

Name:

Reserved

Mnemonic:

Nona

Type:

RAW. 0

inerrupt Vecior MB2

Reserved; must be zero.

bits<9:2>

Name:

Interrupt Vector

Mnemonc:

Type:

AW, 0

When TCR1<6> (IE) and TCR1<7> (INT) transition to a one, an
interrupt is posted at R3000 IRQ 0. When a timer’s interrupt

is acknowledged, the contents of IV are passed to the CVAX and
TCR1<7> is cleared. Interrupt requests are also cleared by clearing
TCR1<6> or TCR1<7>.

bits<1:0>

Name:

Reserved

dMuemonc:

None

Type:

RW, 0

Reserved; must be zero.

KNS8A/A Interface Module Registers
CSR1 Base Address Register (CSR1BADR)

CSR1 Base Address Register (CSR1BADR)
CSR1BADR controls the address of CSR1.

ADDRESS

2014 0130 (SSC)
NWH

mez

210

CSR1 Base Address Register (CSR1BADR)

jmez
mah-0516-60

bits<31:30>

Namae:

Reserved

Mnemonic.

None

Type.

RW, 0

Reserved; must be zero.
“REEERTEE

bits<29:2>

Name

CSR1 Base Address Register

Mnemonic.

CSR1BADR

Type:

RW, 0

CSR1BADR controls the address of CSR1 and is set to 2000 0000 (hex)
by console code during processor initialization.

bits<1:0>

Name:

Reserved

Mnemonic:

None

Type

RW. 0

Reserved; must be zero.

KNSBA/A interface Module Registers

CSR1 Address Decode Mask Reglster (CSR1ADMR)

CSR1 Address Decode Mask Register (CSR1ADMR)
CSR1ADMR controls the addresses that select CSR1.

ADDRESS

2014 0134 (§5C)
313028

Imaz

210

CSR1 Address Decode Mask Register (CSR1ADMR)

Jfiaz
mad0817-80

bits<31:30>

Name:

Reserved

Mnemonc:

None

Type:

AW, 0

Reserved; must be zero.

bits<29:2>

Name.

CSR1 Address Decode Mask Register

Mnemonic.

CSR1ADMR

Type

RW, 0

CSRI1ADMR controls the addresses that select CSR1 and is set to 0000
0000 (hex) by console code during processor initialization.

bits<1:0>

Name:

Reservad

Mnemonic:

None

Type:

RW, 0

Reserved; must be zero.

3-70

KN58A/A Interface Module Reglsters

EEPROM Base Address Register (EEBADR)

EEPROM Base Address Register (EEBADR)
EEBADR spacifies the base address of the EEPROM.

ADDRESS

2014 0140 (SSC)

|mez

bits<31:30>

EEPROM Base Address Register (EEBADR)

Name

Reserved

Mnemonic:

None

Type:

RW, 0

jmez

Reserved; must be zero.

bits<29:2>

Name:

EEPROM Base Address Registcr

Mnemonic.

EEBADR

Type.

RW. 0

EEBADR specifies the base address of the EEPROM &nd is set to 2008
0000 (hex) by console code during processor initislization.
bits<1:0>

Name:

Reserved

Mnemonic.

HNone

Type:

RW,0

Reserved; must be zero.

3-7

KN58A/A Interface Module Registers
EEPROM Address Decode Mask Regleter (EEADMR)

EEPROM Address Decode Mask Register (EEADMR)
EEADMR specifies the addresses that select the EEPROM.

ADDRESS

2014 0144 (SSC)
{mez

EEPROM Address Decode Mask Regster (EEADMR)

ez
mab-0519-60

bits<31:30>

Name:

Reserved

Mnemonic:

None

Type:

RW, 0

Reserved. must be zero.

bltg<29:2>

Name.

EEPROM Address Decode Mask Register

Mnemonic.

EEADMR

Type.

RW. 0

‘

EEADMR specifies the addresses that select the EEPROM and is set
to 0000 7FFF (hex) by console code during processor initialization.

bits<1:0>

Name

Reserved

Mnemonc

None

Type

RW. 0

Reserved; must be zero.

3-72

KNSSA/A Interface Module Reglsters
Device Regilster (XDEV)

Device Reygister (XDEV)
The Device Regisier con‘aing information to idertify the noge. Both fiaids are
loaded dunng node initialization. A zero value indicates an uninitialized node.

ADDRESS

Nodespace base address + 0000 0000 (XCPGA)
3

Device Revision

Device Type

Class

| | L—-—-—-—-— 0 Device

Memory Device

bits«<31:16>

L—— cPu Devce

Name

Device Revision

Mnemonc

DREV

Type

RW 0

Identifies the functional revision level of the module in hexadecimal.
The DREYV field always reflects the letter revision of the module as

follows:
KHSSA/A interface Module

Rovision

DREV (dacimel)

DREV (hen)

0001

0002

001A

3-73

KNS8A/A Interface Module Registers
Device Register (XDEV)

bits<15:0>

Name:

Device Type

#nemonic:

DTYPE

Type:

AW, 0

Identifies the type of node. The Device Type field is broken intc two
subfields: Class and ID. The Class field indicates the major category of
the node. The ID feld uniquely identifies a particuler device within a
specified class. DTYPE contains 83081 (hex) for the KN58A/A interface
module.

3-74

KNSBA/A interface Module Registers
Bus Error Register (XBER)

Bus Error Register (XBER)
The Bus Error Registar contains error status on a failed XMI transaction. This
status includes the failed command, commander (D, and an error bit that
indicates the type of eror that occurred. This status remains locked up until
software resets the error bit(s).

ADDRESS
3|

Nodespace base address + 0000 0004 (XCPGA)

R DTEIDMNDXR N

G WD 17 1815 1413 1211109

olotjoji1|ojocjojojojolojojojojol0jOj0|0}0}1

L Faiing Command (FCMD)
Faiing Commander D (FCID)

Sel-Test Fail (STF)
Extended Teost Fall (ETF)
Node-Speciic Error Summary (NSES)

Commander Errore
— Transaction Timeou! (TTO)
.- Resarved. must be zero

. Command NO ACK (CNAK)
— Read Error Response (RER)

- Read Sequence Ermor (RSE)
- No Read Response (NRR)

L Corrected Read Data (CRD)

- Write Data MO ACK (WDNAK)
Responder Errors
i~ READADENT Deata NO ACK (RIDNAK)
—
L—

Write Sequencae Error (WSE)

Parity Error (PE)

L~ inconsistent Parity (IPE)
idlacotiancous

L Write Error Interrupt (WEH1)
L L. XM Fault (XFAULT)
Corrected Confirmz ion (CC)
— XM BAD (XBAD)

L Node HALT (NHALT)

L — Node Reset (NRST)
Error Summary (ES)

3-75

KNS8A/A Interface Module Registers
Bus Error Reglster (XBER)

Dil<3i>

Name:

Eror Summary

Mnemonic:

Type:

RO, 0

The state of ES represents the logical-OR of the error bits in this
register. Therefore, ES is asserted if any error bit is asserted.

bit<30>

Name:

Node Reset

Mnemonc:

NRST

Type:

AW, 0

Writing a one to NRST initiates a complete power-up reset similar
to the assertion and deassertion of XMI DC LO L (see note below),
the node performs self-test and asserts XMI BAD L until self-test is

successfully completed. Like power-up reset, nodes are precluded from
accessing the node from the time it is node reset until it completes
self-test (or the maximum self-test time is exceeded).
NOTE: During the time that a node is reeponding to node reset, the

node does not access other nodes on the XML, In response to a
real power-up sequence (caused by XMI DC LO L), the NRST
bit resets. Following a node reset sequence, NRST remains set,
allowing the processor to recognize that it should not attempi
to go through the normal boot process.

bit<29>

Name:

Node HALT

Mnemonic

NHALT

Type:

RW. 0

Writing a one to NHALT forces the node to go into a "quiet” state while
retaining as much state as possible. The KN568A/A interface module
will send an INT4 interrupt to the R3000, causing the R3000 to enter
console mode.

bit<28>

Name:

XMI BAD

Mnemonic:

XBAD

Type.

RW, 1

On reads, XBAD ir...cates :he state of the XMI BAD signal. A one
indicates that BAD is asserted. Writes to XBAD cause the state to be

driven on the wired-OR XMI BAD L line by this node; writing a one
asserts XMI BAD L, while writing a zero releases it.

3-76

KNSBA/A Interface Module Regilsters
Bus Error Regleter (XBER)

bit<27>

Name

Corrected Confirmation

Mnemonic:.

Type:

RMWiC, 0

CC sets when the node detects a single-bit CNF error. Single-bit CNF
errors are automatically corrected by the XCLOCK chip.
Ervor Flag Asseried: INT3

Additicnal Status Btored: None

Action: Since the ACK/NAK is usable, no further action is needed.
MR

bit<26>

Name:

XM FAULTY

Mnemonic:

XFAULT

Type:

RWIC. 0

When set, XFAULT indicates that the XMI FAULT signal has been
asserted for at least one cycle. An XMI node asserts FAULT to indicate
that it has sensed a Transmit Error (dete transmitted onto the XMI

does not compare with data received during the same cycle) on a cycle

that was ACKed.

Ervor Flag Asserted: INT3
Additional Status Stored: None

Action: An INT3 is also generated if XFAULT is asserted by another

XMI node, providing systemwide coverage of a connector or multiple
transmitter failure.

bit<25>

Name

Write Enar Interrupt

Mnemonic.

WEI

Type:

RW1C, 0

When set, WEI indicates that the node has received a write error
interrupt transaction (IVINTR).
Error Flag Asseried: INT3

Additional Status Stored: None

Action: R3000 polls nodes to determine source and cause.

3-77

KNSRA/A Interface Module Registers
Bus Error Reglster (XBER)

bit<24>

Namae.

Inconsistent Party Error

Mnramonic:

IPE

Type:

RW1C, 0

When set, IPE indicates that the node has detected a parity error on
an XMI cycle and the confirmation for the errored cycle was ACK. This
indicates that at least one node (the responder) detected good parity
during the cycle time that this node detected a parity error. If this
was a successful write to memory, it could leave the second-level cache
incoherent.

Ervor Flag Asserted: INT3
Additional Status Stored: None

Actinn: KN58A/A interface module hardware disables the second-level
cache by asserting CSR1<18> (Force Miss, FMISS). Software flushes
the second-level cache by writing a one, then a zero, to CSR1<20>
(Force Cache Invalidate, FCI)

bit<23>

Nama:

Party Error

Mnemonic:

Type

HWIC. 0

When set, PE indicates that the node has detected a parity error on an
XMI cycle.

Error Flag Asserted: INT3
Additional Status 8tored: None

Action: Appropriate error recovery is initiated when PE is set.

bit<22>

Namae:

Write Sequence Error

Mnemonic:

WSE

Type

RWIC, 0

Node aborted write transaction due to missing data cycles.
Error Flag Asserted: No Interrupt

Additional Status Stored: None

Action: Write to CSh is not performed. WSE bit sets but the
commander of the issuing node is responsible for error recovery.

3-78

KNSBA/A Interface Modul» Registers
Bus Error Register (XBER)

bit<21>»

Name:

READADENT Date NO ACK

fMnemonic.

RIDNAK

Type:

RW1C, 0

When set, RIDNAK indicates that a read data cycle (GRDn, CRDn,
LOC, RER) transmitted by the node has received 8 NO ACK
confirmation. The KN5S8A/A interface module does not respond to
IDENT transactions.
Error Flag Asserted: No Interrupt
Additionai Status Stored: None

Action: When read data sent by the responder does not get ACKed,
the responder causes RIDNAK to set; hut it is the commander of the
issuing node that is responsible for error recovery.

bit<20>

Name:

Write Data No Ack

Mnemonic.

WDNAK

Type:

RW1C. 0

When set, WDNAK indicates that a write data cycle transmitted by
the node has received a NO ACK confirmation. WDNAK sets only if
the reattempt fails.
Error Flag Asserted: INT3
Additional Status Stored: Failing Address (XFADR), Commander
1D, and Command.

Action: The transaction is reattempted until a timeout occurs. Failed

address is saved.

bit<19>

Name:

Corrected Read Data

Mnemonec:

CRD

Type:

RW1C, 0

When set, CRD indicates that the node has received a CRDn read
response, meaning that the read transaction was received by memory
with bad parity but memory corrected it.
Error Flag Asgerted: INT3

Additional Status Stored: None

Action: Since the data is usable, no further action is necessary.

3-79

KNSSA/A interface Module Registers
Bus Error Register (XBER)

bit<18>

Name:

No Read Responsa

Mnemonic:.

NRR

Type:

RWiC, 0

When set, NRR indicates that a transaction initiated by the node failed
due to a read response timeout.
Error Flag Asserted (READ): BUS ERR if during the first
quadword, INT3 (due to CFE) during second-level cache fill.
Error Flag Asserted (READ/IDENT): INT3

Additional Status Stored: Failing Address (XFADR), Command ID,
and Command.
Action: No retry is attempted. If error flag, the R3000 takes a bus
error exception. If CFE, the R3000 takes an INT3 interrupt. Failed
address is saved.

bitc17>

Name:

Read Sequence Error

Mnemonic:

RSE

Type:

RWIC. 0

When set, RSE indicates that a transaction ini.iated by the node
failed due to a read sequence error, meaning that data which is
returned as the result of a read transaction or an interrupt vector
which is returned in an IDENT transaction is identified as being out of
sequence.

Error Flag Asserted (READ): BUS ERR if during the first
quadword, INT3 (due to CFE) during second-level cache fill.
Error Flag Asserted (READ/IDENT): INT3

Additional Status Stored: Failing Address (XFADR), Commander
ID, and Command.

Action: No retry is attempted. If error flag, the R3000 takes a
bus error exception. If second-level cache fill, then CFE is asserted,
causing an INT3 interrupt to the R3000 and the sub-block in cache is
not validated. Failed address is saved.

KNSS8A/A Interface Module Registers
Bus Error Register (XBER)

bit<16>

Name:

Read Emor Response

Mnemonic:.

RER

Type:

RW1C, 0

When set, RER indicates that a node has received a Read Error
Response, meaning that the result of a read transaction or an interrupt
vector returned in an IDENT transaction is uncorrectable.
Error Flag Asserted (READ): BUS ERR if during the first
quadword, INT3 (due to CFE) during second-level cache fill.
Ervor Flag Asserted (READ/IDENT): INT3

Additional Status Stored: Failing Address (XFADR), Command 1D,
and Command.

Action: No retry is attempted. If error flag, the R3000 takes a
bus error exception. If second-level cache fill, then CFFE is asserted,
causing an INT3 interrupt to the R3000 and the sub-block in cache is
not validated. Failed addrese is saved.

bit<15>

Name

Command NO ACK

Mnemonk:

CNAK

Type:

RW1C. 0

When set, CNAK indicates that a command cycle transmitted by the
node has received a NO ACK confi:. .ition caused by either a reference
to a nonexistent memory location or a command cycle parity error.
This bit is set only if the error recovery reattempts fail.

Ervor Flag Asserted (READ): BUS ERR
Error Flag Aseerted (WRITE/IDENT): INT3

Additional Status Stored: Failing Address (XFADR), Commander
ID, and Command.

KNSBA/A Interface Module Registers
Bus Error Reglster (XBER)

bit<id>

Name:

Reserved

tdnemonic:

None

Type:

AW, 0

Reserved; must be zero.

bitc13>

Name:

Transaction Timeout

Mnemonic:

TTO

Type:

RWIC, 0

When set, TTO indicates that a transaction initiated by the node failed
due to a transaction timeout. This bit is set only if the error recovery
reattempt fails.
Error Flag Asserted: Varies, depends on the transaction causing the
error.

Additional Status Stored: Failing Address (XFADR), Command 1D,
and Command.
Action: Depends on whether a read or write error caused TTO to set.
TTO always sets in conjunction with another error, and the other error
bit determines the appropriate action.

bit<12>

Name:

Node-Specitic Error Summary

Bnemonic.

NSES

Type

RO. 0

When set, NSES indicates that a node-specific error condition has been
detected. The exact nature of the error is contained in node-specific
registers.

bit<1i>

Name:

Extended Test Fail

Mnemonic.

ETF

Typs:

RW1C, 1

When set, ETF indicates that the node has not yet passed its extended
test. This bit clears when the node passes its extended test.

KNS58A/A Interface Module Reglsters
Bus Error Register (XBER)

bit<10>

Name:

Seli-Test Fail

Mnemonic:

STF

Type:

RAWIC, §

When set, STF indicates that the node has not yet passed its self-test.
This bit is cleared by the user interface when the node passes its
self-test.

bits<9:4>

Name:

Failing Commander ID

fMnemonic:

FCID

Type:

FCID logs the commander ID of a failing transaction.

bits<3:0>

Name:

Failing Command

Mnemonic:.

FCMD

Type:

FCMD logs the command code of a failing trav:saction.

KN58A/A Interface Module Registers
Falling Address Register (XFADR)

Failing Address Register (XFADR)
The Failing Address Register logs address and length information associated
with a failing transaction. The XFADR has an undetermined value on powerup.

ADDRESS

Nodespace base address + 0000 0008 (SSC)
3t

N 2

[}

Failing Address

Failing Length (FLN)
~ad-0360-89

bits<31:30>

Name:

Failing Length

Mnamonic:

FLN

Type:

FLN logs the value of XMI D<31:30> during the command cycle of a
failing transaction.

bits<29:0>

Name

Faiing Address

Mnemonic:

Nons

Type:

1218

The Failing Address field logs the value of XMI D<29:0> during the
command cycle of a failing transaction.

KNSSA/A Interface Module Registers
XMi General Purpose Reglster (XGPR)

XMI General Purpose Register (XGPR)
The XGPR is a genaral purpose register that is visible 1o the XMI. This register
is used dunng self-test and by the ROM-based diagnostics.

ADDRESS

Nodespace base address + 0000 000C (XCPGA)
NPANTHBIWRDV222720WW0
T8
141312110
0

ojojojoiojogojojojojojoiojojoioiojojojoljojojojoiojojojojojojojo
met- 0520 60

bits<31:0>

Name

XMi Gonera! Pumpose Register

Mnemonic:.

XGPR

Type.

RW 0

The general purpose register is used by self-test and during ROMbased diagnostics.

KN5BA/A Interface Module Registers
Control and Status Register 2 (CSR2)

Control and Status Register 2 (CSR2)
CSR2 provides KNSSA/A interlace module control and status to the XMi.

ADDRESS

Nodespace base address + 0000 0610 (SSC)

3B BITWHMDN
NI WL YT
I 121110 6 8

]

fojololojolojojolojojo]ojojojojojo]jojojojojojojolo]o]
GAREV

L FP<O>
FP<ct>

FP<2>
Reserved

Control

Wrde Buffer Disable (WBD)

L— Auio Retry Disable (ARD)

—— Enable Seif-invalidates (ES!)
. Read Upper (RUP)
—— Timaout Select (TOS)

——— Reserved

CROD Interrupt Disable (CRDID)
CC Interrupt Disable (CCID)

Status
Reserved
e B0OO1 Processor Disable (BPD)

Boot Processor (BP)
Commander NO ACK Received (CNAKR)

Uniock Write Pending (UWP)
Lockout<0>

Lockoutc1>
Reserved

Emors
el

& U111

Reserved

Duplicate Tag Parity Error (DTPE)
Cache Fill Error (CFE)
Write Data Partty Error (WDPE)

INVAL Quaeue Overfiow (KQ0)

Second-Leve! Cache Partty Error (SCPE)

eb-0809-90

KNSBA/A Interface Module Reglsters
Control and Stetus Register 2 (C8R2)

bits<31:30>

Name

Second-Level Cache Parity Errors

Mnemonic

SCPE

Typa:

RW1C, 0

These bits indicate second-level cache parity errors as shown:
Ble<31:30:

Erver Type

None

Tag Parity Eror (TPE)

Vaid Bit Parity Error (VPE)

Cache Data Panty Error (CDPE)

TPE is a parity error in the Tag Buffer RAMs. VPE is a parity error in

the Valid Bit RAMs. CDPE indicates a parity error in the data stored
in the second-level cache.

Error Flag Asserted: INT3
Additiong! Status Stored: None

Action: TPE, VPE, or CDPE cause a cache miss and disable second-

level cache by setting FMISS (CSR1<18>). On a write, the occurrence

of any of these errors results in a failure to update the cache. Secondlevel cache should be flushed as described in Section 3.6.2.

bit<29>

Name

INVAL Queue Overflow

Mnegmonic:

1QO

Type

RW1C. 0

1Q0 is set whenever the INVAL queue overflows. The second-level
cache is flushed when this error occurs to ensure cache coherency.
When 1QO is set, the INVAL queue in the processor is held clear.
Ervor Flag Asserted: INT3
Additions] Statue Stored: None

Actions: Second-level cache is flushed as described in Section 3.6.2.

bit<28>

Name:

Wite Data Parity Error

Mnemonic.

WDPE

Type:

RWIC, 0

WDPE is set whenever a parity error is detected on write data driven
by the processor on the 1IDAL bus.
Error Flag Asserted: INT3
Additional Status Stored: None

KNS8A/A Interface Module Registers

Control end Status Reglster 2 (CSR2)

Actions: The write transaction is not allowed to proceed onto the
XML If a XCPGA write buffer hit, then data is not loaded into the
XCPGA write buffer. The failing address is not saved by the pinout
error logic.

bit<27>

Name:

Cache Fill Ervor

Mnemonic.

CFE

Type:

RWIC, O

CFE is set whenever a second-level cache fill error occurs. Secondlevel cache fill errors are soft errors that occur on the 2nd, 3rd, or
4th quadword of the second-level cache fills. CFE is always set in
conjunction with other error bits.
Whenever an error occurs on the data being returned to the CVAX, the
second-level cache is disabled because CSR1<FMISS> asserts.
Error Flag Aseerted: INT3

Additional Status Stored: Failing Address (XFADR), Command 1D,
and Command (XBER)
Action: The Valid bit is not set at the completion of 8 hexword read.
The resulting invalid sub-block causes a cache miss when addressed.

bit<26>

Name

Duplicate Tag Party Error

Mnemonwe.

DTPE

Type

RWIC. 0

DTPE is set whenever the duplicate tag store detects a parity error on
lookup. Since this error could result in a second-level cache coherency
prablem (the write might have hit if the parity error had not occurred
and resulted in the generation of an invalidate) the KN58A/A interface
module hardware disables the second-level cache when this error
occurs and posts a soft error interrupt.
Error Flag Asserted: INT3

Additional Status Stored: None
Action: DTPE causes a miss, which if 8 memory write, results in a
potential second-level cache coherency problem. Second-level cache is
flushed as described in Section 3.6.2.

bits<25:23>

Name:

Reserved

Mnemonic.

None

Type.

Reserved.

KNSSBA/A interface Module Registers
Control and Status Register 2 (CSR2)

blis<22:21>

Name

Leckout<t:0>

Mnemonc.

None

Type:

RW, 01

The KNSSA/A interface module supports a lockout avoidance
mechanism that assures access to interlock varisbles. Lockout<l:0>
controls these mechaniems as follows:
Bhe<22:21»
22

Doceription

Interiock lockout avoidance » disabled but XMI LOCKOUT L s still
asseried as defined for Lockout<1.0> » 01

0
1

bit<20>

interiock lockout avowdance is enabled.

Resarved

Reserved

Name

Unlock Write Pending

Mnemonic

UWP

Type

RW1IC, 0

UWP is set whenever an Interlock Read is generated and is cleared
on the subsequent Unlock Write from the same node. The setting and
clearing of this bit is not gated by the successful transmission of the
XMI transaction.

bit<i19»

Name

Commander NO ACK Received

Mnemonic.

CNAKR

Type.

RWIC, O

CNAKR is set whenever a command/address NO ACK is received to
an XMl commander transfer. A NO ACK is not necessarily an error
on the XMI as it is used for retries, but this status bit is used by

diagnostics that wish to know whether a transfer was NO ACKed. The
KNS8A/A interface module automatically reeitempte all XMI transfers
that are NO ACKed until a timeout occurs, unless CSR2<9> (ARD) is
aet.

KNSSA/A interface Module Registers
Control and Status Reglster 2 (CSR2)

bit<18>

Name

Boot Procassor

Mnemunic:

Tvpe:

AW, 0

BP is used to indicate that this KNS8A/A is associated with the boot
processor. The console code sets this bit after self-test if it determines
that this KN58A is associated with the CPU with the lowest node ID
number with its CSR2:BPD bit clear.

bite17>

Name

Boot Processor Disable

Mnemcivic.

BPD

Type

RW. 0

BPD is used to indicate that this KNS8A is diabled from becoming the
boot processor. It is loaded by console code on power-up with a state
stored in EEPROM.

bit<16>

Name

Reserved

Mnemonic:

None

Type

Reserved.

bite15>

Name

CC Inerrupt Disable

Mnemonc:

CCID

Type.

RW, 0

CCID disables the generation of error interrupts to the KN58A/A
interface medule in response to corrected confirmation indications from
the XMI. While CCID is set, XBER<27> (CC) bit will still be set on
the receipt of a corrected confirmation code but the processor will not
be interrupted. When reset, the INT3 line asserts when a corrected
confirmation code is received from the XMI (XBER <27> also sets).

3-80

KNSBA/A Interface Module Registers
Control and Status Register 2 (CSR2)

biteid>

Name:

CRD interrupt Diseble

Mnemonic.

CRDID

Type:

RW, 0

g
i

CRDID disables the generation of error interrupts to the processor

in response to Corrected Read Data responses from memory. While
CRDID is set, the XBER<19> (CRD) bit will still be set on the receipt
of a Corrected Read Data response but the processor will not be
interrupted. When reset, the CRD line will assert when a Corrected
Read Data response is received from the XMI (XBER<19> (CRD)
bit will also be set). Software should clear XBER<19> (CRD) before
clearing CRDID to ensure that only newly generated CRD responses
cause interrupts.

bit<13>

Name:

Roserved

Mnemonic:.

None

Type:

Reserved.
mE—

bit«12>

Name

Timeout Select

Mnemonic

TOS

Type:

RW., 0

TOS selects one of two timeout values (0 selects =16.77 ms, 1 selects
#16.38 us). This timeout value is used to detect both Response and

Reattempt Timeout conditiens. This bit remains clear during normal
system operatiof:.

biteii>

Namae:

Enable Read Upper

Mnemonic:.

ERUP

Type:

RW. 0

When ERUP is set, the upper longword of the data driven on the XMl
is returned in response to an IO gpace read. Normally, the lower
longword is returned. ERUP is used during self-test to test the logic
and pins associated with the upper longword of the XMI data path.

KNSBA/A Interface Module Reglsters

Control and Status Register 2 (CSR2)

bit< 10>

Name

Enable Seli-invahdates

Mnemonic:

ESI

Type:

RW. 0

When ESI is set, the processor will invalidate cache entries matching
its own XMl write addresses. Normally, since the cache is write
through, only writes from other XMI nodes generate invalidates. ESI
is used for testing because it permits a single processor, in conjunction
with XMI memory, to verify the operation of its invalidate logic.

bit<9>

Name:

Av 0 Ratry Disable

Mnemonic:

ARD

Type:

RW, 0

ARD disables auto retry of NO ACKed XM] commander transfers and
causes the immediate return of an error response after the receipt of a
NO ACK confirmation to a commander transfer. ARD is only used by
diagnostics and must be clear during normal operation.
RN EA

bit<8>

Name:

XCPGA Write Bufter Disable

Mnemonic.

WBD

Type:

RW, 0

WBD disables the XCPGA write buffer so that all writes are written
directly to main memory. Logically, the write logic is forced to assume
that all writes are to /O space and this automatically forces the
XCPGA write buffer function to be bypassed.

bit<7>

Name:

Reserved

Mnemonic.

None

Type:

Reserved.

bite<b:4>

Name:

Force Parity <2:0>

Mnemonic.

Type.

AW, 0

FP is used to provide the parity states for XMI P<2:0> when
CSR1<22> (Force Farity Select) is set.

3-92

KNSBA/A Interface Module Registers
Control and Status Reglster 2 (CSR2)

bite<3:0>

Name:

Gate Array Revision

Mnemonic.

GAREV

Type:

GAREYV contains the revision level of the XCPGA.

KNSSA/A Interface Module

3.9

initialization, Self-Test, and Booting
This section gives the KNBBA/A interface module initialization
overview; describes the results of initialization; and then discusses
the bootstrapping or restarting of the operating syetem.

3.9.1

Initialization Overview
The three ways to reset the KN58A/A interface module are:

Power-Up Sequence—When the DECsystem 5800 is powered up, XMI
AC LO L and XM!I DC LO L are sequenced so that all XMI nodes are
reset.

System Reset—The XMI emulates 8 power-up sequence by asserting
the XMI RESET L line, causing the power supply to sequence XMI AC
LO L and XM!I DC LO L as in a "real” power-up. The XMI does not
differentiate between a "real’ power-up and a system reset. A system
reset is caused by:

— Software that asserts XMI RESET L by writing to address 2014
00DC (IORESET). For example, the console initialize command
generates a system reset if no argument is given by using this
mechanism. Note that I/C addresses associated with 1/O adapters
0, 1, 2, and 3 are accessed via ksegl. IO addresses associated
with 'O adapters 4, 5, 6, and 7 are accessed via kseg2. See
Section 4.2.7.2 for more information and an example.
— The XTC power sequencer asserts the XMl RESET L line when
the control panel Restart button is pushed.

Node Reset—-Any KN58A/A interface module can be "node reset”
by setting its XBER<NRST> bit. The console initialize command
generates a node reset if a node ID argument is provided. The
difference between the node reset and a system reset is that XMI
AC LO L is not sequenced during a node reset.

3-94

KNSBA/A interface Module

In response to a "cold” power-up or system reset, the KNS8A/A interface
module(s) participate in the following general initialization sequence:
1

Reset(s) to a known state. (Refer to Table 3-7 for the initialized states
of KN58A/A interface module registers on reset and after self-test
completes.) The KNSSA/B CPU module(s) are held in a reset state
during this portion of the initialization sequence.

The CVAX(es) start executing the consol? program at 2004 0000 in

The KN58A/A interface module associated with the boot processor
prints the results of the gelf-test.

All KNSBA/A interface modules execute & memory interaction test.

The CVAX(es) are disabled, and the KN5SA/B CPU module(s) are

The R3000(s) start execution at IIDAL physical address 200A 0000.
The R3000 portion of the console program executes a self-test for the
KN58A/B CPU module. When self-test is complete, the K3000(s) are
disabled and the CVAX(es) are enabled.

The KN58A/A interface module associated with the boot processor
prints the results of the memory interaction test and KN58A/B CPU
module self-test.

The CVAX(es) run the DWMBA/VAXBI self-tests.

The KN5BA/A interface module associated with the boot processor
prints the resuits of the DWMBA/VAXBI self-tests.

ROM. The console program (firmware) initializes the registers and
executes a partial ROM-based diagnostic (RBD) self-test.

initialized.

10 The KN58BA/A intefece module associated with the boot processor
configures memory.

If maintenance inode 18 not selected, the KN58A/A interface module
associated with the boot processor is disabled, the R3000 starts
execution at 200A 0000, and the KN58A/B CPU module passes control
to the operating system.

12 The operating system initialization code performs the final system
initialization.

KNSBA/A intertuce Module

3.9.2

initialization Details
The following is a flowchart and summary of the initialization process.
The sections that follow explain in some detail the process outlined by the
flowchart.

Figure 3-10

Inktislization Flowchant
18881 (CON)

Power-up orsy=

cPyY2

CPU 1

KNSSA'A

KNSBA A

Sait-Tost

Solt-Tex

flamory

MS82A

Soit-Tes!

8o0ot Procagsor pnnts

8!t to5t resuits

cPy?
WAEM Interaczon Yosts

CPU
MEM inaracton Tess

cPu

- .N

‘

®NSBA
B
Soit Tas'

CPu 2

St Tes

Prnt
Tes®

Hesu"s
1

m
Figure 3-10 Cont'd. on next page

3-96

meb-0203-§9

KNSSA/A Interface Module

Figure 3-10 (Comt.)

inttlalization Fiowcharn

Ezscute DWLADA Soft- Tea:

rY
Prrt DRAMBANVARE!
Yeat Ragvin

Contigure Momory

ewnccasusme

=
Pri blgrmory
Contgurgton

X
Promp:. Resten. o

Comtinug Boor

Operat:

wsyn.o- %
!

e
mss«sm Sats
ry Proceasor
1

Fracca

War

Mamenance WMone
!

.
Reve CCA
Massage
=

CPU ' Rurning

CPU 2 Running

KNS8A/A Interface Module

3921

Restarn Seguence

Initialization typically begins with a CVAX processor restart. The most
common of these is a 03 reset, whih occurs on system power-up or reset.
The R3000 is blocked from executing during CVAX initialization.
The first objectives of the console code during a restart sequence are to

establish its data area and stack, indicate that it is executing, and save
the interrupted machine state, if any. All restarts have the following
sequence in common:

The SSC Configuration Register (SSCCR) is temporarily set to 0076

0000 to select the ROM size and halt protect region.
2

The T1 interval timer is started.

If the self-test ROM is present, the KN58A/A interface module and

KN58A/B CPU module self-tests are started.

The KN58A/A interface module self-test returns the value of the
XBER<NRST> bit, and this value is stored in SSC RAM.

The signature longword in SSC RAM is checked and, if valid, its value
is changed. This step is then skipped in the future.

The SSC address decode registers CSR1BADR and CSR1ADMR are
initialized to allow access to CSR1.

The SSC address decode registers EEBADR and EEADMR are

The SSC Configuration Register (SSCCR) is loaded with the value
8176 5007, which specifies the following configuration:

initialized.

Bit(s)

Setting(s)

Description

Clears any prev:ous battery low condrion to prevent
the time of year clock frcm being reinitialized by
subsequent resets.

30.28

000

Must be zero.

Enable interrupt vectors for console ines and
programmabie timers.

25:24

Must be zero.

Select IPL15 interrupts for console hines and
programmabie timers.

Select 350 ns ROM spesd.

22:20

Select ROM size of 1024K. This maps the ROM and

EEPROM address space 1o appear at beth 2004 0000

through 200B FFFF and 200C 0000 through 2012
FFFF.
19

18:16

Must be zero.

Select hah protect region of 512K. The first image of

the ROMEEPROM address space s halt protected.
The second image is hatt enabled and used to leave
console mode and to run CVAX based boot code.

KNS8A/A interface Module

Bi(s)

Setting(s)

Descripiion

Select CTRL/P as the console interrupt character.

14:12

101

Select datault baud rate of 9800.

117

0000

fMust be zero.

000

Diseble address decode for EEPROM wriles.

fus! bs 2ero.

Enable eddress decode for CSA1 reeds and writes.

The IIDAL Bus Timeout Register (CBTCR) is set to 0000 9000.
10 The interrupt vectors for the programmable timers are set to 78 for

timer 0 and 7C for timer 1.
7

The internal and external caches are disabled.

12 Additional initislization of the console data area in SSC RAM is

performed, as described below.
13 The maintenance mode dispatch routine is called with a CALLG

instruction, which causes the remaining CVAX GPRs to be saved in
SSC RAM.

The additional initialization of the console data area in SSC RAM consists
of the following for a "cold” restart:
1

The Device Revision field (bits<31:16>) of the XDEV Register is
set according to the module revision value stored in EEPROM. If
EEPROM is unusable, the Device Revision field is left as zero.

If self-test passed, XKBER<XBAD> is cleared, which deasserts the XMI
BAD signal.

If this is the KN58A/A interface module associated with the primary
processor, the primary sets the console terminal baud rate according
to the value stored in EEPROM. If EEPROM is unusable, the primary
sets its baud rate to 1200.

All processors in the system scan the XMI node space to locate the
processor with the lowest XMI number—the primary processor. The
primary processor prints initial self-test resulits on the console terminal
and sets CSR2<BP>. If the KN58A/A interface module associated with
the primary processor fails self-test, it bypasses further testing and
memory configuration and attempts to enter maintenance mode.
All KN58A/A interface modules that pass the initial self-test execute

an extended test, also referred to as the memory interaction test. If
the KN58A/A interface module associated with the primary processor
fails the extended test, it bypasses further testing and memory

configuration and attempts to enter maintenance mode.

Each KN58A/A interface module sets the "R3000 self-test” request code
in SSC RAM and passes control to the R3000 portion of the console

program, which initiates the KN5S8A/B CPU module self-test. R3000
code stores the results of the KN58A/B CPU module self-test in SSC
RAM and returns control to the CVAX portion of the console. If the

3-99

KNS8A/A interface Module

KN58A/B CPU module associated with the primary processor fails selftest, it enters maintenance mode after completing the DWMBA/VAXBI
self-test.

If a processor passes its extended test and KNSSA/B CPU module
gelf-test, it again clears XBER<XBAD> and CSR2<BP> and clears
XBER<ETF>.

The KN58A/A interface module associated with the primary processor
prints the self-test results on the console terminal.
The primary processor runs the DWMBA/VAXBI self-test and prints
the results. The DWMBA/VAXBI gelf-test ensures that all DWMBAs
have powered up and completed their self-tests before returning to the
console.
10 The primary processor configures memory as described in Section 3.9.3.

If sufficient memory is found, it builds the console communications
area (CCA) in the highest addressed pages of memory.
"

Once the total size of configured memory is known, the primary
processor completes initialization of each DWMBA as described in
Section 3.9.4.

12 The primary processor once again sets its CSR2<BP> bit to indicate

to secondary processors that they should idle in maintenance mode.
Secondary processors poll their CCA receive buffers for 8 command to
start R3000 execution.

13 The primary processor checks the ROM and EEPROM revisions posted

in the CCA by secondary proceszors. The primary processor prints a
revision banner along with any mismatches that may have been found.
14 ‘The primary processor displays the maintenance mode prompt if

maintenance mode is selected. If maintenance mode is not selected,

the primary processor loads an "R3000 console mode” request in SSC
RAM and passes control to the R3000 portion of the console program.
3922

Nodo Reset

Some of the initialization steps are inappropriate with a node reset since
the remainder of the system must continue to function. The sequence is
modified as follows:

Self-test results are not displayed.

Extended tests are not run. Instead, the XBER<ETF> and
XBER<XBAD> bits are cleared.

DWMBA self-test is not run. No initialization of the DWMBA is
performed and, therefore, no test results are printed.

No memory configuration is performed. The processor searches for the
CCA. If the CCA connot be found, the processor hangs.
The XBER<NRST> bit has its initial value stored in console scratch
memory and is then cleared by self-test. The stored value is used by
the console program to detect a node reset.

3~-100

KNSSA/A Interface Module

3923

Halt Imerrupt

A halt interrupt entry to the console program occurs when CTRL/P is
entered on the congole terminal (and the front panel key switch ie not in

the Secure position) or whenever the XBEK<NHALT> bit is set. A halt
interrupt produces a halt interrupt signal which is gated to whichever
processor chip (CVAX or R3000) is currently controlling the system.

If the CVAX is executing, the halt signal causes a CVAX restart with a
code of 02. The console program performs its initialization sequence and
displays the maintenance mode prompt.

If the R3000 is executing, the halt signal causes & level 4 interrupt to

the R3000. If interrupts are enabled, the operating system handles
the interrupt and calls the console program. The console program then
displays the console prompt.

3924

Errors

An error entry into the console program occurs wihen the CVAX encounters

any restart condition other than reset (03) or halt {02). This occurs when

a CVAX HALT instruction is executed or some other catastrophic processor
event occurs. The console program performs the common initialization
sequence and displays the maintenance prompt.

Errors do not cause entry into the console program while the R3000 is
executing. The operating system handles the error and typically calls back
to the console program to request a system reboot.

3.9.3

Memory Configuration
The CVAX portion of the console program configures memory by setting
the interleave and starting address for each array. The console program

controls the memory configuration because the console uses a portion of
the main memory to hold the console communications area (CCA) and
the R3000 console program state. The console also builds a physical
memory bitmap showing all usable and unusable pages. The results of the
CPU/memory interaction test are used to determine the defective pages.
The memory configuration process verifies that 8 minimum of 256 Kbytes
of usable memory per processor is available plus the space used by the
CCA and bitmap. The location of the CCA is determined and marked as
unusable in the bitmap.

If the primary processor is unable to find the minimum required memory,
it displays an error message and enters maintenance mode. Some
maintenance functions may not be available due to lack of memory.
Console mode is unavailable.

3-101

KNSSA/A Interface Module

3931

Selaction of inerieave
The interleave is specified by the value of the interleave environment
variable. There are three types of interleave:

DEFAULT - The congole program makes all interleave decisions.

EXPLICIT ~ The user supplies configuration data.

NONE -~ No arrays will be interleaved.

If the interleave environment variable is set to the string default, the
console program attempts to form interleave sets. The largest ‘nterleave
factor is obtained for each group of like-sized arrays. If there are more

arrays than can be evenly interleaved, the criteria is repeated for the
remaining arrays until only single arrays remain. The array with the
lowest XMI node ID is assigned to the lowest physical address. All arrays
of the same size are configured before arrays of a different size.
Any array containing hard (unrecoverable) errors is not included in a
default interleave set. Instead, it is configured as uninterleaved. The
remaining arrays that would have formed the set are freed up for inclusion
in another interleave set, if one can be formed. Arrays with hard errors
are configured at the top of physical address space, because ULTRIX
requires contiguous physical memory.
If the environment variable specifies EXPLICIT interleave sets, the console

program interleaves and configures the arrays in the order specified.

When an array in the set has unrecoverable errors, all arrays in the set
are configured without interleaving. If a set specifies a nonexistent array

or is otherwise inconsistent, all arrays in the set are configured without
interleaving.

If the environment vaiable contains the string none, the arrays are
configured uninterleaved, in order by node ID, with the lowest numbered
array at the lowest physical address.

If the environment variable is undefined, contains an invalid value, or if
EEPROM is corrupt, memory is configured as if the environment variable
were default.

3-102

KNSSA/A inter’ace Module

3932

tlemory Testing and the Bikmap
Memory self-test indicates that an array has no unrecoverable (hard)
ervors, one hard error, or multiple hard errors. Self-test executes on all
arrays in parallel end is faster then sofRtware testing of memory. An
attempt is made to use the regults of self-test and avoid performing
goftware testing of memory.

A hard (unrecoverable) error is called an RDS ervor and is defined as
one that is an uncorrectable double-bit error by memory hardware.
A correctable (CRD) error is not considered & hard ervor, and pages
containing CRD ervors are marked as usable.

If self-test indicates that an interleave set contains no hard errors, the set

never undergoes software testing. If an array in an interleave set contains
one or more hard errors, that set is uninterleaved and the failing array is
software tested.

Software testing is performed, one page at a time, beginning with the
lowest addressed page in the array. If required, this testing takes about 7
seconds per megabyte. All locations in the page are written with patterns.
The locations are then read. If the value read from any location does not

match the pattern, or if a machine check occurs reading any location, that
page is marked as unusable, and testing resumes with the next page. The
testing patterns are in this order:
©

All ones

All zeros

Alternating one/zero/one

Alternating one/zero/one with ECC bits complemented

The address of each longword

The complement of the address of each longword

The memory bitmap it initially built in the first block of memory large
enough to hold it. When the bitmap has been configured, it is then moved
to a page-aligned location below the CCA.
If pages must be marked as bad before enough memory has been found to

hold the bitmap, some pages are retested after the bitmap has been built.
The bitmap shows, in addition to pages marked with hard errors, pages
marked as unusable because they are either the bitmap'’s own nages or
are CCA pages. A page is marked as unavailable when its corresponding
bitmap bit is cleared.

3-103

KNSSA/A interface Module

3.94

DWMBA Configuration
The console program performs minimal initialization of the DWMBAs
following self-test. The initialization performed for each DWMBA is:

The BI Starting Address Register (bb+20) and the Bl Ending Address
Register (bb+24) are initialized to the starting and ending limits of
XMI memory.

The BICSR (bb+04) has its Bl Broke bit cleared.

The DMA-B Transmit Buffer is disabled under thesz conditions:

The DWMBA/A module Device Register shows a revision less than
2

The system -ontains five or more XMI commanders and the
DWMBA/B module Device Register shows a revision of less than
0A (hex).

If a DWMBA/A module fails its self-test (us indicated by XBER<STF>), the
BP asserts its own XBER<XBAD5 bit to drive the XMI BAD L line.

3-104

KNSBA/A Interteace Module

3.9.5

Initialized State
In response to a reset, the KN58A/A interface tnodule is initialized to a
known hardware initialized state by external reset signals. If zelf-test

runs successfully, the state of the KNS8SA/A interface module is revised to
a firmware initialized state by the firmware. The firmware initislized state
is what the operating system uses as the initial state of the KINSSA/A
interface module when it starts. The hardware and firmware initial values
for the registers of the KN58A/A interface module are summarized in
Table 3-7.

Table 3-7
Register

KNSBA/A Intertace Module inklal Regleter States
Address

Hardware init

Flrenwsare inh

Kotz

CSR1

2000 0000

0000 0000

See footnote’

SSCBR

2014 0000

3€GCR

2014 0010

0000 0000

0160 A007

Bt<31> may be 1

CL .CR

2014 0020

0000 0000

0000 9000

{DAL timeout « 36.8 ms

CONSEL

2014 0030

0000 0000

0000 000C

¥ not boot processor

0000 000D

i boot processor

CSR1BADR

2014 0130

0000 0000

2000 0000

CSR1ADMR

2014 0134

0000 0000

EEBADR

2014 0140

0000 0000

2008 0000

EEADMR

2014 0144

0000 0000

0000 7FFC

XDEV

2180 0000

0000 0000

0000 8001

XBER

2180 0004

1000 0C"*

0000 00**

B1s<9:0> always contains the
tast commander ID and command
unigss an error occurs

XFADR

2180 0008

0000 0000

sree gnee

Aweays contains the last commande:
address unless an error occurs

XGPR

2180 000C

0000 0000

CSR2

2180 0010

0000 0000

'The state of CSR1

after power-up but before selt-iest s (in
binary):

T11X0 XOX0 3OOUX XOXX XXXK OXXX 1°°° ****
An astensk in a bit position indicates the state is determined by a signal from the backplane, such as the node
iD lines.

3-105

KNSSA/A Interface Module

3.9.6

Restarting or Bootstrapping the Operating System
The console can bootstrap a copy of the operating system for the R3000
from a tape or disk device. In maintenance mode, the console can also

bootstrap a copy of the VAX Diagnostic Supervisor (VAX/DS) from & VAX
formatted tape or ULTRIX formatted disk.

Only the primary processor can initiate a bootstrap. A secondary processor
never attempts to restart the operating system, but rather waits in a
halted state until the operating system passes a START command via the
console communications area (CCA).
396.1

Opereting Sysiem Restart
The primary processor attempts to start/restart the operating system
following a system reset, provided:
°

The front panel key switches are not set to the combination of Enable
and Halt.

The CVAX chip was not running when a power failure occurred.

If the "last chip” flag in SSC RAM indicates that the CVAX was running
when a power failure occurred, meintenance mode is entered. Otherwise,

the console places an “operating system restart” request code into SSC
RAM and passes control to the R3000 portion of the console program.

The R3000 portion of the console program controls the restart of the
operating system via a memory data structure called the restart parameter
block (RPB). The RPB, located at IIDAL physical address 0000 0400
(R3000 virtual address a000 0400), has the format shown in Figure 3-11.

Flgure 3-11

Restart Parameter Block Fermat

SIGNATURE " ATTERN (FEED FACE)

0000 0400

ADDRESS OF RESTART wOUTINE

0000 0404

RESTART OCCURRED FLAG

0000 0408

CHECKSUM OF 1ST 32 WORDS OF RESTART

0000 040C

START ADDRESS OF CONSOLE DATA

0000 0410

END ADDRESS OF CONSOLE DATA

0000 0414
meb-0567-90

3-106

KNSSA/A interface Module

The restart attempt will fail if the RPB is not valid or if the RPB's "restart
occurred” flag is already set. If a restart attempt fails, the system is
rebooted as specified by the default boot path.
39.6.2

Opereating System Bootstrap

The R3000 portion of the console code atiempts to bootstrap the operating
system whenever one of the following events occurs:

‘The frout pcnel key switch is in the Enabled position and the boot
command is typed on the console terminal.

The system is reset and the front panel key switch is in the Autostart

A rostart is attempted and fails.

position.

The console brings an operating system loader into memory using a

bootblock scheme and then assists the loader through use of the support
routines describec in Section 3.9.6.2.1 and Appendix A.

The boot devices supported are the KDB50 VAXBI disk adapter, the
TBK70 tape adapter, and the CIBCA-B VAXBI CI adapters.
The operating system boot process is as follows:

Determine the device to be booted from the boot command or take the
default boot device from the bootpath environment variable. Store
the information in SSC RAM.

If the boot was initiated by a boot command, set a "reset due to
bootstrap” flag in SSC RAM and reset the system. This causes an
initialization and self-test of all modules.

Open the boot device and read block zero. This is the bootblock and it
specifies the location of the operating system .oader. The format of the
bootblock is shown in Figure 3-12.

Read the sequence of blocks described by the bootblock into memory.

Call the loaded code at the start address found in the bootblock. Any
arguments supplied by the boot command are passed using the Clanguage argc/argv conventions. A pointer to the current environment
is also passed.

If any step in this process cannot be completed, the bootstrap fails and
the console prompt is displayed.

3-107

KN58A/A Interface Module

Figure 3-12

Bootblock Format

RESERVED
RESERVED

SIGNATURE PATTERN (FEED FACE)
BOOT BLOCK TYPE
PROGRAM LOAD ADDRESS
PROGRAM START ADDRESS
PROGRAM BLOCK COUNT
PROGRAM STARTING BLOCK ADDRESS
mab-0568
90

396.2.1

Bootstrap Support Routines In the Console

The ULTRIX bootstrap loader contains no code for performing 'O or
machine dependent operations ‘such as flushing cache). Instead, the
loader calls a set of routines provided by the console. The addresses of
these routines are obtained in a transfer vector located in console ROM at
address BOOA 0000. All routines are called as C-language routines using
standard R3000 eslling conventions.
The routines are of several types:

console - Invokes console programs for functions such as restarts and
reboots.

gaio - Provides basic IO support for stand-alone programs. Does not
support file structure processing or O to buffers in kuseg or kseg2.
Only one /0 adapter of each type can be active at a time

machine - Provides machine-specific functions such as interlocked

libc - Provides a subset of standerd C-language library functions

memory access and cache flushes.
{getenv, gsetjump, etc.’

parser - Provides access to console command parser.

command - Pr vides access to a subset of console commands.

The list of supported routines and their calling sequences is previded in
Appendix A

3-108

KNSSA/A interface Module

3.9.7

Console Use of Address Space
The R3000 portion of the console program reserves memory from physical
address 0000 0500 through 0000 FFFF (vigible via keegl as addresses
A0G00 0500 through A000 FFFF) for its own use. This space holds the
console program stack and static data structures.
Memory from physical address 0000 0000 through 0000 O4FF is shared

with the operating system and holds the restart parameter block and the

current exception handling code.
The console generally uses kseg2 addresses starting from address 0000

0000 to access physical addresses not visible from ksegl. These include all
addresses beyond 256 Mbytes of memory and all XMI YO adapter address
spaces. The console establishes translation lookaside buffer (TLB) entries
for the addresses it needs to map and restores the original contents of the
TLB entnes upon console exit.

3-109

KNSSA/A Interface Module

3.9.8

Bootstrap of the VAX Diagnostic Supervisor (VAX/DS)
The VAX Diagnostic Supervisor (VAX/DS) is booted by typing the KOOT
command at the maintenance mode prompt. The boot device must be in
VMS format or have a VMS format bootblock. The CVAX portion of the
console code handles all aspects of booting VAX/DS. Only the primary
processor can boot VAX/DS.
The console's first goal in booting VAX/DS is to load the primary bootstrap
program, VMB, into memory and begin its execution. VMB is loaded from
the device specified by the BOOT command. A set of minimal device
handler routines, called boot primitives, are used to read VMB from the
boot device, a technique called "bootblock” booting.
The console searches tables in EEPROM and ROM, in that order, to
locate a boot primitive that matches the specified device as the first
phase of bootstrap. If a suitable primitive is found, the target device
information is stored in SSC RAM. Then the console forces a system reset.

The system reset causes all processors, memories, and /O adapters to
perform self-test.

The second phase of bootstrap then begins. The console program is
reentered and determines (from values in SSC RAM) that the reentry
is part of a bootstrap operation. Boot parameters are passed from SSC

RAM to the CVAX GPRs, the boot primitive is again loaded, and control

passes to the boot primitive.

The boot devices supported are determined by the boot primitives stored
in EEPROM and ROM, and by devices supported in VMB. The KDB50
VAXBI disk adapter, the TBK70 tape adapter, and the CIBCA-B VAXBI CI
adapters are supported. The table in EEPROM allows new primitives to
be added as new devices are developed.

If the target device is a disk, the boot primitive loads logical block zero
(also called the bootblock) into memory and transfers control to it. The

bootblock contains code that specifies the location and size of the VMB
image on disk. If the target device is tape, the boot primitive skips any
tape labels and reads the first file from the tape into memory. Once VMB
has been loaded, the bootblock passes control to it. The boot primitive
must preserve the boot parameters stored in the GPRs.
The register conventions used by the bootblock program and the

conventions for passing parameters to VMB are described in the
paragraphs that follow.

3.9.8.1

Parameoters Pagsed to the Boot Primitive

The console code passes parameters to the boot primitive through the
GPRs. The boot primitive must preserve all the nonreserved registers

so that they can be passed to VMB. These parameters describe the boot
device and any bootstrap options to be used.

3~-110

KNSSAVA Interface Module

Teble 3-8 show how the registers are used.
Tebie 3-8

Boot Parameters Loaded into GPRe

Regloter

Bhe

Daeeription

GPRO

<7:0>

VIMB dovice type codae. supplied by the boot primitive

GPR1

<74>

Xl node number of the desired DWIMBA

<3:0»

VAXBI node number

<31:28>

When loading VIMB trom the system TK tape drive, the XMI
node aumbar of the DWIMBA controling the tape drve

<2724>

When kading VMB from the system TK tape drve, the
VAXBI node number of the tape adapter

GPR2

<150>

The remote (HSC) node numbars,

the BoovNoda qualter

was specihed

GPR3

Boot device unit nurmber

GPR4

Reservad, the LBN of the secondary bootstrap

GPR5

Software boot control tlags

GPR6

Used by the boot pnmave 1o pass information to the
bootblock program

GRP?

Physical address of the CCA

GPR8

Reserved

GPR9

Reserved

GPR10

The hatt PC

GPR11

The hah PSL

The hatt code

Used by boot primitive 1o pass information 1o the bootblock
program

The address of the 256-Kbyte block of good memory + 512

3111

KNSSA/A interface Module

398.2

Parameters Pagsed to the Bootblock Program
The parameters passed to the bootblock program are the same as those
passed to the boot primitive plus the contents of GPR6. GPRS has the
physical eddress of the read-block routine provided by the primitive. The
bootblock program must preserve all parameters except GPR6 so that they
can be passed to VMB.

39883

Paremeters Reguired by the Boot Primitive
When the bootblock pregram calls the read-block routine in the boot
primitive, it must supply the input parameters shown in Table 3-8 and
the output parameters shown in Table 3-10.
Table 3-2

Input Peramaters Required by the Boot Primitive

Bie

GPR1

XMi and VAXBI node numbers of the boot device, as passed by the
console code

GPR)
GPR8

Unit number of the boot device. as passed by the console code
LBN to be read or, d a tape drive using non-ANSI labeled tape. the length
of the black that was jus! read

Address of the data structures set in memory by the boot pnmitive when
a8 lirst invoked

Table 3-10

3984

Physical address to receive the transter

Output Parameters Required by the Boot Primitive

Bits

GPRO

S$S$_NORMAL d successtul, the low ba clears on etror

GPR7 through GPR10

May be modified

Conegliderations for Tape Drives
The boot primitive rewinds the tape before it performs the first read and
before transterring control to the loaded image.
The boot primitive checks the length of the first block read from the tape
If the block is 80 bytes long, the tape is assumed to be ANSI labeled
and VMB is assumed to be the first file on the tape. The boot primitive
then skips to the first tapemark, reads blocks into memory by storing
them, beginning at the address passed in the SP. Blocks are loaded until
a tapemark is encountered, and then control is passed to the first byte in
the loaded image.
If the first block of the tape is not 80 bytes long, the remaining contents of
the first file are loaded and control is transferred to the loaded image at
offset 12 from the base of good memory.

The read-block reutine also supports rewinding the tape. GPRO must
contain 10$_READPBLK for a read operation or IO$_REWIND for a
rewind. The read-block routine always reads the next block from the
tape and ignores any logical block number (LBN) passed in GPR8. GPR8
returns the length of the block just read.
3-112

KNSSA/A Interface Module

3.10

(Interprocessor Communication through the Console Program
Each CPU of a multiprocessor system must communiocate with
the other CPUs and the operating oystem. In the DECoystem
6800, interprocessor communication is handied by the KNEBA/A
interface module. This section describes interprocessor
communication.

The CVAX portion of the console program runs on each processor of a
multiprocessor DECaystem 5800. Thes2 copies of the console program
must be able to communicate with each other and with the operating
system.

When two processors needing to communicate are running, that is, not in

console mode, the communications take place using mechanisms provided
by the operating system. When one, or both, of the processors is in console
mode, communications take place using a shared data structure called the
console communications area (CCA).

There is no requirement for communication between multiple copies of
the R3000 portion of the console program, since the R3000 portion of the
console program runs on the primary processor only. The R3000 portion

of the console program, however, uses the CCA to communicate with the
CVAX portion of the console program running on a secondary processor. It
also uses the CCA to communicate with the operating system.
The primary processor controls the console terminal and, therefore, most
of the communication in the DECsystem 5800. There is no communication
between secondary processors.

3.10.1

Required Communications Paths
A processor can be in one of four communication states: a running primary
processor, a primary processor in console mode, a running secondary
processor, or a secondary processor in console mode. The following
communication paths are provided.
1

Running primary console to/from secondary console.

The operating system on the primary processor must send complete
console commands to the CVAX portion of the secondary console, such
as to start or stop the secondary processor. The secondary console
program must be able Lo zend responses (human readsble messages)
to the operating system on the primary, such as when the secondary

processor encounters an error halt. The secondary processor can send
these responses at any time.

The secondary processor does not send commands to the primary
processor, and the primary processor does not send responses to the
secondary processor.

3~113

KNSSA/A Interface Module

Primary console to/from secondary console requires two different types

of communication.

The CVAX or R3000 portion of the primary console sends complete
commands to the CVAX portion of the secondary, allowing the primary
console to update the copy of 8 parameter stored on a secondary
processor. An example of this type of communication is to synchronize
the console terminal baud rate whenever it is changed on the primary.
The CVAX portion of the secondary console sends complete responses
to the CVAX or R3000 portions of the primary console to report, for

example, a processor halt. Since responses arrive complete, there
are no interleavi ;g messages on the console terminal. The secondary
processor does not send commands, and the primary processor does not
send responses.

For intelligent 'O adapters only, the consoles support character-at-atime communications to implement the "Z" command, which transfers
characters to and from a secondary node so that the secondary
processor appears to be directly connected to the console terminal.
The primary processor gends single characters of 8 command to the
secondary processor. The receiving secondary processor performs all
the processing of the input characters, including echoing and line
editing. The secondary processor sends single characters of a response
to the primary processor for immediate display on the console terminal.
The "Z" command also extends to communication with VAXBI devices
and, potentially, to non-precessor XMI nodes.
3

Console mode primary processor to/from running secondary processor.
This path exists as a side effect of supporting responses from a
secondary console, but its use is reserved.

3-114

KNS8A/A interface Module

3.10.2

Console Communications Area
The Console Communications Area (CCA) is the shared data structure in
high physical memory used for communications between console programs.

It consists of a one-page header followed by a variable number of pages
containing buffers. The header contains status information that must
be visible systemwide. The buffers, used for passing messages between
processors, are allocated one set for each XMl node that could be in the
system.

The CCA is initialized by the primary (boot) processor at system reset.

It is allocated beginning on a page boundary from the highest addressed
page of system memory that can be located by the primary processor. The
header lies in the lowest addressed page of the CCA, followed by buffers.
The CCA is not initialized under any other console entry conditions (node
reset or halts). The address of the CCA is obtained from the console state
remaining in SSC RAM.
Diagnostic tests that must test or reconfigure memory could overwrite
the CCA. If this should happen, the diagnostic tesis must observe the
following conventions:

The diagnostic tests can only be run from the primary processor.
The diagnostic tests must force the secondary processors to stop polling
the CCA.

The diagnostic tests must rebuild the CCA after completing testing.
The secondary processors must wait for a signal passed through the
XGPR register before locating the new CCA.

3-115

KNSSA/A Interface Module

The location of the CCA is passed to CVAX code at bootstrap time through
VAX GPR?. The location of the CCA is passed to R3000 code at bootstrap
time via the cra environment variable.

During system initialization, each processor is triggered to search for the
CCA. This search starts at the highest addressed memory that can be
located by each processor and then works backward. If a processor cannot
locate the CCA, it enters an endless loop and cannot participate in the
system. The algorithm used by the console code to locate the existing CCA
is as follows:

If (next + CCASL_BASZ) <> next, then goto Step 7.

If (next + CCA$W _IDENT) <> "CC", then goto Step 7.

If next < 0, then "Failed to find CCA."

Next = highest memory address in system + 1 - 512.

Compute sum of bytes at (next) through (next + CCA$B_CHKSUM - 1)
ignoring overflow.

If sum = (next + CCA$B_CHKSUM), then "Exit with CCA found at
next.”

Next = next - 512.

Goto Step 2.

The overall layout of the CCA is shown in Figure 3-13 and Figure 3-14.
The contents of the fields are described in Table 3-11.

3-116

KNS8A/A Interface Module

Flgure 3-13

CCA Layout, Pent 1

OFFSET

(HEX)

CCASL_BASE
C° $W_IDENT
REVISION|

CCASW_SIZE

HFLAG

CHKSUM | WNPROC

CCASQ_READY
CCA%Q_CONSOLE
CCASQ_ENABLED
CCASL_BITMAP_SZ

CCASW SERIALNUM® | TKS0_NODE

CCASQ_SECSTART

CCASQ_USER_HALTED
CCASQ_SERIALNUM
CCASQ_HW_REVISION

¢
&

RESERVED

BAUD RATE

RESERVED

CCASQ_RESTARTIP

RESERVED

CCASL_BITMAP_CKSUM

3§

CCASL_BITMAP

(16 QUADWORDS)

msb-0576-80

3117

KNSBA/A Interface Module

Figure 3-14

CCA Layout, Part 2

OFFSET

(HEX)

CCASQ_HW_REVISION1

{16 QUADWORDS)

RESERVED

164

1FC

CCASQ BUFFERO

(BUFFERS FOR PROCESSOR AT XMi NODE 0)

CCASQ BUFFER?2

(BUFFERS FOR PROCESSOR AT XMI NODE 2)

msb-0577-80

3-118

KNSSA/A interface Module

Table 3-11

CCA Flsids

Flatd

Dosoription

CCASL_BASE

Physical address of the base of the CCA.

CCASW_SIZE

The size, in bytes, of the CCA, usually 3200.

CCAjW_IDENT

The ASCH characters “CC".

CCA$B_NPROC

The number of procassors suppored by the CCA, usually 16.

CGASB_CHKSUM

Checksum of the first CCASB_CHKSUM-1 bytes of the CCA. Computed by doing
signed, byte addition, ignoring any overtiow.

CCASB_HFLAGS

Systemwide status flags:

L— ccasv_sooTmie
CCASV_USE_ICACHE
CCA3V_USE_ECACHE
CCASV_ECACHE_CLEARABLE

RESERVED
CCASV_REPROMPT
CCASV_TERM_CRT
RESERVED

CCASV_BOOTIP

478 50

Whaen set, a bootstrap is being atterapted. This prevents
repeated attempts to bootsirap after a tailure

CCA$V_USE_
ICACHE

Whaen set, the CVAX chip interna! cache 15 1o be enabied by
the oparating system.

CCASV_USE_

When se!, the second-leve! cache 15 {0 be enabled by the

ECACHE

oparatng system

CCASV_ECACHE_
CLEARABLE

When sel, the second-level cache clear operation can be

CCASV_REPROMPT

used successfully. Some operaling System error recovery is
ngede to clgar the cache
This bit 1s used internally by the consolg to sugport the SET
CPU command.

CCASV_TERM_CRT

When sst, the console terminal is a CRY.

CCA$B_REVISION

The revision number for the CCA.

CCA$Q_READY

A bitmask of the procassors thal have data posted in their transmit bufter for
processing by the primary processor. The bis and nodes are numbered, slaming
with 2er0.

C:CASQ_CONS(E

A bitmask ndicating the processors known to ba in console mode. The appropnate bnt
is set and cleared by each processor as ¢ enters and isavaes console mode.

CCA$Q_ENABLED

A bimask indicating which processors are enabled to leave console mode. A

processor sels or clears s bit duning console intialization, based on a bit stored
in EEPROM.

CCASL_BITMAP_SZ

Tra size, in bytes, of the physical memory bitmap. The bitmap is alwavs an even
number of longwords in length.

3-119

KNSSA/A interface Module

Tabls 3-11 (Cont.)

CCA Figids

rlold

CCASL_BITMAP

Daseription

The physical address of the physical memory bémay. The bitmap contains one bit

for @ach page of physical memory present on the system. The bit is clear if the page

contains a hard error or it the page is in use by the bitmap or CCA. The bitmap is
glways page aligned.

CCASL_BITMAP_

Reserved; not used.

CCASW_SERIALMUM1

First two characters of the system serial number. Concatenated with CCASQ_

CKSUM

SERIALNUM.

CCA$B_TKS50_NODE

Reserved. not used.

CCA$Q_SECSTART

Reserved; not used.

CCA$Q_RESTARTIP

Reserved; not used.

CCASB_BAUD_RATE

The SSC b1t value for the current console b~vJ rate.

CCA$Q_USER_HALTED

A bitmask indicating which processors enterea corsole mode as a result of user
intervention (CTRLP or STOP command). This information aliows the operating sytem
to make decisions about timeouts in @ symmetric multiprocessing configuration.

CCASQ_SERIALNUM

The last eight characters of the system serial number. Concatenated with CCASW_
SERIALNUM?Y.

CCASQ_HW_REVISION

Conssts of a 16-quadword array contamming the chip and module revision iormation
for the processors. Module revisions are an ASCIl string; chip revisions onsist of two
digts with an imphed decimal point. The layout of this quadwor? s
OFFSET
(HEX)

COM_GRP

|RESERVED]

SSC REV

CVAX REV

MODULE REVISION

80
mgp-0582

The layout of the COM_GRP byte s
76

082

|
.

l———— CCASV_COM_GRP
CCA$V_COPR
CCASV_WDIE

CCASV_MDIE

80
D057

Whan set. this non-boo! Processor receives imerrupts i this
b s Jear, merrupis are directed only to the boot processor

3-120

KNSSA/A Interface Module

Teble 3-11 (Cont.)

Flatg

CCA Fleide

Deucription

CCASV_COPR

Whaen set, this b indicates that the procsasor can cotrectly
periorm a passive release on an inferupt acknowiadge cycle.

H tius bit 18 cloar, data corrupton reavits from perormming a
pasuve release.

CCASY_COM_GRP

This binary held is used by the oparating system 10 determine
@ all processors in the gystem are hardware compatible. Any

processors
not in the same group as the boot processot are
nhibitad {rom slarting.

CCaSQ_HW_
REVISION1

Consists of an array of 16 quadwords, one for each system node. For nodes with
processors, the first longword contains the contents of the R3000 Processor Revison
ID register The second longword contans the console ROM version (ngh word) and

consoie EEPROM patch lgvel (loft word)

The CCA contains a buffer area for each possible XMI node. Each buffer
area contains fields to support both message oriented and character-at-atime corimunications.

The address of the buffer erea for XMI node n is given by:
Buffern = Base address of CCA + 512 + (n ® 168)
The layout of the buffer area is shown in Figure 3-15, and the contents of
the field are described in Table 3-12.

Figure 3-15

Layout of XM Node Buffers

OFFSET
(HEX)

RESERVED | RESERVED| CCA$8 ZDEST| CCASB FLAGS

RESERVED

CCASB RXLEN| CCAYD THLEN

04
o8

86BVTES)
58

(86BVTES
AB
meb-0581.60

3-121

KNSBA/A Interface Module

Table 3-12

Butfer Flglds

Flold

Dascription

CCASB_FLAGS

Status flags:

L: CCASV_RXRDY
CCASV_ZDEST
RESERVED
CCASV_2ALT

RESERVED

CCASV_RXRDY

0580.60

When set, there 1s a complete message in the CCAST_RX
buffer. The equivalent bit for CCAST_TX is in CCASQ_READY
of the CCA header.

CCAS$V_ZDEST

CCASV_ZALT

When sat, this node 1s serding “Z° command data to the node
hsted in CCA$B_ZDEST.

When sat, the target of the current *Z" command cannot

commuricate through the CCA. The target 15 ether a nonprocassor XMI node or a VAXBI node and must be accessed
using alternate RXCD protocol, as descrbed in the VAXB/
System Reference Manual.

CCA$B_ZDEST

Whan CCASV_ZDEST 15 set. this fisld contains the XM! node number of the node
recewing the “Z° command daia that this node 1s sending H the low four bis of this fieid

dentity a node that is a DWMBA. the high order four bits contain the destination VAXBI
nogde number

CCASB_TXLEN

#f the b corresponding to this node is set n CCASQ_READY, then this field contains the
length, 1n bytes, of the message in CCAST_TX

CCASB_RXLEN

# CCASV_RXRDY 15 set n CCASQ_READY, then this field contains the length, in bytes,
of the message in CCAST_RX.

CCAST_TX

Thes bufier 1s used by the node 1o transmit a response to the pnmary processor Only
tesponse data 1s passed through this buffer since a secondary processor does not send
commands to the primary processor

CCAST_RX

This butfer 1s used by the node to receive a command from the primary processor. Only
command data 1s passed through this bufiar since a secondary processor doss not
receive responses from the primary processor.

3-122

KNSBA/A Interface Module

3.10.3

Sending a Message to Another Processor
The following two examples show how the CCA is manipulated when a
complete message iz sent between two processors.
For the first example, the primary processor, located at XMI node 1, sends
a START command to the secondary processor, located at XMI node 3.
1

Node 1 examines the CCA$V_RXRDY bit in the CCA buffer area for
node 3. If the bit is clear, then go to Step 3.

Node 1 polls the bit until it clears or until a timeout of 12 seconds is
reached. If a timeout occurs, an error is reported.

Node 1 moves the text of the START command into the CCAS$T_RX
buffer for node 3.

Node 1 sets the length of the command into the CCA$B_RXLEN field
for node 3.

Node 1 sets the CCASV_RXRDY bit for node 3 to indicate that a
command is waiting.

Whenever node 3 enters its main console loop, it will eventually check
for commands to execute. It will examine its local commangd buffer and
then check its CCASV_RXRDY bit for a command from another node.

Node 3 will now process the command contained in its CCAS$T_RX
buffer.

After reading the command, node 3 then clears its CCA$V_RXRDY bit,
indicating that the buffer is again available.

3-123

KNS8A/A interface Module

For the second example, the secondary processor, which is located at XMl
node 3, halts, enters console mode, and sends a "halted" measage to the

primary processor, located at XMI node 1.

Node 3 moves the text of its response into its CCA$T_TX buffer.

Node 3 sets the length of the response in its CCA$SB_TXLEN field.

Node 3 polls this bit until it clears.

Node 3 examines bit 3 of the CCA$Q_READY field. If the bit 1s clear,
then go to Step 3.

Node 3 sets bit 3 in CCA$Q_READY to indicates that a response is
waiting.

Node 3 issues an IVINTR interrupt to node 1. If node 1 is running,
this alerts the operating system that a response is waiting. Node 3
polls CCA$Q_READY until bit 3 clears or until a timeout of 60 seconds
expires, preventing the secondary node from performing any action

that might cause the response to be los{ before the primary can display
it.

If node 1 is running, it responds to the IVINTR and eventually checks
for console responses. If node 1 was in console mode, it would be
poling CCA$Q_READY and discover bit 3 set.

Node 1 (either the operating system or the console code) processes the
response from the CCAST_TX buffer for node 3. If the console code is

running, it displays the response on the console terminal.
Node 1 clea s bit 3 in CCA$Q_READY, indicating that the buffer is
again available.

3-124

KNSBA/A interface Module

KNS8A/A Interface Module Errofi-landllng
Thie section describes the error handling features of the KNESBAVA
interface module.

The KN58A/A interface module hardware provides automatic reattempts
of many XMI bus transfer failures:

Ali XMl command/address transfers are resttempted until

acknowledged or a transaction timeout occurs (when XBER<13>
(TTO) asserts).

All XMI write transactions are reattempted until scknowledged or a
transaction timeout occurs.

All second-level cache errors are "soft” and are signaled by asserting INT3

to the R3000. KN58A/A interface module hardware automatically disables
the second-level cache following a cache error that has the potential to
leave the second-level cache incoherent, such as tag or valid bit parity
errors on a write-through. Any errors that leave the second-level cache
incoherent also leave the first-level cache incoherent.

All XMI memory reads are “connected’; the R3000 waits for the data to
be returned and, if it cannot be delivered from the XMI, an error flag
is returned to the R3000 resuiting in a bus error exception. A memory

read "hit” in the active XCPGA rite buffer causes the write buffer to be
purged. If the purge results in an XMI memory write failure, the read is
suppressed and a bus error flag is returned to the R3060.

All XMI memory writes are "disconnects.” They are acknowledged by the
XMI interface and data is placed in the XCPGA write huffer to be written
later. If a subsequent write buffer unload or purge results in an XM! write
failure, it is signaled to the CPU by posting an INTS interrupt. These
ervors are considered hard.
All XMI 1O reads and writes are "connected’; they cause purging of the
XCPGA write buffer prior to their initiation on the XMl and they are not
acknowledged until all XMI transactions are successfully completed. If

the XCPGA write buffer purge results in an XMI memory write failure,
the L/O transaction is suppressed and a bus error flag is returned to the

R3000. If the XCPGA write buffer purge is successful but the sul.sequent

/O transaction fails, the R3000 is released with a bus error flag for reads

or an INT3 interrupt for writes.

For error handling purposes, XMI IVINTR transactions are treated as /O
WTites.

For error handling purposes, XMI IDENT transactions are treated as

I/O reads except that errors are reported with an INT3 interrupt, since a
bus error flag during an Interrupt Acknowledge cycle is interpreted as a
passive release.

3-125

KNSBA/A interface Module

The XMI interface maintains complete error status on a failed XMI
transaction that was initiated by its node. Thic status includes the failed
command, commander ID, address, and an error bit that indicates the type
of error that had occurred. This status remains locked-up until software
resets the error bit(s).

IIDAL parity errors cause bad data and parity to be stored in second-level
cache on cache fills. On writes, the XMI write is suppressed and the data
is discarded if a parity error is detected. An INT3 interrupt to the R3000
signals the error.

3.11.1

Psrity Generation and Checking for Error Detection
Parity generation and check characteristics of the KN58A/A interface
module follows:

The KN5SA/B CPU module generates parity on write data. The
KN58A/B CPU module does not generate parity on command/address
data.

The first-level cache supports parity on the tag bits, valid bits, and
data store. On cache fills and writes, parity is stored and then checked
by the processor on reads.

The second-level cache supports parity cn the tag bits, valid bits, and
data store. On second-level cache fills and writes, parity is stored and
then checked by the KN5B8A/A interface module on reads.

The XCPGA detects IIDAL parity errors on writes.

The XMI supports three parity bits covering both data and command
information. The KN58A/A interface module generates and checks
XMl parity.

3.11.2

The R3010 FPA does not generate or check parnity.

Since the SSC does not support parity, the internal battery-backed-up
1 Kbyte of RAM and the internal registers are not protected.

CSR1 and CSR2 are not parity protected.

Error interrupt Service Routines
Interrupt service routines use the following sequence when an error
occurs:

3-126

Read XBER to determine the type of error.

If XBER<ES> is set, then find more specific error information in CSR2.

Service the error condition. In many cases, the second-level cache

Clear only the individual error bits that were serviced after the error
condition has been handled. All error bits are write-one-to-clear.

must be flushed as described in Section 3.6.2.

KNSBA/A interface Module

Read XBER to ensure that no new ervors have been detected. A new

error condition cannot generate @ new interrupt unless all other error
bits are clear, since the INT3 interrupt line is edge-sensitive. If this

read indicates that no error bits are set, then exit the interrupt service

routine; else loop to step °.

3-127

KNSBA/A Interface Module

3.11.3

KNS8A/A interface Module Error Matrix
Teble 3-13

ERect en

Reforanos
by
RAeat

Second-Level Cache Date Parity Erors
Re
Enpoution

-~ INT)

Efacton

ERatt en

we-love
Cottw

Sra-loved
[« ]

Duaabies

Geaet

on Wain
oty
-

Bver tnilipadon

C8R2¢31 30>

COPE

C3A1<FIAISS> oot

Wreo

Read-Loch

Alzeys matm 2nd Leve: Cacto

Undoch Wree

Nax Appicadio

DENY

Akzays Mmeasas v Lewet Cache

g Love’

Partly a0t chatheg Gunng 2nd-Lewe! Cache 1o

NT3

Daadeo

C8R2¢3' 30>

COPE

Cahe Fu

181-Love!
Cacho Fu

CS5A1cFRISS> oot

Taeble 3-14

Second-Level Cache Tag/Valid BRt Parity Erors
Efact on

Eaet on

Emect en

Retorenc
Tyee

220
Erooudion

etdovet
Cogha

fnddovel
Cecdw

"o iain
tmory

Esver indication

]

Rego

NT3

Daatied

CSR2<3' 20>

TPEVPE

CSR
1 «F MISS> et

Wrre

Distibign

CSR2¢31 30>

TPENVPE

CSR1<FISS> g

Reas Locw

Aways miasss 2na Love' Cache

Unioth W te

INT3

Disatvos

CSR2<31 30>

YPENPE

CSR1«FMISS» sot
IDENT

Ays mepsea 2nd-Leve! Cacne

2nd Love:

Paty creoet o Read

INTI

Duabiec

CS5R2<3' 30»
CSRIFMISS> s

TPENPE

Cacho Fur

fe-lowval Cacne
Fit

3-128

KNS8A/A Interface Module

Teble 3-15

XAl Bus Timeowt Errors
Edocy on

et on

et en

Erlpet

Reloronm
e

R00
Emagion

wtdlawl
Cothae

Engdovl
Catto

en Bsin
Ezmery

Emrer txizngan

Read

BUS ERR

KBER«RRR> eai

16 7ma Timer - XM

KEER«TTO» c@

Reomp 10

10 T Tierer - NXES
Ragsarpn 10

XFADR«<3! I

M Feting AdLon

wWreo

INT3

HEER«TTOnom
RFADA+31 O

Raxo-Loth

BUS ERR

HBER<NRR» ot
KBER<TTOn ot
KFADR<3' 0>

Unigth Wree

NT3

XBE R« TTOx001

16 7w Timgr - NRW

HFADR<I1 D

Regtompt 10

1 Foling AdiLen

18 Yo Timer - XN
Raanaerer 10
XM Fafing AdrLon

M) Fasng AdeLen

DENT

29 Levd'

Cacne Fuil

iNT3

INTI

1sieweCache

=000

Sub-Blooe No

Vasdaleo

e e

HBER<NRR> oet

18 7me Timyr

HBER«TTO» eat

Reamompt 10

XFADR<31 0>

Xib! Fgting Adr en

CSR2CFE> ot

Cacho F il Error

XBER<TTO» san
NFADR<31 0>

Raaempt 10
UM Fadng AdiLen

HBER<NAR) st

10.7me Temr

NEW

NXM

e No MM! Trgraachon Gongrited — — — — — — — —

Table 3-16

XAl Bus Parity Errors
Eitect on

ENpet on

ERact on

ERpet

Reference
Type

R2000
Esoaution

atdavol
Cache

nd-Lovel
Cache

on tan
tzmory

Reao

INT3

Sub-Bcs Not
Vakaxted

Wrie

Rasa Locn

INT3

Emror inication

Hiowo

NBEAPE> 00!
RFADR<I' O>

NAR. Sec £ coulo 880 80!
X Faing A0 Len

Party not checkes’

HBERPE> 0ot

NRA. 8sq Err could ano cot

XFADR<3' 0>

X4t Faang Adrion

Uniock Wrie

Party not chacnes’

IDEN"

iNT3

HBE RePE» 601

NRA Seq
Er could ao oot

XFADR(I' 0>

Kidi Fauing Ao

NBER«PE> oo
EFADR

NRA Seq Er ooud aiso oot
1 Faiting AgrLon

2n0- Love!
Cazhe Fu

INT3

slowiCache

=000

Sub-Block Not
vabdates
e

't 2 bus party efror oocurs on a write data cycle, the responder NOACKs all subsequent data cycles and the
commander reattempls the transaction.

3-129

KNSSA/A Interface Module

Table 3-17

Main Memory Correctable Ervors
Efoct en

Bzt on

ERoet on

Eplpcr

Ratoranca
oo

55
Ezpaaion

totdovel
Cadra

Snddlovl
Cacho

on Gndn
Ciomery

Gwer tnization

Catzn

Reao

Corvecod Ot

Supplon

RBE R<CRD> et

Cerroneed Rozd Dae

Weitton

Corecied
Dais

wrie

Mot ARDhnsdG

Rga- Lock

iNT3

Suppims

XBE R<CRD> et

Comexted Ress Data

Comecied

Oate
UNOTh Wred

ot Applest

IDENT

N Agpiicabi

ond-Leve’
Cahe Fut

INT3

Corectett Dalz
Wrtngn

Suppias
Correcs

HBER«CRD> e

Corected Read Dmta

wievw Cacde

000000

e e e

Oeta

e = %o X! Trarpacton Gongegh) — — — — ~ — — —

Fai

Table 3-18

Maln Memory Uncorreciable Errors
E€zet on

Etoct on

ERpet on

Esiact

Rufe-anoe
Type

RIO00
Exscuion

tidoval
Coache

g dovel
Cache

en Mzin
omory

Emor tndizolion

Read

BUS ERR

Suppios
Unoorr sttt

KBERCRER> pot
KBER<RSE soa

Resd Ervv Responte
Raad Ssquence Erro’

Wre

Not Appicide

R@ag Locn

BuS ERA

Supdios

XBER<RER> oo

Raso Ermy Response

Oaia

Unoomeces

RBER<ASE »ax

Rasd Saquance Error

Oata
Uniotn Wrte

DENT

NT3

Supnima
Unconeoted

Yot Appixabm

KBERCAER> ot
XBERCRSE rua

Road Ermy Rgsponas
Road Sequance €.o

NBERCRER> ot

Reoad Erev Reaponse

CSR2«CFE> st

Cache Ful Error

Oata

ng-L.ove

Catho F o
wiewCache
Eir

3-130

NT3

Suppios

Unooneceo
Data

=000

e e

XBERASE rodt

e —m = - No X Tragaoton Gongrated

Resd Bequonoe Error

PEEHE GNPSOS EP 0 08 000800600268088080008¢8880800
081
NEROOOOOONGC
X XX CGGGEOOOAOGOGHN
A XXX KGO KX KX
KRRXaG00C0CooO00NOO000KOECOOIN
KR KR KX KX KN L EXX
PO RGN0 E

0T 0000000000 000000 000080986 000868 03

PO000000600000
00.068 6004088008 08000¢86848804!
[i019:¢.0.0.0008.0.609.0
0880800008 ¢0860¢0085880604]

0006000060000 0600000000000 688090.8808¢8,
P90.0.0.0.6.860.0.0.0.0.0.60.0.0¢.6900¢00.6 6000868684
XXX
X KOG00000X
fO G0 8.80.0.6.00.0 85000008008 ¢88004844 04
b 0160880050008 88460888060¢000464044

B O.0.0.0.6.0.8.000.000 06000004000 00401
PO 000000 080006000808 +8004004
fO.48.0.6.0.0.0.8:0.0.6.0.0408080¢080¢84
1.0.6.6.6.9.00.0.0.6 6849006680404
D 9,6.6.4.0.0.80.0.4,46 88880460484
0.8:0.0:0.0/0.0.9.6.4.0.0.¢.60644

.0.60.9.0.08.0.6096.06.400¢
. 0.0.4.9.:8.0.6.0.0.0,9.0.¢.4
p.6.9:0.:0.9.9.8.4.0.0.¢4.84
h0.9.8.9.3.0,6:0.6
6.4

.4.0.9.9.9.9,0.9.4
b18.0.4.4.0.04

HWUUXK
XX
X

UXX

AXAKK
HXAXKXXK

XHAAKUXKRX
XUXEXKXXXAUX

19.$.0.9.0.9.4.0.994
¢4
1 9. 4.9.4.0.8.49.¢64¢8¢4
EXXHKARKEXXKAXKAXK

pO.9.5.950.0.466 408840404
b00.6.0.0.0.0.9.6.48:4.04¢908.84
HAXAARKK
KK HHXKHANKANKAK

KAXAXRXKURK
UK A KA KR UK KX LXK
p 840008809000.88844890940¢044

PO 0 006080008008
8808 08008400401
b0.9.4.0.4.0.6.0.6.0.40.4,6.0.6.0.90 008085064844
P06 06008 0004008048600.8800060:040
¢804
DOV

DI 00430000 800.00484848080040044

P O.0.0.0 0000008 6.9 0068084 8480.0006089¢0494
P90 0000000008 00000080084606808
800400¢40

DO90086940008
00600 000008040068 980800898940:
P00 484008208600 9809060960900.406806480604¢8¢874
PO S 0000040800400
80008900000 08860098980¢04¢8¢044
1 9.9.0.6.085086404.9008.000060986800008¢9 8989008809028
§0000998668008
80088008 808600888 8889.994880¢890.9904

1 9.9.9.0.0.0.69.98108008000086000
0800090800080 8048065887 ¢810909

KN58A/B CPU Module

This chapter describes the KN58A/B CPU module, the module ihat
provides the computational power of the KN58A processor. The KN68A/B

CPU module is based on the MIPS! R3000: a 32-bit, virtusl memory
Reduced Instruction Set Computer (RISC) microprocessor.

This chapter includes the following sections:
e

Module Features

R3000 CPU

R3010 FPA

R3020 Write Buffers

First-Level Cache Memory

Interface Logic

! MIPS 1s a registered trademark of MIPSCO, Inc

4-1

KNSSA/B CPU Module

KN58A/B CPU Module Features
The KNSSA/B CPU module is based on the 32-bit, virtual memory
MIPS R3000 RISC microprocessor and ita R3010 floating-point
coprocessor. Up to four KN6SA/B CPU modules can be installed
in a DECsystem 5800, each of which must be accompanied by a
KNBGSA/A interface module.

Figure 4-1

KNSBA/B CPU Module Block Diagram

RDAL<31 00>, RDALP<03 00>

CPU

ingtruchon

Data

R3010

R3000

FPA

Cache

Ceche

Tag and Address Bus

Read Data

Write

Bu;tem

Read Adgdress
Data

Address
inlgrtace Logic

4-2

ToFrom HDAL bus on KNSSA/A intartace Module
Via Backplane Connectors

mud-0880
90

KNS8A/B CPU Module

The KN58A/B CPU module includes the following:
e

The MIPS R3000 CPU chip, which features:

—

Full 32-bit operation. The R3000 contains thirty-two 32-bit
registers. All instructions and addresses are 32 bits in length.

Efficient pipelining. The R3000 5-stage pipeline helps achieve an
execution rate of close to one instruction per cycle. Pipeline stalis
and exceptional events are handled efficiently.

On-chip cache control. The R3000 contains a high bandwidth cache
memory interface that handles transactions with the external
Instruction and Data caches. Both Instruction and Data caches are
accessed during a single CPU cycle.

On-chip memory management. The R3000 contains a memory

management unit (MMU) that supports a 4-Gbyte virtual address
space. The MMU has a fully associative 64-entry Translation
Lookaside Buffer (TLB) designed for multitasking operating
system environments and provides fast virtual-to-physical addrestranslation.

-~
¢

Coprocessor interface. The R3000 generates al! addresses and

handles memory interface control for the R3010 FPA coprocessor.

The MIPS R3010 FPA coprocessor, which adds floating-point
instructions to the CPU’s base instruction set. It has sixteen 64-bit
registers dedicated to floating-point operations and conforms to the
IEEE 754-1985 standard. It supports single- (32-bit) and double(64-bit) precision floating-point operations.

A firet-level cache, which consists of a 64-Kbyte instruction cache
and a 64-Kbyte data cache, implemented as an array of 28 16-Kbyte
x 4 data RAMs. Both caches are direct-mapped. The data cache is
"allocate on write.” Both caches are filled in increments of 8-word
blocks and have as a line size one 32-bit word. Both caches contain tag
and parity information. An invalidate FIFO for the data cache aids in
the maintenance of first-level cache coherency.

Write buffers, which enhance the performance of the R3000 CPU
chip by allowing the chip to perform write operations during CPU run
cycles. There is one write buffer implemented in four R3020 write
buffer chips. This provides four-deep buffering of 32 bits of address
and 36 bits of data and panity.

Interface logic (including a read buffer for data from the module),
which provides the means by which the KN58A/B CPU module
communicates with the KN58A/A interface module. The interface
logic provides the KN58A/B CPU module access to the secondary
cache, the system support chip (SSC), and the XMI corner on the
KN58A/A interface module.

Each of these major portions of the KN58A/B CPU module is explained in

the secticns that follow.

KNSsA/B CPU Module

R3000CPU
The KNESA/B CPU module is based on the R3000 CPU chip. The
module implements the entire R3000 instruction eet, data types,
and memory management. These are outlined in the sections that
follow. Detailed information can be found in M/PS R2000 RISC
Architecture.

R3000 Registers
Figure -2

R3000 Registers

General- Purpose Regsters
k3]

Multiply/ Divids Repistars
k3

{

—

4.2.1

[

<>
o

Program Counter

R29
R30

0
PC

R31

md-0400-09

As shown in Figure 4-2, the R3000 registers consist of 32 32-bit generalpurpose registers, a 32-bit program counter, and two 32-bit registers that
hold the results of multiply and divide operations. The contents of these
registers define the state of the CPU.
The functions traditionally associated with a processor status word (PSW)
are provided by the Status Register and Cause Register. These registers
are part of Coprocessor 0 snd are explained in Section 4.2.2.

KNSSA/B CPU Module

4.2.2

Coprocessor 0 (CPQ0) Registers
Coprocessor 0 (CIP0) is contained on the R3000 chip. It is tightly coupled
with the R3000 and performs memory management and exception
handling. Virtual memory is implemented with a Translation Lookaside
Buffer and the group of programmable registers listed in Table 4-1 and
detailed in the pages that follow.

Teble 4-1

Coprocessor
0 Reglsters

Doscription

EntryH

High hali of a TLB entry

Entrylo

Low half of a TLB entry

index

Programmable powster into the TLB array

Random

Pseudo-random pointar into the TLB array

Status

Mode, interrupt enables, and diagnostic status information

Cause

indicates nature of last exception

EPC

Exception Program Counter

Context

Pointer into kernel's virtual Page Table Entry array

BadVAdar

Most recent bad vinual address

PRid

Processor Revision Identifier Register

KNSS8A/B CPU Module Registers
TLB EntryHl Reglster (Entryil)

TLB EntryHi Register (EntryHi)
The EntryHi and EntryLo registers provide the data pathway through which
the TLB is accessed. When address transiation exceptions occur, these

registers are loaded with relevant information about the address that caused
the excaplion. The registers are also used to build a new TLB entry using
the tibwi and tibwr instructions. The format of an EntryHi/EmryLo register pair

is the same as that of a TLB entry. EntryHi comtains the upper halt of a TLB
entry.

ADDRESS

EntryHi (R3000)
Virnal Page Number

bits<63:44>

Name

Virtual Page Number

Mnemonkc

VPN

Type

PiD

ojojojojoi0

This field contains bits <31:12> of virtual address.

bits<43:38>

Mame

Process ID

Mnemonc.

PID

Type:

RWw

This 15 an 8-bit field that lets multiple processes share the TLB while
each process has a distinct mapping of otherwise identical virtual page
numbers.

bits<37:32>

Name.

Reserved

Mnemonic:

None

Type

RW, 0

Reserved, must be zero.

4-6

KNSSA/B CPU Module Regilsters
TLB EntryLo Register (Entrylo)

TLB EntryLo Register (EntrylLo)
The EntryHi and EntryLo regisiers provide the data pathway through which
the TLB is accessed. When addregs transiation exceplions oocur, these
registers are loaded with relevant information about the address that caused

the exception. The regisiers are aiso used to build a new TLB entry using
the tibwi and tlbwr instructions. The format of an EntryHi/EntryLo register pair
is the same as that of a TLB entry. EntryLo contains the lower half of 2 TLB
entry.

ADDRESS

EntryLo (R3000)
Page Frame Number

bits<31:12>

Name

Page Frame Number

Mnemcnic:

PFN

Type

n|o|v{s|o]o[o}o]o]o]s]o

This field contains bits <31:12> of the physical address. The R3000
maps a virtual page to the PFN.

bit<ii>

Name

Non-cachable

Mnemonic:

Type:

If this bit is set, the page is marked as non-cachable and the R3000
directly accesses main memory instead of first accessing cache.

bit<10>

Name

Ourty

Mnemonc

Type:

If thig bit is set, the page is marked as writahle. This is a "write
protect” bit that software can use to prevent slteration of data. If
a write is attempted on an entry with the D bit cleared, the R3000
causes a TLB Mod trap and the TLB entry is not modified.

4-7

KN58A/B CPU Module Registers
TLB EntryLo Register (EntrylLo)

bit<®>

Name-

Vald

fdnemonic:

Type:

e
S
NS R
I

If this bit is set, the TLB entry is valid. Otherwise, a TLBL or TLBS
Miss occurs.

bit<8>

Name:

Global

Mnemonic.

Type:

If this bit is set, the R3000 ignores the PID match requirement for

velid translation. In kseg2, the Global bit lets the kernel access all
mapped data without requiring it to save or restore Process 1D values.

‘

bits<7:0>

Name:

Reserved

Mnemonic:

None

Type

RW, 0

Reserved; must be zero.

KNSSA/B CPU Module Registers
TLB Index Reglster (index)

TLB index Register (Index)
The TLB index Register is a 32-bit, read/write register. it contains 6 bits that
index an enry in the TLB. The high-order bit of the register ghows the success

or failure of a TLB Probe (libp) instruction. The register aiso specifies the TLB
entry that wiil be affected by the TLB Read (iibr) and TLB Write Index (tibwi)
instructions.

ADDRESS

Index (R3000)
plojofofo[o]o|o]
o] oo]o]o]o]o[o]ofo]

bit<31>

Name:

Probe failure

Mnemonc:

Type.

msex

Jofo]o]ofo]o]o]o

Set to one if the last TLB Probe instruction was unsuccessful.

bits<30:14>

Name:

Reserved

Mnemonc:

None

Type.

Reserved; must be zero.

bits<13:8>

Name:

index

Mnemonic:

Index

Type:

Index to the TLB entry that will be affected by the TLB Read and TLB
Write instructions.

bits<7:0>

Namy:

Reserved

icainonic.

None

Tvpe:

Reserved; must be zero.

KN58A/B8 CPU Module Reglsters
TLB Rendom Reglster (Random)

TLB Random Register (Random)
The TLB Random Register contains a 6-bit Random field that indaxes a

random entry in the TLB. The value of the fieid ranges from 8 to 63. The field

is initiglized to 63 when the R3000 is reset and is decremented eévery machine
cycle. The value of the field wraps back around to 63 when 8 is decremented.

ADDRESS

Random (R3000)
3

bitg<31:14>

Name

»?

Reserved

fnemonic:

None

Type:

Reserved; must be zero.

bits<13:8>

Name:

Random

Mnemonic.

Random

Type

A random index (with a value ranging from 8 to 63) to a TLB entry.

bits<7:0>

Name

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

4-10

KNSBA/B CPU Module Registers
R3000 Status Register (Status)

R3000 Status Register (Status)
The R3000 Status Register contains all major status bits tor the R3000.

ADDRESS

Status (R3000)
3

f{ojolojojo

Int Mashk

&«

3710

ojo

KernvUser Mode Oid —-l l

Bootstrap Exception _J
Vector

Int Enabie Oid

TLB Shutdown

Kernv/User

Panty Error

Mode Previous

Cache Mss

Panty Zero

int Enable
Pravious

Caches

Swap
isciate Cache —J

Kern/User

Mode Current

INENADIE
e
Current
Rb-OM?
89

bits<31:28>

Namae

Coprocessor Usabilty

Mnemonc

Type

These bits control the usability of the four possible coproc.'ssors.
Each bit corresponds to a coprocessor and when set indicat.s that a
coprocessor is usable. For example, if CU<0> is set, Coprocessor 0 is
usable.

bits<27:23>

Name

Reserved

Mnemonic.

None

Type

Reserved; must be zero.

bit-22>

Name:

Bootstrap Exception Veclor

Mnemonc.

BEV

Type:

If set to one, causes the R3000 to use alternate, bootstrap vectors for
ULTB Miss and gencral exceptions.

4-1

KNS8A/B CPU Mcdule Registers
R3000 Status Register (Status)

bit<21>

Nama:

TLB Shutdown

Mnemonic:

Type:

Set to one if the R3000 i.as disabled TLB due to catastrophic error.

Cleared only by R3000 reset.

bit<20>

Name:

Parity Error

Mnemonic:

Type:

Set to one if a parity error occurs. Reset by writing a one to this bit.

bit<19>

Name:

Cache Miss

Mnemonic.

Type:

Set to one if the most recent D-Cache load resulted in a miss (only
when the D-Cache is isolated).

bit<18>

Name:

Party Zero

Mnemonic.

Type.

When set to one, causes zerc to replace normal outgoing parity bits.

bit<17>

Name

Swap Caches

édnemonic:

SwC

Type

Controls swapping of I-Cache and D-Cache usage. When set to one,
the the l.cache is swapped with the D-cache.

bit<16

Name

isolate Cache

Ginemonic.

1sC

Type

RwW

When set to one, isolates D-Cache from main memory system.

4-12

KN58A/B CPU Module Registers
R3000 Status Register (Status)

bits<15:8>

Name

Interrupt Mash

Mnemonc

IntMashk

Type

When a bit is set to one, the corresponding hardware or software
interrupt is enabled. Bits <15:10> correspond to hardware interrupts

5 through 0, and bits <9:8> correspond to software interrupts 1 and 0.

bits<7:6>

Name

Reserved

Mnemonc

None

Type

Reserved. must be zero.

bit<5>»

Name

Kern'Usar Mode Old

Mnemonic

Kllo

Type

Set to zero if kernel, one if user

bit<d>»

Name

int Enable Ola

Mnemonic

IEo

Type

Set to one to enable, zero to disable

bit<3>

Name

KernUser Mode Previous

Mnemonic

Klp

Type

Set to zero if kernel, one if user.

bit<2>

Name

int Enabie Previous

Mnemonic

IEp

Type

Set to one to enable, zero to disable.

4-13

KNS8A/B CPU Module Reglsters
R3000 Status Register (Status)

bitei>

Name:

Kem/AUser Rode Current

Mnemonic.

KUc

Type:

Set to zero if kernel, one if uger.

bit<l>

Name-

int Enable Current

Mnamone

|Ec

Type.

Set to one to enable, zero to disable.

4-14

KN5S8A/B CPU Module Registers
Cause Reglster (Cause)

Cause Register (Cause)
The Cause Ragister contains information about the last exception

ADDRESS

Cause (R3000)
3

o] celo]ofololololo|ole|ofofo]

L— Branch Delay
bit<31>

Name

Branch Delay

Mnemonc

Type

intPenaing

)

swu]oomcooooo

ud 004) &

Set to one if the last exception was taken while executing in a branch
delay slot

bit<30>

Name

Reservad

Mnamonic

None

Type

Reserved; must be zero.

bit<29:28>

Name.

Coprocessor Error

Mnemonic.

Type

Indicates the unit number referenced when a Coprocessor Unusable
exception is taken.

bits<27:16>

Name

Resarved

Mnemonic'

None

Type.

Reserved; must be zero.

4-18

KNSBA/B CPU Module Registers
Causo Reglster (Ceuse)

bit<15:10»>

Name:

interrupts Pending

#Mnemonic:

Tyoe:

Indicates the external interrupts that are pending. Bits <15:10>
correspond t¢ interrupts <5:0>.

bite<©:8>

Name.

Software Interrupts

Mnemonc.

Type

RwW

Indicates which of the two software interrupts is pending. This field is
used to set or reset software interrupts.

bite<7:6:.

Name

Reserved

tMnemonic:

None

Type.

Reserved; must be zero.

bite<5:2>

Name

Exception Code

Mnemonic

ExcCode

Type

Exception code as described in the following table:

&-16

Caecription

M!S
W
-~ O

Int

External Interrupt

MOD

TLB modification exception

TLBL

TL8 muss exception (Load or instruction fetch)

TLB8S

TLB miss exception (Store)

AdEL

Address error exception (Load or ingtruction fetch)

AJES

Address emor exceplion (Store)

IBE

Bus error exception (for an nstructon fetch)

DBE

Bus error excephion (for a data load or store)

Sys

Syscall exception

Breakpoint exception

Reserved Instruction exceplion

CoU

Coprocessor Unusabla exception

Owvt

Anthmetic Ovarfiow exception

RSVD

Reserved

(Snemonic

NoO

Number

KNS8A/B CPU Module Registers
Cause Register (Cause)

13-15

bits<1:0>

Name

Reserved

Mnemonc

None

Type

Reserved. must be zero.

4-17

KN58A/B CPU Module Registers

Excoption Program Counter Register (EPC)

Exception Program Counter Register (EPC)
The Exception Program Coumer Register containg the address where
processing can resume after an exception has been serviced.

ADDRESS

EPC (R3000)
€ roppion Program Countan
~od-0aes
59

bite<31:0>

Name:

Exception Program Counter Register

Mnamonc

EPC

Type

The Exception Program Counter Register contains the virtual
address of the instruction that caused the last exception. When
that instruction resides in a branch delay slot, the register contains
the virtual address of the immediately preceding Branch or Jump
instruction. The R3000 also sets the Cause Register's BD bit if the
exception occurred in the branch delay slot.

4-18

KN58A/B CPU Module Registers
Context Register (Context)

Context Register (Context)
The Context Register duplicates some of the information provided in the
BadVAddr Register, but provides the information in a form that may be more
usetul for a software TLB exception handler W is designed for use in a UTLB
miss handler, which loads TLB entries for normal user-mode reterences

ADDRESS

Context (R3000)
3

[ AN 4

PTE Base

8ad VPN

0{0
mab 044300

bits<31:21>

Name

Page Table Entry Base

Mnamonc

PTEBase

Type

Holds the base for the Page Table Entry (set by software).

bits<20:2>

Name

Bad Virual Page Number

Mnemonic

BadVPN

Type

Holds the failing Virtual Page Number (set by hardware). Contains
bits <30:12> of the BadVAddr register.

bits<1:0>

Name

Reserved

Mnemonic'

None

Type

Reserved, must be zero.

4-19

KN58A/8 CPU Module Reglsters

Bed Virtual Addrese Reglster (BadVAddr)

Bad Virtual Address Register (BadVAddr)
The Bad Virtual Address Register containg the entire bad virual address tor

any address exceplion. AGEL or AdEs.

ADDRESS

]

BadVAddr (R3000)
E A

[

Bad Virtual Address
&
ed-0oas

bite<31:0>

Name:

Bad Vinua! Address Regster

Mnemonic.

BadVAddr

Type:

Note that this register does not save any information for bus errors

since these are not addressing errors.

4-20

KNSSA/B CPY Module Reglsters
Processor Revision ldentifler Reglster (PRId)

Processor Revision Identifier Register (PRIid)
The Process Revision Identiter Register comains data that speafies the
implemantation and revision lavel of the R3000

ADDRESS

PRId (R3000)
3

AUIRIY

ojojojoliojolojolojo|ojolojolojo]

[

impiemenavon

]

Revision
g 08487 &

bits<31:16>

Name

Reserveu

Mnemonc

None

Type

Reserved. must be zero

bits<15:8>

Name

implementation kienthier

Mnemonic

Imp

Type

Identifies the implementation number of the R3000

bits<7:0>

Name

Revision identfier

Mnemonc

Rev

Type

Identifies the revision level of the R3000.

421

KNSSA/B CPU Module

4.2.3

R3000 Pipeline Architecture
The R3000 instruction pipeline consists of five stages:.
1

I - Instruction Fetch. Fetch the instiuction. The R3000 calculates

the instruction address required to vread an instruction from the
I-cache.

RD - Read any required operands from the R3000 registers while
decoding the instruction.

ALU - Perform the required operation on instruction operands.

MEM - Access memory (D-Cache).

WB - Write back results to register file.

Each of these stages requires approximately one cycle. When the pipeline
is fcll, the R3000 can execute instructions at a rate of approximately one
instruction per cycle. The pipeline operates efficiently because different
CPU resources (address and data bus accesses, ALU operations, register
accesses, and so on) are utilized simultaneously without interfering with
one another.

4.2.4

Data Types
The R3000 defines a 32-bit word, a 16-bit half word, and an 8-bit byte.
Byte ordering on the KN58A is compatible with VAX architecture and is
called little endian, which means that byte 0 is the least significant and
rightmost byte.
The R3000 addresses aligned bytes for half word and word accesses;
half word accesses must be aligned on an even byte boundary, and word

accesses must be aligned on a byte boundary divisible by 4.

Special instructions are provided for addressing words not sligned on a 4byte (word) boundary. These instructions (load word left, load word right,
store word left, and store word right) when paired appropriately allow
unaligned words to be accessed in one cycle more than would be required
for an aligned word.

4-22

KNS8A/B CPU Module

4.2.5

Instruction Set
Every R3000 instruction consists of a single word (32 bits) aligned on a
word boundary. For simplicity in instruction decoding, there are only three
instruction formats: 1-Type, J-Type, and R-Type. These are illustrated in
Figure 4-3.

Figure 4-3

Instruction Formats

i Type (Immediate)
"

(LT}

immediate

J- Type (Jump)
3

FL ]

[

Target

R Type (Regster)

.
3

opP

AL BT )

RTY

wog

[

SHAMT

[}

FUNCT

#Ob-0MD
M4

Where:
oP

ts a 6-bnt operation code

1s a 5-bnt source register specther

is a 5-b target (source/destinalon) register or branch congnon

immediate

1S @ 16-br immediate data, branch dizplacement, or address
displacament

Target

15 a 26-bt jump target address

1S @ 5-brt destination reQister spaciier

SHAMT

ts a 5-bit shft amoum

FUNCT

1s a 6-bn function field

4-23

KNSS8A/B CPU Module

4.25.4

Load and Store ingtructions
Load and store instructions move data between memory and general
registers. They are all I-type instructions, since the only addressing mode
sipported is base register plus 16-bit signed immediate offset.

Most load operations have a latancy of one instruction. That is, the
instruction immediately following & load usually cannot use the contents

of the loaded register. An exception is that the target register for the load
word left and load word right instructions may be specified as the same

The load or store instruction opcode specifies the access type, which also
specifies the size of the data item to be loaded or stored. The address
specifies the least significant byte. The bytes within the addressed word
that are used are determined by the access type and the two low-order
bits of the address, as shown in Table 4-2. Note that certain combinations
of access type and low-order address bits never occur (word/01/10/11,
triple-byte/10/11, and halfword/01/11).

Teble 4-2

By’ Specifications for Load and Store Ingtructions
Low-Order

Address

Bytes Accossed

1 1 (word)

3210

1 0 (triple-byte)

210

Access Type

4235.2

Bite

Little Endian Format

10 (tnple-byte)

321

0 i (hafiword)

1.0

0 1 (haliword)

3.2

0 0 (byte)

0 O (byte)

0 0 (byte)

Computational instructions

Computational instructions perform arithmetic, logical, and shift
operations on values in registers. They occur in both R-type (botk
operands are registers) and I-type (one operand is a 16-bit immediate)
formats. There are four categories of computational instructions:

ALU Immediate instructions such as ADD Immediate and OR
Immediate.

$.Operand Register-Type instructions such as Add, Subtract, and

Shift instructions such as Shift Left Logical and Shift Right Logical.

8-24

NOR.

Multiply/Divide instructions such as Multiply Unsigned, Divide, and

Move from LO.

KNSSA/B CPU Module

4253

Jump and Branch Instructions
Jump and branch instructions change the control flow of a program.
Jumps are always to absolute 26-bit word addresses (J-type format) or
32-bit register addresses (R-type). Branches have 16-bit offsets relative to
the program counter (I-type). Jump and Link instructions save a return
address in Register 31.

All jump and branch instructions have a delay of one instruction. That is,
the instruction immediately following a jump or branch executes while the
target instruction is fetched from storage.

Since instructions must be word aligned, a jump register or jump and link
register instruction must use a register whose two low-order bits are zero.
If these low-order bits are not zero, an address exception will occur when
the target instruction is subsequently fetched.
4254

Coproceseor ingtructions

Coprocessor instructions perform operations in the coprocessors.
Coprocessor loads and stores are I-type Coprocessor computational
instructions have coprocessor-dependent formats.

Because of the protected status of coprocessor 0, the move to/from
coprocessor instructions are the only valid mechanism for reading from
and writing to the CPO registers (see Section 4.2.2). The coprocessor
nstructions allow coprocessor 0 to directly read, write, and probe TLB
entries and to modify the operating modes in preparation for returning to
user-mode or interrupt-enabled states.
4255

Special Instructions

There are only two special instructions, system call and breakpoint These
insructions allow software to initiate traps. They are always R-type.

4-25

KN58A/B CPU Module

4.2.6

Memory Management
The R3000 has an addressing range of 4 Gbytes. However, since most
systems implement a physical memory smailer than 4 Gbytes, the R3000
translates addresses composed in a large virtual address space into

available physical memory addresses. Virtual memory is always enabled,
and the 4 Gbyte virtual address epace is divided into 2 Gbytes for users
and 2 Gbytes for the kernel. The physical memory space available on the
XMI to the KN58A is 256 Mbytes for memory and 512 Mbytes for 1/0.

426.1

Trangiation Lockeaside Bufier

The Translation Lookaside Buffer (TLB) reduces the overhead associated
with translating virtual addresses to physical addresses. The on-chip
TLB allows very fast virtual memory access to meet the requirements of
multitesking operating systems. The fully associative TLB contains 64

entries, each of which maps a 4-Kbyte page, with controls for read/write
access, cachability, and process identification. The TLB sllows each user to
access up to 2 Gbytes of virtual address space.
4.26.2

R3000 Operating Modes

The R3000 has two operating modes: user and kernel. The R3000
normally operates in user mode until an exception forces it into kernel
mode. The R3000 remains in kerne! mode until a Restore From Exception

(RFE) instruction is executed. The manner in which memory addresses
are mapped depends on the operating mode of the R3000. Figure 44
illustrates the virtuai address space for the two modes.

As shown in Figure 44, user mode defines a single uniform virtual
address space (kuseg) of 2 Gbytes. Each virtugl address is extended by a
6-bit process identifier to form unique virtual addresses for up to 64 user

processes. All references are mapped through the TLB. Use of first-level
cache is determined by bit settings for each page within the TLB entries.
As shown in Figure 44, kernel mode defines four virtual address
segments: kuseg, kseg0, ksegl, and kseg2.
*

kuseg - Kernel mode references to kuseg are identical to those in user
mode.

kseg0 - References to this 512-Mbyte segment use cache memory but
are not mapped through the TLB. Instead, they always map to the
first .5 Gbytes of physical memory.

ksegl - References to this 512-Mbyte segment do not use cache
memory and are not mapped through the TLB. Instead, they always
map to the first .5 Gbytes of physical memory.

koeg2 - References to this 1-Gbyte segment are always mapped
through the TLB and use of the cache is determined by the bit settings
of the TLB entry.

£-26

KNSSA/B CPU Module

Flgure -4

Virtual Memory for Kermnel and User Modes
Kerna! Mode

1 O Goytes
Mapped

000 0000
b fin

;

1% Gbytes

2000 0000
it it

wnmapped
ksego

05 Gbytes

8000 0000

User Mode

Unmapped

THH i

71 et

Risseg
2 0 Goytes

Mapped

0000 000C

huseg
2 0 Gbyles

Mapped

0000 0000
msb-04233 89

4-27

KN58A/B CPU Module

4.2.7

WMemory Mapping
Memory mapping is necegsary for the R3000 CPU to communicate with
VAX-based hardware on the IIDAL. Figure 4-8 illustrates the relationship
between R3000 virtual addresses, R3000 physical addresses, and IIDAL

(VAX) physical addresses.

Flgure 4-5

R3000 Memory Mapping

R3000 Virnal

R3000 Pryuca:

DAL Pryucal

3 fR

IFFF FFFF

(\num-:r-n

——p

000 G000
De

3000 0000

2000 0000

2 'R

2FFF FFFF

2008 FFFF

(memrw-d)

(R3000 ROM)

«D00 0000

000 0000

1TM »

2000 0000
‘O

AFFF FFFF

1060 11

(Urvmmd-o

D (R300D ROM)
100a 0000

8000 000U

1000 0000

01 1

OFFF FFFF

wsey

_._’

(apped Cachad)
0000 0000

tfemory

0000 00CO

0000 0000
mub-0619-60

The R3000 does not have the same concept of 'O space as a8 VAX-based
CPU, but since the R3000 must operate on a VAX bus, the design of

the KN58A/B CPU module implements & 256-Mbyte 1/O space separate
from the memory space. Physica! address bits 28 and 29 are swapped
between the KN58A/A interface module and KN58A/B CPU module. This
effectively divides the R3000 physical address range into 256 Mbytes of
/O space and 256 Mbytes of memory space and allows kseg0 and ksegl to
map the first 256 Mbytes of XMI I/O space without the use of translation
buffers.

ksegO and keegl both map to the first 512 Mbytes of R3000 physical
memory. kseg0 maps through the cache, and ksegl maps around the
cache. When these address ranges are accessed, the R3000 clears physical
address bits 31, 30, and 29 and uses the remaining ~ddress as the physica)

4-28

KNSSA/B CPU Module

address. kuseg and kseg2 require that translation buffer entries be valid
for the R3000.
4271

R3000 Boot PROM

The R3000 boot PROM is located in keegl (unmapped, uncached space)
at R3000 virtual address b0Oa 0000 through b0Ob fiif. When the RESET
line is deasserted, the first address that the R3000 accesses is 1fc0 0000.
Hardware translates that address directly to 200A 0000, locating the
PROM space on the XMl from 200A 0000 to 200B FFFF.

42.7.2

VO Mapping Exampie: Reading a Register Associated with VO Adapter 7
All XMI node spaces and XM1 /O adapters 0 through 3 exist in XMI
physical address space 2000 0000 through 2FFF FFFF. This range is
typically accessed directly via ksegl using R3000 virtual addresses 0xb000

0000 through Oxbfff fiT. O adapters 4 through 7 exist at XMI physical
address 3600 0000 through 3DFF FFFF. The TLB must be used to map
R3000 virtual addresses to XMI addresses in this range. kseg?2 is used to
map these addresses in system space.

Example 4—1 ma;s the VAXBI base address of the DWMBA/B module at
XMI node E Bl node 1, then reads the DWMBA/B Bus Error Register, and
then unmaps the address.

Example 4-1

VO Mapping

tC,

Ox8CC

use Bir

mecl

t0,

INDEX

load

TLP entry

tC,

Ox3cQC2fCC

load DTYPE

mtcl

tC,

ENTRYLC

index

reg physical

tC.

Oxfcll2C0C

load LC raif of PTE
map DTYFE reg virtua.

mecC

tC,

ENTRYH]

load HI

half

address

via kseg?

PTE

nog

write

tibw:

PTE

intc

TLB

neg

vC,

8¢tl)

read BER

DWMBA'B

nop

mtcC

zaro,

ENTRYLC

invalidate PTE

(clearing V bit)

nog

tlbwi

write

invalid PTE

TLB

« RDVG Dbits

KNS8A/B CPU Module

4.2.8

Interrupts
The R3000 has six external hardware interrupt levels and two software
interrupt levels. Table 4-3 summarizes the types and levels of hardware
interrupts.

Table 4-3

R3000 Exmemal Hordware Inteitupts

Level

CondRion

R3010 fioating-point inerrupt

CTRL/P genarated by congole

dode Hahl bn (XBER<29>) writen
3

KNS8A Hard Errors:
Xt AC LO (CSR1<6>)

DAL Write Data Panty Eror (CSR2<28>)

XBAl Write Error IVINTR (XBER«25>)
M1 FAULT (XBER<26>)

XMI Wrie Errors (XBER<20>. XBER<15>)
XM IDENT Errors (XBER<18:155)
HNS5B8A Soft Errors:

Invatidate FIFO Full (CSR1<26>)

Second-Level Cache Partty Errors (CSR2<31:30>)
(disables second-level cache)

invalidate Queue Overflow (CSR2<29>)
(cisables second-isvel cache)

Second-Leve! Cache Fill Error (CSR2«<27>)
Duplicate Tag Parity Error (CSR2<26>)
(disables second-level cache)

XMI Corrected Contirmation (XBER<27>)
(imterrupt can be disabled)

XM inconsistant Parity Error (XBER<24>)
(disables second-level cache)
XM Parity Error (XBER<23>)

XMl Corracted Road Data (XBER<19>)
{interrupt can be disabied)

XMl leve! 7 interrupt transaction

XM! interpracessar IVINTR

XMI level § interrupt transaction
Imterval timer interrupt

XMl leve! 5 interrupt transaction
Console terminal interrup!

KNSSA/B CPU Module

Tabie ¢-3 (Cont.)

Level

R3I000 External Hardware interrupis

CondRion
Programmable timer interrupt
XMI leve! 4 interrupt transaction

When one of the external hardware interrupts from Table 4-3 is recognized

by the R3000, the R3000 branches to the general exception vector (0x8000
0080). The R3000 sets bits <5:2> of the Cause Register to zero and
sets bits <15:10> with the level of the interrupt. Software obtains the
appropriate interrupt vector by reading the addresses shown in Table 44.
Table 4-4

R3000
interrupt
Line

interrupt Acknowledge Vectors

XAl interrupt Lavel

HDAL
interrupt
Lovel

Address

XM! 4

4000 0050

XMI 5

4000 0054

IVINTR XM! 6

4000 0058

XM 7

4000 005C

No vector is supplied for R3000 interrupt levels 3, 4, or 5. These interrupts
are used as shown in Table 4-5.
Taeble 4-5

R3I000 Interrupt Levels 3, 4, and 5

R3000 interrupt Leval

Purpoge

Corrected read data

First-level invahdate FIFO overfiow

Mamory error
Power fail
Han

4.2.9

Floating-point unit

Exceptions
When the R3000 detects an exception, the normal sequence of instruction
execution is suspended. The processor exits user mode and is forced into
kernel mode where it can respond to the abnormal or asynchronous event.
Events that initiate exception processing are described in detail in the
R3000 RISC Architecture manual. In summary, they are:

&-31

KNS8A/B CPU Module

Reset - Assertion and deassertion of the R3000's RESET signal causes
an exception that transfers control to the vector at virtual address
Oxbfc0 0000.

UTLB mies - User TLB miss. A reference is made {in either user or
kernel mode) to a page in kuseg that has no matching TLB entry.
TLB mies - A referenced TLB entry's Valid bit is not set, or there is a

reference to @ kseg2 page that has no matching TLB entry.

TLB modified - During a store instruction, the Velid bit is set but th»
Dirty bit 1s not set.

Bus error - Assertion of the R3000’s BUS ERR signal, which occurs
as a result of a nonexistent memory read. IIERR on the IIDAL bus is
asserted by the SSC and in response to that, BUS ERR is asserted to
the R3000.

Address ervor - A‘tempt to load, fetch, or store an unaligned word,
that is, a word or halfword at an address not evenly divisible by 4 or
2 respectively. Also caused by reference to a virtual address with most
significant bit set while in user mode.

Overflow - Two's complement overflow during add or subtract.
System call - Execution of the SYSCALL instruction.

Breakpoint - Execution of the BREAK instruction.
Reserved instruction - Execution of an instruction with an
undefined or reserved major operation code (bits <31:26>) or a special
instruction whose minor opcode (bits <5:0>) is undefined.
Coprocessor unusable - Execution of a coprocessor instruction when
the CU (Coprocessor Unusable) bit is not set for the target coprocessor.
Laterrupt - Assertion of one of the R3000's six hardware interrupt
inputs or setting of one of the two software interrupt bits in the Cause
Register.

KNS8A/B CPU Module

4.3

R3010 FPA
The R3010 ficating-point accelerator (FPA) operates in conjunction
with the R3000 CPU and extends the R3000% instruction
eet to perform arithmetic operations on values in floatingpoint repregentations. The RS010 FPA fully conforms to the
requirements of ANSVIEEE Standard 764-18€8, "IEEE Standard
for Binary Floating-Point Arithmetic."

Features of the FPA include:

4.3.1

Full 84-bit operation. The FPA provides 16 64-bit registers that can
be used to hold single-precision or double-precision values. The FPA
also includes a 32-bit contro/status register that provides access to all
IEEE-Standard exception handling capabilities.

Load’/store instruction set. Like the R3000 processor, the FPA uses
load/store instructions with single-cycle loads and stores. Floating
point operations are started in a single cycle and overlapped with
other fixed-point or floating-point operations.

Tightly coupled coprocessor interface. The FPA connects with the
R3000 to form a tightly coupled unit with a seamless integration of
floating-point and fixed-point operations. Since the FPA can receive
and execute instructions in parallel, some floating-point instructions
can execute at the same single-cycle rate as integer instructions.

FPA Registers
As shown in Figure 4-6, the FPA has 32 general-purpose 32-bit registers,
a control/status register, and an implementation/revision register.

Floating-point coprocessor operations (that is, operations involving
Coprocessor 1) reference three types of registers:
¢

Floating-point general registers (FGRs)

Floating-point registers (FPRs)

Floating-point control registers (FCRs)

The sections that follow provide a brief description of these types of
registers.

KNS8A/B CPU Module

Figure 4-6

%)
|

FPA Gensral-Purpose Reglaters

FGA1

32 3
]

FGRO

°
|

rero

FGR3

FGR2

FPR2

FGRS

FGR4

rPRa

[
<=

[

FGR2?

]

FGR26

FrR2s

FGR29

FGR28

erR2e

FGR

FGR30

FPR0

| ControuStatus Register |
[

impRevRegater

|
el 0409 60

43.1.1

Floating-Point General Registers (FGRs)

The FPA contains 32 32-bit floating-point general registers (FGRs).
They are directly addressable and are accessed by load, store, or move
operations.

43.1.2

Floaiing-Point Registers (FPRS)

As shown in Figure 4-6, the 32 FGRs are logically configured as 16 64-bit
fleating-point registers (FPRs). FGR1 and FGRO, for example, are the
upper and lower halves (respectively) of FPRO.
Only even-numbered addresses are used to access FPRs: odd-numbered
addresses are invalid. The FPRs contain data in either single- or doubleprecision floating-point format. During single-precision operations only the
even-numbered FGRs are used. Double-precision operations access FGRs
in pairs.

4313

Flogting-Point Contro! Registers (FCRs)

The FPA has two floating-point control registers (FCRs), which are
accessed only by move operations. These are the control/status register
(FCR31) and the implementation/revision register (FCRO).

KNS8A/B CPU Module Registers
FPA Control/Status Register (FCR31)

FPA Control/Status Register (FCR31)
The Control/Status Register is used to control and monitor @xceplions,

operating modes. and rounding modes. it is written with a Move Control
to Coprocessor 1 (CTC1) instruction.

ADDRESS

FCR31 (R3C10)
»n

[

E)
of{o|o]o]o]ofo{o|c|ojofojofo] Excsetone

Trap:IlOUI
Enabie | Shcky
B
V£{3%"f

v
0

Mob-04
6 89

bits<31:24>

Name-

Reserved

Mnemonic:

None

Type

Reserved, must be zero.

bit<23»

Name

Condition

Mnamonc.

Type

R'W

Set/cleared to reflect the result of a Compare instructior: and drives
the FPAs CpCond output signal.

bits<22:18>

Name:

Researved

Mnamonic.

None

Type

Reserved; must be zero.

bits<17:12>

Name

Exceptions

tinemoncs'

E, V. 2. 0. U, |

Type

These bits are set to indicate any exceptions that occurred during the
most recent instruction. E indicates an unimplemented operation, V
indicates an invalid operation, Z indicates division by zero, O indicates
overflow, U indicates underflow, and I indicates an inexact operation.

3-35

KNSBA/B CPU Module Registers
FPA Contrel/Status Register (FCR31)

bits<11:7>

Name:

Trap Enable

Mnemonics: V, 2,0, U, |

Type:

These bits enable assertion of the FPA's Cplnt signai if the
corresponding Exception bit is set during a floating-point operation. V
is for an invalid operation, Z is for division by zero, O is for overflow, U
i8 for underflow, and I is for an inexact operation.

bits<6:2>

Name:

Sticky bits

Type:

Mnemonics: V, 2,0, U, §

These bits are set if an exception occurs and are reset only by expliutly
loading new settings into this register with a Move instruction. V s
for an invalid operation, Z is for division by zero, O is for overflow, U is
for underflow, and 1 is for an inexact operation.

bits<2:0>

Name:

Rounding Mode

Mnemonic:

Type:

Specify whick of the four rounding modes is to be used by the FPA.

KN58A/B CPU Module Registers
FPA implementation/Revision Register (FCRO)

FPA Implementation/Revision Register (FCRO)
The ImplementatiorvRevision Register is used by diagnostic software to

determine the FPA revision level.

ADDRESS

FCRO (R3010)
ojojojojojojojojojojojojojoioio

bits<31:16>

Name

Ressrved

Mnemonic

None

Type

impigmentaton

Revision

Reserved. must be zero

bits<15:8>

Name

Implementation identher

Mnemonc

Imp

Type

Identifies the implementation namber of the R3010.

bits<7:0>

Name

Revision identit.ar

Mnemonic

Rev

Type

ldentifies the revision level of the R3010.

437

KNSBA/B CPU Module

4.3.2

FPA Formats
The R3010 FPA performs both 32-bit (single-precision) and 64-bit (doubleprecision) IEEE standard floating-point operations. The 32-bit format has
a 24-bit signed-magnitude fraction field and an 8-bit exponent as shown in
Figure 4-1.

Figure 4-7

Single-Precision Floating-Poim Format

Exponent

Frachon

The 64-bit format has a 53-bit signed-magnitude fraction field and an
11-bit exponent as shown in Figure 4-8.

Figure 48

)

Double-Precision Floating-Point Format

Exponent

Frachon
~n-0d70-85

4.3.3

Coprocessor Operation
As an R3000 coprocessor, the FPA continually monitors the R3000's
instruction stream, ignoring non-FPA instructions. When it detecis an FPA
instruction, the FPA executes it and transfers the results and necessary
exception data synchronously to the R3000. The FPA can perform the
following types of operations:
¢

Load and store operations

Moves

Two and three register floating-point operations

KNSSA/B CPU Module

433.1

Load, Store, and Rove Operations

Load, store, and move operations move data between memory or the
R3000 registers and the FPA registers. These operations perform no
format conversions and cause no floating-point exceptions. Load, store,

and move operations reference a single 32-bit word of either the FGRs or
the FCRs.

4332

Floating-Point Operations

The FPA supports the following single- and double-precision format
floating-point operations:

Add

Subtract

Multply

Divide

Absolute Velue

Move

Negate

Compare

In addition, the FPA supports conversion between single- and double-

precision floating-point formats and fixed-point formats.
4333

Exceptions

The FPA supports all five IEEE standard exceptions:
e

Invahd Operation

[Inexact Operation

Division by Zero

Qverflow

Underflow

instruction Set Overview
The R3010 FPA instructions are 32 bits long and can be divided into the
following groups:

Load, store, and move instructions move data between memory, the

Computational instructions perform arithmetic operations on

R3000, and the FPA general registers.

floating-point values in the FPA registers.

Conversion instructions perform conversion operations between the
various data formats.

KNSSA/B TPU Module

4.3.5

Compare instructions perform comparisons of the contents of registers
and set a condition bit based on the results.

R3010 Pipeline Architecture
The R3010 FPA provides an instruction pipeline that parallels that of the
R3000 processor. The FPA, however, has a 6-stage pipeline instead of the
5-stage pipeline of the R3000: the additional FPA pipe stage is used to
provide efficient coordination of exception responses between the FPA and
the R3000. The pipeline for the FPA has the following stages:
¢

[F - Instruction Fetch. The R3000 calculates the instruction address
required to read an instruction from the I-cache. No action is required
of the FPA during this stage since the R3000 is responsible for address
generation.

RD - The instruction is present on the data bus during pha:- 1 of this
stage, and the FPA decodes the data on the bus to determine if it is an
instruction for the FPA.

ALU - If the instruction is an FPA instruction, instruction execution
begins during this stage.

e MEM - If this is a coprocessor load or store instruction, the FPA
presents or captures the data during phase 2 of this stage.

WB - The FPA uses this stage solely to deal with exceptions.

FWB - The FPA uses this stage to write back arithmetic results to its
register file. This stage is the equivalent of the WB stage in the R3000
processor.

KNSSA/B CPU Module

4.4

R3020 Write Buffers
All R3000 write references are simultancously written into the

first-level cache (see Section 4.6) and the R3020 write bufiers. The
paragraphs that follow describe the operation of the write buffers.

The KN58A/B CPU module has four R3020 write buffer chips that buffer
R3000 write references before they appear on the I[IDAL bus. The write
buffers enhance R3000 performance because they allow the R3000 to
perform write operations duning run cycles, which would ctherwise stall
the pipeline. Each write buffer handles an 8-bit slice of address and an
8-bit slice of data As a unit, the four buffers allow four-deep buffering of
32 bits of address and 32 bits of data and parity.

When the R3000 performs a write operation, the write buffers capture the
output data and its address (including the bits that indicate the access

type). The write buffers can hold up to four such data/address sets (or
pairs) while waiting to drive the IIDAL bus. Transfers from the R3000 to
the write buffers occur synchronously at a cycle rate of 25 MHz, and the
write buffers stall the R3000 if they are unable to accept write data. The
write buffers communicate asynchronously with the IIDAL control logic to
coordinate the transfer of write data over the IIDAL bus

4.4.1

Write Buffer Flush
The write buffers are flushed by the IIDAL control logic under any of the
following conditions:

/O Read - An R3000 read reference with address bit <28> set. This
corresponds to an HIDAL reference with address bit <29> set.

Interrupt Acknowledge Transaction - An R3000 read reference with
address bit <30> set.

Read Lock Reference - See Section 4.6.5.

°*

Main Memory Read Reference

In general, the CPU gives write operations priority over read operations.

Refer to Section 4.6 for more information on the IIDAL control logic.

KNS8A/B CPU Module

44.2

Write Buffer Byte Gathering
The write buffers perform byte, half-byte, tri-byte, and word gathering

to decrease the number of write transfers to the same longword location.
Byte gathering allows bytes or half-words to be collected and written
to main memory. Without byte gathering, the write buffers present

address/data sets individually to the IIDAL controi logic in the sequence in
which they were received from the R3000.

During byte gathering, sequential writes to the same longword address
have their data gathered into the same address/data set in the write
buffers. Writes to the same byte location are overwritten in the write
buffers.
Gathering does not occur for the address/data set that is currently
available to the [IDAL control logic. The first write into empty write
buffers will not have subsequent writes gathered. Subsequent writes are
placed in the next available buffer. Also, byte gathering does not occur for
nonsequential writes to the same address.
One result of the gathering scheme is that in some cases two IIDAL
bus write references are required to empty a single write buffer entry. For
example, if bytes 0 and 3 of a word are sequentially written, two references
are required to empty the write buffer entry.
Another result of the gathering scheme is that where order is important
in writing (such as for /O controllers), software should avoid sequential

accesses to the same word. In cases where write-read access order is
important but the reading of the written location is not desired (such as in

/0), a write followed by an 1/O read to a dummy location will ensure that
the first write has occurred before continuing.
The byte gathering mechanism is transparent and inaccessible to the user.
Its state at any particular time is not readily determined. Software should
not rely on the operation of the byte gathering mechanism.

4.4.3

Write Bufter Parity
The KN58A/B CPU module contains logic that generates parity for the
output of the R3020 write buffers before the output is driven onto the
IIDAL bus.

KNS8A/B CPU Module

4.5

First-Level Cache Memory
As shown in Figure 4-8, the R3000 interfaces directly with a 128Kbyte first-level cache. The cache is direct-mapped and writethrough with a 20 ns cycle time. The firet-level cache is nrganized
as a 84-Kbyte instruction cache (I-cache) and & 84-Kbyt data
cache (D-cache). First-level D-cache ccherency ie maintained by
hardware. First-level I-cache cocherency must be mainiained by
sofiware.

Figure -9

Cache Organization

R3000

Fus!-Level

Second Level

1 & D stream
20 ns acoess
Dwect mapped

t & D stream
450 ns acoess
Direct mapped

Cache
120 KB

1 worg or

8-word hit

Cache
256 KB

64 byte block

XMl Main

Memory
Upto512MB

1 2 us 20c009ss
assuming
an
“idie® XM!

32 byte hi

msd- 039780

45.1

First-Level Cachable References
Any reference stored by the first-level cache is called a “first-level
cachable reference” (FL cachable reference). For cache coherency to be
maintained, the first-level cache must be initialized properly, as explained
in Section 4.5.3.

The R3000 generates IIDAL references, depending on the reference type,
as follows:

Whenever the R3000 generates a non-FL cachable reference, a single
longword reference of the same type is generated on the IIDAL bus.

Whenever the R3000 generates an FL cachable read reference that is

already stored in the first-level cache, no reference is generated on the
IIDAL bus.

KNSsA/B CPU Module

Whenever the R3000 generates an FL cachable write reference, a write
reference is generated for both the FL cache and the IIDAL bus (see

Section 4.5.7).

All R3000 writes first pass through the R3020 write buffers (see
Section 4.4) before they appeer on the IIDAL bus.

4.5.2

First-Level Cache Organization
The first-level cache is divided into two independent storage arrays called
the I-cache and the D-cache (see Figure 4-10). Each one contsins a
64K-row x 24-bit tag array and a 64K-row 36-bit data array.
Figure 4-10

First-Level Cache Orgenization

I-Cache

;A-Bn

Rows

Tag Array

16K

D-Cache

maen

t:‘asflx

Deta Aray

Teg Arnray

by 16K

3&%‘:‘

(

Data Array

ERT e
59

36 35

¢ m“’
0
msb-0402-89

A row within the I-cache or D-cache corresponds to a cache entry. Each
cache entry contains a 24-bit tag portion (including valid and parity bits)
and a 36-bit data portion (including parity hits). There are 16K entries in
the I-cache and 16K entries in the D-cache. Figure 4-11 shows the format
of a cache entry. Table 4—6 -escribes the component parts of an entry.
Figure 4-11
86

TAGP

Cache Entry

B 8

B »

PFN

DATAP

]

DATA
mut-0403-89

KNS8A/B CPU Module

Table 4-6

Cache Eniry Flelds

Fleld

Dasceiption

TAGP

Teg partty. Parity over the V and PFN tie.ws. TAGPO (bit <57>) contains
party over the low byle of the PFN (bits <43.365). TAGP1 (bt <58>)
contains party over the next kowes! byte of the PFN (bids <51:44>).
TAGP2 (bit <59>) contains parity over the upper bits of the PFN (bis
<55:52>) and the V bit (b1t <565).

Vahid bt. When set, indicates a vahd cache entry.

PFN

Page frame number. Spaciies the page frame number.

DATAP

Data pardy. Party over the DATA field There is one party bt for each
byte of the DATA field. DATAPO (bit <32>) comains parity aver bis
<7.0>. DATAP! contains partty over bits <15 8>, DATAP2 contains
party over bits <23 16>, and DATAP3J containg party over bits <31:24>.

4.5.3

Initializing the First-Level Cache
When the first-level cache is first powered up, the Valid bit (bit <56>) of
each cache entry has an unpredictable value. The first-level cache must
therefore be completely initialized or invalidated by the operating system

upon power-up. D-cache and I-cache are initialized differently.
D-cache is initialized by isolating and flushing it. Isolation is accomplished
by setting the ISC bit (bit <18>) in the Status Register and the RINVAL
bit (bit <16>) in CSR1. Software must then read the RINVAL bit to ensure
that it 1s set. All writes then hit the cache. Software flushes D-cache by
performing partial word stores, each of which clears the Valid bit of a
cache entry When the flush is complete, software must clear the RINVAL
bit.

I-cache is initialized by isolating, swapping, and flushing it. Swapping
(or exchanging I-cache and D-cache control signals) is required because
I-cache cannot ordinarily be written directly. Swapping 1s accomplished by
setting the SWC bit (bit <17>) in the Status Register.
Before initializing I-cache, the R3000 must be executing from uncached
space. To initialize the cache, it is isolated by the software as previously

described and then swapped. The R3000 must not execute any load/store
instructions immediately before the swap operation. Software completes
the initialization by flushing the cache with partial word stores, each of
which clears the Valid bit of a cache entry.

KNSSA/B CPU Module

454

First-Level Cache Address Translation
Whenever the R3000 requires I-stream or D-stream data, the first-level
cache is checked to determine if the referenced location is stoved there.

Figure 4-12

Cache Addreas Tranglation

RTAG

eoppca

Cache Index

)

|
Vaid

I-Cache

D-Cache

36-Bu!

24-81

Data

Tap

36-But
Data

TR
%%‘Wmml

°
internal
1o

R3000

Chup

Match?

Daia

Mab-0604-89

KNSsA/B CPU Module

The first-level (FL) cache is checked by translating the physical address
(sce Figure 4-12) as foliows:
¢

On non-FL cachable references, the reference is never stored in the
cache, 8o a first-level "miss” orcurs and a single longword reference is
generated on the IIDAL bus.

On FL cachable references, the physical address must be translated

to determine if the contents of the referenced location is resident in
the cache. The Cache Index field, bits <15:2> of the address, is used
to select one of the 16K rows of the cache, with each row containing

u single entry of data and tag. The RTAG field, bits <31:12> of the
physical address, is then compared to the PFN of the entry in the
selected row.

If a match occurs with the PFN of the entry, and the Valid bit within
the entry is set, and no parity errors are encountered, the contents
of the referenced location 15 contained in the cache and a cache "hit’
occurs. No IIDAL bus transfers are initiated on R3000 references that
hit the first-level cache.

4.5.5

If no matcn occurs, then the contents of the referenced location is not
contained in the cache and a cache miss occurs. The data must be
obtained from either the second-level cache or from XMI memory. In
either case, a single longword transfer is initiated on the IIDAL bus.

First-Level Cache Data Block Allocation
FL cachable references that miss the first-level cache cause a longword
read to be initiated on the 1IDAL bus. When the requested longword is in
the second-level cache, the hexword containing the requested longword is
transmitted on the IIDAL to the R3000 and stored in the FL cache.
If the read reference misses the second-level cache, a 16-word block
is deallocated in the first-level D-cache and the requested longword is

supplied by main memory. The longword is then transmitted on the
IIDAL to the R3000 and stored at the addressed location in the previously
invalidated block.

4.5.6

First-Level Cache Behavior on Writes
The first-level cache is "allocate on write." All R3000 cached write
references are written into the first-level cache regardless of whether
they hit or miss the FL cache. Write references are also latched by the
R3020 write buff:r, which stores the write until it is gated onto the IIDAL
bus.

KNS8A/B CPU Meodule

4.5.7

First-Level Cache Coherency
First-level I-cache coherency must be maintained by the operating
system software. There is no hardware on the KN58A/B CPU medule
to implament this function.

First-level D-cache coherency is maint. .ned as a subset of the second-level
cache. A read miss in the first-level cache (either I-cache or D-cache) and
the second-level cache will force the 16-longw
ord block specified by the tag
address to be invalidated in the first-level D-cache.

The XCPGA on the KN58A/A interface nodule maintains an 8-deep
invalidate queue. When there is an entry in the invalidate queue, the
XCPGA arbitrates for the IIDAL to send an invalidate address to the
second-level cache, invalidating a 16-lengword block.
The KN58A/B CPU module contains an invalidate FIFO buffer that stores
the invalidate addresses sent to the second-level cacke. Each address in

the invalidate FIFO causes the invalidation of a 16-longword block in the
first-level D-cache. If the invalidate FIFO buffr is full and the XCPGA
generates another invalidate, an overflow is indicated in CSR1 and the
R3000 is interrupted.

Since the first-level cache is "allocate on write” and the second-level cache
is not, writes that miss the second-level cache must be marked invalid in
the first-level cache. This is necessary to maintain the first-level caclie
as a proper subset of the second-level cache. The invalidate FIFOs are
used to accomplish this write invalidate. If a write misses the second-level
cache, one word in the first-level D-cache i invahdated. If a read misses
the second-level cache, 16 words in the first-level D-cache are invalidated.
Device drivers not using an interlock instruction when reading a
semaphore must perform a "dummy” read of CSR1 after reading a
gsemaphore and before reading the data. This is required because of

the latency involved between an XMI write operation and its associated
invalidation of the first-level cache.

458

First-Level Cache Error Detection
Both the tag and data arrays in the first-level cache are protected by
parity. Each 8-bit byte of cache deta, each of the lower two bytes of the
PFN, and the Valid bit plus the upper four bits of the PFN are stored
with an associated parity bit. An even parity scheme is used. Tag and

date parity (on the entire longword) are checked on read and partia! store
references that hii the cache.

Upon Aetection of & parity error, the PE bit (bit <20>) in the Status
Register is set. No interrupt is generated. The R3000 transparently

recovers from parity errors by taking a cache miss and accessing main
memory for a good copy of the cache entry.

KN58A/B CPU Module

4.6

interface Logic
The interface logic controls communication between the KNSSA/B

CPU module and the KNS8A/A interface module via the IIDAL bus.
The interface logic is particularly important in performing control
functions (such as lock transactions) that cannot be performed
by the RS000 chip itself. This section discusses the IIDAL and
the types of IIDAL traneactions initiated and coordinated by the
interface logic.

4.6.1

The AL Bus
The protoco! for the IIDAL bus was derived from that of the CVAX CPBUS.
It is nearly identical in its timing From the perspective of the IIDAL, the
KN58AB CPU module appears as a CVAX when it is the 1IDAL bus

master.

4.6.2

Rezd Operation
An 1IDAL read operation is initiated whenever the R3000 misses the firstlevel cache or makes an uncached read reference. The 1IDAL interface
logic can only issue longword reads on the IIDAL bus. At the beginning
of the operation, IIDAL<31.30> specifies a longword transaction and
CSDP<3:0> indicates an I-stream read request, even if data is being
fetched. Read operations typically require two cycles to complete.

A read stall 1s defined as any additional cycles occurring between the
address and data portion of the read operation. This can occur whenever
read data is not readily available. IIDAL control logic 1s stalled by
withholding the IIRDY signal. Stalls occur in increments of one cycle.

4.6.3

Write Operation
During an IIDAL write cycle, the R3020 write buffers output write
information onto the IIDAL bus. A write operation tekes 8 minimum
of 2 cycles and can occur every 4 cycles.

A write stall is defined as any additional cycles occurring between the
address and data portion of the write operation. This can occur any time

write data cannot be readily accepted by the target device. IIDAL control

logic is st 'led by withholding the IIRDY signal. Stalls occur in increments
of one cycle.

KNS584A/B CPU Module

4.6.4

Interrupt Acknowledge Operation
The IiDAL control logic initiates an interrupt acknowledge in response
to an R3000 interrupt acknowledge read reference. When the R3000 is
interrupted, the interrupt is vectored to a single interrupt handler. The
software performs an uncached read reference with address bit <30> set

and bit <31> clear. Address bits <6:2> indicate the IPL (in hex). The other
address bits are zero. This address is then driven onto the IIDAL bus
and CSDP<3:0> indicate an interrupt acknowledge operation. The read
data driven onto the bus in response is the desired interrupt acknowledge
vector. The software uses the vector to jump to the correct interrupt
gervice routine.

46.5

Lock Transactions
The IIDAL control logic initiates a lock transaction in response to an

R3000 read lock reference and an R3000 write unlock reference. The
transaction is initiated on the IIDAL by asserting the correct code on
CSDP<3.0>.

Software generates an R3000 read lock reference by writing the Interlock
Address Register (2013 0000) with the address of the interlock variable.
The software must then read the Interlock Register (2011 0000). This
causes the IIDAL control logic to perform a read lock transaction on the
IIDAL bus using the =ddress in the Interlock Address Register. The read

data is returned to the R3000.

Software generates a write unlock reference by writing the address of
the interiock variable to the Irierlock Address Register (2013 0000).
The software must then write the Interlock Register (2011 0000). This
causes the IIDAL control logic to perform a Write Unlock transaction
on the IIDAL bus using the address in the Interlock Address Register.
To maintain consistency between the first-level and second-level caches,

the unlock write transaction must be preceded by a cached write to the
interlock variable.

Note that only the lock transaction occurs on the IIDAL bus. The writing

of the Interlock Address Register and any reads or writes of the Interlock
Register will not appear on the IIDAL bus.

4.6.6

DMA onthellDAL Bus
The KN58A/B CPU module contains DMA logic that controls the granting
of the IIDAL bus. There are three possible masters of the IIDAL bus:
*

The CVAX chip (on the KN58A/A interface module)

The IIDAL control logic

KN58A/B CPU Module

The XCPGA (on the KN5S8A/A interface module)

The CVAX or XCPGA is bus master only at power-up or after reset. At
power-up or after reset, bus ownership defaults to the CVAX and the
XCPGA must request the bus to gain ownership. Setting bit <24> of CSR1
allows the IIDAL control logic to gain ownership of the bus. When this bit

is set, bus ownership defaults to the IIDAL control logic and the XCPGA
must request the bus to gain ownership.

4.6.7

idle
The IIDAL bus is idl2 when no activity is taking place on it. During an

idle, the IIDAL lines are undefined and the control signals are deasserted.

4-51

)19
6.0.0.60006.8.0.0.004¢
0
¢
P0:6.0.0:5.8:4:0.5.0:9,0.0.94
P00 9:0.0.0.8.0.4,6.0
¢4
.
0.0.:9.0:0.0.6.04.94
P4
84044994
XHOGHXX
XHKEK

RAX
X

X
XXX
XXXXX

XXHXXXX

£0.4.4.0.4.64.44
XXXUXXXXXXK
AXAXXKKUXKXXX
XXXYEXXXAKEKLKXAXK
f O0400644404844

XXXXAALLXK
XXX AKXXKXK
P00 00400.6.000006880460
P OO0 000
08000008098
80404

KXEXXERXUXKKXK
L LXK EXHEXKNH
XXX IO

Y XA XXX XA XA XAIAXEN,

00000000 ¢6890098840¢00444

PSS S

E 0000080408 50800.68620040¢4

0000800000000
00 0884090680 ¢808004
OOCOCRONNN
XXX XX KX KU KO KK HKXAEX

XXXX0GOGoOO0OONOI
XXX XXX X NXKX
PO 000000000 800000808040
8008 800000860004
PO
040000080808
0000 iP0ee
09 880008000 9080044

MS62A Memory Module

The MS52A memory module is a metal-oxide semiconductor (MOS),

dynamic random access memory (DRAM), that provides 32 Mbytes of data
storage. The memory array is designed for use in the DECsystem 5800
system and communicates over the XMI bus.
This chapter contains the following sections:
Module Features
Technica! Description

Self-Test and Initialization

Starting Address and Interleaving
Control and Status Registers
Error Handling and Command Responses

MS62A Memory Module

5.1

Module Features
The MSE2A memory module is 2 dynamic random access memory
(MRAM) that communicates through the XMI bus to provide
DECsystem 6800 system memory.

The MS62A memory module has the following features:
¢

'The memory module contains MOS dynamic RAM (DRAM) arrays, a

Storage arrays are made up of four banks of 72 DRAMs.

e
e

CMOS gate array (that contains error correction code (ECC) logic and
control logic), and an XMI interface (the XMI Corner).
ECC logic detects single-bit and double-bit errors and corrects single-

bit errors.

Memory self-test checks all RAMS, the data path, and control logic on
power-up.

Quadwords, octawords, and hexwords can be read from memory.

Quadwords and octawords can be written to memory.

The memory can be configured by the system for 1-, 2-, 4-, 8-way, 71 no
interleaving.

5-2

MS62A Memory Module

5.2

Technical Description
The MS62A memory module uses XMA logic, DRAM arrays, and
a PROM to provide 32-Mbytes of memory to the DECsystem 5800
system.

The MS62A memory module consists of the following major components:
¢

XMI Corner

XMA gate array

Address and control logic

DRAMs

The XMI Corner is the module’s interface to the XMI bus and contains
CMOS gate arrays and interface logic. Its primary purpose is to transfer
data between the MS62A memory module and the KNG8A processor.

The XMA gate array transfers data between the XMI Comner and the
DRAMs. The gate array also controls address multiplexing, command
decoding, arbitration, and CSR logic functions.

Address and control logic modifies address bits received from the XMI
Corner. These modified address bits are used to control the selection of the
DRAMs during reading and writing.
Ali power for the XMI memory array is supplied from +5V. If power to the
system is lost, memory is lost as well.

MSE62A Memory Moduls

Self-Test and Initialization
The MSS2A memory module performs an initialization and self-test
sequence on a cold power-up or when the sequence is requested by
a congole command.

During a cold power-up the gate array chip is initialized, all memory
locations are tested, and the control and status registers are initialized.
A warm power-up occurs when the system loses power. During a warm

power-up, self-test is not run and memory contents are unmodified.
However, any data in the data path is lost.

Memory self-test takes about 60 seconds to run. While self-test runs, the

Fault light on the system front panel is on. When self-test completes, the
Fault light goes off and the console printout of self-test begins. For details
on the self-test console printout, refer to Chapter 6 of the DECsystem 5800
Owner’s Manual.

MS62A Memory Module

5.4

Starting Address and Interleaving
On power-up the DECsystem 6800 console firmware loads the
Starting and Ending Address Register (SEADR) with the starting
address, the interleave mode, and the ending address. The
following paragraphs describe how to set the SEADR for proper
system operation. Section 5.5 gives a description of the SEADR.

5.4.1

Starting and Ending Addresses
The memory responds to starting addresses on any 2-Mbyte boundary.
The ending address is also on any 2-Mbyte boundary. The ending address
must be greaier than the starting address to ensure that data will not
be overwritten. The ending address minus the starting address must be
equal to or less than tke memory size multiplied by the number of ways
interleaved.

EA - SA = Memory Size X (# of ways interleaved)

Starting addresses for memory can be in the range from 0 to 510 Mbytes
and ending addresses in the range from 0 to 512 Mbytes. Ending
addresses greater than 512 Mbytes are not permitted. The area above
512 Mbytes is reserved for CSR addresses.

54.2

Interleaving
Interleaving achieves greater throughput to memory by optimizing
memory access time and increasing the effective memory transfer rate.
This is done by operating memory modules in parallel.
The memory array supports 1-way, 2-way, 4-way, §-way, or no interleaving

at the system level. Up to eight memory array modules can be interleaved.
interleaving is done on hexword boundaries.

MS62A Memory Module

5.5

Control and Status Registers
The CSR names and their relative addresses are shown in
Table §-1. Descriptions of the CSRs are also included in this
section.

Tabie 5-1

RS62A Memory Module Control and Status Reglsters

CSR Name

Mnemonic

Address

Bus Error Register

XBER

8B + 0000 0004

Starting and Ending Address Register

SEADR

8B + 0000 0010

Memory Control Register 1

MCTL1

BB + 0000 0014

Memeory ECC Error Register

MECER

BB + 0000 0018

Memory ECC Error Address Register

MECEA

BB + 0000 001C

Maemory Contro! Register 2

MCTL2

BB + 0000 0030

TCY Registor

TCY

BB + 0000 0034

Device Register

Interlock Flag Status Registers

XDEV

IFLGn

BB'+ 0000 0000

BB + 0000 0007

‘

'=BB" rafers to the base address of an XMI node (2180 0000 + (node 1D x 8000)).
2Refer to the Interlock Flag Status Register description for the relative address of the
Interlock Flag Status Registers.

The memory contains 24 control and status registers (CSRs) to control
the memory and log errors. All CSRs are 32 bits long and respond only to

longword read and write transactions. When writing to the CSRs, only full .
writes are performed. If a parity error occurs during a write operation, the
operation is aborted and the contents of the CSRs are unchanged.
Some bits in the registers are cleared on power-up, while others need a
one written to them to clear.

The CSRs siart at an address dependent upon the node ID. All CSR
addresses are designated as BB + n, where n is the relative offset of the
register.

MS62A Memory Module

The following definitions apply to the descriptions of the control and status
registers.

CRD error - A correctable single-bit error.

RDS error - An uncorrectable double-bit error that occurs when the
syndrome bits represent an unused ECC code.
RER error - A general uncorrectable double-bit error indicator that
includes an RDS error, a row parity error, a column parity error, or a byte
write error.

RO - Indicates a read-only register.

RO, 0 - Indicates a read-only register, cleared on power-up.
R/W - Indicates a read and write register.

R/W, 0 - Indicates a read and write register, cleared on power-up.

R/W1C - Indicates a read and write register, write a one to clear.

R/WI1C, O - Indicates a read and write register, write a one to clear, and
cleared on power-up.

R/W1C, 1 - Indicates a read and write register, set on power-up.

W/0, 0 - Indicates a write only register, cleared on power-up.

5-7

MS62A Memory Module Registers
Device Register (XDEV)

Device Register (XDEV)
The Device Register contains information to identify the MS62A memory
module. Both fields are loaded during node initialization. A zero value
indicates an uninitialized node.

ADDRESS

Nodespace base adaress + 00000 0000
n

Must Be Zero (MB2Z)

18 15

Device Type (DTYPE)

l-—— Device Revision (DREV)
mab-0377-88

bits<31:20>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

bits<19:16>

Name:

Device Revision

Mnemonic:

DREV

Type:

Identifies the revision level of the MS62A memory module. The use of
the Device Revision field is implementation dependent. The field does
not indicate the hardware revison level, only the functional level.

bits<15:0>

Name:

Device Type

Mnemonic:

DTYPE

Type:

Identifies the type of node. The device type for an MS62A memory
module is 4001 (hex). This value is set in the Device Register.

MS62A Memory Module Registers
Bus Error Register (XBER)

Bus Error Register (XBER)
The Bus Error Register records error and status information about the XMi

bus.

ADDRESS

Nodespace base address + 0000 0004

30 20 28 27 26 25 24 23 22 21

0|0}

[MB

19 18 17

6 15

Must Be Zero (MB2)

Must Be Zero (MBZ)

I l——- Self-Test Fail (STF)

Node-Specific
Emor Summary (NSES)

Read Data NO ACK (RDNAK)
Write Sequence Error (WSE)

I Parity Error (PE)

Corrected Confirmation (CC)

Node Reset (NRST)

L————- Error Summary (ES)
bit<31>

Name:

Error Summary

Mnemonic:

Type:

RO, 0

mar-0376-89

This bit state represents the logical OR of the error bits in this
register.

bit<30>

Name:

Node Reset

Mnemonic:

NRST

Type:

W/0, 0

Writing a one to this location initiates a complete node reset, including
self-test.

MS62A Memory Module Registers
Bus Error Register (XBER)

bite<29:28>

Name:

Reservad

Mnemonic:

None

Type:

Reserved; must be zero.

bit<27>

Name:

Corrected Confirmation

Mnemonic:

Type:

RW1C, 0

This bit is set when the XMI Corner interface (XCI) bus detects a

single-bit error on the XMI CNF bits.

bits<26:24>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<23>

Name:

Parity Error

Mnemonic:

Type:

RWI1C, 0

This bit is set when the node detects a parity error on an XMI cycle.

bit<22>

Name:

Write Sequence Error

Mnemonic:

WSE

Type:

RWIC, 0

When set, indicates that the node aborted a write transaction due to
one or more missing data cycles.

bit<21>

Name:

Read Data NO ACK

Mnemonic:

RDNAK

ype:

RWIC, 0

When set, indicates that the node received a NO ACK confirmation for
a data cycle it transmitted.

5-10

MS62A Memory Module Registers
Bus Error Register (XBER)

bits<20:13>

Name:

Resserved

Mnemonic.

None

Type:

Reserved; must be zero.

bit<12>

Name:

Node-Specitic Error Summary

Mnemonic:

NSES

Type:

RO, 0

When set, this bit indicates tha: a noede-specific error condition has
been detected. The exact nature of the error is located in the memory
error status registers.

bit<ii>

Name:

Reserved

Mnerntonic:

None

Type:

Reserved; must be zero.

bit<10>

Name:

Selt-Test Fail

Mnemonic:

STF

Type:

RW1C, 1

While set, tt is bit indicates that the nod 2 has not yet passed its selftest. This bit is cleared when self-test suscessfully completes. This bit
also drives XMI BAD (an XMI bus signal that reports node failures).
Clearing this bit also clears XMI BAD.

bits<9:0>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

511

MS62A Memory Module Registers

Starting and Ending Address Register (SEADR)

gtarting and Ending Address Register (SEADR)
The Starting and Ending Address Register contains the memory starting
and ending addresses. See Section 5.4.1 for a description of the rules that
must be followed when setting these addresses. This register aiso sets the
inteiteave mode.

ADDRESS

Nodespace base address + 0000 0010
N

21 20

MBZ

16 15

M8z

86 5

Mez

L— Ending Address (ENDADR) -J
Starting Address (STRADR;
interleave Address 2 (INAD2)
Interleave Address 1 (INAD1)
Interleave Address O {INADO)

Inteiteave Mode 1 (INTM1)

Interieave Mode G (INTMO)
mab-0664-90

bits<31:30>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bits<29:21>

Name:

Ending Address

Mnemonic:

ENDADR

Typs:

RW. 0

The Ending Address for the 1iemory on 2-Mbyte boundaries. The
memory is enabled if the ending acdress is greater than the starting
address. The ending address range is from 0 to (510 Mbytes + 2
Mbytes).

5-12

MS62A Memory Module Registers
Sterting and Ending Address Ragister (SEADR)

bits<20:16>

Nama:

Resen s

Mnemonic:

None

Type:

Reserved; must be zero.

bits<15:8>

Name:

Starting Addrass

Mnemonic:

STRADR

Type:

RW, 0

The Storting Address for the memory on 2-Mbyte boundaries. The
starting address range is from 0 to 510 Mbytes.

bits<7:5>

Name:

Interleave Address

Mnemonic:

INADn

Type:

RW, 0

The address bits used for interleaving. This address determines to
what address the module will respond.

bits<4:2>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bits<1:0>

Name:

interleave Mode

Mnemonic:

INTLMn

Type:

RW, 0

These bits show how many ways the module is being interleaved and
are used to determine the addresses that the module will respond to.

§-13

MS62A Memory Module Registers

Memory Control Register 1 (MCTL1)

Memory Controi Register 1 (MCTL1)
The Memory Control Register 1 along with the Memory Control Register 2
contains memory-specific control, status, and eror bits. The MCTL1 Register
also controls the diagnostic modes of the inemory module.

ADDRESS

Nodespace base address + 0000 0014
3t 30 20 28

19 17 18 15 14 13 12 1t 10 © @&

MEMSIZ

MBZ

Diagnostic Check
(DIAGCK)

ECC Diagnostic (ECCDIAG)

= Emor Summary (ERRSUM)

- m;m‘m;nxoi';;)‘umeo)
- Enable Protecticn Mode (EPM)

— Memory Valid (MEMVAL)

L Inhibit CRD Status (ICRD)

~ RAM Typo (RAMTYF)

bit<31>

Name:

Error Summary

Mnemonic:

ERRSUM

Type:

ma0860-90

This bit contains the ORed sum of error bits in MCTL1, MCTL2, and
Memory ECC Error Registers.

b“e 30>

Name:

ECC Diagnostic

Mnemonic:.

ECCDIAG

Type:

RW, 0

This bit is used for diagnostic purposes.

5-14

MS62A Memory Module Registers
Memory Control Register 1 (MCTL1)

bit<29>

Name:

ECC Disable

Mnemonic:

ECCDIS

Type:

RW, 0

This bit is used for diagnostic purposes.

bits<28:18>

Name:

Memory Size

Mnemcnic:

MERMS!IZ

Type:

These bits contain the memory module size in 256-Kbyte increments,
where 00000011000=6 Mbytes, 00000100000=8 Mbytes, and
00010000000=32 Mbytes.

bits<17:16>

Name:

RAM Type

Mnemonic:

RAMTYP

Type:

These bits contain the size of the RAM.

bit<15>

Name:

Inhibit CRD Status

Mnemonic:

ICRD

Type:

RW, 0

This bit inhibits the reporting of CRD status to the commander on
read cycles. When this bit is set, any CRD response is changed to a
GRD response. The CRD errors are still logged, and RER errors are
logged and reported normally.

bit<14>

Name:

Memory Valid

Mnemonic:

MEMVAL

Type:

RO, 0

This bit indicates that valid data is stored in memory. The bit is set on
the first write to the module memory space.

515

MSE2A Memory Moduls Reglsters
Memory Control Register 1 (MCTL1)

bit<13>

Name:

Enable Protection Mode

Mnemonic:

EPM

Type:

RW, 0

When this bit is set, the operation of the ECC Diagnostic <30> and
ECC Disable <29> bits are inhibited in the first 2 Mbytes of memory
space, starting address to starting address plus 2 Mbytes.
o

bit<12>

Name:

Lock Queue Error

Mnemonic:

LQERR

Type:

AWIC, 0

This bit is set if a data word is sent as a response to an Interlock Read
and no lock is pending in the memory.

bit<ii>

Name:

Unilock Sequence Error

Mnemonic:

UNSEQ

Type:

RAWIC, 0

This bit is set if an Unlock Write transaction is accepted and no
corresponding matching location is marked as locked. Either an
Interlock Read was never performed to this location, the lock did not
get, or the lock might have been cleared by another source.

bit<10>

Name:

MWrite Error

Mnemonic:

MWRER

Type:

RW1C, 0

This bit is set on an RDS error during a partial write cycle.

Dits<9:8>

Name:

Ressrved

Mnemonic:

None

Type:

Reserved; must be zero.

5-16

MS62A Memory Module Registers
Memory Control Register 1 (MCTL1)

bits <7:0>

Name:

Diagnostic Check

Mnamenic:

DIAGCK

Type:

RW, 0

These bits are used during ECC diagnostic mode as substitute check
hits.

5-17

MS62A Memory Module Registers
Memory ECC Error Register (MECER)

Memory ECC Error Register (MECER)
The Memory ECC Error Register lons ECC error status. The MECER also
icgs uncorreciable error codes for row parity error, column parity errors, and
byte write errors. The MECER logs ECC emor information during read cycles
only. if an RER error occurs during a Write Mask cycle, the MWRITE eror bit
in the MCTL1 Register is set.
This register logs ECC error type and error syndrome information when
correctable and uncorrectable errors occur during Read transactions. During
a Write Mask transaction, only the MWRITE error bit logs the fact that the
ECC error occurred.
For read accesses, the register logs the first correctable emor and holds it

until either an uncorrectable error occurs or the error is cleared. Additional
correctable errors are only reported and are not logged. An uncorrectable
error will overwrite a logged comrectable error. A correctable error will not
overwrite a logged uncorrectable error or a previously logged comectable error
until the error has baen cleared.
This register logs errors during moduie seif-iest.

ADDRESS

Nodespace base address + 0000 0018
31 30 B 2027 WB M

MUST BE ZERO

Emor Syndrome (ERSYN) —l
Column Parity Error (CPER)

Row Parity Error (RPER)
Byt Write Emor (BWERR)
CRD Error (CRDER)
High Error Rate (HIERR)
Uncorrecteble Double-Bit (RER) Error (RERER)

bit<31>

Name:

Uncorrectable Double-Bit (RER) Emor

Mnemonic:

RERER

Type:

RWiC, 0

This bit indicates that an uncorrectable error occurred during a read

transaction. The Error Address and Error Syndrome are valid for the
uncorrectable double-bit error. If the Column Parity Error bit, the Row

Parity Error bit, and the Byte Write Error bi¢ are not all set, then the ‘

uncorrectable double-bit error is an RDS error.

5-18

MS62A Memory Module Registers
Memory ECC Error Register (MECER)

blt<30>

Name:

High Error Rate

Mnemonic:

HIERR

Type:

RW1C, 0

This bit indicates that another error, RER or CRD, occurred before the
previous one was cleared from the register.

bit<29>

Name:

CRD Error

Mnemonic:

CRDER

Type:

RW1C, 0

This bit indicates that a CRD error occurred during a read transaction.
This includes a single-bit error in the check bits, =ven though no
correction is done on the data bits. The error address and error
syndrome are valid if no RER error log exists.

bit<28>

Nama:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<27

Name:

Byte Wiits Ericr

Mnemonic:

BWERR

Type:

RO, 0

This bit indicates that the RER error was due to reading a location
that was marked bad during a partial write cycle that had previously
detected an RER error. Cleared when MECER<31> is cleared.

bit<26>

Name:

Row Parity Error

Mnemonic:

RPER

Type:

RO, 0

This bit indicates that the RER error is due to a row address parity
error. Cleared when MECER<31> is cleared.

5-19

MS62A Memory Modiule Registers
Memory ECC Error Register (MECER)

bit<25>

Nams:

Column Parity Error

Mnerionic:

CPER

Tvoe:

RO, 0

This bit indicates that the RER error is due to a column address parity
error. Cleared when MECER<315> is cleared.

bite<24:8>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bits<7:0>

Name:

Error Syndrome

Mnemonic:

ERSYN

Type:

RO, 0

These bits are the syndrome bits of the location in an RER or CRD

error.

5-20

MS62A Memory Module Registers
Memory ECC Error Address Register (MECEA)

Memory ECC Error Address Register (MECEA)
The Memory ECC Error Address Register logs the address of correctable and
uncorrectable errors logged in the Memory ECC Error Register.

For read accesses, this register logs the address of the first corrected read
data (CRD) error and holds it until a double-bit uncorrectable error (RER)
occurs or the error is cleared. An RER error causes a logged CRD error
address to be overwritten. A CRD will not overwrite a logged RER error

address. If multiple RER emors occur, only the first error address is logged.
This register logs errors during seif-test.

ADDRESS

Nodespace base addre:ss + 0000 001C
313029

210

MBZ

bits<31:30>

ERROR ADDRESS (ERRAD)

Namae:

Reserved

Mnemonic:

None

Type:

]MBZ

Reserved; must be zero.

bits<29:3>

Name:

Error Address

Mnemonic:

ERRAD

Type:

RO, 0

The error address of the RER or CRD error logged in the Memory ECC
Error Register. This register is valid only if the RER or CRD Error log
bits are set in the Memory ECC Error Register. This address is the
bus address of the cycle that was being performed at the time of the
error.

bits<2:0>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

521

MS62A Memory Module Registers
Memory Control Register 2 (MCTL2)

Memory Control Register 2 (MCTL2)
The second memory controi reg:ster contains additional co.trol and error

status information.

ADDRESS

Nodespace base address + 0000 0030
2

16 1§

MUST BE ZERO

Refresh & or (RERR) —J

210

MUST BE ZERO

Disable Hold (DISH) —-I I

Refresh Rate<2> (RRB2)

Refresh Rate<1> (RRB1)
Refresh Rate<0> (RRBO)
Arbitration Suppression Control <1> (ARBSC1)

Arbitration Suppression Control <0> (ARBSCO)
ran-0681.00

bits<31:17>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bit<16>

Name:

Refresh Error

Mnemonic:

RERR

Type:

AW1C, 0

This bit is set if a refresh request is set, and a second refresh request
is asserted before the first one is implemented, meaning that a refresh
was missed.

bits<15:6>

Name:

Reservad

Mnemonic:

None

Type:

Reserved; must be zero.

5-22

’

MS62A Memory Module Registers
Memory Control Register 2 (MCTL2)

bit<5>

Name:

Disable Hold

Mnemonic:

DISH

Type:

RW, 0

This bit is used by memory arbitration logic to disable the use of XMI
HCLD L.

bits<4:2>

Name:

Refrash Rate

Mnemonic.

RRB

Type:

RwW

This bit controls the module’s DRAM refresh rate.

bits<1:0>

Name:

Arbitration Supression Control

Mnemonic;:

ARBSCn

Type:

RW, 0

These bits control the Arbitration Supression mode.

MS62A Memory Module Registers
TCY Taster Register (YCY)

TCY Tester Register (TCY)
The TCY Tester Register contains contro! bis to implement manufacturing
tests.

ADDRESS

Nodespace base address + 0000 0034
31

MUST BE ZERO

l.__ TCY Mode (TCYM)

|
ECC Test (ECCT)
TCY Refresh Request (TRR)
mab-0565-90

5-24

MS62A Memory Module Registers
Interlock Flag Register (IFLGn)

Interlock Flag Register (IFLGn)
The Interlock Flag n Register (IFLGn) (where nis 0 to 15) holds the address

and D of the last interlock flag only if all lower interlock flags are set. The
locations of IFLGn flags are shown in the relative address table.

ADDRESS

Nodespace base address + (relative address)

Interock Address (IADR)

Lower Interlock 1D Bits <4:0> (LIID) ——-l
Interlock 1D Bit <5> (IIDB)
Inteilock Flag n (IFLG)
(where nis the number of the
Intertock Flag Register (0-15))

mab.0378-89

interlock Flag Register

Reolative Address

Interlock Flag 0 Status Register

BB+ 20

Interiock Flag 1 Status Register

BB + 24

Interlock Flag 2 Status Register

BB + 28

interlock Flag 3 Status Register

BB + 2C

Interlock Flag 4 Status Register

BB + 40

Interlock Flag 5 Status Register

BB + 44

intarlock Flag 6 Status Register

8B + 48

interlock Flag 7 Status Regisier

BB + 4C

Interlock Flag 8 Status Register

BB + 80

Interlock Flag @ Status Register

BB + 84

interiock Flag 10 Status Register

BB + 88

interiock Fiag 11 Status Register

BB + 8C

interlock Flag 12 Status Register

88 + 100

Interlock Flag 13 Status Reqister

BB + 104

interlock Flag 14 Status Register

BB + 108

interlock Flag 15 Status Register

88 + 10C

MS62A Memory Module Registers
interiock Flag Reglster (IFLGn)

bit<31>

Name:

interlock Flag n

Mnemonic:

IFLGn

Typs:

RWI1C, 0

This bit is Interlock Flag n, where n = (0-15). If asserted, the Interlock
Address and Interlock ID are valid and the lock is set. The lock cannot

be set by writing directly to IFLGn. Writing a one to IFLGn clears the
lock.

bit<30>

Name:

Interiock IiD <5>

Mnemonic:

1IDB

Type:

RO, 0

IIDB is the most significant ID bit of the Interlock Read transaction.
This bit is valid only if Interlock Flag n is set.

bit<29>

Name:

Reserved

Mnemonic:

None

Type:

Reserved; must be zero.

bits<28:5>

Name:

interlock Address

Mnamenic:

1ADR

Tvpe:

RO, 0

IADR gives the address of the Interlock Read transaction. It is valid
only if Interlock Fiag n is set.

bits<4:0>

Name:

Lower Interiock ID <4:0»

Mnemonic:

LIID

Type:

RO, 0

LIID are the lower four ID bits of the Interlock Read transaction.
These bits are valid only if Interlock Flag n is set.

5-26

MS62A Memory Module

5.6

Error Handling and Command Responses
The following paragraphs describe how the memory responds to
an error condition. The memory performs single-bit correction
and double-bit detection on the data stored.

56.1

[Read Errors
If no errors occur during a read operation, a Good Data (GRDn) function
code is returned with the data. If a correctable error occurs during the
read operation, a Corrected Read Data (CRDn) function code is returned.
If an uncorrectable error occurs, a Read Error Response (RER) is returned
in place of the data.

The lock bit is not set if:

An RER error occurs during an Interlock Read transaction.

The confirmation of Interlock Read data is missing or bad.

A locked response is sent if:

The address of an Interlock Read transaction matches a locked
hexword.

5.6.2

All locks are set and memory receives an Interlock Read request.

Full Write Errors
A full write is performed on a quadword or octaword, dependent on
the number of mask bits that are set. If mask bits <47:32> are set, an
octaword write transaction takes place. If mask bits <35:32> are set,
a quadword write transaction takes place. Write data is written into
memory with the generated ECC check bits. The write transaction does
not begin until all the write data is received from the XMI bus and checked
for parity.

If an XMI parity error occurs on one or more quadwords of received data,
the write will not begin and a NO ACK response is returned.

§-27

MS62A Memory Module

5.6.3

Partial Write Errors
If the mask bits for a quadword or octaword are not all set, a partial write
is performed. After write data is merged with read data, the write data is

written into memory. If the reed data is correct, the write is completed.
If a correctable read error occurs, the write continues to completion
with the corrected data. Uncorrectable read data causes the old data

to be rewritten with a Byte Write Error ECC code to mark the location
defective. If the cycle is an Unlock Write cycle, an uncorrectable error
causes the location to be marked bad and the interlock flag cleared.
If an XMI parity error occurs on one or more quadwords of received data,
the write does not begin. If the parity error occurs during an Unlock Write

command or data cycle, the lock is not reset.

5-28

KKIGOIH XXX N Y KKK EHKKR
KIOOORHRKKHANR ¥ LRI
GX
RO
OOCOOCONOOON
HHHHH KA K H KR KKK LXK RO
K XK AKX XXX XX KX
MR X XA K K H KRR
N
OO
N
KXY
ERRHMK KX KRNX0NCCNOGONNGINNNNI

PO EH

PSSO

O09.00080800050800848001

HR
ROCO0O0X
OCGLRAOC
ALK
FEHHHHIH

KKK EONON0GNNEINE XU XXKXKX
X
XK
XKHHRXK OO ONONOOOCH
U
KRHHR

RHHOOCOGOODHRAARAA
UK

44
P8 000086.0000060088880884500

#:914.0.6.00.69.0.6.960088066088804
P16
POV

P00 00000000600 0004

HUHAX XXX KEKHA KN KRHKATKKK
PO 40006008080 86¢80¢001
PO SIS04000880009088

P8.4.4:¢.4.0.4.4:0.9.9.9.9.9¢.94
HHAAXKXKHAKKAXKK
P10 9.0.0.0.60.9 80604

AKX

P4.9.9.9.9.9.9.¢.4
1904 8.4 ¢

HUHXX
XXX
X

X
XXX
XXXXX
XXXXXXX

XXXXXHKAX
HXXXAAKXXXK

AXXXAXKXKKAXXX

HXHXLAXAXXXXXKK
XX XXXAXAXKXAXXKKK
KXXKXXXXKNKXAKXXXKXKXK

XX HXXKK
XUXHKOOOCOHHLL

860003
P8.0.0.09.400.04.840¢088

XK UXKAKXK
XXX XU XXXAXK
XXHHX
ML XA KKHURAXAX
KROOIROOONO
800904
D0.0.0.0.0.050000008080086080

8084088888000/
00800
00008
06000
P00

8
00080066 988000004
000600040008
B0
AEEAKXK
AKX
AKX
XK
XXX RO XX R LA

KEAKKKKX
X UK AR XXX K AKXOOL
FXHXXOOHRC
KR KOO XX R AR KX R XIHA XA KX A KKXKR

000 840004
000
0 800 0000000040080
2088460000
PO
P9 900148 0000808.006.0040006000888080.90960689000]

0080800860084
000000
088
P90 0008080000 8040800000
XXX UK KK AKX UK UL KKK KKK
MOOH R XXX KOO
XXX XX XXX X KK XX KX
KX ONNOIK
OO0O0ONNNNOGON
O
XXX XX XXX KX AX KKK KK
N IR XGOOE
CINO0ORO
XSO0

DWMBA XMIi-to-VAXBI Adapter

The DWMBA XMI-to-VAXBI adapter provides an information path
between the XMI bus and I/O devices on the VAXBI bus.
This chapter contains the following sections:
DWMBA Overview
CPU Transactions

DMA Transactions
DWMBA Registers
Interrupts

Error Reporting

DWMBA Initialization, Self-Test, and Booting

6-1

DWMBA XiMi-to-YAXBI Adapter

6.1

DWMBA Overview
The DWMBA XiMI-to-VAXBI adapter provides an information path
between the XMI bus and VD devices on the VAXBI bus. The
DWHMBA consiets of tws modules: the DWRMBA/A XMI module and
the DWMBA/B VAXBI meodule. The IBUS connects the two modules.

Figure 6-1

DWMBA XRMi-to-VAXBI Adapter Block Dlagram

DWMBA/A

DWMBA/B
BuUsS
MODULE
LOGKC §@—8% MODULE
LOGIC

XMI

n—urconuen

vV
Hhat

12012 MODULE

71043 MODULE

VAXB!

DWMBA XMi-to-VAXBI Adapter

The DWMBA/A module contains an XMI Corner, register files, XMI

required registers, DWMBA-specific registers, and control sequencers for
the XMI interface.

The DWMBA/B module contains a BIIC, iaterconnect drivers, control
sequencers to handle the control of the data transfer, status bits to/from
the DWMBA/A module's register files and the BIIC, DWNMBA/B module
specific registers, decode logic for DMA operations, and VAXBI clockgeneration circuitry.

These two modules are connected by four cables of 30 wires each. The 120
wires make up the IBUS, which transfers data and control information
between the two modules.
The DWMBA uses CPU and DMA transactions to exchange information.
CPU transactions originate from the KN58A processor(s) and are
presented to the DWMBA from the XMl bus with the CPU as the XMl
commander and the DWMBA as the XMI responder.
DMA transactions originate from VAXBI nodes that select the DWMBA
as the VAXBI slave. These are read or write transactions targeted to
XMI memory space or are VAXBI-generated interrupt transactions that
target a KN58A processor. For DMA transactions, the DWMBA is the XMl
commander and the MS62A memory module is the XMI responder.
Write transactions, whether DMA or CPU, are always disconnected. This
means that as soon as either the CPU or the VAXBI master issues the
write, it waits for an ACK confirmation that the command and write data
was accepted but not necessarily completed at the destination. If the write
faiis, an IVINTR is returned.
The DECsystem 5800 system uses a 30-bit physical address. Chapter 2
describes the XMI address space. The VAXBI Options Handbook describes
the VAXBI address space. The DWMBA can be both a master and a slave
on the VAXBI. As a master, it carries out transactions requested by its
XMI devices. As a slave, it responds to VAXBI transactions that select its
node.

DWMBA XMi-to-VAXEBI Adapter

CPU Transactionsj
The DWMBA XMI-to-VAXBI adapter translates XMI transactions
into equivalent VAXBI transactions. Regardless of whether the
transaction ie a read, write, or IDENT, scftware need not concern
itself with the details, as the XMI transaction behaves as it would
if it were directed to memory or other XMl devices.

Table 6-1

XAdl-to VAXBI Command Transiations

]

VAXBI

Longword Read

Quadword Reud

liegal

Octaword Read

llegal

Hexword Read

llegal

Longword Interlock Read

Longword Interiock Read {IRCI)

Quadword interlock Read

lllegal

Qctaword Interlock Read

llsgal

Hexword Interlock Read

Hegal

Longword Mask Writa

Longword Write Mask (WMCH)

Quadword Mask Write

llegal

Octaword Unlock Write Mask

egal

Longword Unlock Write Mask

Longword Unlock Write Mask (UWRCH)

Quadword Unlock Write Mask

llegal

Octaword Unlock Write Mask

{legal

interrupt Request (INTR)

Hiegal

indentify (\{DENT)

IDENT

implied Vector Interrupt (IVINTR)

lliegal

DWMBA XMi-to-VAXBI Adapter

6.2.1

General Operation
The DWMBA responds to XMI longword transactions. When an XMI
commander issues a Read, Interiock Read, Write Mask, Unlock Write
Mask, or IDENT targeting the DWMBA, the XMI commander arbitrates
for the XMI bus, wins the bus, sends out the function, command, address,
ID, and parity. The targeted DWMBA recognizes its ID and returns ACK

or NO ACK (for busy, an error, or illegal transaction). Once the DWMBA
accepts a CPU transaction from an XMI commander, it asserts the NO
ACK confirmation code to all subsequent XMI conmanders that attempt a
CPU transaction until the current transaction completes.
For Read transactions, the DWMBA decodes the XMI command and
determines if the address references VAXBI I/O space or a DWMBA
register. If VAXBI address space is referenced, the DWMBA generates a

VAXBI Read transaction and waits for the return of read data from the
VAXBI. Upon receiving the read data from either the VAXBI or a DWMBA
register, the DWMBA arbitrates for the XMI bus as a responder and
returns the requested data to the commandar. The XMI commander sends
confirmation of the receipt of data back to the DWMBA. If the Read fails,
the XMI commander retries the Read.
Interlock Read transactions are handled the same as Reads except:

DWMBA registers do not support Interlock Reads and handle them
the same as Reads.

If the Interlock Read command that targets the VAXBI bus gets a
RETRY CNF from the VAXBI, the DWMBA returns the Lock Response
back to the XMI commander.

Write transactions to the VAXBI are disconnected. The CPU continues

‘

on after the DWMBA/A ACKs the Mask Write and Unlock Write Mask
transaction if the command/address (C/A) and data received from the XMI

bus is ervor free. The DWMBA decodes the XMI command and determines
if the address references VAXBI I/O space or a DWMBA register. If VAXBI

address space is referenced, the DWMBA generates the corresponding
VAXBI write transaction. If a DWMBA register is referenced, it is written
with the write data. Write ¢zrors cause an IVINTR to be returned to the
CPU.

DWMBA XMi-to-VAXBI Adapter

6.2.2

VAXBI VO Space Reads
The two XMI read transactions are Read and Interlock Read. The XMI
Interlock Read is translated to a VAXBI IRCI transaction while the XMl
Read is translated to a VAXBI Read transaction.

The length of the generated VAXBI transaction must be a longword
(D<31:30> = 01 in the VAXBI command/address cycle). XMI address
bits<28:25> are forced to zero to map XMI addresses to VAXBI addresses
and passed onto the VAXBI. The DWMBA ignores with a NO ACK
confirmation any targeted transaction longer than a longword.

If the VAXBI issues a RETRY on an XMI Interlock Read request to
VAXBI /O address space due to the resource being locked by a previous
Interlock Read request, the DWMBA issues a Locked Response to the XMl
commander.

6.2.3

VAXBI /O Space Writes
The two XMI writes are Mask Write and Unlock Write Mask. The Mask
Write is translated to a VAXBI Write Mask with Cache Intent (WMCI),

while the Unlock Write Mask is translated to a VAXBI Unlock Write Mask
with Cache Intent (UWMCI).

The length of the generated VAXBI transacti>n must be a longwerd
(D<31:30> = 01 in the VAXBI command/address cycle). XMI address
bits<28:25> are forced to zero and passed onto the VAXBI. The DWMBA
ignores with £ NO ACF. confirmation any targeted XMI transaction longer
than a longword. The DWMBA supports interlocked instructions even
though the KN58A processor never issues interlocked instructions to VO
space.

6-6

DWMBA XMi-to-VAXBI Adapter

6.2.4

interrupts

6.2.4.1

XAl IDENT to VAXB! IDENT
When an XMI CPU issues an XMI IDENT, the DWMBA issues a VAXBI
IDENT if the DWMBA does not have a pending interrupt at the IDENT

level. The DWMBA/B module fetches the IDENT command from the
DWMBA/A module’s register file and clears the corresponding level and
interrupt sent flip-flops that were previously set by the VAXBI-initiated
interrupt, providing that no IBUS parity errors are detected.

The DWMBA/B module writes the received vector data into the CPU read
data buffer and notifies the DWMBA/A module that the vector is available.
The DWMBA/A module then issues an IDENT response cycle on the XMI
(with a Good Read Data response where the function code = 100 and the
vector is in bits<15:25).

6.2.4.2

XMI IDENT with DWMBA Adapter Pending Interrupt
If an XMI IDENT is decoded with an IPL matched by the DWMBA/B
module while the DWMBA's interrupt-pending flip-flop is set, the interrupt
vector of the DWMBA is issued to the XMI. The IDENT clears both the
IPL level 17 sent fiip-flop and the DWMBA interrupt-pending flip-flop.
The corresponding level 17 VAXBI interrupt-pending flip-flop, if also set, is
not cleared, resulting in the DWMBA issuing an XMI INTR transaction.

6.24.3

Passive Release of VAXB! interrupts

If the requesting VAXBI node aborts its interrupt request before the XMI
CPU generates an IDENT transaction at that level, the resulting IDENT
on the VAXBI gets NO ACKed. The DWNMBA then issues a Read Error
Response (RER) to the XMI commander.
If an XMI CPU issues an IDENT to the VAXBI and the DWMBA has no
pending flip-flops set, the DWMBA issues the IDENT to the VAXBI. The
resulting IDENT on the VAXBI gets NO AUKed. The DWMBA then issues
a Read Error Response (RER) to the XMI commander and sets the IDENT
Error bit in the DWMBA/B module’s Error Summary Register (BESR<1>»).

6-7

DWMBA XMi-to-VAXBI Adapter

6.3

DMA Transactions
The DWMBA XMI-to-VAXBI adapter translates a VAXBI ¢ ransaction
into an XMI bus transaction when a VAXBI node selec’
s the
DWMBA a2 the slave node for a VAXBI transaction. Tine XMI
bus transaction is serviced by a memory node, and the reqguested
data is then read from or written to XMI memory.

Table 6-2

VAXBI-to-XiM! Command Trangiations

VAXBI

Xean

Interlock Raad with Cache Intent

interiock Read

Read

Read with Cache Intent

Read

Write (LW)

Write Mask on the unused longword
within the XMI quadword

Write (QW)

Write Mask (QW)

Write (OW)

Write Mask (OW)

Write with Cache Intent (LW)

Write Mask on the unused longword

Wirite with Cache Intent (QW)

Write Mask

Write with Cache Intent (OW)

Write Mask

Unlock Write Mask with Cache intent (LW)

Unlock Write Mask

Unlock Write Mask with Cache Intent (QW)

Unlock Write Mask

Unlock Write Mask with Cache Intent (OW)

Unlock Write Mask

Write Mask with Cache Intent (LW)

Write Mask an the unused ongwoid
within the XMI quadword

within the XMi quadword

’

DWMBA XMi-to-VAXBI Adapter

Table 6-2 (Cont.)

VAXBI-to-XM Command Translations

VAXBI

(]

Write Mask with Cache Intent (QW)

Wirite Mask (QW)

Write Mask with Cache Intent (OW)

Write Mask (OW)

interrupt (INTR)

Interrupt

identity (IDENT)

Not supported (NO ACK to VAXBI)'

Invalidate (INVAL)

Not supported (NO ACK to VAXBI)

Broadcast (BDCST)

Not supported (NO ACK to VAXBI)

interprocessor Iitsriupt (IPINTR)?

Interrupt at IPL 16

Stop

Not supported (NO ACK to VAXBI)

'The DWMBA does not procass VAXEI IDENTs onto the XM bus but the DWMBA's
BIIC responds to VAXBI IDENTs that are directed to it if:
— The BIIC detects an error condition that results in a generated interrupt.
~ The user sets the force interrupt bits in the appropriate BIIC register.

~ External logic such as the IPINTR decode logic asserts the BCI INT signal
(pins<7:4> on the BIIC).

25ee Section 6.3.4.

A VAXBI transaction can reference an address between the addresses in
the Starting and Ending Address Registers in the DWMBA's BIIC. VAXBI
transactions c...not access DWMBA-specific registers.

6.3.1

VAXBI-to-XMI Memory Space Rvads
If the incoming VAXBI transaction is a read-type transaction and the

address falls between the address in the DWMBA's BIIC Starting and
Ending Address Registers, the slave sequencer determines if a DMA buffer
is available for use. If so, the slave sequencer moves the C/A data to the
DMA(x) buffer, where x indicates either DMA-A or DMA-B, and notifies
the DWMBA/A module that VAXBI C/A data has been loaded and the
DWMBA/A module should request the XMI bus. The slave sequencer then
issues a STALL response to the VAXBI w.itil the transaction completes.

Later, the DWMBA/A module receives a Read response cycle from XMI
memory with the requested data. The DWMBA/A module loads the
data into the DMA data buffer and notifies the slave sequencer in
the DWMBA/B module that the requested data is available. The slave
sequencer then moves the data to the VAXBI, completing the request.
The DWMBA does not support the caching of memory on VAXBI nodes

8o VAXBI reads are always answered with the VAXBI "don’t cache" read
status.

-9

DWMBA XMi-to-VAXBI Adapter

6.3.2

VAXBI-to-XMI Memory Space Interlock Reads
VAXBI interlock reads (IRCI) behave the same as reads except if a VAXBI
node references a location in XMI memory that is locked. In that case, the
memory roturns a Locked Response (LOC) to the DWMBA. The DWMBA
issues a REIRY confirmation code to the VAXBI commander, releasing the
VAXBI. The DWMBA returns to idle and awaits the next VAXBI request.

6.3.3

VAXBI-to-XM! Memory Writes
The disconnected write mode of operation is used for VAXBI-to-XM!I
memory writes, allowing use of the VAXBI by other devices while the
DWMBA completes the write on the XMI.

The DWMBA's slave sequencer moves the C/A and write data (whether
longword, quadword, or octaword) to an available DMA buffer location
when the incoming write-type VAXBI transaction’s address falls between
the addresses in the DWMBA'S Starting and Ending Address Registers
in its BIIC. The slave sequencer then issues an ACK confirmation to the
VAXBI.

When the buffer load completes, the slave sequencer notifies the
DWMBA/A module’s XMI transmit logic that it should request the XMI
bus. Upon receiving an XMI grant, the DWMBA transmits the write data
transaction and waits for an ACK response.
The DWMBA has two sets of register files, DMA-A and DMA-B, which
allows the DWMBA to accept either a second VAXBI write transaction or
a VAXBI read transaction before the previous XMI write completes. The
DWMBA performs the operations on the XMI in the order that the VAXBI
issues the transactions to ensure that out-of-order sequences do not occur.

If a third VAXBI write transaction occurs before the first and second XMI
writes complete, the DWMBA stalls this VAXBI transaction until the first
XMI write completes successfully.

6.3.4

VAXBI-Generated Interrupts
Interrupts can either be (1) generated by the DWMBA if there is a status
change or an error condition or (2) passed through the DWMBA to the
XMI bus if generated by various I/O devices on the VAXBI bus. These
interrupts are translated into the appropriate XM! interrupt transactions.
If a DWMBA and a VAXBI device interrupt are both pending at the same
IPL when an XMI IDENT transaction is issued, the DWMBA returns its

vector to ensure that DWMBA error interrupts are serviced first.

6-1 LY

DWMBA XMi-to-VAXBI Adapter

6.4

DWMBA XMi-to-VAXBI Adapter Registers
Two sets of registers are used by the DWMBA: DWMBA reg sters
(residing on both modules cf the DWMBA) and VAXBI resisters
(residing in the BIIC). The DWMBA registers include the XMI
required registers and DWMBA-specific registers in D #MBA
private space.

Table 6-3 lists the DWMBA/A module XMI module registers. Table 6—4
lists the DWMBA/B module VAXBI module registers. Table 6-5 lists the
VAXBI registers. See Chapter 5 of the VAXBI Options Handbook for a
description of the VAXBI registers, except for the VAXBI Device Register.
The remainder of Section 6.4 gives detailed descriptions of the DWMBA
registers. The DWMBA/A module registers are presented first, followed b
the DWMBA/B module registers and the VAXBI Device Register.

See Section 2.2.2.3 for more information on /O addressing.
Table 6-3

XMI Ragisters on the DWMBA/A Module

Name

Mnemonic'

Address?

Device Register

XDEV

B88+0000 0000

Bus Error Register

XBER

BB+0000 0004

Failing Address Register

XFADR

B8B+0000 0008

Responder Error Address Register

AREAR

B8B+0000 000C

Error Summary Register

AESR

88+0000 0010

Intarrupt Mask Register

AIMR

B8B8+0000 0014

Implied Vector Interrupt Destination/Diagnostic

AIVINTR

BB+0000 0218

ADG1

B88+0000 001C

Diag 1 Register

'The first letter of the mnemonic indicates tha folluwing:
X=XMI regisier, resides on the DWMBA/A XMI module

A=Resides on the DWMBA/A XM! module
B=Resides on the DWMBA/B VAXBI module

2The abbreviaticn *BB” refers to the base address of an XMl node (the address of the
first iocation of the nodespacs).

6~11

DWMBA XMi-to-VAXBI Adapter

Table 6-4

XMl FRegisters on the DWMBA/B Module

Name

#nemonic’

Address?

Control and Status Register

BCSR

BB+0000 0040

Emor Summary Register

BESR

BB+0000 0044

Interrupt Destination Registar

BIDR

BB+0000 0048

Timeout Address Register

BTIM

BB+0000 004C

Vactor Offset Register

BVOR

BB+CN00 0050

Vector Register

BVR

B8B+0000 0054

Diagnostic Control Registor 1

BDCR1

BB+0000 0058

Reserved Ragister

B8B+0000 005C

'The first letter of the mnemonic indicates the following:
Y2 XMl ragister, resides on the DWMBA/A module
<=Resides on the DWMBA/A module

BaRe..uas on the DWMBA/B module

2The abbreviaiion "BB" refers to the base address of an XMI node (the address of the
first location of the nodespace).

6-12

‘

DWMBA XMi-to-VAXBI Adapter

Table 6-5

VAXS! Reglsters

Name

Mnemonic

Addrese’

Devica Register

DTYPE?

bb+00

VAXBI Control and Status Registar

VAXBICSR

bb+04

Bus Error Register

BER

bb+08

Eror Interrupt Control Register

EINTRSCR

bb+0C

interrupt Destination Register

INTRDES

bb+10

IPINTR Mask Register

IPINTRMSK

bb+14

Force-Bit IPINTR/STOP Destiriation Register

FIPSDES

bb+18

IPINTR Source Register

IPINTRSRC

bb+1C

Starting Address Register

SADR

bb+20

Ending Address Register

EADR

bb+24

BCI Control and Status Register

BCiCSH

bbe28

Wirite Status Re/ister

WSTAT

bb+2C

Force-Bit IPINTR/STOP Command Register

FIPSCMD

bb+30

User Interface Interrupt Control Register

UINTRCSR

bb+40

General Purpose Register 0

GPRO

bb+FO0

General Purpose Register 1

GPR1

bb+F4

General Purpose Register 2

GPR2

bb+F8

General Purpose Register 3

GPR3

bb+FC

Stave-Only Status Register

SOSR

bb+100

Receive Console Data Register

RXCD

bb+200

'The abbreviation "bb" refers ‘0 the base address of a VAXBI node (the address of the
fir
st location of the nodespace).

2Dasrribed in this section.

6-13

DWMBA/A XMi Module Replsiers
Device Register (XDEV)

Device Register (XDEV)
The Device Register contains information to identify the node and is loaded
during node initialization. A zero value ingicates an uninitialized node.

ADDRESS

XMI nodespace base address + 0000 0000
»

1% 13

]

Devics Revision

Davice Typa (2001)
mob 032020

bits<31:16>

Name:

Davice Ravision

Mnemonic:

DREV

Type:

RO, 0

Identifies the functional revision level of the module in hexadecimal.

The DREV field always reflects the letter revision of the module as
follows:

bite<15:0>

DWWMBA/A Adapter Ravigion

DREV (decimal)

DREV (hex)

0001

0002

001A

Name:

Devica Type

Mnemonic:

DTYPE

Type:

RO, 0

Identifies the type of node. DTYPE is 2001 (hex) for the DWMBA/A
module.

6-14

DOWMBA/A XMl Module Registers
Bus Error Reglster (XBER)

Bus Error Register (XBER)
The Bus Error Register contairis error status on a failed XMl transaction. This
status includes the failed commarnd, commander ID, and an error bit that
indicates the type of error that occured. This status remains locked up until
software resets the error bit(s).

ADDRESS

XM nodespace base address + 0000 0004

3% 30 20 28 27 28 25 24 23 22 21 20 19 18 17 W@ 15 14 13 12 11 10 ¢

ojojojijojojolojojojojolojojeioi0lojGj0j1)1

l— Failing Command (FCMD)
Failing Commander D (FCID)

Self-Test Fail (STF)
Extended Test Fail (ETF)
Node-Spacitic Error Summary (NSES)
Commander Errore

- Transaction Timsout (TTO)
— Reserved; must be zero

i L. Command NO ACK (CNAK)
Read Error Response (RER)
— Read Sequence Eror (RSE)
— No Read Respaonse (NRR)

L Corrected Read Data (CRD)
L~ Write Data NO ACK (WDNAK)

Responder Errors
— READ/IDENT Data NO ACK (RIDNAK)

- Write Sequence Error (WSE)

L- Parity Error (PE)

L Inconsistent Parity (IPE)
tizcollancous
— Write Zrror Interrupt (WEL)
L XM Fault ({FAULT)

L Corrected Confirmation (CC)

L XMi BAD (XBAD)

- Node HALT (NHALT)
—

Node Reset (NRST)

— Error Summary (ES)

6-15

DWMBA/A XMI Module Registers
Bus Error Reglster (XBER)

bit<31>

Name:

Error Summary

Mnemonic:

Type:

RO, 0

ES represents the logical OR of the error bits in this register.
Therefore, ES asserts whenever any error bit asserts.

bit<30>

Name:

Node Reset

Mnemornic:

NRAST

Type:

RW, 0

Writing a one tc NRST initiates a power-up reset of the system. Reads
to this bit location return zero. When NRST has a one written to it,
the DWMBA:

Resets all logic on the DWMBA/A module to an initialized (powerup) state.

Asserts the RESET control signal to the DWMBA/B module,
sequencing the VAXBI pov/er supply(s). The assertion of RESET
to the DWMBA/B causes the DWMBA/B to sequence BI AC LO,
and BI DC LO. The assertion of Bl DC LO causes the DWMBA/B
module to reset to an initialized (power-up) state.

When NRST is set, it remains asserted for six to eight XMI cycles,
after which it is cleared by logic on the DWMBA/A module. During the
time that the DWMBA is performing its node reset, it does not affect
the operation of the XMI bus.

bit<29>

Name:

Node HALT

Mnemonic:

NHALT

Type:

AW, 0

Unused; must be zero.

bit<28>

Name:

XM BAD

Mnemonic:

XBAD

Type:

Aw, 0

Unused; must be zero.

6-16

DWMBA/A XMI Module Registers
Bus Error Register (XBER)

bit<27>

Name:

Corrected Confirmation

Mnemonic:

Type:

RWIC, 0

CC sets when the DWMBA detects a single-bit CNF error. Single-bit
CNF errors are automatically corrected by the XCLOCK chip in the
XMI Corner.
i

bit<26>

Name:

XMI FAULT

Mnemonic:

XFAULT

Type:

RWIAC, 0

Unused; must be zero.

bit<25>

Name:

Wiite Error Interrupt

Mnemonic:

WE!

Type:

RAWIC, 0

Unused; must be zero.

bit<24>

Name:

Inconsistent Parity Error

Mnemonic:

IPE

Type:

RWI1C, 0

Unused; must be zero.

bit<23>

Name:

Parity Error

Mnemonic:

Type:

RW1C, 0

When set, PE indicates that the DWMBA has detected a parity error
on an XMI cycle.

bit<22>

Name:

Write Sequence Error

Mnemonic:

WSE

Type:

RW1C, 0

When set, WSE indicates that the DWMBA aborted a write transaction
directed to it due to missing data cycles.

6-17

DWMBA/A X! Module Reglsters
Bus Error Reglster (XBER)

bit<21>

Name:

Read/IDENT Data NO ACK

Mnemonic:

RIDNAK

Type:

RW1C, 0

When set, RIDNAK indicates that a Read or IDENT data cycle (GRDn,
CRDn, LOC, RER) transmitted by the DWMBA has received a NO
ACK confirmation.

bit<20>

Name:

Write Data NO ACK

Mnemonic:

WODNAK

Type:

RW1C, 0

When set, WDNAK indicates that
a Write data cycle (GRDn, CRDn,
LOC, RER) transmitted by the DWMBA has roceived a NO ACK
confirmation.

bit<19>

Name:

Comrectad Read Data

Mnemonic:

CRD

Typ-

RW1C, 0

When set, CRD indicates that the DWMBA has received a CRDn read
response.

bit<18>

Name:

No Read Response

Mnemonic:

NRR

Tvps:

RW1C, 0

When set, NRR indicates that a read transaction initiated by the
DWMBA failed due to a read response timeout.

blit<i7>

Name:

Read Sequence Error

Mnemonic:

RSE

Type:

RWI1C, 0

When set, RSE indicates that a transaction initiated by the DWMBA
failed due to a read sequence error.

6-18

DWMBA/A XMI Module Registers
Bus Error Register (XBER)

bit<16>

Name:

Read Error Response

Mnemonic:

RER

Type:

RWIC, 0

When set, RER indicates that a DWMBA has received a Read Error
Response.
R

bit<15>

Name:

Command NO ACK

Mnemonic:

CNAK

Type:

RWIC, 0

R
I
R
AR

When set, CNAK indicates that a command cycle transmitted by the
DWMBA has received a NO ACK confirmation caused by either a
reference to a nonexistent memory location or a command cycle parity
error. This bit is set only if the reattempts fail.

bit<id>

Name:

Reserved

Mnemonic:

None

Type:

RW, 0

Reserved; must be zero.

bite13>

Name:

Transaction Timeout

Mnemonic.

TTO

Type:

RWIC, 0

When set, TTO indicates that a transaction initiated by the DBWMBA
failed due to a transaction timeout. This bit is set only if the
reattempts fail.

bit<12>

Name:

Node-Specific Eror Summary

Mnemonic:.

NSES

Type:

RO, 0

When set, NSES indicaies that 1 node-specific error condition has
been detected. The exact nature of the error is contained in DWMBAspecific registers.

6-19

DWMBA/A XM! Module Registers
Bus Error Register (XBER)

R R

biteti>

Name:

Extended Test Fail

Mnemonic:

ETF

Type:

RWI1C, 0

CERTTEED

Unused; must be zero.

bit<10>»

Name:

Seit-Test Fail

Mnemonic:

STF

Type:

AWIC, 1

When set, STF indicates that the DWMBA has not yet passed its selftest. This bit is cleared by the CPU node that executed the DWMBA
self-test when the DWMBA passes its self-test.

bits<9:4>

Name:

Failing Commander 1D

Mnemonic:

FCID

Type:

The Failing Commander ID field logs the commander ID of a failing
transaction. FCID sets only if the retried transaction fails.

kits<3:0>

Name:

Failing Command

Mnemonic:

FCMD

Type:

The Failing Command field logs the command code of a failing
transaction. FCMD sets only if the retried transaction fails.

DWMBA/A XMI Module Registers
Falling Address Register (XFADR)

Failing Address Register (XFADR)
The Failing Address Register logs address and length information &ssociated
with a failing transaction.

ADDRESS

Nodespace base address + 0000 0008 (SSC)
3N W N

]

Failing Address

Failing Length (FLN)
m-0380-60

bits<31:30>

Name:

Failing Length

Mnemonic:

FLN

Type:

FLN logs the value of XMI D<31:30> during the command cycle of a
failing transaction.

bits<29:0>

Name:

Failing Address

Mnemonic:

None

Type:

The Failing Address field logs the value of XMI D<29:0> during the
command cycle of a failing transaction.

6-21

DWMBA/A XMi Moduie Hegisters

Responder Error Address Reglster (AREAR)

Responder Error Address Register (AREAR)
AREAR logs the failing address received from a CPU node initializing an 110
write, read, or IDENT transaction to the DWMBA or the VAXBI. AREAR is
loaded when the DWMBA/A module ACKs the XMl's C/A cycle.
AREAR is locked when the DWMBA is unable to compiete the requested

operation, either a CPU write transaction that fails, resulting in the VO Write

Failure bit in the DWMBA/A module's Error Summary Register being set or a

CPU read or IDENT ftransaction that results in the setting of the Data NO ACK
bit in the DWMBA/A module’'s XBER register.

ADDRESS

XM nodespace base address + 0000 000C

Responder Failing Address

l—_ Responder Failing Length (RFLN)
bits<31:30>

Name:

Responder Failing Length

Mnemonic:

RFLN

Type:

mab-0666-00

RFLN logs the value of XMI D<31:30> during the cycle that the
DWMBA accepts the C/A cycle for the XMI commander.

bits<29:0>

Name:

Responder Failing Address

Mnemonic:

None

Type:

The Responder Failing Address bits log the value of XMI D<29:0>
during the cycle that the DWMBA accepts the C/A cycle from the XMl
commander.

6-22

DWMBA/A XMI Module Registers
Error Summary Register (AESR)

Error Summary Register (AESR)
AESR is used to capture DWMBA/A module-related error conditions.

ADDRESS

XMl nodespace base address + 0000 0010

)

22 25

mez

20 19

16 1§

e?2765
43 210

MUST BE ZERO

X8l Cable OK

i- Failing Comrand (ECVD)

Failing Commander ID (EID)

XBIA intemai Error
/O Write Failure During CPU Write Transaction
:
BCIACLO

IBUS DMA-A Data Panity Emor
1BUS DMA-A C/A Parity Emor
1BUS DMA-B Data Panity Error

IBUS DMA-B C/A Parity Error
1BUS CPU Data Parity Eror
mad-0667-80

bit«31>

Name:

XBI| Cable OK

Mnemonic:

None

Type:

XBI Cable OK sets to one on initialization if the four IBUS cables are
correctly connected and if the DWMBA/B module has DC power from
the VAXBI backplane. If XBI Cable OK clears and the DWMBA/E
module has VAXBI DC power, then one or more of the cables is not
connected or is inceTrectly installed.

bits<30:26>

Name:

Reserved

Mnemonic:

None

Tvpe:

RO, O

Reserved; must be zero.

6-23

DWMBA/A XMI Module Registers
Error Summary Regist.r (AESR)

bits<25:20>

Name:

Failing Commander 1D

Mnemonic:

EID

Tyne:

EID logs the XMI commander ID of a failed DWMBA /O write, /0
read, or XMI IDENT transaction. The DWMBA will load this register
after it ACKs the XMI commander’s C/A cycle. EID locks if the
DWMBA is unable to complete the requested operation as follows:
1

A failing CPU write transaction that sets the /O Write Failure bit
in the PDWMBA/A module’s Error Summary Register.

A CPU read or IDENT transaction that sets the Data NO ACK bit
in the DWMBA/A module’s Bus Error Register (XBER).

The lock on EID clears when both of the locking error conditions clear.

bits<19:16>

Name:

Failing Command

Mnemonic:

ECMD

Type:

ECMD logs the XMI commander command of a failed DWMBA 1/O
write, VO read, or XMI IDENT transaction. The DWMBA lecads this

register after it ACKs the XMI commander’s C/A cycle. ECMD locks if
the DWMBA is unable to complete the requested operation as follows:
1

A failing CPU write transaction that sets the 'O Write Failure bit
in the DWMBA/A module’s Error Summary Register.

A CPU read or IDENT transaction that sets the Data NO ACK bit
in the DWMBA/A module’s Bus Error Register (XBER).

The lock on EID clears when the locking error conditions clear for both
ECMD and EID.

bits<15:8>

Name:

Reserved

#yemonic:

None

Type:

RO, 0

Reserved; must be zero.

6-24

‘

DWMBA/A XMI Module Registers
Error Summary Reglster (AESR)

bit<7>

Name:

XBIA Internal Error

Mnemonic:

None

Type:

RW1C, 0

The XBIA Internal Error bit sets to indicate that an UNEXPLAINED
internal error to the DWMBA/A module gate array was detected,
generally a hardware problem where control logic encountered
UNDEFINED conditions. The DWMBA/A module issues an IVINTR
transaction with "mem write error” set in the Type field when XBIA
Internal Error sets.

bit<6>

Name:

VO Wriie Failure During CPU Wiiie Transaction

Mnemonic:

/O Write Failure

Type:

RWi1C, 0

/O Write Failure During CPU Write transaction sets if the DWMBA/B
module is unable to complete a CPU write transaction to either its
register space or to VAXBI address space. Its assertion coincides with

the generation of an IVINTR transaction due to this error condition.

The DWMBA issues an IVINTR with "mem write error” set in the
Type field when /O Write Failure During CPU Write Transaction is

asserted. Software uses this bit and other error bits to determine the
cause of a DWMBA-generated IVINTR transaction.

When VO Write Failure During CPU Write Transaction sets, the

contents of the DWMRA/A module Responder Error Address Register,
the Failing Commander ID bits, and the Failing Command bits lock.

bit<5>

Name:

BClACLO

Mnemonic:

None

Type.

RWIC, 1

The BCI AC LQ bit sets when VAXBI power falls below specifications,
as indicated by an asserted 5Ci AC LO L signal (asserted = one). The
DWMBA issues an IVINTR with "mem write error” set in the Type
field when BCI AC LO is asserted so that software can determine the

zause of this IVINTR transaction. Software then clears BCI AC LO as
part of the interrupt service routine that executes as a result of the
IVINTR.

The DWMBA self-test program clears BCI AC LO.

6-25

DWMBA/A XMl Module Registers
Error Summary Register (AESR)

bit<d>

Name:

IBUS DMA-A Data Parity Error

Mnemonic:

None

Type:

RWIC, 0

IBUS DMA-A Data Parity Error sets when the DWMBA/A module

detects a parity error on the IBUS when the DWMBA/B module was

loading a DMA-A data buffer location. The DWMBA issues an IVINTR
with "mem write error” set in the Type field when IBUS DMA-A Data
Parity Error asserts.

bit<3>

Name:

IBUS DMA-A C/A Parity Error

Mnemonic:

None

Type:

RWIC, 0

IBUS DMA-A C/A Parity Error sets when the DWMBA/A module
detects a parity error on the IBUS when the DWMBA/B module was
loading a DMA-A C/A location. The DWMBA issues an IVINTR with
"mem write error” set in the Type field when IBUS DMA-A C/A Parity
Error asserts and the failing DMA transaction is a write or interrupt.
The DWMBA issues an error interrupt if this error bit is set and the
appropriate mask bit is also set.

bit<2>

Name:

IBUS DMA-B Data Parity Error

Mnemonic:

None

Type:

AWIC, 0

IBUS DMA-B Data Parity Error sets when the DWMBA/A module
detects a parity error on the IBUS when the DWMBA/B module was
loading a DMA-B data buffer location. The DWMBA issues an IVINTR
with "mem write error” set in the Type field when IBUS DMA-B Data
Parity Error asserts.

bit

Name:

IBUS DMA-B C/A Parity Error

Mnemonic:

None

Type:

HWiC, 0

IBUS DMA-B C/A Parity Error sets when the DWMBA/A module
detects a parity error on the IBUS when the DWMBA/B module
was loading a DMA-B C/A location. The DWMBA issues an IVINTR
with "mem write error” set in the Type field when IBUS DMA-B C/A
Parity Error asserts and the failing DMA transaction is a write. The
DWMBA issues an error interrupt if this error bit is set and the
appropriate mask bit is also set.

6-26

DWMBA/A XMl Module Registers
Error Summary Register (AESR)

bit<0>

Name:;

IBUS CPU DATA Parity Error

Mnemonic:

None

Type:

RWIC, 0

IBUS CPU DATA Parity Error sets when the DWMBA/A module
detects a parity error on the IBUS when the DWMBA/B module was

loading CPU DATA location during a CPU-initiated IO read or IDENT.
The DWMBA issues a Read Error Response (RER) to the commander
when IBUS CPU DATA Parity Error asserts. The DWMBA issues an
error interrupt to the XMI if this ervor bit is set and the appropriate
mask bit is also set.

DWMBA'A XMI Module Regilsters
interrupt Mesk Register (AIMR)

Interrupt Mask Register (AIMR)
AIMR enables/disables the generation of an error interrupt transaction when
the corresponding error bit in both the DWMBA/A module's XMI Bus Error
Register (XBER) and the DWMBA/A module’s Error Summary Register
(AESR) is set.

ADDRESS

XMI nodespace base address + 0000 0014
»

MBZ

N W

101817 1318

mBZ

1. 13

MUST BE ZERO

L Diagnostic Read _I
or Write

INTR on 1BUS DMA-A C/A PE

Diagnostic Raad or Write
INTR on IBUS DMA-B C/A PE
INTR on IBUS CPU DATA PE
.. INTR on Command NO ACK
.- INTR on Read Error Response
- INTR on Read Sequence Eror
L L~ INTR on No Read Response
INTR on Corrected Read Data

— |INTR on Write Data NO ACK

L INTR on Read/IDENT NO ACK
=

{NTR on Write Sequence Error

L INTR on Parity Emor

INTR on Corrected Confirmation

Enable IVINTR Trarsactions

blt<31>

Name:

Enable IVINTR Transactions

Mnemonic:

None

Type:

RW, 0

mab 086800

When Enable IVINTR Transactions is set and the IVINTR Lestination

CAUTION: The Enable IVINTR Transactions bit MUST be set to ensure
proper error reporting in the case of asynchronous write
failures and to report the occurrence of a pending VAXBI
power-fail not initiated by XMI AC LO, XMI DC LO, or XBI
Node Reset.

6-28

DWMBA/A XMI Module Registers
interrupt Mask Register (AIMR)

bite<30:28>

Name:

Reserved

Mnemonic:

None

Typa:

RO, 0

Reserved; must be zero

bit<27>

Nama:

INTR on Corrected Confirmation

Mnemonic:

None

Type:

RW, 0

When INTR on Corrected Confirmation sets, the DWMBA/A module
asserts the IR XMI ERR BIT SET L line of the IBUS, which generates
an interrupt request if XBER<23> (PE) is set.

bits<26:24>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

bit<23>

Name:

INTR on Parity Error

Mnemonic:

None

Type:

RW, 0

When the INTR on Parity Error bit sets, the DWMBA/A module
asserts the IR XMI ERR BIT SET L line of the IBUS, which generates
an interrupt request if XBER<23> (PE) is set.

bit<22>

Name:

INTR on Write Sequence Error

Mnemonic:

None

Type:

RW, 0

When the INTR on Write Sequence Error bit sets, the DWMBA/A

module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if XBER<22> (WSE) is set.

DWMBA/A XMi Module Registers
interruj.t Mask Register (AIMR)

bit<21>

Name:

INTR on Read/IDENT NO ACK

Mnemonic:

None

Type:

AW, 0

When the INTR on Read/IDENT NO ACK sets, the DWMBA/A module
asserts the IR XMI ERR BIT SET L line of the IBUS, which generates
an interrupt request if XBER<21> (RIDNAK) is set.

bit<20>

Name:

INTR on Write Data NO ACK

Mnemonic:

None

Type:

RW, 0

When the INTR on Write Data NO ACK sets, the DWMBA/A module
asserts the IR XMI ERR BIT SET L line of the IBUS, which generates
an interrupt request if XBER<20> (WDNAK) is set.

bit<19=>

Name:

INTR on Corrected Read Data

Mnemonic:

None

Type:

RW, 0

When the INTR on Corrected Read Data bit sets, the DWMBA/A
module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if XBER<19> (CRD) is set.

bit<18>

Name:

INTR on No Read Rasponse

Mnemanic:

None

Type:

RW, 0

When the INTR on No Read Response bit sets, the DWMBA/A module
asserts the IR XMI ERR BIT SET L line of the IBUS, which generates
an interrupt request if X3ER<18> (NRR) is set.

bit<17>

Name:

INTR on Read Sequence Error

Mnemonic:

None

Type:

RAW, 0

When the INTR on Read Sequence Error bit sets, the DWMBA/A
module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if XBER<17> (RSE) is set.

DWMBA/A XMiI Module Registers
interrupt Mask Reglster (AIMR)

bit<16>

Name:

INTR on Read Error Response

Mnemonic:

None

Type:

AW, 0

When the INTR on Read Error Response bit sets, the DWMBA/A
module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if XBER<16> (RER) is set.

bit<15>

Name:

INTR on Command NO ACK

Mnemonic:

None

Type:

RW, 0

When the INTR on Command NO ACK bit sets, the DWMBA/A module
asserts the IR XMI ERR BIT SET L line of the IBUS, which generates
an interrupt request if XBER<15> (CNAK) is set.

bite<id>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

bit<i13>

Name:

Diagnostic Read or Write

Mnemonic:

Non:

Tupe:

RO, X

Diagnostic Read or Write is used by diagnostic tests.

bits<12:5>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Keserved; must be zero.

DWMBA/A XMi Module Regilsters
interrupt Mask Registor (AIMR)

blicd>

Name:

Diagnoatic Read or Write

Mnemonic:

None

Type:

RO, X

Diagnos*ic Read or Write is used by diagnoctic tests.
R

bit<3>

Name:

INTR on 1BUS DMA-A C/A PE

Mnemonic:

None

Type:

RW, 0

When the INTR on IBUS DMA-A CA PE bit sets, the DWMBA/A
module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if a8 parity error was deiected on the
{BUS when the DWMBA/B module was loading a DMA-A C/A location.

bit<2>

Name:

Diagnostic Read or Write

Mnamonic:

None

Type:

RO, X

Diagnostic Read or Write is used by diagnostic tests.

bit

Name:

INTR on 1BUS DMA-B C/A PE

Mnemonic:

None

Type:

RW, 0

When the INTR on IBUS DMA-B C/A PE bit sets, the DWMBA/A
module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if a parity error was detecied on the
IBUS when the DWMBA/B module was loading a DMA-B C/A location.
EEERITRTE

bite<O>

Name:

INTR on IBUS GPU DATA PE

Mnemonic:

None

Type:

RW, 0

When the INTR on IBUS CPU DATA PE bit sets, the DWMBA/A
module asserts the IR XMI ERR BIT SET L line of the IBUS, which
generates an interrupt request if a parity error was detected on the
IBUS when the DWMBA/B r .dule was loading the CPU data iocation.

DWMBA/A XMI Mcdule Regisiers
implied Vector interrupt Desgtination/Diagnostic Reglster (AIVINTR)

implied Vector Interrupt Destination/Diagnostic
Register (AIVINTR)
The AIVINTR is used during diagnostics and DWMBA-initiated IVINTR

transactions.

ADDRESS

XMI nodespace base address + 0000 0018
i

18 1S

[

Diagnostic Read or Wnte

!0— IVINTR Destination ——-"
wad0869-80

bits<31:0>

Name:

Diagnostic Read or Write

Mnemonic:

None

Type:

The Diagnostic Read or Write bite are used by diagnostic routines

to verify the integrity of the DWMBA/A mcdule’s main data path

inside the DWMBA/A module gate array. When used in this manner,

diagnostics need to raise the processor’s IPL level above IPL 30 so
that, should an error occur causing the DWMBA/A module to issue an
IVINTR transaction, an unexpected interrupt will not occur.
During DWMBA-initiated IVINTR transactions, bits <15:0> are used
as IVINTR Destination bits.

bits<15:0>

Name:

IVINTR Destination

Mnemonic:

None

Type:

RW, 0

The IVINTR Destination bits determine which nodes on the XMI will
be targeted by the DWMBA when it issues an Implied Vector Interrupt
transaction. Each of the 16 bits corresponds to one of the 16 XMl
nodes (only 14 nodes are used in the DECsystem 5800). When a bit

is set, the selected node wiil be the target. For example, if bit <12>
becomes set, then XMI node 12 is the node that the DWIMBA selects to
participate in the IVINTR transaction. Any number of bits can be set.
A second use for the IVINTR Destination bits is by diagnostics.

6-33

DWMBA/A XMI Module Registers
Diag 1 Register (ADG1)

Diag 1 Register (ADG1)
ADG?1 is used by diagnostics to test parity and other f2atures in the DWMBA/A
moduie and the IBUS.

ADDRESS

XMI nodespace base address + 0000 001C

765
43 2110

MUST BE ZERO

L Auto Retry Disable (ARD)

mez

Force Octaword Transfers _—J I
Force DMA-A Buffer Busy

Force DMA-B Butfer Busy
General Bad IBUS Receiver Party
General Bad IBUS Transmit Paity
b 0870-90

bit<31>

Name:

Auto Retry Disable

Mnemanic:

ARD

Type:

RW, 0

Settinz Auto Retry Disable disables reattempts of failed XMI
commander transfers. XMI error indications (NO ACKs) are
immediately logged in the XMI Bus Error Register, and the
appropriate action is taken.

CAUTION: A NO ACK confirmation is a legal response that an XMI node

may issue if it is currently unsble to respond to the requested
transaction because it is busy. If the user sets Auto Retry
Disable, the user must ensure that either a "busy” NO ACK
cannot be issued by the targeted node or the XMI or the
DWHMBA has the capability to handle a traneaction that may
not complete.

bits<30:7>

Name:

Raserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

6-34

‘

DWMBA/A XM! Module Registers
Diag 1 Register (ADG1)

bit<6>

Name:

Force Octawerd Transfers

Mnemonic:

None

Type:

RW, 0

When Force Octaword Transfers is set, the DWMBA/A module
generates ectaword DMA transactions regardless of the length
code that the DWMBA/B module loaded into the DMA buffer.
The Force Octaword Transfers bit ie used with Force DMA-A/B
Busy (ADG1<5:4>), Flip FADR bit 1 (BDCR1<6>), and Flip Bit 29

(BDCR1<4>) to allow diagnostics to test the DWMBA's DMA buffer
memory using CPU loopback transactions to XMl memory.

CAUTION: When Flip Bit 286 (BDCR1<4>) has been set to use the diagnostic
feature "DMA loopback mode," only LEGAL addresses are
permitted. ILLEGAL addresses result in UNDEFINED data.

The CPU-generated address must be either 2zxxx xxx( or 2xxx
xxx4 to be legal. The following are ILLEGAL addresses: 2xxx
zxxB and 2xxx xxxC.

bit<5>

Name:

Force DMA-A Buffer Busy

Mnemonic:

None

Type:

RW, 0

When set, the Force DMA-A Buffer Busy bit forces the DMA buffer
control logic to place the DMA-A. buffer into the BUSY state, forcing
all DMA traffic through the DMA-B buffer.
CAUTION: If both ADG1<5> and ADG1<4> are set, all DMA transactions

(VAXBI transactions that select the DWMBA as the slave and
whose address falls within the bounds of the Starting and
End.ng Address Registers) will stall.

bit<d>

tame:

Force DiA-B Buffer Busy

Mnemonic:

None

Type:

AW, 0

When set, the Force DMA-B Buffer Busy bit forces the DMA buffer
control logic to place the DMA-B buffer into the BUSY state, forcing
all DMA traffic through the DMA-A buffer.
CAUTION: If both ADG1<&> and ADGl<4> are get, all DMA transactions

{(VAXRBI transactions thai select the DWMBA as the slave and

whose address falls within the bounds of the Starting and
Ending Address Registers) will stall.

DWMBA/A XMI Module Registers
Diag 7 Register (ADG1)

bit<3>

Name:

General Bad IBUS Receiver Parity

Mnemonic:

GEN BAD IBUS RCV PAR

Type:

PW, 0

Setting GEN BAD IBUS RCV PAR causes the parity check bit on
the DWMBA/A module for IBUS parity to be a one, regardless of the
data that is loaded onto the buffer. Diagnostic rouiines use this bit
and specific data patterns to force IBUS parity check errors n the
DWMBA/A module when the DWMBA/B module loads the contents of
the C/A or data buffers contained in the DWMBA/A module gate array.

bit<2>

Name:

Ceneral Bad 1BUS Transmit Parity

Mnemonic:

GEN BAD IBUS XMIT PAR

Type:

AW, 0

Setting GEN BAD IBUS XMIT PAR causes the parity bit sent to the
DWMBA/B module for IBUS parity to be a one, regardless of the data
that resides in the buffer. Diagnostic routines use this bit and specific
data patterns to force IBUS parity errors on the DWMBA/B module
when the DWMBA/B module fetches the contents of the C/A or data
buffers contained in the DWMBA/A module gate array.

bits<1:0>

Name:

Reserved

Mnemonic:

None

Type:

RC, 0

Reserved; must Lo »ero.

6-36

DWMBA/B VAXBI Module Registers
Control and Status Register (BCSR)

Control and Status Register (BCSR)
BCSR contains DWIMBA/B module operational control and status bits.

ADDRESS

XMI nodespace base address + 0000 0040
31 30

MUST BE ZERO

L Enable XBl interrupts

BIBAD

B! Interlock Read Failed Mask
Bl Seit-Test LED
1BUS Parity Error Intarrupt Mask
meb>0671-80

bit<31>

Name:

Enable XBI intarrupts

Mnemonic:

None

Type:

AW, 0

Setting Enable XBI Interrupts enables the DWMBA to generate

XM interrupt requests in response to DWMBA-generated or VAXBIgencrated interrupts. The appropriate interrupt mask bits must also
be set for interrupts to be generated.

bits<30:5>

Name:

Reserved

Mnemonic:

MNone

Type:

RO, 0

Reserved; must be zero.

DWMBA/B VAXBI Module Registers
Conirol and Status Reglster (BCSR)

bit<d>

Namae:

BI BAD

Mnemonic:

None

Type:

The initial state of the BI BAD bit on power-up or reset reflects the
state of the BI BAD L line on the VAXBI by monitoring the line. It
is used by console initialization software and error handling software
to detect faulty VAXBI nodes. The assertion of BI BAD L on a VAXBI
node results in the assertion of the XMI BAD line.
The BI BAD bit sets to logic level one when the VAXBI BI BAD L
deasserts. When the BI BAD bit sets, it indicates that all VAXBI
nodes have passed self-test, except for the DWMBA/B module, which
does not asseit BI BAD L

bite3>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

bit<2>

Namae:

B! interlock Rez Failed Mask

Mnemonic:

None

Type:

RW, 0

Setting BI Interlock Read Failed Mask to a one causes the DWMBA
to generate an error interrupt request if BESR<2> (BI Interlock Read
Failed) is set.
R

bitei>

Name:

Bl Salf-Test LED

Mnemonic:

None

Type:

RW, 0

The BI Self-Test LED bit is set by the XMI boot processor node when
the XBI self-test completes without error. If any portion of the XBI
self-test fails, this bit does not set. When the BI Self-Test LED bit
sets, the VAXBI Self-Test LED lights on the DWMBA/B module.
NOTE: The BI Self-Test LED bit has NO EFFECT on the operation

of the XMI Self-Test LED on the DWMBA/A module. The XMI
Self-Test LED is controlled by XBER<10>, Self-Test Fatil.

DWWBA/B VAXBI Module Rsglsters
Control and Status Register (BCSR)

bit<0>

Name:

IBUS Parity Error Intarrupt Mask

Mnemonic:

None

Type:

AW, 0

Setting IBUS Parity Error Interrupt Mask to one causes the DWMBA
to generate an error interrupt request if BESR<0> (XBIB-Detected
IBUS Parity Error) is set.

DWMBA/B VAXBI Module Reglsters
Error Summary Reglster (BESR)

Error Summary Register (BESR)
The BESR contains statiis biis for errors detected by the DWMBA/B module.

ADDRESS

XMl nodespace base address + 0000 0044
17 1

132 v

87688
43 210

MUST BE ZERO

Interrupt Sent Status _I

XBI interrupt-Panding Status
B! Intarrupt-Pending Status
Muttiple CPU Errors
Command/Address Fatch Failad
Slave Sequancer Transaction Failed
Master Sequencer Transaction Failed

liegal CPU Command
8! intarlock Read Failed
IDENT Emor

XB1B-Detected IBUS Parity Error
mab-0872.60

bits<31:17>

Name:

Reserved

#nemonic:

None

Type:

RO. 0

Reserved; must be zero.

bits<16:13>

Name:

interrupt Sent Status

Mnemonic:

None

Type:

RO, 0

The Interrupt Sent Status bits correspond to the 4-bit interrupt sent
flops internal to the gate array, with BESR<16> corresponding to
IPL<17>, BESR<15> corresponding to ILP<16>, ete. The interrupt
sent status flops and BSER<12:8> determine the current interruptpending status.

DWMBA/B VAXBI Module Registers
Error Summary Register (BESR)

bit<i2>

Name:

XB! Interrupt-Perding Status

Mnemonic:

None

Type:

RO, 0

The XBI Interrupt-Pending Status bit is a direct read of the XBI
interrupt-pending flip-flop. A one indicates that a DWMBA interrupt
is pending.

bits<11:8>

Name:

B! Interrupt-Pending Status

Mnemonic:

None

Type:

RO, 0

The Bl Interrupt-Pending Status bits set to indicate that one or more

of the VAXBI interrupt-pending flip-flops is set. When asserted, they
indicate that a VAXBI-generated interrupt targeting the DWMBA
was successfully received and that a CPU IDENT at the correct IPL
has not yet been received. These bits are a direct read of the VAXBI
interrupt-pending flip-flops, with BESR<11> corresponding to IPL<17>
and BESR<8> corresponding to IPL<14>.

bit<7>

Name:

Muitiple CPU Errors

Mnamonic:

None

Type:

RW1C, 0

Multiple CPU Errors sets when BESR«<4> and BESR<0> have
previously set due to a CPU transaction IBUS parity error when
C/A or data is removed from the CPU buffer. This indicates that an
error occurred on a subsequent CPU transaction before software had
acknowledged a previously failed CPU transaction. This bit does not
gset on a parity error on write data accompanying the command/address
on which an error was detected since the transaction has already been
recorded as having failed.

blt<6>

Name:

Command/Address Fatch Failed

Mnemonic:

C/A Fetch Failed

Type:

RO, 0

C/A Fetch Failed, when set with BESR<0> set, indicates that the
DWMBA/B module detected an IBUS parity error on the C/A fetch
from the CPU C/A buffer. C/A Fetch Failed will NOT set on a
DWMBA/B module detected IBUS parity error when write data is
fetched from the CPU Write Data buffer.

DWMBA/B VAXBI Module Registers
Error Summary Reglster (BESR)

bit<5»

Name:

Slave Sequencer Transaction Failec

Mnemonic:

None

Type:

RO, 0

Slave Sequencer Transaction Failed sets with BESR<0> to indicate
that an IBUS parity error occurred while the slave sequencer had
control of the IBUS during a read data fetch from the DMA read
buffer.

bited>

Name:

Master Sequencer Transaction Failed

Mnemonic:

None

Type:

RO, 0

Master Sequencer Transaction Failed sets with BESR<0> to indicate

that an IBUS parity error occurred while the master sequencer had
control of the IBUS during a C/A or write data fetch from the CPU
buffer.

NOTE: This bit will be set but NOT VALID w.nless bit<0> in this register
is also set.

bit<3>

Name:

lllegal CPU Command

Mnemonic:

None

Type:

Illegal CPU Command sets to indicate that an illegal CPU command
was decoded by the DWMBA/B module. This error occurs only if an

undetected multi-bit parity error happened during the time when
the DWMBA/B module fetches the commmand/address from the CPU
buffer. The error results in the master sequencer terminating the
transaction and signaling the DWMBA/A module that the transaction
failed.

The Illegal CPU Command bit does NOT generate an error interrupt.

DWMBA/B VAXBI Module Registers
Error Summary Reglster (BESR)

bit<2>

Name:

Bl Interlock Reed Failed

Mnamonic:

None

Type:

RWIC, 0

BI Interlock Read Failed sets to indicate that a VAXBI-to-XMI memory
Interlock Read operation failed to successfully complete on the VAXBI.
When this error occurs, it is highly probable that the lock set in XMl
memory will not be unlocked by the VAXBI device that issued the
Interlock Read. The contents of the Timeout Address Register and the

setting of BI Interlock Read Failed can be used to determine the locked
address in XMI memory. The operating system can clear the lock in
XMI memory by writing to a specific CSR in XMI memory.

BI Interlock Read Failed sets whenever 8 VAXBI Interlock Read
command has been decoded and the summary EV code Illegal CNF
Received for Slave Data (ICRSD) is decoded during a VAXBI Interlock
Read transaction. Setting Bl Interlock Read Failed locks the contents
of the Timeout Address Register. Writing a one to Bl Interlock Read
Failed clears both the bit and its lock on the register.
When BI Interlock Read Failed is set with its corresponding mask bit,
an error interrupt request is generated.

bitei>

Name:

IDENT Etror

Mnemonic:

None

Type:

RW1C, 0

IDENT Error sets to indicate that the DWMBA received an XMl
IDENT transaction and no VAXBI nor DWMBA interrupt requests
were pending at the IDENTed IPL. A set IDENT Error indicates an
error condition on the XMI bus with multiple IDENTs being izsued on
the XMI for the same interrupt transaction. (Only one XMI IDENT

is issued on the XMI if a single interrupt targets multiple CPUs.) All
other CPUs that are waiting for an XMI bus grant to issue their XMI
IDENTS will cancel their IDENT transactions if they see an IDENT

transaction that matches the node ID and IPL of the IDENT that they
are waiting to issue.

IDENT Error sets if a CPU IDENT command is decoded and ne
interrupts are pending in the DWMBA/B module gate array.
The setting of IDENT Error does NOT generate a DWMBA error
interrupt.

DWiMBA/B VAXBI Module Regicoters
Error Summary Register (BESR)

bit<0>

Name:

XBIB-Detevtied IBUS Parity Error

Mnemonic:

None

Type:

AWiC, 0

XBIB-Detected IBUS Parity Error sets if the DWMBA/B module
detects an IBUS parity error on a CPU transaction’s C/A cycle, on a
write data cycle when the data is removed from the CPU buffer by the
master sequencer, or on a DMA transaction read data cycle when the
read data is removed from the DMA read buffer by the slave sequencer.
When XBIB-Detected IBUS Parity Error sets, the appropriate bit of
BESR<6:4> sets.

The Timeout Address Register also locks on IBUS parity errors

detected during DMA read data fetches from the buffer.

Writing a one to XBIB-Detected IBUS Parity Error also clears
BESR«<6:4> and the lock on the Timeout Address Register.

When the XBIB-Detected IBUS Parity Error bit is set with its
corresponding mask bit, an error interrupt request is generated.

DWMBA/B VAXBI Module Registers
interrupt Desiination Register (BIDR)

interrupt Destination Register (BIDR)
BIDR is used by the DWMBA module to dsterming the targeted nodes on the
X! for an interrupt transaction. BIDR is used by both VAXBI-initiated and
DWMBA ervor/status-initiated interrupts.

ADDRESS

XMl nodespace base address + 0000 0048
n

18 18

DIAGNOSTIC READAWRITE

INTERRUPT DESTINATION
mab0873-27

bite<31:0>

Name:

Diagnostic Read/Write

Mnemonic:

None

Type:

Diagnostic R’W bits are used by diagnostics to verify much of the data
path integrity of the DWMBA/B module gate array.

bits<15:0>

Name:

interrupt Destination

Mnemonic:

None

Type:

RW, 0

The Interrupt Destination bits determine the nodes on the XMI that
are targeted by the DWMBA when it issues an interrupt transaction.
Each bit in the 16-bit field corresponds to one of the 16 XMI nodes

(only 14 nodes are used in the DECsystem 5800). When a bit is set
to one, the selected node is the targeted node that the DWMBA will
interrupt. Multiple bits can be set to interrupt as many XMI nodes as
the user desires.

During diagnostics, bits<15:0> are used as part of the Diagnostic
Read/Write bite<31:0>, as described above.

645

DWMBA/B VAXBI Module Registers
Timeout Address Reglster (BTIM)

Timeout Address Register (BTIM)
The Timeout Address Register is loaded each time a VAXBI
command/address is latchad off the VAXBI. BTIM locks when (1) a VAXBIto-XMI memory Interiock Read fails, causing the Bl Interlock Read Failed bit
(BESR<2>) to set, or (2) a VAXBI-to-XMI memory read-type fails, causing the
XBIB-Detected IBUS Parity Emor bit (BESR<0>) to set.

ADDRESS

XMI nodespace base address + 0000 004C
3 0 ¥

Bt DMA ADDRESS

L_ Length
bits<31:0>

B! DMA Failing Address

Mnemonic:

None

The BI DMA Failing Address contains the longword physical address

(bits<29:0>) and length of the received VAXBI-to-XMI transaction

(bits<31:30>.) If no errors are detected, the register reads back the
last VAXBI! transaction. The register logically locks upon error and
unlocks when that error clears.

6-46

mab-0874.20

Name:

Type:

DWMBA/B VAXBI Module Registers
Vector Offset Register (BVOR)

Vector Offset Register (BVOR)
BVOR contains a value ihat is concatenated with the VAXBI device-supplied
vector, if bits<13:9> of the VAXBI-supplied vector are equal to zero.

ADDRESS

XMI nodespace base address + 0000 0050
N

16 15

MUST BE ZERO

XBI Vector Offset Register (VOR) -—I
bits<31:16>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

MUST BE ZERO l
mab-0875-00

Reserved; must be zero.

bits<15:9>

Name:

XB! Vactor Offset Register

Mnemonic:

VOR

Type:

RW, 0

BVOR is a 7-bit register loaded by software upon system initialization.
BVOR contains a value that is concatenated with the VAXBI devicesupplied vector, providing that bits<13:9> of the VAXBI-supplied vector
are equal to zero, ensuring that multiple DWMBA/VAXBIs with the
same devices on each bus will have a unique entry point into the SCB.

bits<8:0>

Name:

Reserved

Mnemonic:

Ncne

Type:

RO, 0

Reserved; must be zero.

6-47

DWMBA/B VAXBI Module Registers
Vector Register (BVR)

Vector Register (BVR)
BVR is loaded by software upon system initialization. BVR contains the
DWMBA vector that will be transmitted to the IDENTing XMI node when the
DWMBA has a pending interrupt request that matches the interrupt source
and IPL sent during the XMI IDENT transaction.

ADDRESS

XMI nodespace base address + 0000 0054
n

16 1%

MUST BE ZERO

XBI VECTOR

VB2

mab-0676-90

bits<31:16>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero,

bits<15:2%

Name:

XBl Vector

Mnemonic:

None

Type:

RW, 0

The XBI vector is transmitted to the IDEXNTing XMI node when the
DWMBA has a pending interrupt request that matches the interrupt
source and IPL sent during the XMI IDENT transaction. This vector
is NOT sent for any VAXBI-generated interrupts or BIIC interrupts
due to error conditions.

bits<1:0>

Name:

Reserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

DWMBA/B VAXBI! Module Rsgisters
Diagnostic Control Register 1 (BDCR1)

Diagnostic Control Register 1 (BDCR1)
The BDCR1 is used by diagnostics to perform various diagnostic functions on

the DWMBA/B module, ensuring that its hardware operates properiy.

ADDRESS

XMl nodespace base address + 0000 0058
n

7686
43 210

MUST BE ZERO

JMBz

Flip FADDR Bit 1 __I I

Flip Bit 29
BIIC Loopback Mods
Force BC| Bad Parity

mab-0377-80

bits<31:7>

Name:

Reserved

Mnemonic:

None

Type:

RG, 0

Reserved; must be zero.

bit<6>

Name:

Flip FADDR Address Bit 1

Mnemonic:

None

Type:

RW, 0

The Flip FADDR Address Bit 1, used with Force DMA-A/B Busy bits

(ADG1<5:4>) and Flip Bit 29, enables diagnostics to test the DWMBA's
DMA buffer memory using CPU loopback transactions to XMI memory.
When Flip FADDR Address Bit 1 is set, the invert state of FADDR
Address Bit 1 is used to address the data werds in the buffer, allowing
diagnostics to use the buffer locations that normally would only be
used for transfers greater than a quadword.

Setting Flip FADDR Address Bit 1 only affects FADDR address bit 1
when the DWMBA/B module logic accesses data locations in the buffer.
During the cycle when the C/A is addressed in the buffer, the setting
of Flip FADDR Address Bit 1 has no effect on the buffer address.

DWMBA/B VAXBI Module Registers
Diagnostic Control Register 1 (BDCR1)

bit<5>

Namas:

Resserved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

bited>

Name:

Flip Bit 29

Mnemonic:

None

Type:

RW, 0

Setting Flip Bit 29 inverts the state of bit 29 and BCI parity after

the CPU C/A has been fetched and decoded by the master sequencer.
The new address, which now resides in XMI memory space, is issued

to the VAXBI. The DWMBA is the selected slave for the transaction,
which processes this transaction like any other VAXBI-initiated DMA
longword transaction, allowing diagnostic programs executing on the
XMI to issue a CPU transaction to the DWMBA, which then converts
it into a DMA transaction.

bit<3>

Name:

BIIC Loopback Mode

Mnemonic:

None

Type:

RW, 0

All reguesis to the master port of ithe BIIC become loopback reguests
whenever BIIC loopback mode is set, allowing the master sequencer to
make loopback requests to access BIIC registers. The loopback mode
prevents the BIIC from initiating VAXBI cycles to access the BIIC
registers. When the BIIC is in loopback mode, it ignores the node ID
portion of the address presented to it.

bit<2>

Name:

Force BCI Bad Parity

Mnemonic:

None

Type:

RW, 0

When Force BCI Bad Parity is set, bad parity is forced onto the BCI
bus to the VAXBI during CPU C/A, CPU data cycles, and DMA read
data cycles.

bite<1:0>

Name:

Ressrved

Mnemonic:

None

Type:

RO, 0

Reserved; must be zero.

DWMBA/B VAXBI Module Registers
Reserved Reglster

Reserved Register
The Reserved Reagister is an undefined register that is reserved for future use.
Reads to this register return UNDEFINED data with correct parity. Writes to
this register appear to complete successfully.

ADDRESS

XMI nodespace base address + 0000 005C
n

RESERVED
med0878-00

bits<31:0>

Name:

Reserved Register

Mnemonic.

None

Type:

Undefined

The reserved register bits are reserved for future use.

VAXBI Registers
Device Register (DTYPE)

Device Register (DTYPE)
The VAXBI Device Register is loaded during seif-test by console code with the
DWMBA VAXBI device type and by the revision select logic with the revision
level.
0

ADDRESS

e o

)

VAXBI nodespace base address + 0000 0000
n

1% 13

Device Ravision

Device Typa (2107)
meb-0876-00

bits<31:16>

Name:

Device Revision

Mnemonic.

DREV

Type:

RW, 0

Identifies the revision level of the device. The revision level is loaded
by hardware during BCI DC LO. For revision H, the DREV field
contains 7 (hex). There is no revision I. Starting with revision J, the
DREV field reflects the letter revision of the module as follows:

blte<15:0>

DWHMBA/B Revielon

DREV (decimal)

DREV (hox)

000A

0008

000B

001A

Name:

Device Type

Mnemonic:

DTYPE

Type:

RW, 0

Identifies the type of VAXBI node. The processor’s console code loads
DTYPE with 2107 (hex) after successful completion of self-test.

DWMBA XWMi-to-VAXBI Adapter

6.5

interrupts
The DWMBA XMI-to-VAXBI adapter implements two mechanisms
for generating interrupts to XMI CPUs. One is in responee to
interrupts from the VAXBI bus and one in response to errors
detected on the XMi bus. The BIIC also generates error interrupts

on the VAXBI in response to errors on the VAXEI.

DWMBA XMi-to-VAXBI Adapter

6.5.1

DWMBA XMi-to-VAXBI Adapter Vector Formats and Requirements
Interrupt vectors returned by VAXBI nodes, as seen by the XMI IDENT
transactions, fall into three categories:
o

XMI bus device interrupt vectors

UNIBUS device interrupt veciors

VAXBI bus device interrupt vectors

Figure 6-2

XMI Bus Vector Format

XMI VECTOR

Figure 6-3

MBZ

UNIBUS Vector Format

F.naz

210

UNIBUS VECTOR [MBZ

L— Starnting Address Offset
mab-0681-80

Figure 6-4
15
L]

VAXBI Node Bus Vector Format
8

s | NODEID hnaz

k—— vaxeivector ——
it<139>0lBIVEL OR=0

LN ]

XBIVOR | VAXBIVECTOR <80>

DWMBA XMi-to-VAXBI Adapter

6.5.1.1

XM Bus Vector Format
XMI device-initiated interrupts return vectors in the format shown
in Figure 6-2 as a response to an XMI IDENT transaction. It is the

responsibility of the operating system software to assign vector values to

any vector register(s) that may exist on XMI devices that are capable of
generating interrupt requests.

65.1.2

Offestiable Bus Vectors
There are several interrupt vectors returned by offsettable devices,
including the BUA (VAXBI-to-UNIBUS Adapter) and the KLESI-B (VAXBI

to Low-End Storage Interconnect). These other buses suppo=t devices that
generate interrupts that must be differentiated from vectors generated by
VAXBI devices. Figure 6-3 shows an example of the UNIBUS vector.

The UNIBUS vector field is an architecturally fixed vector returned by
UNIBUS devices. Bits <8:0> cannot be modified by software. The SAO
field must be a non-zero software assemble offset value to be used to index
into the SCB with a unique vector.
65.1.3

VAXBI Node Vectors

The VAXBI node vector format has bits <15:9> as non-zero and are
assigned a value by the operating system during initialization. The
offset value, contained in XBI VOR (Vector Offset Register or BVOR) on
the DWMBA/B module is concatenated with the vector value returned
by a VAXBI node, bits <8:2>, providing that bits <13:9> of the VAXBI
vector are zero. This new value is returned to the XMI commander during
XMI IDENT cycles when a VAXBI node generates the interrupt request.
If bits <13:9> of the VAXBI vector are non-zero, the vector will not be
concatenated with the BVOR and will be passed to the XMI commander
unchanged.

VAXBI device-initiatad interrupts return vectors in the format shown in
Figure 6—4 as a response to an XMI IDENT transaction. Node ID is the
VAXBI node ID of the interrupt node. S is the interrupt vector number,
which can be one of four possible interrupt vectors per node. BVOR must
be a non-zero software assemble offset value to be used to index into the
SCB with a unique vector for multiple VAXBI devices. BVOR bits <15:9>
may be supplied by the DWMBA. The BVOR is necessary as the XMI is
capable of supporting multiple DWMBA nodes, where the same device
may exist on multiple VAXBIs. Since some VAXBI nodes might have fixed

vectors that are unchangeable by software, the RVOR is used to ensure
that multipie VAXBI devices with fixed vectors have a unique entry point
into the SCB.

DWMBA XMi-to-VAXBI Adapter

6.5.2

Interrupt Levels and Vectors
Table 6-6 lists the interrupt conditions used by the DWMBA adapter.
Table -6

DWMBA Adapter interrupt Levels end Veciors

IPL (hox)

kiama

DWMBA VAXBI Ermor/Status ~ XMI-7
Change

VAXB! Levei 7 interrupt

VAXBI-7

VAXBI IPINTR 6 Interrupt

BIIC UINTRCSR REG-6'

VAXBI Level 6 Interrupt

VAXBI-6

VAXBI! Leval 5 Intarrupt

VAXBI-S

VAXBI Leve! 4 Interrupt

VAXBI-4

Vector (hex)

'The DWMBA treats IPINTR as an error. The IP..:
TR « alue is written in the
UINTRCSR as a generic VAXBI interrupt. For example, it bits <13:0> of the vecior
value equals zero, then the DWMBA will logically "OR" the contents of the BVOR
(Vector Offset Register) with the value cantained in bits <8:0> of the vector.

6.5.3

Types of interrupts
Two types of interrupts are generated or passed through the DWMBA to
the XMI bus. They are the interrupts generated by the DWMBA due to
a st..tus change or error condition and those interrupts generated on the
VAXBI bus by I/O devices. The VAXBI interrupts are translated into XMI
interrupt transactions.
653.1

DWMBA-Generated Interrupts

The DWMBA generates two types of interrupts: error interrupts and
power-fail interrupts.

Ervors detected by the DWMBA logic set bits in the DWMBA/A module
and DWMBA/B module error summary registers. If the corresponding
interrupt mask bit is enabled, an interrupt at level 7 (IPL 17) is requested
by the DWMBA. A DWMBA error interrupt request is cleared when an
XMI IDENT transaction is received at IPL 17.

The DWMBA generates an IVINTR transaction when it detects that a
power failure is about to take place on the VAXBI. When BCI AC LO
is asserted, the DWMBA/A module generates an IVINTR transaction
with "mem write error" set in the Type field that targets the XMI node(s)
specified in the Destination field of the command. During power-up and
initialization, the DWMBA does not issue IVINTR transactions.

DWWMBA XMi-to-VAXBI Adapter

6.5.3.2

VAXBI-Gonerated Interrupte
Interrupts directed at the DWMBA node are passed on to the XMI bus.
The BIIC handles INTR transactions directed at the DWMBA node and

sets one of four interrupt leve! flip-flops, which store the acceptance of
an INTR transaction at the given level. The INTR transaction causes
the DWMBA/B module to iszue an XMI interrupt command, at the
corresponding IPL, to be poeted on the XMI.
The BIIC generates INTR transactions on the VAXBI in response to

errors detected on the VAXBI. The user has control of this mechanism
via the BIIC Error Interrupt Control Register. The DWMBA's BIIC is
configured to select itself as a destination node for INTR transactions,
thereby informing an XMI CPU of VAXBI-related ervors.

Interprocessor interrupts generated by VAXBI nodes targeting the
DWMBA are supported. For the DWMBA to receive interprocessor
interrupts, the software must set the DWMBA/B module’s IPINTR Mask
Register and enable the IPINTREN bit in the DWMBA/B module's BCI
Control and Status Register.
The DWMBA handles intcrprocessor interrupts by asserting the BCI INT
6 signal on the DWMBA/B module’s BIIC, causing the BIIC to generate
an IPL 16 interrupt. The DWMBA/B module’s BIIC Interrupt Destination
Register configures to select itself as the destination of the interrupt
transaction, thus causing this interrupt to be received by the DWMBA/B
module as a generic VAXBI IPL 16 interrupt. When the DWMBA/B

module receives an IDENT transaction from the XMI, it issues the IDENT
onto the VAXBI. If no other interrupts are pending on the VAXBI, the
DWMBA/B module’s BIIC issues the vector that had been previously
written by software during initiglization onto the BIIC’'s UINTRCSR
rcgister.

The :nterprocessor interrupt vector value written in the UINTRCSR is
treated by the DWMBA hardware as a generic VAXBI interrupt. If bits
<13:9> of the vector value are zero, then the DWMBA logically ORs the
contents of the BVOR with the value contained in bits <8:0> of the vector.

DWMBA XMi-to-VAXBI Adapter

6.5.4

XMIIDENT to VAXBI IDENT
There are two XMI to VAXBI IDENT transactions for the DWMBA: one
when the DWMBA has no interrupts pending and one when the DWMBA
has an interrupt pending.

6.5.4.1

Xl to VAXBI IDENT

The DWMBA issues a VAXBI IDENT when an XMI CPU issues an XMl
IDENT unless the DWMBA has a pending interrupt at the IDENTed level.
The DWMBA issues an IDENT response cycle on the XMI (Good Read
Data response—funiction code = 1000 with the vector in bits <15:2> of the
data field) upon receiving a vector from the VAXBI.

The VAXBI interrupt-pending flip-flop(s) and th- INTR Sent Flip-Flop(s)
that correspond to the IDENTed IPL are cleared when BCI RAK L is
asserted, ater the DWMBA/B module makes a VAXBI request.
If the requesting VAXBI node aborts its interrupt request before the XMI
CPU generates an IDENT transaction at that level, the resulting IDENT
on the VAXBI gets NOACKed. The DWMBA then issues a Read Error
Response (RER) to the XMl commander and sets the IDENT Error bit in
the DWMBA/B module's Error Summary Register.

654.2

XA to VAXBI IDENT (DWRMBA Interrupt Pending)

If the DWMBA has its interrupt-pending flip-flop set and it decodes an
XMI IDENT transaction with IPL 17 get in D<19:16> of the IDENT
command, it responds by issuing the DWMBA's vector that is located in
BVOR. When the vector has been written into the DWMBA/A module’s
register file by the DWMBA/B module’s master sequencer (gtate machine

controller), the DWMBA's interrupt-pending and sent flip-flops clear.

If an XMI CPU issues an IDENT to the DWMBA and the DWMBA has
no interrupt-pending flip-flops set, the DWMBA issues the IDENT on the
VAXBI. There is a direct mapping of the XMI IDENT IPL (D<19:16> to
that of the VAXBI D<19:16>). No remapping is required.

SwniBA XMI-to-VAXBI Adapter

6.6

Error Reporting
The DWMBA adapter uses two mechaniems for detecting and

reporting errors. One mechaniem is the BIIC fr.r VAXBI-related
errors and the other mechanism deals with DWMBA-internal and
XMil-related errors.

6.6.1

VAXBI Errors
The BIIC implements error checking and reporting features that deal with
the VAXBI. These errors are reported to an XMI CPU via BIIC registers
where bus errors are reported: the Bus Error Register, Error Interrupt
Control Register, and the Interrupt Destination Register.

6.6.2

DWMBA Errors
Error generation and checking is performed on the DWMBA, both ports
of the CPU, DMA-A and DMA-B register files, and the IBUS data path
between the modules.

A specific error is flagged in one of the two Error Summary Registers

(AESR and BESR) so that errors can be traced by software and
diagnostics. When an error occurs, the DWMBA locks its error and
address registers to ensure that a subsequent transaction will not change
any states in the DWMBA until software services the error condition(s).
Even though an error causes the DWMBA/A module to assert IVINTR,

any pending DMA or CPU transactions that are error free are processed to
completion, even if a previous transaction was halted due to an error.

6-59

DWMBA XMi-to-VAXBI Adapter

6.6.3

DWMBA XMIi-to-VAXBI Adapter Error Responge Matrix
Table 6~-7

XMl Errors During DMA Transactions (VAXBI to XMl Memory)

Xi2l Eeror

Read C/A Cycle

Read Dats Cycle

Write C/A Cycle

Write Data Cycle

XMI Fault

Corrected Read

DWMBA generates

Corrected
Confirmation

DWMBA generates
interrupt

DWMBA genaerates
interrupt

Read Error
Response

DWMBA generates
interrupt (NO ACK

DWMBA generates
intarrupt
-

inconsistent Parity

Parity Error

DWMBA gonerates

DWMBA generates

Write Data NO ACK

DWMBA generates

DWMBA geneiates

DWMBA generates
interrupt (NO ACK

Data

Command NO ACK
Write Ssquence
Error

interrupt

to VAXBI)

interrupt

Read Sequence
Error

interrupt

= DWMBA generates
interrupt

DWMBA generates
interrupt

interrupt

to VAXBI)

Transaction Timovut

DWMBA/A module
generates IVINTR

DWMBA/A module
generates, IVINTR

DWMBA/A module
generates IVINTR

No Read Response

DWMBA generates

Write Error Interrupt
Read/IDENT Data
NO ACK

6-60

interrupt (NO ACK
to VAXBI)

DWMB
A XM!i-to-VAXBI Adapter

Table 6-8

XMi Errors During CPU I/C Transactions (XMl to VAXBI)

Heal Ervor

Read C/A Cycle

Read Data Cycle

Write C/A Cycle

Write Data Cycle

XMI Fauh

Correctad Read
Data

DWMBA generates

Corrected
Confirmation

interrupt

Read Error
Responsa

Inconsisteni Parity
Parity Emor

DWMBA genaerates

DWMBA generates

DWMBA generatas

DWMBA generates

interrupt

Write Data NO ACK

Command NO ACK
DWMBA generates

Write Sequence
Error

interrupt

Rsad Segusnce
Error

Transaction Timaout
No Read Responsa
Write Error Interrupt

Road/IDENT Data
NO ACK

DWMBA generates
interrupt

DWMBA XiMi-to-VAXBI Adapter

Teble 6-9

DWWMBA Errore During DMA Trangactions (VAXBI to XMI Memory)

DWBA Error

Reed C/A Cycle

Read Data Cycle

Write C/A Cycle

Write Data Cycle

—————————— DWMBA/A XMI Module — — — — == = = e e —
O Write Failure

BCIACLO

DWMBA/A module

= DWMBA/A module

genarates IVINTR

generates IVINTR

IBUS DMA-A Data
Parity Error

DWMBA/A module
generates IVINTR

IBUS DMA-A C/A
Faiiy ciar

DWMBA/A module
ganeiaies nieirupi
(NO ACK to VAXBI)

DWMBA/A module
generatss IVINTR

—

{8US D¥MA-B Data
Parity Error

DWHMBA/A module
generates IVINTR

1BUS DMA-B C/A
Parity Error

DWMBA/A module
generates interrupt
(NO ACK to VAXBI)

DWMBA/A module
genarates IVINTR

iBUS CPU Data
Parity Error

Multi-CPU Errors
Interlock Read Error

DWMBA generates
interrupt Lock Time

IBUS Data Parity
Error

DWMBA generates
interrupt. Bad

DatafParity to
VAXBI.
liegal CPU
Command

generates IVINTR

DWMBA XMi-to-VAXBI Adapter

Table 6-10

DWMBA Errors During CPU /O Transaciions (Xl to VAXBI)

DWBA Error

Read C/A Cycle

Read Data Cycie

Write C/A Cycle

Write Deta Cycle

———
e e
o e = - DWMBAVA XMI ModUI®
— = e e e e — — —

O Write Failure

BCIAC LO

DWMBA/A module
generates IVINTR

1BUS DMA-AData
Parity Error

IBUS DMA-A C/A

DWMBA generates
interrupt. RER to

= DWMBA/A module
genarates IVINTR

DWMBA/A module
generates IVINTR

= DWMBA/A module
generates IVINTR

Parity Error

IBUS DMA-B Data
Parity Error

IBUS DMA-B C/A
Parity Error

IBUS CPU Data
Parity Error

XML

—————————— DWMBA/B VAXBI Module — — — — — —~ = — — —

Multi-CPU Errors

DWMBA generates
interrupt. RER to

—

DWMBA/A modulo
generates IVINTR

DWMBA/A module
generates IVINTR

XMI

Interlock Read Error

{DENT Error

RER to XMl

1BUS Data Parity

DWMBA generates

lilagal CPU

DWMBA generates

Eror

interrupt. RER to

DWMBA/A module

DOWMBA/A module

generates IVINTR

DWMBA/A module

Xhal.

Command

interrupt. RER to
XMl

generates IVINTR

DWiBA Hili-to-VAXBI Adapter

Table 6-11

VAXBI Errors During DMA Transections (VAXBI to XAl Memory)

VAXB! Erroe
(CWRiBA/B
modula's BIIC)

Roed C/A Cycle

Read Data Cycle

Write C/A Cycle

Write Data Cycle

DWMBA generates

DWWMBA generates

DWMBA generates

interrup?

interrupt

inferrupt

NO ACK to Multi105pONSES

RMaster Xriiit Ercor
Control Xmit Error
Master Parity Error

DWRMBA generates

Interlock Sequence
Error

interrupt

DWMBA genarates

Transmitter During
Fault

interrupt

IDENT Vector Error

Command Parity
Error

DWMBA generates

interrupt

DWMBA generates

Slave Parity Error

imerrupt

Read Data
Substitute

Retry Timeout

Stall Timeout
Bus Timeout
Nonexistent Address

DWMBA generates

lilegal Confirmation
Error

iD Parity Error
Corrected Read
Data
Null Bus Parity Error

interrupt.

DWMBA generates

interrupt.

DWMBA XMi-to-VAXBI Adapter

Tabie 6-12

VAXBI Errers During CPU /O Transactions (XMI TO VAXBI)

VAXBI! Error
(OWiiBA/B

modula's BIIC)

Road C/A Cycle

Reed Data Cycle

Write C/A Cycle

Write Data Cycle

NO ACK to Mutti-

DWMBA generates

responses

interrupt

Master Xmit Error

DWWMBA generates

DWMBA generates

module generates

DWMBA/A module

DWMBA generates

interrupt. RER to

Kidi
Control Xmit Error

DWMBA generates

IVINTR.

interrupt

Master Parity Error

interrupt. DWMBAV/A

interrupt.

generates IVINTR.

interrupt

DWMBA generates

interrupt. RER to
XMl

interiock Saquence

DWMBA generates

Transmitter During

DWMBA generates

= DWMBA generates

IDENT Vector Error

DWMBA generates

Error
Fault

intarrupt

interrupt

intarrupt

interrupt

Command Parity

DWMBA generates

Error

interrupt

Slave Parity Error

interrupt

OWMBA generates
interrupt

Read Data

Substitute

DWMBDA generates

interrupt. RER to

DWMBA genarates
interrupt. DWMBA/A

XMl

Retry Timeout

DWMBA generates
interrupt. RER to

XMI

module gensrates
IVINTR.

Stall Timeout

Bus Timeout

DWMBA generates

—

DWMBA generates

intarrunt, AER 10
XAl

interrupt. DWMBA/A
module gansrates
IVINTR.

Nonexistent Address

llegal Confirmation
Eror

iD Parity Error

DWMBA gensrates

DWMBA generates

interrupt. RER to

interrupt. DWMBA/A

module ganerates
IVINTR

~ DWMBA genarateas
interrupt. RER to
XM

DWMBA generates
interrupt

DWMBA generates
interrupt. RER to
XMl

= DWMBA generates = DWMBA generates
interrupt. DWMBA/A
interrupt.
module generates

DWMBA/A module

IVINTR

generates IVINTR

DWMBA generates
interrupt

DWMBA XMi-to-VAXBI Adapter

Table 6-12 (Cont.)
VAXBI Error
(DWiBA/B

VAXBI Errors During CPU /O Trangactions (XA TO VAXBI)

module's BIIC)

Read C/A Cycls

Read Data Cyele

Writs C/A Cycle

Write Date Cycle

Corrected Read
Data

DWMBA generates
intarrupt

Null Bus Parity Enor

6-66

DWIMBA XMi-to-VAXBI Adapter

DWMBA Initialization, Self-Test, and Booting
This section discusses the DWMBA adapter initialization and
diagnostics.

DWMBA Initialization
The three ways to reset the DWMBA are:

Power-Up Sequence—When the DECsystem 5800 is powered up, XMl

AC LO L and XMI DC LO L are sequenced so that all XMI nodes are
reset.

System Reset—The XMI emulates a power-up sequence by asserting
the XMI RESET L line, causing the power supply to sequence XMI AC

LO L and XM!I DC LO L as in a "real” power-up. Software asserts XMI
RESET L by writing to IPR55. The XMI does not differentiate between
a "real" power-up and a system reset. The console INITIALIZE
command generates a system reset if no argument is given.

Node Reset—A DWMBA is "node reset’ by setting its XBER<30>

(NRST) bit. The console INITIALIZE command generates a node

reset if a node ID argument is provided. For the KN58A processor the

differences between the node reset and a system reset are as follows:
— XMI AC LO L is not sequenced during node reset.

— VAXBI "self-test” is not run during i:ode reset.
When initalized, the DWMBA performs as follows:
e

All DWMBA logic resets to a known state.

The DWMBA asserts XMI STF L until self-test completes successfully.

The DWMBA registers are initialized to a known value by self-test.

The VAXBI subsystem of the DWMBA resets as would any VAXBI system
whenever the XMI resets. Each VAXBI backplane in a DECsystem 5800
is connected to power, and each DWMBA/B module has logic that controls
the VAXBI backplane.

Setting XBER<30> (NRST) initiates a node reset, which resets both the
DWMBA/A module and DWMBA/B module as well as the corresponding
VAXBI subsystem. When NRST is written to a one, the DWMBA/B module
sequences the BI AC LO and BI DC LO signals, causing each VAXBI node
to reset its logic.

A DWMBA/B module and its VAXBI subsystem, when powered do..
=, has
no effect on the DWMBA/A module and the XMI bus.

DWMBA Xii-to-VAXBI Adapter

6.7.2

DWMBA Seli-Test and Diagnostics
The two diagnostic control registers are used to force bad parity internal

to the DWMBA, for performing a loopback in the BIIC, and to act as
temporary storage registers for diagnostic routines.

6.72.1

Loopback

Two diagnostic loopbacks are implemented on the DWMBA: the BIIC
loopback of the VAXBI and a transformation of a CPU transaction into a
DMA transaction.

The BIIC loopback of the VAXBI occurs when the DWMBA/B module’s
BDCR1<3> (Force BIIC Loopback Mode) sets to a one.
When BDCR1<4> (Flip Bit 29) sets to a one, the DWMBA/B module
inverts the state of address bit<29> and BCI parity when they are sent to

the BIIC, allowing a VAXBI /O space request to be converted into a DMA
request that targets the DWMBA as the selected slave. This causes a CPU

transaction to be transformed into a DMA transaction (Jongword only) that
accesses XMI memory.

6.7.2.2

Self-Teat

DWMBA self-test is executed by the boot processor on the XMI using the
processor’s resident ROM.

R R ARKHIOGOOUN O

RL S saRAR R AR AR

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
rtdds
00
s tesdedo
006
stttts
060
00t
70701007000
0000
OO
N
W
Y
R

XXX
XXXXX

AAXKXKX

XXXAUKKXKX

KAXXAXXKKKX
XXAXXXXAXXXKXXX

F6.0.0.40.0.04.9080444

KRXXXXAAXKKAKKKEX
XX KEXXKAX
KXX
KKK
KAX
RAXX
XK
KA AXAXLXK
AXXA

AXAKKLKXKK
XXX RXHR
KAXXXKUE
K
XA LKKAKLK
XX KKKXAR
HAXKXX
KKKKX
AEALKH
AKX
AXX
XXX
KA
AKX
X
XAK LXK AKKXKKK
XAXA
XX
A XL L
KHAX
XXAXKKXXXX
AR K E XA XKEX
OO
XXX
BI

KKK
XH
AX
KXY XX KAAXAKE
XK H AKX KEX
KURH

KX
XHHXH KR

K XXX H XX XA X AR KK KX UK KKHKKKX
HEUH XK KK H AKX KKOARKAKK

LU
LS LIL PRSI LI UIRP LU
WY
GO DO T W XDO
OO

XX XUHAX XX KXX

Power and Cooling Systems

The DECsystem 5800 power system consists of an AC power controller, the
power and logic unit, five power regulators, and a temperature sensor. The
cooling system consists of two blower units and an airflow sensor, with the
airflow path through the XMI and VAXBI card cages. See Chapter 12 of
the DECsystem 5800 Options and Maintenance manual for more on power
components.

The power system contains the following components:
*

An H405-E AC power controller for 60 Hz systems; for 50 Hz, an
H405-F and a high-voltage autotransformer

An H7206 power and logic unit (PAL)

Two H7215 power regulators, one for the XMI card cage and one for

Three H7214 power regulators, two for the XMI card cage and one for

An XTC power sequencer

A temperature zensor and an airflow sensor

the VAXBI card cages

7-1

Power and Cooling Systems

7.1.1

Input Power
The input power is five-wire (three-phase AC, neutral, and ground). 208V
60 Hz AC enters the H405-E AC power controller. Either 380 or 416V
50 Hz AC inputs the H405-F AC power controller and then enters the
high-voltage autotraneformer, which reduces the voltage to 208.

The H405 AC power controllers suppress conducted einissions. The
AC power controller has a contactor that closes when the control panel
upper key switch is in any position except "0," allowing AC power to the
H7206, and opens if the cabinet’s temperature sensor detects an excessive
temperature.

7.1.2

H7206 Power and Logic Unit
The H7206 PAL:

e
o

Rectifies the three-phase power into 300V DC for the DC-to-DC power

regulators

Develops regulated +14V DC for both internal use and the DC-to-DC

power regulators

Develops 110 watts of 24V DC for the cooling system blowers and its
own internal fan

Controls the interface between power regulators

Controls the interface between the power regulators and the rest of
the DECsystem 5800 system

A red LED on the front face of the PAL lights to indicate that an inhibit
(shutdown) latch has been set.
Two green LEDs light to indicate the presence of the +14V DC for internal
use and the presence of 300V DC.

7.1.3

H7214 Power Ragulator
The H7214 inputs 300V DC and +14V bias. A 30 kHz clock synchronizes
this to all other power components. Qutputs are 120 A of +5V DC and 0.5
A of +13.5V DC for Ethernet transeeivers. A green LED lights to indicate
that the +5V output is present.

Power and Cooling Systems

714

H7215 Power Regulator
The H7215 inputs 300V DC and outputs 20 A of -8V DC, 7 A of -2V DC, 4
A of +12V DC, and 2.5 A of -12V DC. A green LED lights to indicate that
the outputs are present. An internal overtemperature switch asserts the
OVERTEMP signal when necessary.

715

XTC Power Sequencer
The XTC power sequencer contains:

7181

XMI reset timing control logic

Time-of-year (TOY) clock power circuits

[EIA RS-232/RS-423-compatible congole line driver and receiver

X Reest Timing Control Logic

The XMI reset timing control logic handles these sequences:

7152

Cold start power-up

Loss of AC power followed by a cold start power-up

Reset, which mimics a power-down and then a cold start power-up

TOY Circuite

The TOY circuits consist of a battery charger circuit that trickle charges
the TOY clock battery and a voltage-level detection circuit that monitors
the TOY battery voltage.

7153

Conegole Line Driver and Racelver
The XTC power sequencer contains the gystem console line driver and
receiver, which are EJA RS-232/RS-423 compatible.

7-3

Power and Cooling Systems

7.1.6

Power System Signals
Power gystem signals are partitioned so that a failure of power supply 1

shuts down only the XMI! side or a failure of power supply 2 chuts down

only the VAXBI side.

The power system gignals are described in Table 7-1.

Teble 7-1

Power System Signals

Kemae

Origin

Daatination

Beenription

ON SENSE L

Control pane!

XTC

Asserts when the control panel upper key switch

PNL RESET L

Controf panel

XTC

Asserts while the cont:ol panel! Restart button

i3 in any position except "0."

is pressed. Causes the XTC to start the reset

sequence.

STANDBY CMD L

Control panel

H7206

Asserts when the control panel upper key ewitch

ONCMD L

Control panel

H7206

Asseris when the control panel upper key switch

is in any position except "0."

is in eithar the Enable or Secure position. Applies

DC power to entire DECaystern 5800.

PBREQL

Control panel

H7206, then

Asserts when STANDBY CMD L asserts to close

bus and
AC power

systom and memory. Controls all peripherals tied
to the DEC power bus.

from H7206
to DEC power

controlier

DEC Power Bus

Control panel

H405

DCOKH

H7206

XT1C

a contactor in tha AC power controller, applying
AC power to H7206 and DC power to cooling

Safety Extra Low Voitage (SELV) circuit that
allows the DECsystem 5800 io tumn Gther
equipment on and off.

Asserts to indicato that the DC outputs from the

powser reguigiors are OK. Used by the XTC power
sequencar to start the power-up/power-down
sequenca.

ACOK H

H7206

X1C

Asserts 10 indicate that the AC input voliage is

adequate. i deasserts when the H7208's 300V
DC output level reachss a level that guarantees
4.2 milliseconds of acceptable 300V DC prior to

the deassertion of DCOK H. Used by the XTC
power sequencer during the power-up/powerdown SaQuUEncs.

CHANNEL nOK (CH n
OK)

Power regulator n

H7206

OVER TEMPZRATURE n

H7215

H7206

7-4

Asserts t0 toll the H7208 that the power regulator
specified by the number n is OK.
Assents 1o tell the H7206 that the H7215

tamparature is above epaciiication, causing an
orderly system shutdown foliowed by a latched
inhibit of the appropriate outputs.

Power and Cooling Systems

Table 7-1 (Cont.)

Power System Signals

Name

Origin

Deatination

Dascription

INTERLOCK nINHIBITH

Cabinet

H72%%6

Asserts 10 tell the H7208 that an interlock switch

inmerlock
switch

BLOWER FAULT H

Cooling
system

CHANNEL n INHIBIT

H7206

has boen thrown, cauging an orderly system
shutdown followed by a latched inhibit of the

eppropriate oviputs.

H7206

Asserts to indicate an airflow sensor has detected
@ loss of airflow. When asserted for more than

30 seconds, an orderly system shutdown occurs
followed by a latched inhibit of the outputs.

Power regulator n

Asserts to command the respsctive power

regulator to turn off and reset to a ready state
80 that output power restores as the signal
deasserts.

SYNC

7.2

H7206

Power

reguiator

A pulse train used to synchronize depandent
power regulators.

Cooling System1
The cooling system consists of two identical blowers, one for the front of
the cabinet, the other for the back. An airflow sensor signals a loss of
airflow.

The H7206 PAL unit has an internal fan.

7-5

20
0900000
T 07079107016/91619 0160 $.0101010.0.00 00LLLIIETTO000000
RO OO D R RISONO NN R R KK KX XXX AR R EEKKR KX
THHRX K XIOCOOOK KN KRR KIOOOND 00NN

XARKKXAX

KR RERY
KRR KOOI X KRR KRKKR
o]
te 03
1001601419906 00.0.0:60.9.09600608008
e
0
bty
abo
064
000t
E00
000
088
8.0
101000
KK
EX
XXAK KK LKAKKEK
KRX
R KU HX AKX
RXXXKA
X
HXAXXRXAXKHODOARKXTXROCDOOOOEA
e
b ettt ed0
0000000t0000
01970009
PO 6400000040000 00080800840
eI 0 0108100000.0.0.00.0.00050603081
OO REHRKHHHRHKAKAEKA
P0.9:019. 0.4 06761065 0.0. 86,0490
EXXOONOOGHOGHRKOOK
HEHRKIOOOOOOOUOXX
P6.6.0.0.014.0.6:9.0.0:0.068.8
PO 010.4.0.9.89 04000
HHHRIHAICODEOK

D0.9.0.6.00.65.95 400486801

XOAKAXKXXXKKXKAKXKXXX
ARAXXRALAKXRXXKOXAKKXKAX
HARXXXX XX KA XX KK XK ARKLXKKAR
AXKLKXKK
UX
XA HKARKAK
RL
KAXXX

XAKIOOHAURKXKAKXRKKRARXKKAKKK
KKK
X
XA KAXAAXK
KH
UK XXX AX KR
HH
HHUK
AUHXXKK KK T UK U XK REARKKHX XA K LK KXXAK

o000 89,00 4000 0000000 eeeostesesse]
ty ]
D19701919.0 9,069 4.0:0.0.0.4.00 00000000080t

O 00070 909 eIt reteds bt et r ettt bt ooy vt et iyl
O

X X

XX XU XY KX

U KRR XXX KX AR AR KU RERKAKAXAK

Console Entry Points

The following entry points are defined by the R3000 portion of the console
program for the use of the operating system loader, operating system, and
other stand-slone programs.

All routines are called as normal C-language routines, using the normal
R3000 calling conventions. The entry points are located in a table
beginning at address b00a 0000. The beginning of a routine is at address:
b00a 6000 + (8 * entry_nr)

where entry_nr is the entry point number shown in the routine description.

It is the responeibility of the caller to handle exceptions. The console does
not enable its own exception handlers.

A.1

reset - Power-up console entry - Entry 0
This entry point receives control when the R3000 chip is reset. It is not
normally invoked by software.

promexec - Exec new program - Entry 1
Not currently supported.
R

exit - Reenter console - Entry 2
This entry point returns control of the processor to the console program,
without reinitializing the console state. The console will display a message
indicating an exit was performed with the return value status. Control
will then pass to the console prompt.

The state of the program that called exit is not preserved.
void
exit (atatus)

int status;

reinit_console - Reinitialize the console - Entry 3
This entry returns contro! of the processor to the console program and
reinitializes the console’s state. It is normally called only by the cunsole

program itself to recover from unexpected error conditions.

A-1

Congoie Entry Points

conditional_boot - invoke power-up aciion - Entry 4
This entry returns control of the processor to the console program, and

takes the action selected by the front panel key switches. If the key
switches are set to Halt and Enabled, the console prompt will be displayed.
If the key switches are set otherwige, the system will be rebooted as if
system power-up had occurred.
void

conditional
boot ()

A.6

reboot - Reboot the system - Entry 5
This entry unconditionally attempts to reboot the system, from the device
specified in the bootpath environment variable. If the bootpath is not set
or ig invalid, an error message is displayed and control remains with the
console program.
void
()
raboot

open - O;ofn a file - Entry 6
Open provides /O access to a file or device specified by filename in a
fashion similar to the Ultrix system call. The flags perameter indicate

the type of access desired. Returns an integer file descriptor that must be
supplied on cslls to routines that manipulate the file.

If an error is encountered, a message is displayed on the console terminal,
and open returns -1,

The pointer used to mark the current position within the file is set to the
beginning of the file.
A maximum of 7 files can be open simultaneously. On the first open for a
given device controller, the console may reinitialize the controller.
int
open(filename,

flaqs)

char *filename;
int flags:

A71

filename
The string supplied for the filename parameter has the general form:
dev{controfler,unit,pariition
path)

The perentheses and the dev and controller components are always

required. All the numeric portions of the filename can be given either
in decimal or in hexadecimel, by using the Ox prefix. The compcnents of
the filename string are:

A-2

dev—Identifies the type of device being opened. Recognized devices
are discussed in Section A.45.

Console Entry Points

controller—Identifies the physical path through the /O adapters to the
device being opened. The controller string is of the form “/xl/bm/cn”
where [, m, and n are the XMI node number, VAXBI node number,

and CI node numbers needed to locate the boot device. The /b and /c
components are omitted if they are not applicable.
¢

unit—lidentifies the unit number of the device. If the unit number is
omitted, it defaults to zevo.

partition—ldentifies the starting logical block of the softwarc managed

partition of the device. Partition is only meaningful for disk devices. If
omitted, partition defaults to zero.

A72

path—Supplies the Ultrix path name of the file to be opened. For disk
devices, the path may be specified but is ignored. For Ethernet boots,
the specified path is requested from the booting system. Specifying the
path parameter is illegal on boots from tape.

flags
The flags argument indicates the type of access requested. Legal values
are:

O_RDONLY = 0000
O_WRONLY = 0001

read - Read from a file - Entry 7
This funciion atiempis to read cit bytes from a file into a buffer, buf. The
data is read from the current position of the file, and the number of bytes
read is returned. fd is a file desci iptor returned by an open() call.
A returned value of 0 indicates the end of the file. If an error is

encountered, a message is displayed cn the console tzrminal and -1 is
returned.
int

read(fd,

buf,

cnt);

int fd;
char

*buf;

int cnt;

A.9

write - Write to a file - Entry 8
The write entry attempts to write cnt bytes of data from the buffer buf to
a file. The file is specified by fd, a file descriptor returned from an open()
call. The data is written at the current file position.

The number of bytes written is returned if the write was successful. If
an error occurs, & message is displayed on the console terminal, and -1 is
returned.

Console Entry Points

int

urite(iu,
int
char

buf,

cnt)

£d;
tbuf;

int cnt;

A.10

loctl - Device-specific /O operation - Entry 9
This entry performs @ device-specific operation, as specified by the
value supplied in cmd. The device is specified by fd, a file descriptor

returned from an open() call. The supported operations are discussed
in Section A 45. If an error occurs, 8 message is issued on the consgole
terminal, and -1 is returned.
int

ioctl(fd,
int f£d;

A.11

int

cmd;

int

arg.

cmd,

arg)

close - Ciose an open file - Entry 10
The close function tern.inaies access to the file associated with the file

descriptor fd. The console requires all files associated with a given device

or controller to be closed before other soRware attempts to gain contro! of

the device or controller.

If an error is encountered, @ message is displayed on the cor:ole terminal

and a value of -1 is returned.
int

close(fd)

int

A.d2

f£d:

lseek - position within a file - Entry 11
The Iseek function moves the pointer associated with a file open for
reading or writing. The file descriptor fd indicates the file to be positioned.
If how is set to zero, the file is positioned to the specified offset. If how is
set to one, off'set is added to the current file file position.
If an error cccure, an error message is written on the console terminal,
end & value of -1 is returned.
ine

lsack (£d,
int f£4;

offsst,

how)

unsigned offset;
int how;

A.13

getchar - Input a single character - Entry 12
This function reads a single character from the current console input

device. Control does not return until a character is available.
int
getchar();

aA-4

Console Entry Points

A.14

putchar - Qutput a single character - Entry 13
This function writes a single character to the current consc.e output
device.
A newline character is preceded with a carriage return. A tab character is

converted to sufficient blanks to position to the next "tab stop,” where “tab
stops” occur every 8 characters.
void

putchar(c)
char ¢;

A.15

ashowchar- Output a singlc character - Entry 14
This function writes a single character to the current console output
device.

Al printing characters are displayed normally. The function displays
backspace as "\b", form feed as "\f", newline as "\ n", carriage return as
"\r", and tab as "\t". All other nonprinting characters are displayed as
"\xxx", where xxx is the octal code for the character.
void
(c)
shouchar

char c.:

A.16

gets - Get line of input - Entry 15
The gets entry reads a line of input for the console terminal and places
the results into buf. Control returns when a carriage return or newline
character is received, terminating the line of input. The terminating
character is not buffered. The addres:: of buf is returned.
Line editing characters can be used when data is being read by gets.
char *
gets (buf)

char

A.17

®buf;

puts - Display a line of output - Entry 16
This entry writes a line of output pointed to by line to the console terminal.
Characters are handled as described for the pute function.
void

putsiline)

char *line;

Console Entry Polnts

A.18

printi - Print formatted values - Entry 17
The printf entry formats and displays one or more value arguments on
the console terminal. The formatting is controlled by the string passed as
fmt.

This function implements a subset of the standard C library printf
function. Consult C language documentation for datails. The following
format items are supported: %x, %d, %u, %o, %c, %b, %8s, %%, numeric
field widths with optional leading minus, and numeric field width with
leading zero.
void
printf (fmt,

va_alist)

char *fmt;
va_dcl

A.19 flush_cache - Flush processor cache - Entry 28

This function causes all entries in the processor’s primary instruction and
data caches to be invalidated.
void
flush_cache
()

A.20

clear_cache - Clear part of mrocessor cache - Entry 29
This function causes any cache entries associated with a specific range
of addresses to be invalidated. The range begins at address base and
extends for cnt bytes. Entries are cleared from both the instruction and
data caches.
void

clear_ cache(base,
unsigned base;
int

A.21

cnt)

ent;

setjmp - Save program context - Entry 30
The setjmp entry point is used for dealing with exceptions and error
conditions encountered by low-level console routines. When setjmp is
called, it saves the current stack position and register contents of the

program, and returns zero. A later call to the longimp entry point will
restore this saved context and return control to the point following the call
to eetjmp.
typedef

jmpbuf(ll};

int

set jmp ( imp_buf);
Jmp_buf

jmp_buf;

Console Entry Points

A.22

longjmp - Restore program context - Entry 31
This entry terminates execution in the current context and restores the

program context stored by a previous call to eeijmp. The context is
specified by supplying the jmp_buf used on the call to setjmp. When
context is restored, the setjmp call returns the value supplied in rval.
longimp (jmp_buf, rval);
struct jmp_buf *jmp_buf;
int rval;

A.23

utibmiss_except - Console UTLB miss vector - Entry 32
This entry corresponds to the console’s UTLP miss exception handler. The
position of this entry in the entry point table is dictated by the MIPS
processor architecture. Calls to this entry point are not supported.

A.24

getenv - Get value of an environment variable - Entry 33
This entry returns the value of the console environment variable specified
by name. If the specified name is not found, a null pointer is returned.
char *
getenv(name)
char

A.25

*name;

setenv - Set value of an environment variable - Entry 34
This entry sets the value of the console environment variable specified by
name to the string supplied in value. The function always returns zero.
Certain environment variables are known to the conscle. An error message
is issued if setenv is called for a variable marked read only. Variables
not marked as "volatile" are also stored in EEPROM, efter the memory

copy of the variable has been set. An error messages is issued if the
EEPROM copy cannot be written (corrupted EEPROM, key switch not set
to "Update," etc.) Various side effects also apply (for example, changing
the variable baud changes the console terminal baud rate).
int

setenv(name,

value)

char *name;
char *value;

CERRT

A.26

atob - Convert ASCIl te binary - Entry 35
Convert the ASCII string str to a binary value that is placed in the location
pointed to by intp. Conversion continues until a nonnumeric character (or
the null string terminator) is encountered. The return value is a pointer
to the unprocessed portion of str.

aA-7

Console Entry Polnts

The string must be integer, with an optional minus sign. Leading blanks
are ignored. If the first digit seen is not "0", the number is considered to
be in decimal notation. A prefix of "0Ox" indicates hexadecimal notation,
"Ob" indicates binary notation, and "0" followed any other digit indicates
octal notation.
If the converted value generates an arithmetic overflow, 8 warning
message is printed on the console terminal.
char ¢

atob(str, intp)
char ®str;
int

A27

*2intp;

stremp - Compare tv/o strings - Entry 36
‘The strcmp function compares two null-terminated strings. The return

value is zero if the two strings are the same, a negative value if str! is less

than str2, or a positive value if str] is greater than sir2.
int

stremp(strl,

str2)

char *strl;
char *®*str2;

A.28

strien - Find string length - Entry 37
This function returns the length in bytes of a null-terminated string.
int

strlen(str)
char

A.29

*str;

strcpy - Copy a string - Entry 38
This function copies the null-terminated string str2 to str! and returns a

pointer to the next available charscter position in strl. strl must be long
enough to contain str2.
char *
strepy (strl,
char *strl;

str2)

cher *gtr2;

A.30

strcat - Concatenate two strings - Entry 39
This function appends a copy of the null-terminated string str2 to the end
of the null-terminated string strl. str! must be long enough to hold the

additional characters. A pointer to strl is returned.
char

strcat (astrl,
char ®gtrl;

char *stre;

A-S

str2)

Console Entry Points

A.31

parse - Parse a simple command - Entry 40
This entry provides access to the command parser used by the console.
When this routine .8 called, it enters an endless loop executing the
following steps:
1

The string prompt is displayed on the console terminal.

Aline of input is read from the console terminal using ge?-

The argvize function is used to build an arge/argv argument list.

The cmd_table is searched for a command that matches the first entry
in the argv list.

8§

If a command is found, the corresponding routine is called with the
arge/argv arguments.

Ifthe routine returns a non-zero value, the usage string is displayed.

If the command is not found, an error message is printed.

struct cmd table(
char *name;
/* Command name */
int (*routine)(); /* Command routine */
char tusage;
/* Help or usage string */

}:
int

parser{cmd_table, prompt, reserved)
struct cmd_table *cmd table;
char
char

A.32

*prompt;
*reserved,

parse_range - Parse an address range - Entry 41
This entry provides access to the console routine that parses tr. - address
range syntax used in console commands. The string str is parse:... The first
component of the range is stored using basep, and the sec:nd component
of the range is stored using cntp. The function returns zero if the range is
of the form address:address, one if the range is of the form address#count,

and -1 if the range cannot be parsed. A range consisting of a single
number is treated as address#count, with a count of ope.
int

parse_rarge(str,
char

basep,

cntp)

®atr;

unsigned *basep;
unsigned *catp;

A.33

argvize - Parse string intc tokens - Entry 42
This entry breaks the string str into tokens and fills in a structure tlp with

a copy of each of the tokens. Tokens are delimited by spaces, which are
otherwise ignored. Text enclosed in single or double quotes is considered
as one token. The function returns the number of tokens found.

Congole Entry Points

struct token_liat(

char
char
char
G.A&r

*strptrs [MAXSTPINGS]);
/* Vector of token pointers ®/
*atrbuf [STRINGBYTES]:;
/* The token strings */
®*atrp;
/* Ptr to next free byte in strbuf @/
*atrent;
/* Number of tokens in structure */

}:
int

argvize(str,

tlp)

char ®str:

struct token_list *tilp;

A.34

help - Print help from a command table - Entry a3
This entry displays on the console terminal the help text associated with
one or more commands. The commands and help text are defined in emd_
table, as described for the command_parser entry point. An error message
is printed for any command not found in the table.

If no commands are supplied (arge=1), all help text is displayed.
int

help(arge,
int

argv,

cmd_tablea)

argc;

char **argv;

struct cmd_table *cmd_table;

A35

dumpcmd - Invoke console dump command - Entry 44
This entry point allows access to the consoie’s dump command, for
producing formatted dumps of memory. argv points to a sequence of
character string pointers. The first string is ignored. The remaining
strings are interpreted as the tokens that would be typed on the dump
command line. Tokens are the sequences of characters delimited by spaces.

If an error is encountered, @ message is displayed on the console terminal.
void

dumpemd (arge,

argv)

int argc:;
char **argv;

A.36

setenvcmd - Invoke console setenv command - Entry 45
This entry point allows access to the console’s setenv command. argv
points to three character strings, the first of which is ignored. The second

string specifies the variable to be set. The third string specifies the value

to be stored in the variable.

If an error is encountered, a message is displayed on the console terminal.
void
setenvemd (arge,
int argc;

char

A-10

*vargv;

argv)

Console Entry Polints

A.37

unsetenvcmd - invoke console setenv command - Entry 46
This entry point allows access to the console’s unsetenv command. argy
points to two character strings, the first of which is ignored. The second
string specifies the variable to be removed.

If an error is encountered, a meseage is displayed on the console terminal.
void

unsetenvemd (arge,

argv)

int argce:

char *vargv;

A.38

printenvemd - Invoke console printemfcommand - Entry 47
This entry point allows access to the console’s printenv command. argv
points to a sequence of character string pointers, the first of which is
ignored. The remaining strings specify the variables for which the values
should be displayed. If no additional strings are supplied (argc=1), then
all known environment variables are displayed along with their values.
If an error is encountered, a message is displayed on the console terminal.
void

printenvemd(arge,
int
char

A.39

argv)

argc;
*“argv;

general_except - Console general exception vector - Entry 48
This entry corresponds to the console’s general exception handler. The
position of this entry in the entry point table is dictated by the MIPS
processor architecture. Calls to this entry point are not supported.

A.40

clear_nofauit - Clear console fault handlers - Entry 51
Not supported.

A41

not_implemented - Unimple_rflénted function - Entry 52
This position in the entry point table does not correspond to a routine.
Instead, it is guaranteed to contain the value used in the table to represent
an unimplemented function. To determine if a particular entry point is
implemented, compare the 32-bit value in the desired entry with the
32-bit value in entry 52. If they are equal, the desired function is not
implemented.

A-11

Console Entry Points

A.42

halt_interrupt - Service hait interrupt - Entry 54
This is the entry point where tne console expects to receive control on a
halt interrupt. Halt interrupts are caused when the console hardware
detects a Control-P typed on the console terminal, or when the processors

XBE:NHALT bit is set. The R3000 is interrupted (if enabled) using
interrupt 4. Any program that establishes a general exception handler
should avoid masking this interrupt and should pass control to tkis control

entry point whenever the interrupt is received. The interrupt handler

should avoid modifying any machine state except for the kt0 generalpurpose register. If thiis is not possible, then the register contents visible
with the console examine will reflect the charges made by the interrupt
handler.

On entry to this routine, the console will save all processor registers that
can then be examined with the console e (examine) command.
The console continue command restores all saved states and returns from
this routine.
void

halt_interrupt
()

A.43

enter_maintmode - Enter mainteriance mode - Entry 96
This entry point causes control of the system to be returned to the
maintenance mode command parser, executing on the CVAX portion of
the processor. The contents of memory are not altered, but all state
internal to the R3000 processor is lost.
void

enter_maintmode()

A.44

start_m~int - Start code on the maintenance prifoessor - Entry 87
This entry point causes control of the system to be returned to code
executing on the CVAX portion of the processor. The call must include a
parameter giving the CVAX physical address at which execution should
begin. All R3000 internal processor state is lost.
void

start_maint (address)
unsigned address:;

A-12

Console Entry Points

A.45

Prom device drivers
The console standard /O entry points are layered on a set of device
drivers. The following sections describe some details of the supported
device drivers:

A.45.1

bootp - BOOTP protocol Ethernet driver
Not supported.

A.45.2

ra-MSCP disk driver
The ra driver supports MSCP disks connected via a KDB50 or via a
CIBCA-B and HSC disk controller.

Up to three KDB50 controllers can be active. A controller is active
until all the file descriptors open for it are closed. Any number of units
may be accessed, up to the open file limit.

Only one CIBCA-B controller can be active at a time. Only one unit
can be accessed.

Iseek operations must be on a 512-byte block boundary.

There are no supported ioct! operations commands.

mop - MOP protocol Ethernet driver
Not supported.

A.45.4

tms - MSCP tape driver
The tms driver supports TMSCP tapes connected via a TBK50 or TRK70
controller.

Only one TBKxx controller can be active.

[lseek is not supported. The tape iz always accessed sequentially.

The following ioct! commands are supported:
MTWEOF - Write a tape mark
MTREW - Rewind the tape

MTOFFL - Rewind the tape and unload (if unload supported by
the drive).

a-13

Congole Entry Polii)

A.45.5

ity - console terminal port
The tty driver controls the console terminal line. Only one unit, unit zero
is supported. The following ioctl commands are supported:
FIOCSCAN - Poll device for input
TIOCRAW - Disable recognition of control characters
TIOCFLUSH - Flugh all pending input
TIOCREOPEN - Reopen the device, applying the current parameters

(for example, the baud rate).

A-14

index
Bl SeM-Test LED bit- 6-38

BLO. 3-41
Bootblock booting+ 3-110
Boot Processor bit

ACLOL

See BP

See XM AC LO L signal

Boot Processor Disable bit
See BPD
Bootstrap Exception Vector bit» 4-11
Bootstrapping the operating system+ 3-106

ACOKH. 74
AC power controliers 7-2

ADG1+ 6-34
AESR. 6-23
AR 6-28

BP. 3-90

BPD- 3-90

AIR FAULT. 7-5

BTIM - 6-46

AVINTR . 6-33

BTO. 3-46

Arbitrations 2-10, 2-16

BUS ERR + 3-80, 3-81

Arbitration Supression Control bit

Bus Emor Register

Seo ARBSC

See XBER

ARBSC- 5-23
Architectures 1-4

Bus Timeout Interval bits + 3-46

BVOR- 6-47, 6-55

ARD. 3-89, 392, 6-34

BVR. 6-48
BWERR- 5-19
Byte gathering « 4-42

AREAR. 6-22
Auto Retry Disable bit

See ARD

Byte Write Error bit

Auxiliary Baud Select bits « 3-45

See BWERR

C
Bad Virtual Address Register» 4-20

C/A Fetch Failed bit

See BadVAddr
Bandwidth 2-3

See Command/Address Fetch Failed bit
Cache Address Comparators 3—-10
Cache entry
DATAP field » 4-45

Battery Low bit
See BLO
BCI AC LO bite 6-25, 6-56

PFN field 445

BCSR register- 6-37

TAGP figld » 4-45
Vield e 445
Cache Fill Error bit

BDCR1- 6-49
BESR- 6-40

BIAC LO- 6-67

See CFE
Cache Hit Status bit
See LATHIT

B1BAD bit- 6-38
B1 BAD L signal« 6-38

BIDC LO- 6-67
B! DMA Failing Address bits « 646
BIDR+ 6-45

BIIC Loopback Mode bite 6-50
B1 Interiock Read Failed bit» 643
Bl interlock Read Failed Mask bit« 6-38
Bl interrupt-Pending Status bits « 641

Cachs Memory, First-Levele 4-42 to 4-48

Cache Memory, Second-Levels 3-10 to 3-14

Cache Miss bite 4-12
Cache-resident node» 2-29

Cause Register» 4-15
Ses Cause

CBTCR- 346

index-1

indox

CC- 3-77, 3-90, 5~10, 6-17
CCA+« 3-101, 3-105, 3-113, 3-115 to 3-122
CCA$B_BAUD_RATE- 3-120

CNAK- 3-81,6-19
CNAKR. 3-89
CNTRPP. 3-31

CCASB_CHKSUM- 3-119
CCASB_FLAGS- 3-122

Column Parity Eror bit

CCASB_HFLAGS-+ 3-119

Command - 3-79, 3-80, 3-81, 3-82, 3-88

CCASB_NPROC- 3-119
CCA3B_REVISION- 3-119
CCASB_RXLEN. 3-122
CCA$B_TK50_NODE - 3-120
CCASB_TXLEN+ 3-122
- 3-122
CCA3SB_ZDEST
CCASL BASE- 3-119
CCASL_BITMAP« 3~120
CCASL_BITMAP_CKSUM+ 3-120
CCASL_BITMAP_SZ- 3-119
CCA$Q_CONSOLE- 3-119
CCASQ_ENABLED- 3-11¢

CCA$Q_HW_REVISION. 3-120
CCASQ_HW_REVISION » 3-121
CCASQ_READY. 3-119
CCASQ_RESTARTIP - 3-120
CCA$Q_SECSTART. 3-120
CCASQ_SERIALNUM- 3-120

CCA$Q_USER_HALTED+ 3-120
CCAS$T_RX+» 3122
CCAST
_TX . 3-122

CCAS$V_BOOTIP- 3-119
CCAS$V_ECACHE_CLEARABLE - 3-119
CCA$V_REPROMPT
. 3-119

CCAS$V_RXRDY. 3-122
CCASV_TERM_CRT- 3-119

CCAS$V_USE_ECACHE- 3-119
CCA$V_USE_ICACHE- 3-119

See CPER
Command/Address Fetch Failed bit- 6-41
Command cycles 2-19
Commander controller

Ses XCC
Commander ID- 3-80
Commander NO ACK Received bit

See CNAKR
Command ID- 3-79, 3-81, 3-82, 3-88

Command NO ACK bit

See CNAK
CONSEL - 3-48, 3-56
Console Not Secure bite 3-30
Console program + 3-113

Console Recsiver Control and Status Register
See RXCS
Console Rece:ver Data Bufier
See RXDB

Console Select Register

See CONSEL
Console Terminal Baud Rate Select bits

See CT BAUD SELECT
Console Transmitter Control and Status Register
See TXCS

Console Transmitter Data Bufier Register
See TXDB
Context Register 4-19

See Context

CCASV_ZALT. 3-122

Control/? Enable bit

CCASW_IDENT- 3-119

Ses CTP
Control and Status Registsr

CCASW_SERIALNUM1 » 3-120
CCASW_SIZE- 3-119

CCiD- 3-80
CC Interrupt Disable bit
Sse CCID
CDAL Bus Timeout bit

Seg BTO
CDPE
- 3-87

CFE. 3-88
CHANNEL n iNHIBIT- 7-5

CHANNEL nOK

See CH nOK,
CHnOKe 7=4
Clear Write Bufler

See CWB

index-2

See BCSR

Control and Status Registcr 1
See CSR1
Control and Status Register 2

See CSR2
Control panel
locgtione 1-8
Cooling system+ 7-5
location» 1-8, 1-9

Coprocessor Usability field» 4-11
Corrected Confirmation bit
See CC

Correcied Read Data bit
See CRD

index

CPER- 5-20
CPUD- 3-32

Dirty bit« -7
Disablo Hold bit

CRD. 3-79, 3-91,6~18

Sees DISH

CRD bit» 2-103
CRDER. 5-19
CRD Error bit
Sge CRDER
CRDID« 3-91
CRD interrupt Disable bit

DISH » 5-23

SEE CRDID
CSR1. 3-29

CSR1 Address Decode Mask Register
See CSR1ADMR
CSR1ADMR 3-70
CSR1BADR- 3-89
CSR1 Base Address Register

DLCKOUTEN» 3-35
DREVs 3-73, 5-8, 6-14, 8-562
DTPE. 3-22, 3-88
DYYPE . 3-74, 5-8, 6-14, 6-52
Duplicate Teg Perky Error bit
See DTPE
Duplicate Tag Store» 3-22
DWMBA adapter- 1-5
DWMBA registers - 6-11 o 6-53
NPo

See CSR1BADR

CSR1 EN. 345
CSR1 Enable bits
See CSHAY EN
CSR2. 3-86
CT BAUD SELECT» 3-44
CTP- 3-44
CwB. 3-21
Cycle types- 2-16 to 2-26

D
D7- 348

DCLOL
See XMl DC LO L signal

DCOK He 7-4
DEC Power Bus- 74
Delayed Lockout Enable bit
See DLCKOUTEN
Device Revision bits
Seo DREV

Device Typs bits
See DTYPE

Diag 7 Register
Ses ADG1

DIAGCK « 5-16
Diagnostic Check bits

See DIAGCK
Diagnostic Control Register 1
Sea BDCR1

Diagnostic Read/Writs bits » 645
Diagnostic Read or Write bits » £€-33

ECCDIAG - 5~14
ECC Diapnostic bit
Ses ECCDIAG
ECCDIS» 5-15
ECC Disable bit

Ses ECCDIS
ECMD - 6-24

EEADMR - 3-72
EEBADR-. 3-71
EEPROM Base Address Ragister
See EEBADR
EEPROM EN+ 345
EEPROM Enghle bits
See EEPROM EN
EEPROM Write Address bits

Ses EEWADR
EEROM Address Decode hMask Register
Ses EEADMR
EEWADR» 3-35
EiD- 6-24
EINTMR » 3-34
Engble Intarval Timer - LED D3
Ses EINTMR

Eneable IVINTR Transactions bite 6-28
Enable Protection Mode bit

Ses EPM
Enable Raad Uppar bit

Ses ERUP
Enable Self-invalidates bit
Ses ES!
Enable XBI Inierrupts bit+ 6-37
ENDADR - 5-12

index-3

Ending Address bits
See ENDADR
EPEEBUE. 3-38

EPM. 5-16
ERR. 3-61, 3-57, 3-83
ERRAD. 5-21

Faiting Command bits (cont'd.)

Ses ECMD
Ses FCMD
Failing Commander ID bits

See EID

Ses FCID

Eror Address bit

Failing Longth

See ERRAD
Eeror bit

Seo FLN tiold
FBTP. 3-33

Ses ERR

FCACHEEN. 3-32
FCle 3-32, 3-78, 3-87, 3-88

Ermor handling by KNSBA/A interface module « 3-125
to 3-130

FCiD- 3-83, 68~20

Errors

FCMD« 383, 6-20

handling = 2-44

FHIT. 3-33

First-lovel cacha+ 4~3

parity » 2-42

Flip Bt 29 bit» 6-50, 6-88

recovery¢ 2-45

Flip FADDR Address Bit 1 bite 6-49

reporting» 2~45

FLN fiold» 3-84, 6-21

gequences 2~43

FMISS » 3-22, 3-33, 3-78, 3-87, 3-88

timoout» 2-42

Force Bad Second-Leve! Tag Parity bit

Emer Summary bit
See £S
Eror Summary bits

See ERRSUM
Error Summary Register
Ses AESR

See BESR
Error Syndrome bit
See ERSYN
ERRSUM- 5~-14
EASYN. 5-20

ERUP - 3-91
ES- 3-76, 5-9, 6-16
ESls 3-22, 3-92
ETF- 3-82, 6-20
Exception Program Counier Register» 4-18
See EPC
Expander cabinet
VAXBl. 1-14
Extended Test Fail bit

See ETF

F
Failing Address field » 3-84, 6-21
Failing Address Register

See XFADR
Failing Command bits

indexn-4

Ses FBTP
Force BCI Bad Parity bit« 6-50
Force BIC Loopback Mode bit - 6-68
Force Cache Enable bit

Ses FCACHEEN
Force Cache Invalidate bit

Sea FCI
Force DMA-A Butler Busy bit» 6-35
Force DOAA-B Buifer Busy bit» 6-35
Force Octaword Transfers bit« 8-35
Force Parity bits

Ses FP
Forco Parity Salect bit
Ses FPSEL
Force Second-Level Cache Hit bit

See FHIT
Force Second-Level Cache Miss bit
Seo FUAISS
FP. 3-22
FPA ControV/Status Register« 4-35

Ses FCR31
FPA implamentation/Ravision Register- 4-37
Ses FCRO

FPBD- 3-36
FPSEL - 3-32, 3-92
Framing Eror bit
Ses FRM ERR
FRM ERR. 3-82
Front Pangl Boot Disable bit

Sea FPBD

index

Front Pane! EEROM Update Enable bit
See EPEEUE

G
GAREV- 3-93

Gate Array Revision bits
See GAREV
GEN BAD (BUS RCV PAR bit- 6-36
GEN BAD 1BUS XMIT PAR bit» 6-36

identity transactions (cont'd.)

Sea IDENT
IE~ 3-58, 3-84
FIFOFL. 3-31
FLG. 5-26
FLGn+ 5-25

HDAL Bus Timeout Control Register
See CBTCR
IDAL Interchip Inmerconnect controller

See IC
DB+ 5-26
tiegal CPU Coinmand bits 8-42

Global bite 4-8

implied Vector interrupt Destination/Diagnostic
Register

implied Vector Interrupt transaction

Seo AIVINTR

H405 AC power controller» 7-2

H7205 power and logic unit

See PAL
HALT PROT Space+ 3-43
HIERR - 5-19
High Error Rate bit

See HIERR

See IVINTR
Inconeistent Parity Error bit

See IPE
inconsistent Parity errors « 2-42
Index fiekd » 4-9

inhibit CRD Status bit
See ICRD
initiglization» 2-38 to . -40, 3-84 to 3-105, 6-67
to 6-68
INT« 3-57, 3-83
INT3 interrupts 3-125
im Enable Current bit+ 4-14

int Enable Old bit+ 4-13
/O bulkhead space

locatione 1-9
/0 nodas+ 1-5
{0 space 2-13
/O space restrictions » 2-8
/O System Resst Register

See IORESET
10 Write Failure bit- 6-25

1O Write Failure During CPU Write Transaction bit

See VO Write Failure bit
{ADR« 5-26
iBUS CPU DATA Parity Error bite §-27
{5US DMA-A C/A Parity Error bit« 6-26
IBUS DMA-A Data Parity Eror bit» 6-26
1BUS DMA-B C/A Parity Error bit+ 6-26
IBUS Parity Error interrupt Mask bit- 6~39
{C- 3-20

{CRD. 5-15
IDENT. 2-30
{DENT Error bit» 6~-43
ideniify transactions

int Enable Previous bit- 4-13
interchip Interconnect controlier
See IC
interface togic
Seo XL
Iinterloave Address bits

Ses INTLVADR
Interleave Mode bits

See INTLM
interleaving

5-5, 5-13

Interlock Address bit

Ses IADR
interlock Address Register (NTADR)« 4-50
interlock Flag bit

See IFLG
interiock Flag Ragister

Ses IFLGn
interlock 1D bit
Ses IDB
INTERLOCK n+ 7-5
interlock Read transactions - 2-28

index-5

index

imerlock Ragister (INTREG). 4-50
interprocaasor communication e 3-113 to 3-124
interprocessor intarrupt

Seo P
imterrupt bit

See WY
interrupt Destination bite « 645

interrupt Destination Register
See BIDR

See FIFOFL

invalidate Queve

See IQ
INVAL Queus Overtiow bit

Sse QO
INVINTR - 2-42
Write emors 2-45
P

3-24, 3-25

IPE « 3-22, 3-78, 6-17
IPINTREN- 6-57

interrupt Enable bit

Ses i€
interrupt Level One bit

See INTR1
interrupt RMask fielde 4-13
interrupt Mask Register
See ABMR
interrupts » 6-7

interprocessor

invalidate FFO Full bit (cont'd.)

2-31

Types+ 2-9, 6~56

VAXBI-generated » 8-10, §-57
Vactors » §-54

PL Leve! Select bits

Ses #PL LVL SEL
PL LVL SEL. 3-42
e 3-20

00- 3-22, 3-87
IREAD - 2-28
isolate Cache bite 4-12
iv. 3-82, 3-88

VO« 3-42

IVINTR - 2-31
WINTR Destination bits+ 8~33

Write Errore 2-31, 2-45
interrupt Sent Status bits » 640
interrupt transaction

See INTR
interrupt Vector bits

See IV
interrupt Vector Disable bit

See VD
interval Timer bit

See INTMR
INTLM- 5-13
INTLVADR - 5-13
INTMR - 3-30

iINTR. 2-30

INTR1- 3-30

INTR INTR
on Command NO ACK bite 6-31
INTR INTR on No Read Responss bit+ 6-30
INTR INTR on Resd Ewor Response bt 6-31
INTR INTR on Read Sequence Emer bite 8-30
INTR on Corrected Confirmation bite 6-29

K
KemAJser Mode Current bits 4-14

Kern/User Mode Old bit+ 4-13
Kerm/Ugar Mode Previous bt 4-13
KNS8A/A interiace module featurss « 3-2

KNSBA/A inmterface module registers « 3-27

KNSBA/A Seli-Test Passed - LED D4
See EINTMR
KNS8A/A Timeout Enable - LED D5
See TWAOTE
KNSSA/B CPU module festuras « 4-2
KNSBA/B CPU module registers » 44
KNSBA/R Timeout bit
See THAOT
KNS8A processor

Seo also Processor

INTR on Comrected Read Data bit» 6-20
INTR on BUS CPU DATA PE bit» 6-32

INTR on (BUS DMA-A C/A PE bit» 6-32
INTR on IBUS DMA-B C/A PE bit 6-32

INTR on Parity Ervor bit- 6-29
INTR on Read/IDENT NO ACK bit+ 6-30
INTR on Write Data NO ACK bit» 6-30
INTR on Write Sequence Error bite 6-29

Invalidate FIFO Full bit

Indaxu-6

L
LATHIT- 3-30
LED D1+ 3-31
LED D2+ 3-34
LED D3- 3-34
LED D4~ 3-34

LED D5~ 3-34
LED DS

LESI- 6-55
LiiD. 5-26

NHALT» 3-76, 6-16

Lockout bits- 3-89
Lock Quaue Error bit

NID+ 3-36

Node HALT bit
Seo NHALT

See LOERR
Lock Transactions« 4-50
Low-End Storage interconnect

Node D bits

See NID

See LESI
Lower Inferlock ID bits

Node Reset bit
See NRST

See LID

Nodespace- 2-14

LQERR- 5-16

Node-Spasitic Error Summary bit

Ses NSES
Non-cachable bit« 4-7

Nonexistent memory locations
See NXM
No Read Response bit

MAINT« 3-54

Ses NRR

Maintenance bit

See MAINT
PMaster Sequencer Transaction Failed bit« 6—42
MCTL1 . 5-14
MCTL2. 5-22
MECEA. 5-21

NRR. 3-80, 6-18
NAST. 2-38 to 2-40, 3-76, 5-9, 6-16, 6-67
NRST bit- 3-94
NSES. 3-82, 5-11,6-19

NXi. 2-45

MECER- 5-18
bMemory

See MS62A memory
Memory contiguration= 3-101
tMemory Control Register 1

ONCMDL. 74

See MCTL1

ON SENSE L+ 7-4

Memory Control Register 2

Opsrating system bootstrapping or restarting » 3-106

See MCTL2

Overrun Error bit

iMemory ECC Error Address Register

Ses OVR ERR
OVER TEMPERATURE n+ 74

See MECEA
Memory ECC Error Register

Overtemperature switch, H7215

See MECER

7-3

OYR ERR- 3-51

temory interisave« 3-102
Memory Registers

5-8 to 5-26

Memory Size bits
See MEMSIZ
Memory Valid bit

Page Frame Number field« 4-7

See MVAL
MEMSIZ- 5-15

PAL. 7-2
Parity Error bite 4-12

AIS62A memory module- 1-5

See PE

dMuttiple CPU Emors bit+ 6-41
.

—_

;wfl}ERs-:m

e e BB
B o

INTR on Write Sequence Error bite 6-29
invalidate FIFO Full bit

Indaxu-6

Parity Zeio bits 4-12
Patity errors » 2-42

o W - Wy

LED D3- 3-34

LEDD4- 3-34

PB REO Le 7'4

indox

PNL RESETL. 74
Power reguletors

location s 1-8, 1-9
Power sequencer

See XTC
Power system- 1-17 o 1-18

Primary system bootstrap program

Sae VB
Probe failure bit° 4-9
Process D figld« 4~
Processore 1-5
registers« 3-27
*bAl interace» 3-3
Procsss Revision identdier Registers 4-21

See PRI

Receiver Done bit (cont'd.)
See RX DONE

Recaeiver interrupt Enable bit

Seo RX IE
Refresh Emor bit
See RERR
Refresh Ratoe bits
See RRB
Registers

processors 3-27
Rogi;t_ogr:. KNSSA/A interface module+ 3-28 to

Registers, KNS8AB CPU module 4-5 to 4-21,
4-34

Registers, VAXBI
Device Register- 6-52
Registers, XMl

Device Ragister
Bus Error Register« 3-75, 59, 6-15
Dovice Register« 3-73, 6-14
R3000 Enable bit+ 3-31
R3000 Status Registers 4~15

See Status
RAMTYP - 5-15

RAM Type bits
See RAMTYP

Random figld . 4~10
RBUF . 3-52
ACV BRK » 3-52

RDNAK - 5-10

RDS erors« 3-103
READ. 2-27
Read/IDENT Data NO ACK bit

Seo RIDNAK
Read/Mirite CNTRL P Pending bit
Sao CNTRPP
Read Data ND ACK bit

Seo RDNAK
Read Eror Response bit
See RER
Read Queus

Seo RQ
Read Sequence Error bit

See RSE
Read transactions « 2-27, 2-32 t0 2-36
Recaived Break bit
See RCV BRK
Received Data bits

Seoe RBUF
Receiver Done bit

indox-8

RER- 3-81, 6-19, 6-58

RERER-. 5-18
RERR. 5-22
Reserved Register= 6-51

Reset Invalidate FIFOs - LED D2
Seo RINVAL

Responder controlier
Ses XRC
Responder Emor Address Register
See AREAR

Respondaer Failing Address bits « 6-22

Responder Failing Langth bits

Se¢o RFLN
Respones timeouts» 2 42

Restarting the operating system « 3-108
Restan parameter block

See RPB
Retry timgouls « 2-42
Revision Level bits
See REV LEVEL
REV LEVEL- 3-37
RFLN. 8-22
RIDNAK « 3-79, 6-18
RINVAL+ 3-34

ROM Address Space Size Seloct bits

Seo ROM SIZE SEL
ROM Malt Protect Address Space Size Select bits
Ses HALT PROT Space
ROM SEZE SEL- 3-42
ROM Speed bit

index

ROM Speed bit (cont'd.)

Soe RSP
Row Parity Error bit

Seo RPER
RPB- 3-105
RPER. 5~19

RQ-. 3-20
KRB+ 5-23
RSE- 3-80, 6-18

RSP. 342
RUN- 3-59, 3-65
Run bit
See RUN
RXCS. 350
RXDB. 3-51
RX DONE - 3-50
RX IE- 3-50

SSC Baso Address bits
Ses SSCBA
SSCBR- 3-39
SSC Configuration Register

Ses SSCCR
SSCCR« 3-41
STANDBY CMD L« 7-4
Starting Address bits
Ses STRADR
Stanting and Ending Address Registar

See SEADR
Status LED D7 bit
Ses D7
STF- 2-38 to 2-40, 3-83, 5-11, 6-20
STL- 3-36
Stop bit

See STP
STP. 3-58, 3-64

STPLED- 3-35

STRADR: 5-13

Safety Exira Low Voltage circuit

SYNC. 7-5

Seo SELV circuit
SAO- 6-55

SCB- 6-55

SCPE. 3-87
SEADR-. 5-12
Second-Level Cache Parity Errors
See SCPE
Second-Level Cache Parity Update Disable bit

See CPUD
Sell-Tast Fail bit
See STF
Seli-Test Loop bit

Swap Caches bit 4-12
System

architecture» 14
front views -8
rear view+ 1-9

System support chip

See SSC.
System Type bits

See SYS TYPE

System Type Register

Ses SYSTYPE
SYS TYPE (bits)s 3-37

SYSTYPE (register)

3-37

See STL

Seli-Test Pass LED bit
See STPLED
SELV cireuit. 74
Sequence errors « 2-43
SGL+ 3-58, 3-64
Single bit
See SGL
Slave Sequencer Transaction Failed bt 6-42

SLED?

See D7
8SSC- 33

SSCBA. 3-39
SSC Base Addres Register

See SSCBR

TBUF « 3-55
TCRO. 3-57, 3-63
TCR1. 3-57, 3-63
TCY. 5-24

TCY Tester Register

See TCY
Temperature sensor, cabinete 7-2
Time of Year Clock

See TODR
Timeout Address Register
See BTIM

Index-9

indox

Transmit Breek bit (cont'd.)

Timeouls

See XMIT BRK

Response » 2-42

Transmit Data bits

Retry - 2-42

See TBUF

Timeout Selact bit

Tranemitier interrupt Engble bit

See TOS
Timer Control Registers

See TCRD and TCR1
Timer imerrupt Vactor Registers
See TIVRO and TIVR1
Timer Interval Repisters

Seo T IE
Transmitter Roady bit

Seo TX RDY
110+ 3-82, 3-125, 6-19
TXCS» 3-53
TXDB+ 3-55

See TIRO and TIRY
Timer Next Interval Registers

TXIEs 3-53

TX RDY- 3-53

Seo TNIRO and TNIR1
TIMOT» 3-30

TiRO- 3-60

TIR1« 3-66

TIVRD - 3-62
T

UINTRCSR » 6-57

TK70 tape drive
location

Uncorrectable Double-Bit (RER) Error

1-8

TLB EntryHi Register

See RERER

4-6

UNIBUS - 6-55

Sees EntryHi

Unilock Sequence Error bit

TLB EntryLo Register+ 4-7

See UNSEQ

See Enmrylo

Uniock Write Pending bit

TLB indax Register 4-9

See UWP

See index

TL8 Random Register

4-10

Ses Random

Uniock Write transaction 2-30

UNSEQ- 5-16
UWMASK « 2-30

TLB Shutdown bite 4-12

UWP. 3-89

TNIRO- 3-89
TNIR1. 3-67

TODR. 3-47
TOS. 3-91

TOYe 7-3

Valid bits 4-8

TPE» 3-22, 3-87

VAXBI card cage

Transaction errors « 2-42

Transactions » 2-27 to 2-37
identity- 2-30

Implied VYector interrupt

2-31, 2~42

locations 1-8, 1-9
VAXBI Device Register

See DTYPE

interiock Read - 2-28

VAXBI expander cebinets 1-14

interupte 2-30

Vector Offset Register

Read - 2-27,2-32 to 2-36
Unlock Write = 2-30
Write Mask » 2-29

Writes» 2-37

Transaction Timeout bit

See TTO
Tranafer bit

See XFR

Transmit Break bit

inden-10

See EVOR
Vector Offsei Register bits

See VOR
Vector Register
See BVR

Virtual Page Number field+ 4-6
VOR- 647
VPE- 3-22, 3-87

index

W
WB- 3-20, 3-21

WBD- 3-92
WODNAK. 3-79, 6-18
WDPE . 3-87
WE - 3-25
WEl+ 3-77, 6-17
WMASK» 2-29
Write bufferz« 4-3
Write Data %O ACK bit

Seo WDONAK
Write Data Parity Error bit
See WDPE
Write Error interrupt» 2-45
Write Error Interrupt

See WE
Write Error Intarrupt bit
See WEI
Write Error INVINTR» 2-45

XFADR-» 3-7%, 2-§%, 3-81, s-82, 3-88
XFALR register» 3-84, §-21
XFAULT. 3-77, €~17
XFR. 3-58, 3-64

XGPRe« 3-85
XL« 3-20
XMI AC LO bit

See XACLO
XMIACLO Le 2-36 t0 2-40, 657
XMIAC LO L sigr.als 394
XMi BAD nit
Ses XBAD
XMIBAD L= 2-38 to 2-40
XMi BAD L signal« 6-38
XM card cage

{ocatione 1-8, 1-9
XMI CMD REQ L+ 2-10, 2-17
XMI CND- 242

XMI Cornere 2-4
XMI D 242
XMIDCCL L. 6-67

Write Mask transactions = 2-29

XMIDCLO L. 2-38 to 2-40
XMi DC LO L signale 304

Write Sequence Error bit

XMIF. 2-42

See WSE
Write transactions « 2-37

WSE+ 3-78, 5-10, 6~17

XMI FAULT bit

See XFAULT
XM General Purpose Register
Ses XGPR

X
XACLO+ 3-36

XBAD- 3-76, 6-16
XOER- 3-75, 5-9, 6-15
XBIA internal Error bits 6-25
XBIB-Detected IBUS Parity Error bit+ 6-44

XBI Cabis OK bit- 6-23
XBI Interrupt-Pending Status bite 6-41
X8I Vector bits» 6-48

uCC+ 3-20
XCGPA Write Bufier
See WB
XCIACLO
L+ 2-38 to 2-40
XCIDCLOL- 2-38 to 240
XCPGA Chip+ 3-19
XCPGA Write Butfer

See WB

XMI GRANT L« 2-10, 2-17
XMIHOLD L 2-17
XMI D+ 2-42
XMl inftialization» 2-38 to ~-40
XM interface » 3-3
XMi interrupts = 3-23 to 3-25

XMI NODE 1ID<3:.0>+ 2-17
XMIPa 2-42

XMIRESET L= 2-38 to 2-40
XMI RESET L signale 3-84
XM Reset Timing Control Logics 7-3
XMI RES RE. L- 2-10, 2-17
XMISTFL- 667
XMISUP L. 2-17
XMIT BRK« 3-54
XMi-to-VAXB! adapter 1-5
See also DWMBA adapter
XRC. 3-20
XTC power sequencers 1-9, 2-39, 3-94, 7-3

XCPGA Write Butfer Disable bit
Ses WBD
XDEV. 3-73, 5-8, 6~14

Index-11