Digital PDFs

EK-KA680-TM-001

December 1991

560 pages

Original

1.7MB

Document:	KA680 CPU Module Technical Manual
Order Number:	EK-KA680-TM
Revision:	001
Pages:	560
Original Filename:

OCR Text

KA680 CPU Module
Technical Manual
Order Number: EK-KA680-TM-001

First Edition, December 1991
The information in this document is subject to change without notice and should not be construed
as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no
responsibility for any errors that may appear in this document.
The software described in this document is furnished under a license and may be used or copied
only in accordance with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment that is not supplied
by Digital Equipment Corporation or its affiliated companies.
© Digital Equipment Corporation 1991.
All Rights Reserved.
The postpaid Reader’s Comments forms at the end of this document request your critical evaluation
to assist in preparing future documentation.
The following are trademarks of Digital Equipment Corporation: DEC, DECnet, DEQNA, DSSI,
LPV11–SA, MicroVAX, PDP, Q–bus, Q22–bus, RRD50, RSTS, ThinWire, ULTRIX, UNIBUS, VAX,
VAXELN, VAXstation, VMS, VT, and the Digital logo.

This document was prepared using VAX DOCUMENT, Version 2.0.

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xxiii

1 Overview
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
KA680 CPU Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
The Central Processing Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1.1
The NVAX Central Processing Unit (DC246) . . . . . . . . . . . . . . . . .
1.2.1.2
The Cache Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
The System Support Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.1
The System Support Chip [SSC (DC511)] . . . . . . . . . . . . . . . . . . .
1.2.2.2
The Firmware ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.3
The Boot and Diagnostic Register . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.4
The Station Address ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3
The I/O Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3.1
NVAX CP-bus Bus Adapter [NCA (DC243)] . . . . . . . . . . . . . . . . . .
1.2.3.1.1
DSSI Mass Storage Interface [SHAC (DC542)] . . . . . . . . . . . .
1.2.3.1.2
Ethernet Interface [SGEC (DC541)] . . . . . . . . . . . . . . . . . . . . .
1.2.3.1.3
Q22–bus Interface [CQBIC (DC527)] . . . . . . . . . . . . . . . . . . . .
1.2.4
The Memory Control Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.1
NVAX Memory Controller [NMC (DC244)] . . . . . . . . . . . . . . . . . . .
1.3
MS690 Memory Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
H3604 Console Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1–1
1–2
1–4
1–4
1–5
1–5
1–5
1–6
1–6
1–6
1–6
1–6
1–7
1–7
1–7
1–7
1–8
1–8
1–8

2 Installation and Configuration
2.1
Installing the KA680 and MS690 Memory Modules . . . . . . . . . . . . . . . . . .
2.2
Module Configuration and Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Mass Storage Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1
Changing the Node Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
Changing the DSSI Unit Number . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
Accessing RF-series Firmware in VMS Through DUP . . . . . . . . . . . . .
2.3.3.1
Allocation Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
DSSI Cabling, Device Identity, and Bus Termination . . . . . . . . . . . . . . . . .
2.5
KA680 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2–1
2–2
2–3
2–4
2–5
2–6
2–6
2–7
2–7

3 Central Processor
3.1
3.1.1
3.1.2
3.1.3
3.2
3.3

Processor State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General-Purpose Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processor Status Longword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Processor Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3–1
3–1
3–2
3–3
3–23
3–23

iii

3.4
Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5
Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1
Translation Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2
30-bit to 32-bit Physical Address Translations . . . . . . . . . . . . . . . . . . .
3.5.3
Memory Management Control Registers . . . . . . . . . . . . . . . . . . . . . . .
3.6
Interrupts and Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1.1
Power Fail Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1.2
Hard Error Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1.3
Soft Error Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7
Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1
Arithmetic Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.2
Memory Management Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3
Emulated Instruction Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.4
Vector Unit Disabled Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.5
Machine Check Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.6
Console Halts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.7
Kernel Stack Not Valid Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8
System Control Block (SCB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9
System Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1
System Identification Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2
System Identification Extension (SIE) Register (20040004) . . . . . . . .
3.10
CPU References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.1
Instruction-Stream Read References . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.2
Ownership Read References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.3
Disown Write References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.4
Data-Stream Read References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.5
Write References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11
NVAX Data/Address Lines (NDAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.1
NDAL Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.1.1
Reads and Fills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.1.1.1
D-stream Read Requests (DREAD) . . . . . . . . . . . . . . . . . . . . .
3.11.1.1.2
I-stream Read Requests (IREAD) . . . . . . . . . . . . . . . . . . . . . . .
3.11.1.1.3
Ownership Read Requests (OREAD) . . . . . . . . . . . . . . . . . . . .
3.11.1.1.4
Read Data Return Cycles (RDR0, RDR1, RDR2, RDR3) . . . . .
3.11.1.1.5
Read Data Error Cycles (RDE) . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.1.2
Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.1.2.1
Normal Write Transactions (WRITE) . . . . . . . . . . . . . . . . . . . .
3.11.1.2.2
Disown Write Transactions (WDISOWN) . . . . . . . . . . . . . . . . .
3.11.1.2.3
Write Data and Bad Write Data (WDATA,BADWDATA) . . . . .
3.11.2
Cache Coherency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.3
VAX Architecturally-defined Interlocks . . . . . . . . . . . . . . . . . . . . . . . .
3.11.3.1
Ownership and Interlock Transactions . . . . . . . . . . . . . . . . . . . . . .
3.11.4
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.4.1
Transaction Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.4.2
Nonexistent Memory and I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3–23
3–24
3–24
3–26
3–28
3–29
3–29
3–33
3–34
3–34
3–34
3–35
3–36
3–37
3–39
3–39
3–40
3–41
3–41
3–44
3–44
3–45
3–46
3–46
3–47
3–48
3–48
3–48
3–48
3–48
3–51
3–51
3–51
3–51
3–52
3–52
3–52
3–52
3–53
3–53
3–53
3–55
3–55
3–55
3–55
3–55

4 KA680 Cache Memory Overview
4.1
Cacheable References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Virtual Instruction Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1
Virtual Instruction Cache Organization . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2
Virtual Instruction Cache Internal Processor Registers . . . . . . . . . . . .
4.2.2.1
VIC Virtual Memory Address Register (VMAR) - IPR 208 . . . . . . .
4.2.2.2
VIC TAG Register (VTAG) - IPR 209 . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.3
VIC Data Register (VDATA) - IPR 210 . . . . . . . . . . . . . . . . . . . . . .
4.2.2.4
VIC Control and Status Register (ICSR) - IPR 211 . . . . . . . . . . . .
4.3
Primary Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1
Primary Cache Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2
Pcache Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3
Pcache Hit/Miss Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3.1
Hit/Miss Determination by Tag Comparison . . . . . . . . . . . . . . . . .
4.3.3.2
Conditions That Force Pcache Miss . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3.3
Conditions That Force Pcache Hit . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4
Pcache Behavior on Write Operations . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.5
Pcache Replacement Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6
Pcache Fill Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.7
Pcache Invalidate Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.8
Pcache IPR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.8.1
PCADR - IPR 240 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.8.2
PCSTS - IPR 241 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.8.3
PCCTL - IPR 242 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.8.4
PCTAG - IPRs 0180000016 to 01801FE016 . . . . . . . . . . . . . . . . . . .
4.3.8.5
PCDAP - IPR 01C0000016 to 01C01FF816 . . . . . . . . . . . . . . . . . . .
4.3.9
Pcache IPR Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Backup Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1
Write-back Cache and Ownership Concepts . . . . . . . . . . . . . . . . . . . . .
4.4.2
Backup Cache Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3
Backup Cache Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.4
NVAX Backup Cache Organization and Interface . . . . . . . . . . . . . . . .
4.4.5
Backup Cache Block Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.6
Backup Cache Data Block Allocation . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.6.1
Read References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.6.2
Write References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.7
Effects of I/O Traffic on the Backup Cache . . . . . . . . . . . . . . . . . . . . . .
4.4.8
Backup Cache Internal Processor Registers . . . . . . . . . . . . . . . . . . . . .
4.4.8.1
Bcache Control IPR (CCTL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.8.2
Backup Cache Data ECC IPR (BCDECC) . . . . . . . . . . . . . . . . . . .
4.4.8.3
Backup Cache Tag Store Error Registers (BCETSTS, BCETIDX,
BCETAG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.8.3.1
Bcache Error Tag Status (BCETSTS) . . . . . . . . . . . . . . . . . . . .
4.4.8.3.2
Bcache Error Tag Index (BCETIDX) . . . . . . . . . . . . . . . . . . . .
4.4.8.3.3
Bcache Error Tag (BCETAG) . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.8.4
Backup Cache Data RAM Error Registers (BCEDSTS, BCEDIDX,
BCEDECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.8.5
Bcache Error Data Status (BCEDSTS) . . . . . . . . . . . . . . . . . . . . .
4.4.8.5.1
Bcache Error Data Index (BCEDIDX) . . . . . . . . . . . . . . . . . . .
4.4.8.6
Bcache Error Data ECC (BCEDECC) . . . . . . . . . . . . . . . . . . . . . . .
4.4.9
Fill Error Registers (CEFADR, CEFSTS) . . . . . . . . . . . . . . . . . . . . . . .
4.4.9.1
Bcache Error Fill Status (CEFSTS) . . . . . . . . . . . . . . . . . . . . . . . .
4.4.9.2
Fill Error Address (CEFADR) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4–2
4–2
4–3
4–4
4–4
4–5
4–6
4–7
4–8
4–8
4–9
4–12
4–12
4–12
4–13
4–13
4–13
4–14
4–14
4–15
4–15
4–15
4–16
4–16
4–17
4–18
4–18
4–19
4–19
4–20
4–21
4–22
4–23
4–23
4–23
4–23
4–24
4–28
4–32
4–33
4–33
4–35
4–36
4–38
4–38
4–40
4–41
4–41
4–42
4–45

4.4.10
4.4.10.1
4.4.10.2
4.4.10.3
4.4.10.4
4.4.10.5
4.4.11
4.4.12
4.4.13
4.4.13.1
4.4.13.2
4.4.13.3
4.4.14
4.4.15
4.4.16
4.4.16.1

NDAL Error Registers (NESTS, NEOADR, NEOCMD, NEDATHI,
NEDATLO, NEICMD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NDAL Error Status IPR (NESTS) . . . . . . . . . . . . . . . . . . . . . . . . .
NDAL Error Output Address IPR (NEOADR) . . . . . . . . . . . . . . . .
NDAL Error Output Command (NEOCMD) . . . . . . . . . . . . . . . . . .
NDAL Error Input Command (NEICMD) . . . . . . . . . . . . . . . . . . .
NDAL Error Data High and NDAL Error Data Low (NEDATHI
and NEDATLO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache Tag Store Access Through IPR Reads and Writes
(BCTAG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache Deallocates Through IPR Access (BCFLUSH) . . . . . . . .
Bcache Abnormal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NVAX Behavior When the Backup Cache is OFF . . . . . . . . . . . . . .
NVAX Behavior When the Backup Cache is in FORCE_HIT
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NVAX Behavior When the Backup Cache is in Error Transition
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to Turn the Bcache Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to Turn the Bcache On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache Errors Incurred While in Error Transition
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4–46
4–46
4–49
4–49
4–50
4–50
4–51
4–52
4–53
4–53
4–55
4–55
4–57
4–58
4–58
4–61

5 KA680 Main Memory System
5.1
Overview of the NVAX Memory Subsystem Support Functions . . . . . . . . .
5.1.1
The NMC Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2
The GMX Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2
Overview of NMC-supported NDAL Transactions . . . . . . . . . . . . . . . . . . .
5.3
Overview of NMI Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4
NMC Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1
NDAL Bus Interface Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1.1
The Non-Writeback Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1.2
The Write-back Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1.3
The OUT_QUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2
Memory Interface Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2.1
Data Memory Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2.2
Memory Set Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2.3
Memory Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2.4
Ownership Bit Memory Organization and Addressing . . . . . . . . . .
5.4.3
NMI Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3.1
Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3.2
Signature Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3.3
Read/Write Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3.4
Nonexistent Memory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.4
Error Checking for Data Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.5
Error Checking for Ownership Bit Memory . . . . . . . . . . . . . . . . . . . . .
5.4.6
Memory Diagnostic Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.6.1
Fast Diagnostic Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.6.2
Diagnostic Check Bit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5–1
5–1
5–2
5–2
5–2
5–2
5–3
5–3
5–5
5–5
5–5
5–6
5–6
5–7
5–8
5–10
5–10
5–10
5–10
5–11
5–11
5–12
5–12
5–13
5–13

Ownership Bit Memory Diagnostic Support . . . . . . . . . . . . . . . . . . . . .
Reconstruction Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Test Mode with ECC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fast Memory Test Mode with ECC . . . . . . . . . . . . . . . . . . . . . . . .
Memory Test Mode with Forced Check Bits . . . . . . . . . . . . . . . . . .
Fast Memory Test Mode with Forced Check Bits . . . . . . . . . . . . . .
I/O Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Configuration Registers (MEMCON0 MEMCON7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.8.1.2
Memory Signature Registers (MEMSIG0 - MEMSIG7) . . . . . .
5.4.8.1.3
Error Address Information Register (MEAR) . . . . . . . . . . . . . .
5.4.8.1.4
Error Status Register (MESR) . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.8.1.5
Mode Control and Diagnostic Status Register (MMCDSR) . . . .
5.4.8.1.6
O-bit Address and Mode Register (MOAMR) . . . . . . . . . . . . . .
5.4.8.1.7
O-bit Data Registers (MODRs) . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.8.1.8
Clear Write Buffer Register (NMC_CSR20) . . . . . . . . . . . . . . .
5.4.9
NMC Transaction Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.9.1
NMC Internal Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.9.2
Transaction Handler Datapath . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.10
NMC Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.10.1
Ownership Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.10.2
Memory Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.10.3
Memory Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.10.4
Disown Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.11
I/O Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.12
NMC Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.13
NDAL Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5
NMC Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1
Internal Register States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.2
Counter States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6
Memory Subsystem Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1
64-bit Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.2
GMX Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4.7
5.4.7.1
5.4.7.2
5.4.7.3
5.4.7.4
5.4.7.5
5.4.8
5.4.8.1
5.4.8.1.1

5–13
5–14
5–14
5–14
5–14
5–14
5–14
5–15
5–15
5–17
5–17
5–18
5–21
5–25
5–26
5–28
5–28
5–29
5–30
5–30
5–30
5–30
5–30
5–31
5–31
5–31
5–34
5–35
5–35
5–35
5–35
5–35
5–36

6 KA680 I/O Subsystem
6.1
NCA Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
I/O System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3
NCA Chip Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1
NCA Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2
NDAL Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2.1
NDAL Slave Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2.2
NDAL Master Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3
CP1 and CP2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3.1
CP Master Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3.2
MT and NRA Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3.3
CP Slave Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4
Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4.1
Control and Status Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4.2
Error Status Register (CESR) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4.3
Mode Control and Diagnostic Register (CMCDSR) . . . . . . . . . . . . .
6.3.4.4
CP1 Slave Error Address Register (CSEAR1) . . . . . . . . . . . . . . . .
6.3.4.5
CP2 Slave Error Address Register (CSEAR2) . . . . . . . . . . . . . . . .

6–1
6–1
6–2
6–4
6–4
6–4
6–5
6–6
6–6
6–7
6–7
6–8
6–9
6–9
6–14
6–16
6–17

vii

6.3.4.6
CP1 IO Error Address Register (CIOEAR1) . . . . . . . . . . . . . . . . . .
6.3.4.7
CP2 IO Error Address Register (CIOEAR2) . . . . . . . . . . . . . . . . . .
6.3.4.8
NDAL Error Address Register (CNEAR) . . . . . . . . . . . . . . . . . . . .
6.4
Interval Clock Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1
Interval Clock Control and Status Register (ICCS) . . . . . . . . . . . . . . .
6.4.2
Next Interval Count Register (NICR) . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.3
Interval Count Register (ICR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5
NCA Transaction Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1
IO Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.2
IO Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3
Interrupt Vector Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.4
Register Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.5
Register Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.6
CP1 DMA Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.7
CP1 DMA Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.8
CP2 DMA Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.9
CP2 DMA Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6
NCA Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6–18
6–19
6–19
6–20
6–20
6–21
6–21
6–21
6–22
6–22
6–24
6–25
6–25
6–26
6–27
6–27
6–29
6–30

7 The Console Line, TOY Clock
7.1
KA680 Console Serial Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1
Console Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1.1
Console Receiver Control/Status Register (IPR 32) . . . . . . . . . . . .
7.1.1.2
Console Receiver Data Buffer (IPR 33) . . . . . . . . . . . . . . . . . . . . .
7.1.1.3
Console Transmitter Control/Status Register (IPR 34) . . . . . . . . . .
7.1.1.4
Console Transmitter Data Buffer (IPR 35) . . . . . . . . . . . . . . . . . . .
7.1.2
Break Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.3
Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.4
Console Interrupt Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
KA680 TOY Clock and Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1
Time-of-Year Clock (TODR) - EPR 27 . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2
Programmable Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2.1
Timer Control Registers (TCR0 and TCR1) . . . . . . . . . . . . . . . . . .
7.2.2.2
Timer Interval Registers (TIR0 and TIR1) . . . . . . . . . . . . . . . . . . .
7.2.2.3
Timer Next Interval Registers (TNIR0 and TNIR1) . . . . . . . . . . . .
7.2.2.4
Timer Interrupt Vector Registers (TIVR0 and TIVR1) . . . . . . . . . .

7–1
7–1
7–1
7–2
7–4
7–5
7–6
7–6
7–7
7–7
7–7
7–8
7–8
7–9
7–10
7–10

8 KA680 Boot and Diagnostic Facility
8.1
Boot and Diagnostic Register (BDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2
Diagnostic LED Register (DLEDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3
EPROM Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1
EPROM Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2
KA680 Resident Firmware Operation . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2.1
Power-Up Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4
Battery Backed-up RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5
KA680 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.1
Power-up Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2
Hardware Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3
I/O Bus Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3.1
I/O Bus Reset Register (IPR 55) . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.4
Processor Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.4.1
Configuring the Local I/O Page . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

8–1
8–4
8–5
8–5
8–6
8–6
8–6
8–6
8–7
8–7
8–7
8–7
8–7
8–7

8.5.5
8.5.6
8.5.7
8.5.8

SSC Base Address Register (SSCBR) . . . . . . . . . . . . . . . . . . . . . . . . . .
BDR Address Decode Match Register (BDMTR) . . . . . . . . . . . . . . . . .
BDR Address Decode Mask Register (BDMKR) . . . . . . . . . . . . . . . . . .
SSC Configuration Register (SSCCR) . . . . . . . . . . . . . . . . . . . . . . . . . .

8–8
8–8
8–9
8–9

9 KA680 Q22–bus Interface
9.1
9.1.1
9.1.2
9.1.3
9.2
9.3
9.3.1
9.3.2
9.4
9.5
9.5.1
9.6
9.7
9.7.1
9.7.2
9.7.3
9.8

Q22–bus to Main Memory Address Translation . . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Registers (QMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing the Q22–bus Map Registers . . . . . . . . . . . . . . . . . . . . . . . . .
The Q22–bus Map Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP to Q22–bus Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interprocessor Communications Facility . . . . . . . . . . . . . . . . . . . . . . . . . .
Interprocessor Communication Register (IPCR) . . . . . . . . . . . . . . . . . .
Interprocessor Doorbell Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Interrupt Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Q22–bus Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Base Address Register (QBMBR) . . . . . . . . . . . . . . . . .
System Configuration Register (SCR) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Reporting Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DMA System Error Register (DSER) . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Error Address Register (QBEAR) . . . . . . . . . . . . . . . . . . . . .
DMA Error Address Register (DEAR) . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Interface Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9–2
9–3
9–5
9–6
9–7
9–8
9–8
9–9
9–10
9–10
9–10
9–11
9–12
9–12
9–14
9–15
9–16

Network Interface
10.1
Ethernet Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2
NI Station Address ROM (NISA ROM) . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3
Programming the SGEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.1
Command and Status Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2
Host Access to NICSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2.1
Physical NICSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2.2
Virtual NICSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2.2.1
NICSR Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2.2.2
NICSR Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.3
Vector Address, IPL, Sync/Async (NICSR0) . . . . . . . . . . . . . . . . . . . . .
10.3.4
Receive Polling Demand (NICSR2) . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.5
Descriptor List Addresses (NICSR3, NICSR4) . . . . . . . . . . . . . . . . . . .
10.3.6
Status Register (NICSR5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.6.1
NICSR5 Status Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.7
Command and Mode Register (NICSR6) . . . . . . . . . . . . . . . . . . . . . . .
10.3.8
System Base Register (NICSR7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.9
Reserved Register (NICSR8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.10
Watchdog Timers (NICSR9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.11
Revision Number and Missed Frame Count (NICSR10) . . . . . . . . . . . .
10.3.12
Boot Message (NICSR11, 12, 13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.13
Diagnostic Registers (NICSR14, 15) . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.13.1
Diagnostic Breakpoint Address Register (NICSR14) . . . . . . . . . . .
10.3.13.2
Monitor Command Register (NICSR15) . . . . . . . . . . . . . . . . . . . . .
10.3.14
Descriptors and Buffers Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10–1
10–3
10–3
10–4
10–4
10–5
10–5
10–5
10–5
10–5
10–8
10–9
10–11
10–15
10–16
10–21
10–22
10–22
10–24
10–25
10–26
10–26
10–26
10–28

10.3.15
10.3.15.1
10.3.15.2
10.3.15.3
10.3.15.4
10.3.15.5
10.3.16
10.3.16.1
10.3.16.2
10.3.16.3
10.3.16.4
10.3.16.5
10.3.17
10.3.17.1
10.3.17.2
10.3.17.3
10.3.17.4
10.3.17.5
10.3.18
10.3.18.1
10.3.18.2
10.3.18.3
10.3.18.4
10.3.18.5
10.3.18.6
10.3.18.7

Receive Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES0 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES1 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES2 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES3 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Receive Descriptor Status Validity . . . . . . . . . . . . . . . . . . . . . . . . .
Transmit Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES0 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES1 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES2 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES3 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmit Descriptor Status Validity . . . . . . . . . . . . . . . . . . . . . . . .
Setup Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
First Setup Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subsequent Setup Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup Frame Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perfect Filtering Setup Frame Buffer . . . . . . . . . . . . . . . . . . . . . .
Imperfect Filtering Setup Frame Buffer . . . . . . . . . . . . . . . . . . . .
SGEC Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware and Software Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Startup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reception Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmission Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loopback Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DNA CSMA/CD Counters and Events Support . . . . . . . . . . . . . . .

KA680 Mass Storage Interface
11.1
SHAC Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2
CI-DSSI Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3
SHAC Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1
CI Port Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1.1
Port Queue Block Base Register (PQBBR) . . . . . . . . . . . . . . . . . . .
11.3.1.2
Port Status Register (PSR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1.3
Port Error Status Register (PESR) . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1.4
Port Failing Address Register (PFAR) . . . . . . . . . . . . . . . . . . . . . .
11.3.1.5
Port Parameter Register (PPR) . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1.6
Port Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1.6.1
Port Command Queue 0 Control Register (PCQ0CR) . . . . . . . .
11.3.1.6.2
Port Command Queue 1 Control Register (PCQ1CR) . . . . . . .
11.3.1.6.3
Port Command Queue 2 Control Register (PCQ2CR) . . . . . . .
11.3.1.6.4
Port Command Queue 3 Control Register (PCQ3CR) . . . . . . .
11.3.1.6.5
Port Datagram Free Queue Control Register (PDFQCR) . . . .
11.3.1.6.6
Port Message Free Queue Control Register (PMFQCR) . . . . .
11.3.1.6.7
Port Status Release Control Register (PSRCR) . . . . . . . . . . . .
11.3.1.6.8
Port Enable Control Register (PECR) . . . . . . . . . . . . . . . . . . .
11.3.1.6.9
Port Disable Control Register (PDCR) . . . . . . . . . . . . . . . . . .
11.3.1.6.10
Port Initialize Control Register (PICR) . . . . . . . . . . . . . . . . . .
11.3.1.6.11
Port Maintenance Timer Control Register (PMTCR) . . . . . . . .
11.3.1.6.12
Port Maintenance Timer Expiration Control Register
(PMTECR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1.6.13
Port Maintenance Control and Status Register (PMCSR) . . . .

10–28
10–29
10–31
10–32
10–32
10–33
10–33
10–34
10–35
10–37
10–37
10–38
10–38
10–38
10–38
10–39
10–40
10–42
10–46
10–46
10–47
10–47
10–48
10–49
10–51
10–52

11–1
11–3
11–5
11–6
11–6
11–8
11–11
11–12
11–13
11–13
11–14
11–14
11–14
11–14
11–14
11–14
11–14
11–14
11–15
11–15
11–15
11–15
11–15

11.3.2
11.3.2.1
11.3.2.2

SHAC Specific Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SHAC Software Chip Reset Register (SSWCR) . . . . . . . . . . . . . . .
SHAC Shared Host Memory Address (SSHMA) . . . . . . . . . . . . . . .

11–16
11–17
11–17

12 KA680 Firmware
12.1
KA680 Firmware Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2
Firmware Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.1
General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.2
Halt Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.3
Halt Entry - Saving Processor State . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.4
Halt Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.4.0.1
External Halts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.4.1
Halt Exit - Restoring Processor State . . . . . . . . . . . . . . . . . . . . . .
12.2.5
Power-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.5.1
Identifying the Console Device . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.5.1.1
Mode Switch Set to "Test" . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.5.1.2
Mode Switch Set to "Query" . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.5.1.3
Mode Switch Set to "Normal" . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.5.2
LED Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6
Operating System Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6.1
Preparing for the Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6.1.1
Boot Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6.1.2
Boot Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6.2
Primary Bootstrap, VMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6.3
Device-Dependent Bootstrap Procedures . . . . . . . . . . . . . . . . . . . .
12.2.6.3.1
Disk and Tape Bootstrap Procedure . . . . . . . . . . . . . . . . . . . . .
12.2.6.3.2
PROM Bootstrap Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.6.3.3
Network Bootstrap Procedure . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.7
Operating System Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.7.1
Locating the RPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8
Console Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.1
Console Control Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.2
Console Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.3
Console Command Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.4
Console Command Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.5
Console Numeric Expression Radix Specifiers . . . . . . . . . . . . . . . .
12.2.8.6
Command Address Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.7
Console Symbolic Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.8.8
References to Processor Registers and Memory . . . . . . . . . . . . . . .
12.2.9
Console Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTINUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DEPOSIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EXAMINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HALT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HELP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INITIALIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12–1
12–2
12–3
12–4
12–4
12–5
12–6
12–7
12–8
12–8
12–9
12–9
12–10
12–11
12–12
12–12
12–14
12–15
12–16
12–18
12–19
12–20
12–20
12–22
12–23
12–23
12–23
12–26
12–27
12–28
12–28
12–29
12–29
12–33
12–34
12–35
12–37
12–38
12–39
12–41
12–44
12–45
12–46
12–49
12–50
12–52

12.3
12.3.1
12.3.2
12.3.3
12.4
12.4.1
12.4.2
12.4.3
12.4.4
12.5

REPEAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SEARCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SHOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
START . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UNJAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X - Binary Load and Unload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XDELTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
! - Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic Interdependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Areas Not Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12–54
12–55
12–58
12–62
12–67
12–68
12–72
12–73
12–75
12–78
12–83
12–84
12–85
12–85
12–86
12–86
12–86
12–87
12–87
12–88

A NVRAM Partitioning
A.1
A.1.1
A.1.2
A.1.3
A.1.4
A.1.5

SSC RAM Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Public Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Program MailBoX (CPMBX) . . . . . . . . . . . . . . . . . . . . . . . . . .
Firmware Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
USER Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A–1
A–1
A–1
A–3
A–3
A–3

B Data Structures
B.1
B.2
B.3

Halt Dispatch State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMB Argument List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B–1
B–4
B–8

Error Messages
C.1
C.2
C.3
C.4

Machine Check Register Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Halt Code Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMB Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C–1
C–1
C–3
C–4

D Machine State on Powerup
D.1
Main Memory Layout and State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1
Reserved Main Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1.1
PFN Bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1.2
Scatter/Gather Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1.3
Firmware "Scratch Memory" . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.2
Contents of Main Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.2
Memory Controller Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.2.1
On-chip Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xii

D–1
D–1
D–2
D–2
D–2
D–3
D–3
D–3

D.2.2
D.2.3

Translation Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Halt-Protected Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D–3
D–3

E MOP Support
E.1
E.2

Network "Listening" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MOP Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E–1
E–6

F Q22–bus Specification
F.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.1.1
Master/Slave Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.2
Q22–bus Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3
Data Transfer Bus Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3.1
Bus Cycle Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3.2
Device Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4
Direct Memory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.1
DMA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.2
Block Mode DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.2.1
DATBI Bus Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.2.2
DATBO Bus Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.4.3
DMA Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.5
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.5.1
Device Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.5.2
Interrupt Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.5.3
Q22–bus 4-level Interrupt Configurations . . . . . . . . . . . . . . . . . . . . . .
F.6
Control Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.6.1
Halt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.6.2
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.6.3
Power Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7
Q22–bus Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.1
Signal Level Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.2
Load Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.3
120-Ohm Q22–bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.4
Bus Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.5
Bus Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.6
Bus Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.7
Bus Interconnecting Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.7.1
Backplane Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.7.2
Intrabackplane Bus Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.7.7.3
Power and Ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.8
System Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.8.1
Power Supply Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.9
Module Contact Finger Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F–1
F–2
F–2
F–5
F–6
F–7
F–17
F–17
F–20
F–22
F–24
F–25
F–25
F–26
F–27
F–31
F–32
F–32
F–32
F–32
F–32
F–33
F–33
F–33
F–33
F–34
F–34
F–35
F–35
F–35
F–36
F–36
F–39
F–39

G Specifications
G.1
G.2
G.2.1
G.2.2
G.3
G.4
G.5

Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Backplane Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Console Connector (J2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DC Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Battery Back-up Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

G–1
G–1
G–1
G–7
G–12
G–12
G–12

xiii

G.6
G.7
G.8

Nonoperating Conditions (Fewer Than 60 Days) . . . . . . . . . . . . . . . . . . . .
Nonoperating Conditions (More Than 60 Days) . . . . . . . . . . . . . . . . . . . . .
Mean Time Between Failures (MTBF) Estimate . . . . . . . . . . . . . . . . . . . .

G–13
G–13
G–13

H VAX Instruction Set
I Address Assignments
I.1
I.2
I.3
I.4

KA680 General Local Address Space Map . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Detailed Local Address Space Map . . . . . . . . . . . . . . . . . . . . . . . . .
External, Internal Processor Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Global Q22–bus Address Space Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I–1
I–2
I–5
I–6

J Configurable Machine State
Index
Examples
2–1
2–2
10–1
10–2
10–3

Changing a DSSI Node Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing a DSSI Unit Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perfect Filtering Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Imperfect Filtering Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Imperfect Filtering Setup Frame Buffer Creation C Program . . . . . . .

2–4
2–5
10–42
10–43
10–44

KA680 Module in a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 CPU Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 CPU Module Component Side . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 CPU Module Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .
H3604 Console Module Front . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backplane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General-Purpose Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processor Status Longword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Address Space Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PTE and TB Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Translation Buffer Tag (TBTAG) - IPR 47 . . . . . . . . . . . . . . . . . . . . . .
Translation Buffer Data (TBDATA) - IPR 59 . . . . . . . . . . . . . . . . . . . .
Interrupt Priority Level Register (IPLR) - IPR 18 . . . . . . . . . . . . . . . .
Software Interrupt Request Register (SIRR) - IPL 20 . . . . . . . . . . . . .
Software Interrupt Summary Register (SISR) - IPL 21 . . . . . . . . . . . .
Power Fail Interrupt Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hard Error Interrupt Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . . . .
Soft Error Interrupt Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arithmetic Exception Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Management Exception Stack Frame . . . . . . . . . . . . . . . . . . .
Instruction Emulation Trap Stack Frame . . . . . . . . . . . . . . . . . . . . . .

1–1
1–2
1–3
1–4
1–9
2–2
3–1
3–2
3–4
3–25
3–27
3–27
3–33
3–33
3–33
3–33
3–34
3–34
3–36
3–37
3–38

Figures
1–1
1–2
1–3
1–4
1–5
2–1
3–1
3–2
3–3
3–4
3–5
3–6
3–7
3–8
3–9
3–10
3–11
3–12
3–13
3–14
3–15

xiv

3–16
3–17
3–18
3–19
3–20
3–21
3–22
4–1
4–2
4–3
4–4
4–5
4–6
4–7
4–8
4–9
4–10
4–11
4–12
4–13
4–14
4–15
4–16
4–17
4–18
4–19
4–20
4–21
4–22
4–23
4–24
4–25
4–26
4–27
4–28
4–29
4–30
4–31
4–32
4–33
4–34
4–35
4–36
4–37
4–38
5–1
5–2

Suspended Emulation Fault Stack Frame . . . . . . . . . . . . . . . . . . . . . .
Generic Machine Check Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . .
Console Saved PC and Saved PSL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Stack Not Valid Stack Frame . . . . . . . . . . . . . . . . . . . . . . . . . .
System Control Block Base Register (SCBB) - IPR 17 . . . . . . . . . . . . .
System Identification Register (SID) - IPR 62 . . . . . . . . . . . . . . . . . . .
System Identification Extension Register (SIE) . . . . . . . . . . . . . . . . . .
KA680 Cache/Memory Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VIC Cache Row Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMAR Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VTAG Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VDATA Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ICSR Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Pcache Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pcache Address Breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCCTL Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCADR Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCSTS Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCTAG Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCDAP Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Address Space Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tags and Data for 128-Kilobyte Cache . . . . . . . . . . . . . . . . . . . . . . . . .
Address Used for 128-Kilobyte Cache . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Address Space Decoding as Seen by Software . . . . . . . . . . . . . . . .
IPR Format of CCTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the BCDECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of BCETSTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Tag Store Error Address IPR . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of BCETAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tag Store Error Correcting Code Matrix . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of BCEDSTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BCEDIDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the BCEDECC Register . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache Data Store Error Correcting Code Matrix . . . . . . . . . . .
IPR Format of CEFSTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of CEFADR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of NESTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of NEOADR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of NEOCMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Format of NEICMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEDATHI, Address Cycle Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEDATLO, Address Cycle Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache Tag Store IPR Addressing Format . . . . . . . . . . . . . . . .
IPR Format of the Backup Cache Tag Store . . . . . . . . . . . . . . . . . . . .
Backup Cache Deallocate IPR Addressing Format . . . . . . . . . . . . . . . .
NDAL IN_QUEs in the NMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Memory Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3–39
3–40
3–40
3–41
3–41
3–45
3–45
4–1
4–3
4–4
4–5
4–6
4–7
4–9
4–9
4–10
4–15
4–15
4–16
4–17
4–18
4–22
4–22
4–24
4–28
4–32
4–33
4–35
4–36
4–37
4–38
4–40
4–41
4–41
4–42
4–46
4–47
4–49
4–49
4–50
4–50
4–51
4–51
4–51
4–52
5–4
5–6
xv

5–3
5–4
5–5
5–6
5–7
5–8
5–9
5–10
5–11
5–12
5–13
6–1
6–2
6–3
6–4
6–5
6–6
6–7
6–8
6–9
7–1
7–2
7–3
7–4
7–5
7–6
7–7
7–8
7–9
8–1
8–2
8–3
8–4
8–5
8–6
9–1
9–2
9–3
9–4
9–5
9–6
9–7
9–8
9–9
10–1
10–2
10–3
xvi

O-bit Port Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SEC/DED/SSD Code Used in the NMC . . . . . . . . . . . . . . . . . . . . . . . .
Single Error Correcting Code for O-bit Memory . . . . . . . . . . . . . . . . . .
Memory Configuration Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Address Information Register . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Control and Diagnostic Status Register . . . . . . . . . . . . . . . . . . .
O-bit Address and Mode Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O-bit Data Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NMC Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Organization with 64-bit Interconnect . . . . . . . . . . . . . . . . . .
NCA Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Control and Diagnostic Status Register . . . . . . . . . . . . . . . . . . .
CP1 Slave Error Address Register . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP2 Slave Error Address Register . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP1 IO Error Address Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP2 IO Error Address Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NDAL Error Address Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interval Clock Control and Status Register . . . . . . . . . . . . . . . . . . . . .
Console Receiver Control/Status Register (IPR 3210 2016 ) . . . . . . . . . .
Console Receiver Data Buffer (IPR 3310 2116 ) . . . . . . . . . . . . . . . . . . .
Console Transmitter Control/Status Register (IPR 3410 2216 ) . . . . . . .
Console Transmitter Data Buffer (IPR 3510 2316 ) . . . . . . . . . . . . . . . .
Time-of-Year Clock (TODR) - (EPR 2710 1B16 ) . . . . . . . . . . . . . . . . . . .
Timer Control Registers (TCR0 and TCR1) . . . . . . . . . . . . . . . . . . . . .
Timer Interval Registers (TIR0 and TIR1) . . . . . . . . . . . . . . . . . . . . . .
Timer Next Interval Registers (TNIR0 and TNIR1) . . . . . . . . . . . . . . .
Timer Interrupt Vector Registers (TIVR0 and TIVR1) . . . . . . . . . . . . .
Boot and Diagnostic Register (BDR) . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic LED Register (DLEDR) . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSC Base Address Register (SSCBR) . . . . . . . . . . . . . . . . . . . . . . . . . .
BDR Address Decode Match Register (BDMTR) . . . . . . . . . . . . . . . . .
BDR Address Decode Mask Register (BDMKR) . . . . . . . . . . . . . . . . . .
SSC Configuration Register (SSCCR) . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Register Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Cache Entry Format . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interprocessor Communication Register (IPCR) . . . . . . . . . . . . . . . . . .
Q22–bus Map Base Address Register (QBMBR) . . . . . . . . . . . . . . . . .
System Configuration Register (SCR) . . . . . . . . . . . . . . . . . . . . . . . . .
DMA System Error Register (DSER) . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Error Address Register (QBEAR) . . . . . . . . . . . . . . . . . . . . .
DMA Error Address Register (DEAR) . . . . . . . . . . . . . . . . . . . . . . . . .
Ethernet Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vector Address, IPL, Sync/Async (NICSR0) . . . . . . . . . . . . . . . . . . . . .
Polling Demand (NICSR1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5–9
5–12
5–12
5–16
5–18
5–19
5–22
5–25
5–27
5–29
5–37
6–3
6–10
6–14
6–17
6–17
6–18
6–19
6–19
6–20
7–2
7–3
7–4
7–6
7–7
7–8
7–10
7–10
7–11
8–1
8–4
8–8
8–8
8–9
8–9
9–2
9–4
9–6
9–8
9–10
9–11
9–13
9–15
9–15
10–2
10–6
10–7

10–4
10–5
10–6
10–7
10–8
10–9
10–10
10–11
10–12
10–13
10–14
10–15
10–16
10–17
10–18
11–1
11–2
11–3
11–4
11–5
11–6
11–7
11–8
11–9
11–10
11–11
12–1
12–2
12–3
12–4
12–5
12–6
12–7
12–8
12–9
12–10
12–11
12–12
12–13
12–14
A–1
A–2
A–3
A–4
D–1
F–1
F–2

NICSR2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Descriptor List Addresses Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR5 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR6 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR7 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR9 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revision Number and Missed Frame Count (VIRTUAL NICSR10) . . .
Boot Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR14 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR15 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Receive Descriptor Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmit Descriptor Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup Frame Descriptor Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perfect Filtering Setup Frame Buffer Format . . . . . . . . . . . . . . . . . . .
Imperfect Filtering Setup Frame Format . . . . . . . . . . . . . . . . . . . . . . .
Relationship of the DSSI to SCA and CI . . . . . . . . . . . . . . . . . . . . . . .
Port Queue Block Base Register (PQBBR) . . . . . . . . . . . . . . . . . . . . . .
Port Queue Block Base Register (PQBBR) After Reset . . . . . . . . . . . .
Port Status Register (PSR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Error Status Register (PESR) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Failing Address Register (PFAR) . . . . . . . . . . . . . . . . . . . . . . . . .
Port Parameter Register (PPR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Maintenance Control And Status Register (PMCSR) . . . . . . . . . .
SHAC Software Chip Reset (SSWCR) . . . . . . . . . . . . . . . . . . . . . . . . .
SHAC Shared Host Memory Address (SSHMA) . . . . . . . . . . . . . . . . . .
KA680 Firmware Structural Components . . . . . . . . . . . . . . . . . . . . . .
Console Banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Language Selection Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Normal Diagnostic Countdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abnormal Diagnostic Countdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Boot Display with No Default Boot Device . . . . . . . . . . . . . . .
Memory Layout Prior to VMB Entry . . . . . . . . . . . . . . . . . . . . . . . . . .
VMB Boot Flags (/R5:) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Successful Automatic Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Layout at VMB Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Boot Block Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Locating the Restart Parameter Block . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic Register Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 SSC NVRAM Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NVR0 (20140400) : Console Program MailBoX (CPMBX) . . . . . . . . . .
NVR1 (20140401) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NVR2 (20140402) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Layout after Power-up Diagnostics . . . . . . . . . . . . . . . . . . . . .
DATI Bus Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATI Bus Cycle Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10–8
10–10
10–11
10–16
10–21
10–22
10–24
10–25
10–26
10–27
10–29
10–34
10–39
10–41
10–43
11–2
11–6
11–7
11–8
11–11
11–12
11–13
11–14
11–16
11–17
11–17
12–3
12–8
12–9
12–10
12–10
12–10
12–11
12–13
12–15
12–17
12–18
12–19
12–23
12–84
A–1
A–2
A–3
A–3
D–1
F–8
F–10
xvii

F–3
F–4
F–5
F–6
F–7
F–8
F–9
F–10
F–11
F–12
F–13
F–14
F–15
F–16
F–17
F–18
F–19
F–20

DATO or DATOB Bus Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATO or DATOB Bus Cycle Timing . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATIO or DATIOB Bus Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATIO or DATIOB Bus Cycle Timing . . . . . . . . . . . . . . . . . . . . . . . . .
DMA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DMA Request/Grant Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATBI Bus Cycle Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATBO Bus Cycle Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interrupt Request/Acknowledge Sequence . . . . . . . . . . . . . . . . . . . . . .
Interrupt Protocol Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Position-Independent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
Position-Dependent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus Line Terminations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single Backplane Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiple Backplane Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical Pin Identification System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quad-Height Module Contact Finger Identification . . . . . . . . . . . . . . .
Typical Q22–bus Module Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . .

F–11
F–13
F–15
F–16
F–19
F–20
F–21
F–22
F–28
F–30
F–31
F–32
F–34
F–37
F–38
F–39
F–40
F–41

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General-Purpose Register Description . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Process Register Definitions . . . . . . . . . . . . . . . . . . . . . . . . . .
IPR Address Space Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processor Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interrupt Priority Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exception Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arithmetic Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Management Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Management Exception Fault Parameter . . . . . . . . . . . . . . . .
Instruction Emulation Trap Stack Frame . . . . . . . . . . . . . . . . . . . . . .
The System Control Block Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Identification Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Identification Extension Register Bits . . . . . . . . . . . . . . . . . . .
NDAL Command Usage by NVAX . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NVAX Backup Cache Invalidates and Write-backs . . . . . . . . . . . . . . . .
VIC Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMAR Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VTAG Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VDATA Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ICSR Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCCTL Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pcache IPRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCSTS Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pcache Tag IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pcache Data Parity IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xxiv
3–2
3–3
3–5
3–7
3–30
3–34
3–36
3–36
3–37
3–39
3–42
3–45
3–46
3–50
3–54
4–3
4–4
4–5
4–6
4–7
4–10
4–15
4–16
4–17
4–17

Tables
1
3–1
3–2
3–3
3–4
3–5
3–6
3–7
3–8
3–9
3–10
3–11
3–12
3–13
3–14
3–15
4–1
4–2
4–3
4–4
4–5
4–6
4–7
4–8
4–9
4–10

xviii

4–11
4–12
4–13
4–15
4–15
4–16
4–17
4–18
4–19
4–20
4–21
4–22
4–23
4–24
4–25
4–26
4–27
4–28
4–29
4–30
4–31
4–32
4–33
4–34
4–35
5–1
5–2
5–3
5–4
5–5
5–6
5–7
5–8
5–9
5–10
5–11
5–12
5–13
6–1
6–2
6–3
6–4
6–5
6–6
6–7
6–8
6–9

Backup Cache Size and RAMs Used . . . . . . . . . . . . . . . . . . . . . . . . . .
Tag and Index Interpretation Based on Cache Size . . . . . . . . . . . . . . .
IPR Address Space Decoding - KA680 . . . . . . . . . . . . . . . . . . . . . . . . .
Bcache/NDAL Processor Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bcache/NDAL Processor Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CCTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TAG_SPEED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DATA_SPEED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bcache Tag Store Status IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretation of TS_CMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BCETAG IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TAG Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bcache Data RAM Status IPR Format . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretation of DR_CMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BCEDIDX Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fill Error Status IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NESTS IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEOCMD IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bcache Tag IPR Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tag and Index Interpretation for BCTAG IPR . . . . . . . . . . . . . . . . . . .
Backup Cache Behavior During ETM . . . . . . . . . . . . . . . . . . . . . . . . .
Backup Cache State Changes During ETM . . . . . . . . . . . . . . . . . . . . .
Backup Cache ECC Errors and NVAX CPU Error Responses . . . . . . .
Backup Cache ECC Error Handling During ETM . . . . . . . . . . . . . . . .
Memory Address Mapping for Data . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Signature Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O-bit Port Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NMC Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Configuration Registers, MEMCON0-7 . . . . . . . . . . . . . . . . .
Error Address Information Register, MEAR . . . . . . . . . . . . . . . . . . . . .
Error Status Register, MESR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Control and Diagnostic Status Register, MMCDSR . . . . . . . . . .
O-bit Address and Mode Register, MOAMR . . . . . . . . . . . . . . . . . . . . .
O-bit Data Registers, MODR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NDAL-related Errors and NMC Responses . . . . . . . . . . . . . . . . . . . . .
Memory-related Errors and NMC Responses . . . . . . . . . . . . . . . . . . . .
NDAL Arbitration Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NCA Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NCA CSR and Interval Timer Registers . . . . . . . . . . . . . . . . . . . . . . .
Error Status Register, CESR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Control and Diagnostic Status Register, CMCDSR . . . . . . . . . . .
CP1 Slave Error Address Register, CSEAR1 . . . . . . . . . . . . . . . . . . . .
CP2 Slave Error Address Register, CSEAR2 . . . . . . . . . . . . . . . . . . . .
CP1 IO Error Address Register, CIOEAR1 . . . . . . . . . . . . . . . . . . . . . .
CP2 IO Error Address Register, CIOEAR2 . . . . . . . . . . . . . . . . . . . . . .
NDAL Error Address Register, CNEAR . . . . . . . . . . . . . . . . . . . . . . . .

4–21
4–21
4–25
4–26
4–27
4–29
4–30
4–30
4–31
4–34
4–35
4–36
4–37
4–39
4–40
4–40
4–43
4–47
4–49
4–52
4–52
4–56
4–57
4–59
4–61
5–7
5–7
5–9
5–15
5–16
5–18
5–19
5–22
5–26
5–27
5–32
5–33
5–34
6–4
6–9
6–10
6–15
6–17
6–18
6–18
6–19
6–20
xix

6–10
6–11
6–12
6–13
6–14
6–15
6–16
7–1
7–2
7–3
7–4
7–5
7–6
7–7
8–1
8–2
8–3
8–4
9–1
9–2
9–3
9–4
9–5
9–6
10–1
10–2
10–3
10–4
10–5
10–6
10–7
10–8
10–9
10–10
10–11
10–13
10–14
10–15
10–16
10–17
10–18
10–19
10–20
10–21
10–22
10–23
10–24
xx

Interval Clock Control and Status Register, ICCS . . . . . . . . . . . . . . . .
IO Read RDR number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interrupt Vector Read RDR Number . . . . . . . . . . . . . . . . . . . . . . . . . .
CP1 DMA Memory Read Prefetching . . . . . . . . . . . . . . . . . . . . . . . . . .
CP2 DMA Memory Read Prefetching . . . . . . . . . . . . . . . . . . . . . . . . . .
NDAL-Related Errors and NCA Responses . . . . . . . . . . . . . . . . . . . . .
CP-Bus (CP1 and CP2 Buses) Related Errors and NCA Responses . . .
Console Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Receiver Control/Status Register . . . . . . . . . . . . . . . . . . . . . .
Console Receiver Data Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Transmitter Control/Status Register . . . . . . . . . . . . . . . . . . . .
Console Transmitter Data Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Baud Rate Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timer Control Register Bit Descriptions . . . . . . . . . . . . . . . . . . . . . . .
Boot and Diagnostic Register Bit Description . . . . . . . . . . . . . . . . . . .
Diagnostic LED Register Bit Descriptions . . . . . . . . . . . . . . . . . . . . . .
Power-Up Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSC Configuration Register Bit Descriptions . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Register Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Register Bit Description . . . . . . . . . . . . . . . . . . . . . . . .
Q22–bus Map Cache Entry Bit Description . . . . . . . . . . . . . . . . . . . . .
Interprocessor Communication Register Bit Description . . . . . . . . . . .
System Configuration Register Bit Description . . . . . . . . . . . . . . . . . .
DMA System Error Register Bit Description . . . . . . . . . . . . . . . . . . . .
Bit Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR0 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR0 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR1 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR1 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR2 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR2 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Descriptor List Addresses Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR3 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR4 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR5 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR5 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR6 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR6 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR7 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR7 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR9 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR9 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR10 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR10 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR11,12,13 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR11,12,13 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR14 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6–21
6–24
6–25
6–26
6–28
6–30
6–31
7–1
7–2
7–3
7–5
7–6
7–6
7–9
8–2
8–4
8–6
8–10
9–4
9–5
9–7
9–8
9–11
9–14
10–4
10–7
10–7
10–8
10–8
10–8
10–8
10–10
10–10
10–10
10–11
10–15
10–16
10–21
10–21
10–22
10–23
10–24
10–24
10–24
10–25
10–25
10–26

10–25
10–26
10–27
10–28
10–29
10–30
10–31
10–32
10–33
10–34
10–35
10–36
10–37
10–38
10–39
10–40
10–41
10–42
11–1
11–2
11–3
11–4
11–5
11–6
12–1
12–2
12–3
12–4
12–5
12–6
12–7
12–8
12–9
12–10
12–11
12–12
12–13
12–14
12–15
12–16
12–17
A–1
A–2
A–3
B–1
B–2
B–3

NICSR14 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR15 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR15 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES0 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES1 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES2 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RDES3 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Receive Descriptor Status Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES0 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES1 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES2 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDES3 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmit Descriptor Status Validity . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup Frame Descriptor Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NICSR Fields Not Reset to Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reception Process State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmission Process State Transitions . . . . . . . . . . . . . . . . . . . . . . . .
CSMA/CD Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Queue Block Base Address Register (PQBBR) . . . . . . . . . . . . . . .
Port Queue Block Base Address Register Bits After Reset . . . . . . . . . .
Port Status Register Bit Descriptions . . . . . . . . . . . . . . . . . . . . . . . . .
Port Error Status Register Bit Definitions . . . . . . . . . . . . . . . . . . . . . .
Port Parameter Register Bit Descriptions (PPR) . . . . . . . . . . . . . . . . .
Port Maintenance Control and Status Register (PMCSR) Bits . . . . . . .
Halt Action Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LED Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Supported Boot Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMB Boot Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Control Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command, Parameter, and Qualifier Keywords . . . . . . . . . . . . . . . . . .
Console Radix Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Symbols Using Last Referenced Address . . . . . . . . . . . . . . .
Console Symbols for General-Purpose Registers - /G . . . . . . . . . . . . .
Console Symbols for Internal/External Processor Registers - /I . . . . .
Console Symbols for VAX Physical I/O Space Registers - /P . . . . . . . .
Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Radix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XDELTA Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XDELTA Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Qualifier Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPMBX NVR0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPMBX NVR1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPMBX NVR0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Firmware State Transition Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restart Parameter Block Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMB Argument List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10–26
10–27
10–27
10–29
10–31
10–32
10–33
10–33
10–34
10–35
10–37
10–37
10–38
10–39
10–46
10–49
10–50
10–52
11–6
11–7
11–8
11–11
11–13
11–16
12–6
12–11
12–14
12–15
12–24
12–27
12–28
12–29
12–29
12–30
12–31
12–34
12–34
12–75
12–76
12–79
12–81
A–2
A–3
A–3
B–2
B–4
B–8
xxi

C–1
C–2
C–3
E–1
E–2
E–3
E–4
E–5
F–1
F–2
F–3
F–4
F–5
F–6
F–7
G–1

xxii

HALT Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMB Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Console Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Network Maintenance Operations Summary . . . . . . . . . . . . . .
Supported MOP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ethernet and IEEE 802.3 Packet Headers . . . . . . . . . . . . . . . . . . . . .
MOP Multicast Addresses and Protocol Specifiers . . . . . . . . . . . . . . . .
MOP Counter Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data and Address Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . .
Control Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power and Ground Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . .
Spare Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Transfer Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus Signals for Data Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus Pin Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KA680 Console Connector (J2) Pinout . . . . . . . . . . . . . . . . . . . . . . . . .

C–2
C–3
C–4
E–2
E–3
E–5
E–5
E–6
F–2
F–3
F–4
F–4
F–5
F–6
F–41
G–7

Preface
The KA680 CPU Module Technical Manual documents the functional, physical,
and environmental characteristics of the KA680 CPU module, and includes
information on the MS690 memory expansion modules.

Organization
The manual is divided into three parts.
Overview and Installation
•

Chapter 1, ‘‘Overview,’’ introduces the KA680 CPU module, the MS690
memory module, and the H3604 console module, including module features
and specifications.

•

Chapter 2, ‘‘Installation and Configuration,’’ describes the procedures for
installing and configuring the CPU, memory, and console modules in the
Q22–bus backplanes and system enclosures.

Architecture
•

Chapter 3, ‘‘Central Processor,’’ describes the functions of the central
processing unit.

•

Chapter 4, ‘‘KA680 Cache Memory Overview,’’ describes the operation of the
KA680 CPU module’s cache memory.

•

Chapter 5, ‘‘KA680 Main Memory System,’’ describes the operation of the
KA680 CPU module’s main memory.

•

Chapter 6, ‘‘KA680 I/O Subsystem,’’ describes the I/O system configuration,
along with the NCA chip architecture.

•

Chapter 7, ‘‘The Console Line, TOY Clock,’’ describes the console serial line
and the time-of-year clock. The chapter also provides an overview of the
KA680 bus system.

•

Chapter 8, ‘‘KA680 Boot and Diagnostic Facility,’’ describes the boot and
diagnostic registers, EPROM memory, battery backed-up RAM and hardware
initialization.

•

Chapter 9, ‘‘KA680 Q22–bus Interface,’’ describes the interfaces the KA680
CPU module uses for the Q22–bus.

•

Chapter 10, ‘‘ Network Interface,’’ describes the network interface of the
KA680.

•

Chapter 11, ‘‘ KA680 Mass Storage Interface,’’ describes the interfaces the
KA680 CPU module uses for the mass storage bus.

xxiii

Firmware
•

Chapter 12, ‘‘KA680 Firmware,’’ describes the entry dispatch code, boot
diagnostics, device booting sequence, console program, and console commands.

Appendices
•

Appendix A, ‘‘NVRAM Partitioning,’’ describes how the KA680 firmware
partitions the SSC 1 Kb battery backed-up (BBU) RAM.

•

Appendix B, ‘‘Data Structures,’’ describes the global data structures used by
the KA680 firmware.

•

Appendix C, ‘‘ Error Messages ,’’ describes the error messages for the KA680,
including machine check register dumps, halt codes, VMB error messages,
and console error messages.

•

Appendix D, ‘‘Machine State on Powerup,’’ describes the state of the KA680
after a power-up halt.

•

Appendix E, ‘‘MOP Support,’’ describes the maintenance operation protocol
(MOP) support features in the KA680 firmware.

•

Appendix F, ‘‘Q22–bus Specification,’’ describes the specifications for the
Q22–bus.

•

Appendix G, ‘‘Specifications,’’ describes the physical, electrical, and
environmental characteristics of the KA680 CPU module.

•

Appendix H, ‘‘VAX Instruction Set,’’ is a list of the VAX instructions, provided
for reference only.

•

Appendix I, ‘‘Address Assignments,’’ provides a map of VAX memory space.

•

Appendix J, ‘‘Configurable Machine State,’’ provides a list of all configurable
bits in the CPU module that are left after the successful completion of
power-up RAM diagnostics.

Conventions
The following table lists the conventions used in this manual.
Table 1 Conventions

xxiv

Convention

Meaning

<x:y>

Represents a bit field, a set of lines, or signals, ranging from x through
y. For example, R0 <7:4> Indicates bits 7 through 4 in a generalpurpose register R0.

[x:y]

Represents a range of bits, from y through x.

Return

A label enclosed in a box represents a key (usually a control or a special
character key) on the keyboard (in this case, the return key).

Note

Contains general information.

Caution

Contains information to prevent damage to equipment.

Indicates a variable.

[]

Represents a console command element that is optional.

{}

Represents a console command element.

...

Represents a list of command elements.

CPU

Refers to the NVAX central processor chip used in this design.

Related Documents
The following documents are related to the KA680 CPU.
•

Microcomputer Interfaces Handbook (EB-20175-20)

•

Microcomputers and Memories Handbook (EB-18451-20)

•

VAX Architecture Handbook (EB-19580-20)

•

VAX–11 Architecture Reference Manual (EK-VAXAR-RM)

You can order these documents by phone or mail.
Continental USA and Puerto Rico
Call 800–258–1710 or mail to:
Digital Equipment Corporation
P.O. Box CS2008
Nashua, NH 03061
New Hampshire, Alaska, and Hawaii
Call 1-603-884-6660.
Outside the USA and Puerto Rico
Mail to:
Digital Equipment Corporation
Attn: Accessories and Supplies Business Manager
c/o Local Subsidiary or Digital-Approved Distributor

xxv

1
Overview
1.1 Introduction
This chapter briefly describes the KA680 CPU/memory subsystem.
The KA680 CPU module combines with the MS690 memory modules to form the
CPU/memory subsystem for the VAX 4000-500 product. The subsystem is housed
in the BA440 enclosure. The subsystem uses the DSSI bus to communicate with
mass storage devices and the Q22–bus to communicate with I/O devices. A single
KA680 CPU module can support up to four MS690 memory modules. Figure 1–1
is a block diagram of the CPU/memory subsystem’s major functions.
Figure 1–1 KA680 Module in a System
Backplane Interconnect

DSSI #1

Ethernet

Serial Line

H3604
Console
Module

Ribbon
Cable

KA680
Processor
Module

DSSI #2
Q22-bus
Memory
Interconnect

MS690
Memory
Module/s

The KA680 can be configured only as an arbiter CPU on the Q22–bus, where
it arbitrates bus mastership and fields bus interrupt requests and any on-board
interrupt requests. The module uses multiple levels of cache memory to maximize
performance. It is designed for use in high-speed, real-time applications and for
multiuser, multitasking environments.
The KA680 and the MS690 designs are implemented in fingerless quad-height
sized modules. Both use high-density, right angle connectors and mount in
dedicated slots in the backplane. The CPU uses a 270-pin backplane connector
while the memory module uses a 150-pin connector.

Overview 1–1

Overview
1.1 Introduction
The CPU module communicates with the memory modules across a memory
interconnect routed through the high-density connectors and the backplane. The
backplane connector also connects the subsystem with the Q22–bus and one DSSI
bus. There are no jumpers or switches to configure on the processor module.
Fuses are located on the H3604 console module. The KA680 connects to the
H3604 console module with a 100-pin ribbon cable. The console module contains
configuration switches, Ethernet and DSSI connectors, and an LED display.

1.2 KA680 CPU Module
Figure 1–2 is a photograph of the KA680 CPU Module.
Figure 1–2 KA680 CPU Module

photograph of the MS690 memory module

1–2 Overview

Overview
1.2 KA680 CPU Module
The major hardware components of the KA680 CPU module are listed below. The
chip identification numbers are shown in Figure 1–3.
DC246

Central processor

(NVAX)

Cache RAMs

A 128 KB backup cache

–

DC243

NDAL to CDAL I/O bus interface chip

(NCA)

DC244

Main memory controller, with ownership bit control

(NMC)

DC527

Q22–bus interface

(CQBIC)

DC541

Ethernet interface

(SGEC)

DC542

DSSI interface chips (2)

(SHAC)

DC511

System support chip

(SSC)

DC509

Clock

(CCLK)

Firmware ROMs (4)

512 KB; each 128 KB by 8, FLASH programmable

–

Console Connection

100-pin ribbon cable to the H3604 console module

–

Backplane Connection

270-pin ribbon cable to the backplane carrying signals for
the Q22–bus, the DSSI bus, and the memory interconnect

–

Figure 1–3 shows the positions of the major chips on the KA680.
Figure 1–3 KA680 CPU Module Component Side

Console Connector

BCache
(tag
store)

E-net ROM

DC541 DC542

Firmware

SGEC

ROMs

SHAC

DC246
NVAX

DC243
NCA
CLK

DC511
SSC

Obit RAMs

B-CACHE
(data store)

DC244
NMC

DC527 DC542
CQBIC

SHAC

High Density Backplane Connector

Figure 1–4 shows the major functional blocks of the KA680 CPU module.

Overview 1–3

Overview
1.2 KA680 CPU Module
Figure 1–4 KA680 CPU Module Block Diagram
To Console Module

SHAC1

DSSI

SHAC2

DSSI

To BA440 disks

SGEC

Ethernet

To Console Module

CQBIC

Q22-bus

To BA440 Backplane

NCA
NDAL

CDAL 1

NVAX
CPU
SSC

Bcache
I&D

VIC

ROM
CDAL 2

NMC
To Memory

Functionally, the KA680 CPU module is divided into four major areas:
•

The central processing subsystem

•

The system support subsystem

•

The I/O subsystem

•

The memory control subsystem

The H3604 is described in Section 1.4.

1.2.1 The Central Processing Subsystem
The central processing subsystem includes the NVAX CPU chip with an integral
floating-point accelerator and a 3-level cache architecture. The RAM storage for
the third level of cache (backup cache) is located on the CPU module.

1.2.1.1 The NVAX Central Processing Unit (DC246)
The NVAX CPU (DC246) chip is the heart of the KA680 module. It executes the
VAX base instruction group as defined by the VAX Architecture Standard plus
the optional VAX vector instructions and the virtual machine instructions. A
complete listing of the instructions executed by the CPU is given in Appendix H.
The NVAX processor also supports full VAX memory management with demand
paging and a 4-gigabyte virtual address space.
For the rest of this document the NVAX CPU chip will be referred to simply as
the "CPU," or "central processor," or "NVAX."
The central processor supports the VAX base instruction set with the following
string instructions:

1–4 Overview

Overview
1.2 KA680 CPU Module
CMPC3

CMPC5

LOCC

MOVC3

MOVC5

SCANC

SKPC

SPANC

The central processor provides the following subset of the VAX data types:
Byte

Word

Longword

Quadword

Character string

Variable-length bit field

F-floating

G-floating

D-floating

Support for the remaining VAX data types can be provided through macrocode
emulation.
1.2.1.2 The Cache Memory
The KA680 processor module uses a 3-level cache architecture to maximize
performance. The first level of cache, referred to as the virtual instruction cache
(VIC), is 2 kilobytes (KB), and is located in the CPU chip. This cache handles
instructions only (no data references), and deals only with virtual addresses.
In this way, the CPU can obtain instruction information without the need for
virtual to physical address translation, thereby decreasing latency and improving
performance.
The second level of cache, referred to as the primary cache (Pcache), is 8 kilobytes
in size and is located in the CPU chip. This cache implements a write-through
instruction and data cache, and helps to reduce latency on access to instructions
that are not found in the VIC. The Pcache uses physical addresses.
The third level of cache, referred to as the backup cache (Bcache), stores
instruction and data, and is 128 KB in size. The Bcache is controlled by the
Bcache controller located in the CPU chip. The data and tag store memory for
this cache is located in SRAM chips on the KA680 module. The Bcache uses
physical addresses.

1.2.2 The System Support Subsystem
The system support subsystem handles the basic functions required to support
the console in a system environment. This subsystem contains the system
support chip (SSC), the firmware ROMs, the boot and diagnostic register, and the
station address ROM.

1.2.2.1 The System Support Chip [SSC (DC511)]
The SSC chip is in an 84-pin CERQUAD surface mount package. It provides
console and boot code support functions, operating system support functions,
timers, and the following features:
•

ROM address decoding

•

1 KB battery backed-up RAM

•

Halt-arbitration logic

•

Console serial line

•

VAX standard time-of-year clock with battery backup

•

IORESET register

Overview 1–5

Overview
1.2 KA680 CPU Module
•

Programmable CDAL bus timeout

•

Two programmable timers

•

1.2.2.2 The Firmware ROMs
Resident firmware ROM is located on four chips, each 128K by 8 bits of FLASH
programmable EPROMs, for a total of 512 KB of ROM. The firmware gains
control when the CPU halts, and contains programs that provide the following
services:
•

Board initialization

•

Power-up self-testing of the KA680 and MS690 modules

•

Emulation of a subset of the VAX standard console (auto or manual bootstrap,
auto or manual restart, and a simple command language for examining or
altering the state of the processor)

•

Booting from supported Q22–bus and DSSI devices

•

Multilingual translation of key system messages

1.2.2.3 The Boot and Diagnostic Register
The boot and diagnostic register (BDR) allows the firmware and the operating
system to read KA680 configuration bits.
1.2.2.4 The Station Address ROM
The station address ROM contains the network hardware address of the system.
It is implemented in a 32 byte by 8 bit ROM (6331).

1.2.3 The I/O Subsystem
The I/O subsystem contains the following:
•

CP-bus adapter

•

DSSI mass storage interfaces

•

An Ethernet interface

•

A Q22–bus interface

1.2.3.1 NVAX CP-bus Bus Adapter [NCA (DC243)]
In order to provide buffering and connection to the I/O devices, the KA680 contains an NCA
(DC243). The NCA provides an interface between the NVAX NDAL bus and two CP-buses
where the the I/O device adapters reside. The CP-buses do not leave the KA680 module. As
a bus adapter, the NCA controls transactions between the higher performance NDAL bus and
the lower performance CP-buses. Each of the NCA’s CP-bus ports provides a CVAX compatible
peripheral bus for direct memory access (DMA) by peripheral devices. The NCA is in a 339-pin
PGA package.

1–6 Overview

A FLASH EPROM is a programmable read-only memory that uses electrical (bulk)
erasure rather than ultraviolet erasure.

Overview
1.2 KA680 CPU Module
1.2.3.1.1 DSSI Mass Storage Interface [SHAC (DC542)] The two shared-host
adapter chips (SHAC) implement the DSSI (Digital storage system interconnect)
bus interfaces. One SHAC interfaces to the system console module while the
other SHAC interfaces to the system backplane. The DSSI interface allows each
DSSI bus on the KA680 to transmit packets of data to, and receive packets from,
up to seven other DSSI devices. The SHAC facilitates scatter and gather mapping
along with internal FIFO buffering, and features parity protection during data
transfers to and from the CPU and main memory.
The DSSI bus improves system performance because it has a higher transfer rate
than the Q22–bus and it relieves the Q22–bus of disk traffic. The DSSI bus has
eight data lines, one parity line, and eight control lines. Controllers are built into
the integrated storage elements (ISEs), enabling many functions to be handled
without host or adapter intervention.
1.2.3.1.2 Ethernet Interface [SGEC (DC541)] The Ethernet interface handles
communications between the CPU module and other nodes on the Ethernet.
It is implemented with the second generation Ethernet controller chip (SGEC,
DC541) on-board network interface. Used in connection with the H3604 console
module, the SGEC allows the KA680 to connect to either a ThinWire or standard
Ethernet. It supports the Ethernet Data Link Layer and provides CP-bus parity
protection. The SGEC chip is in an 84-pin package. The chip facilitates scatter
and gather mapping along with dual internal FIFO buffering.
1.2.3.1.3 Q22–bus Interface [CQBIC (DC527)] The KA680 includes a Q22–bus
interface that allows communication between the KA680 and other devices on the
bus. It is implemented with the CP-bus to Q22–bus asynchronous adapter chip
(CQBIC, DC527). The CQBIC is in a 132-pin CERQUAD surface mount package.
The KA680 does not provide Q22–bus termination; the backplane provides the
termination resistors. The Q22–bus interface supports the following functions:
•

Scatter/gather mapping functions

•

Masked and unmasked longword reads and writes from CPU to the Q22–bus
memory and I/O space and the CQBIC registers

•

Up to 16-word, block mode writes from Q22–bus to main memory

•

Up to 2-word, block mode transfers between the CPU and Q22–bus devices

•

Transfers from CPU to local Q22–bus memory space

1.2.4 The Memory Control Subsystem
This subsystem provides support for the KA680 memory subsystem. A key
feature of the KA680 memory subsystem is the use of ownership bits to maintain
a sense of ownership over each hexaword (32 bytes) of main memory. This
ownership mechanism serves the dual function of maintaining coherency between
main memory and the NVAX cache memory, as well as providing a secure
interlock mechanism for synchronization between NVAX and the I/O devices.

Overview 1–7

Overview
1.2 KA680 CPU Module
1.2.4.1 NVAX Memory Controller [NMC (DC244)]
The memory controller is implemented by the NVAX memory controller
chip (DC244). The NMC is an ECC1 memory controller. The NMC controls
transactions between the main memory and the NVAX, and between main
memory and any of the I/O devices (CQBIC, SGEC, and the two SHAC chips). In
addition, the NMC has a key role in maintaining main memory coherency with
the NVAX primary and backup caches through the use of ownership bits.
The NMC interfaces the NVAX and I/O subsystem with up to four memory
modules. The NMC controls access to shared memory locations through the
use of the ownership bits, thereby providing a reliable interlock mechanism for
memory that is shared between the NVAX and the I/O devices.

1.3 MS690 Memory Module
The MS690 is a double-sided memory board, in a 72-bitwide array (64-bit data
and 8-bit error correction code). Two versions will be offered; one implemented
with 1 Mb DRAM chips and another version using 4 Mb DRAM chips. The
version using 1 Mb DRAMs will contain 32 MB per module, and the version using
4 Mb DRAMs will contain 64 MB or 128 MB per module.
The module mounts in a dedicated memory backplane slot. It is fingerless and
uses a 150-pin high density, right angle connector to connect to the backplane.

1.4 H3604 Console Module
The H3604 console module (Figure 1–5) allows the KA680 CPU module to
interface to a serial line console device, a DSSI bus, and to the Ethernet. The
H3604 module is wide enough to cover the five slots dedicated to the KA680 and
its four MS690 modules. Five adhesive tags are included for the user to name the
modules in the respective slots.

1–8 Overview

ECC stands for error checking and correction.

Overview
1.4 H3604 Console Module
Figure 1–5 H3604 Console Module Front

Language
Inquiry Switch
Baud Rate
Select Switch

Modified
Modular Jack
Baud
300___________0
600___________1
1200__________2
2400__________3
4800__________4
9600__________5
19200_________6
38400_________7

Halt Enable/
Disable Switch

Bus 0

HEX Display

Bus 1

DSSI
Connectors

Bus Node ID Plugs
Ethernet Connector
Switch
Standard Ethernet
Connector
ThinWire Ethernet
Connector
MLO-003896

The H3604 contains the following connectors to allow CPU communication:
•

A console serial line with baud rate switch

•

Two Ethernet connectors, with a switch to choose between them

•

Two DSSI connectors (50-pin high density) that allow daisy chaining of one
DSSI bus; terminators for both DSSI connectors; and two DSSI BUS ID select
plugs

The H3604 also has four feature selection switches:
•

Baud rate select switch for the serial console line.

•

Power-up mode switch.

•

Break enable/disable switch. This determines whether the CPU may be
"halted", causing execution to jump to the halt restart firmware. If halts are
enabled, then the CPU may be halted from the console keyboard in one of
two ways, depending on the setting of bit 15 of the SSC configuration register
(SSCCR<15>). Refer to Section 12.2.2 for more information regarding halts.
If this switch is set to the enable position (1), the system does not autoboot on
powerup. It enters console I/O mode and displays the >>> prompt.

•

Ethernet connector switch to select the following:
A 15-conductor connector for standard Thickwire Ethernet cable.
A male BNC connector for a ThinWire Ethernet coaxial cable.
LEDs indicate the selected connector and valid +12 Vdc for that connector.

Overview 1–9

Overview
1.4 H3604 Console Module
In addition, the H3604 contains the following features:
•

Console serial line drivers and receivers

•

Hexadecimal display

•

Battery charger and low-voltage detect

•

25.6 KHz TOY clock oscillator

•

-9 V dc/dc converter

•

Ethernet serial interface adapter chip (SIA)

•

Fused current surge protection

The door of the H3604 contains a DSSI circuit fuse and two plugs. The fuse is to
protect against shorts from the accidental grounding of the DSSI cable power pin.
The external node ID plugs are used to select the host adapter numbers. Node
number 7 is preset to both of the SHAC DSSI bus controllers on the CPU board.
(The two DSSI buses are separate.)
There are two connectors from the H3604 to the internal BA440. One is a 4-pin
power connection to a small printed circuit card that inserts into the backplane
alongside the KA680. The other is the 100-pin connector to the KA680 CPU
module.

1–10 Overview

2
Installation and Configuration
This chapter describes how to install the KA680 in a system. It discusses the
following topics:
•

Installing the KA680 and MS690 modules

•

Configuring the KA680

•

KA680 connectors

2.1 Installing the KA680 and MS690 Memory Modules
Note
You can use the KA680 and MS690 modules only in BA440 system
enclosures that use high-density backplane connector slots.

The KA680 CPU module and the MS690 memory modules must be installed
in the five rightmost backplane slots. Note that the KA680 module installs in
backplane slot J5, and the memory modules install in slots J4 through J1.
To install the KA680 and MS690 modules:
1. Install the KA680 CPU in slot J5 of the backplane.
2. Install MS690 memory modules in slots J4 through J1 next to to the KA680
CPU.
•

If you only use one memory module , you can install it in any of the slots
J4 through J1.

•

If you use more than one memory module, you must install the first
memory module in J4, the second in J3, and so on. Do not leave a gap
between memory modules.

3. Install a 100-pin ribbon cable between the KA680 CPU and the console
module.
Figure 2–1 shows the positions of the KA680 CPU and the memory modules in
the backplane.

Installation and Configuration 2–1

Installation and Configuration
2.1 Installing the KA680 and MS690 Memory Modules
Figure 2–1 Backplane

J29
o
o
o
dssi

Mass Storage Devices
J30
o
J27
J21
o
o
o
o
o
o
o
o
o
o
o
o
o
o

J28
o
o
o
o
o
o

slot
11

J7
J19 J17 J15 J13 J11 J9
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
* Q22* Q22*Q22*Q22*Q22* Q22 *
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
* C/D* C/D*C/D*C/D*C/D* C/D *
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
J6
J18 J16 J14 J12 J10 J8

J31
o
o
o
o
o
o

J23
o
o

J20
o
o
o
o
o
o

slot
2

KA680 CPU
J5
|*|
|*| DSSI
|*|
J25
|*|
J26
|*| MS680 Memory
Q22 |*|
o
Modules
|*| J4 J3 J2 J1 o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*|
|*|NMI*|NMI|NMI|NMI| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
|*| |*| |*| |*| |*| o
o
|*|
pwr
|*|
J24
supply
|*|
o
|*|
o console
o pwr
J22
fan
power

2.2 Module Configuration and Naming
Each Q22–bus module in a system must use a unique device address and
interrupt vector. The device address is also known as the control and status
register (CSR) address. Most modules have switches or jumpers for setting the
CSR address and interrupt vector values. The value of a floating address depends
on what other modules are housed in the system.

2–2 Installation and Configuration

Installation and Configuration
2.2 Module Configuration and Naming
Set CSR addresses and interrupt vectors for a module as follows:
1. Determine the correct values for the module with the CONFIG command at
the console I/O prompt (>>>). The CONFIG utility eliminates the need to
boot the VMS operating system to determine CSRs and interrupt vectors.
Enter the CONFIG command, then HELP for the list of supported devices:
>>> CONFIG
Enter device configuration, HELP, or EXIT
Device, Number? HELP
Devices:
LPV11
RLV21
DMV11
RQC25
KXXXX-TAPE
CXB16
VSV21
IAV11A
IGQ11

KXJ11
TSV05
DELQA
KXXXX-DISK
KMV11
CXY08
IBQ01
IAV11B

DLV11J
RXV21
DEQNA
TQK50
IEQ11
VCB02
IDV11A
MIRA

DZQ11
DRV11W
RQDX3
TQK70
DHQ11
QDSS
IDV11B
ADQ32

DZV11
DRV11B
KDA50
TU81E
DHV11
DRV11J
IDV11C
DTC04

DFA01
DPV11
RRD50
RV20
CXA16
DRQ3B
IDV11D
DESQA

The LPV11–SA has two sets of CSR address and interrupt vectors. To
determine the correct values for an LPV11–SA, enter LPV11,2 at the DEVICE
prompt for one LPV11–SA, or enter LPV11,4 for two LPV11–SA modules.
2. See the KA680 CPU System Maintenance Manual for switch settings and CSR
and interrupt vector jumper settings for supported options.

2.3 Mass Storage Configuration
There is space for four mass storage devices—either three integrated storage
elements (ISEs) and one tape drive, or four ISEs. The ISEs are part of the Digital
storage system interconnect (DSSI) bus.
The DSSI bus is part of the backplane. The ISEs are part of the RF-series, and
they plug into the backplane to become part of the bus. Each ISE must have
its own unique DSSI node ID. The ISE receives its node ID from a plug on the
operator control panel (OCP) on the front panel.
The VMS operating system creates DSSI disk device names according to the
following scheme:
nodename $ DIA unit number
For example:
SUSAN$DIA3
You can use the device name for booting, as follows:
>>> BOOT SUSAN$DIA3

Installation and Configuration 2–3

Installation and Configuration
2.3 Mass Storage Configuration
You can access local programs in the RF-series ISE through the MicroVAX
diagnostic monitor (MDM), or through the VMS operating system and console
I/O mode SET HOST/DUP command. This command creates a virtual terminal
connection to the storage device and the designated local program using the
diagnostic and utilities protocol (DUP) standard dialog. Section 2.3.3 describes
the procedure for accessing DUP through the VMS operating system.

2.3.1 Changing the Node Name
Each ISE has a node name that is maintained in EPROM on board the controller
module. This node name is determined in manufacturing from an algorithm
based on the drive serial number. You can change the node name of the DSSI
device to something more meaningful by following the procedure in Example 2–1.
In the example, the node name for the ISE at DSSI node address 1 is changed
from R3YBNE to DATADISK.
Example 2–1 Changing a DSSI Node Name
>>> SHO DSSI
DSSI Node 0 (MDC)
-DIA0 (RF71)
DSSI Node 1 (R3YBNE)
-DIA1 (RF71)

!The node name for this drive will be
!changed from R3YBNE to DATADISK.

DSSI Node 7 (*)
>>>
>>> SET HOST/DUP/DSSI 1
Starting DUP server...
Copyright 1988 Digital Equipment Corporation
DRVEXR V1.0 D 5-NOV-1988 15:33:06
DRVTST V1.0 D 5-NOV-1988 15:33:06
HISTRY V1.0 D 5-NOV-1988 15:33:06
ERASE V1.0 D 5-NOV-1988 15:33:06
PARAMS V1.0 D 5-NOV-1988 15:33:06
DIRECT V1.0 D 5-NOV-1988 15:33:06
End of directory
Task Name? params
Copyright 1988 Digital Equipment Corporation
PARAMS> SHO NODENAME
Parameter
Current
Default
Type
Radix
--------- ---------------- ---------------- -------- ----NODENAME
R3YBNE
RF71
String Ascii B
PARAMS> SET NODENAME DATADISK
PARAMS> WRITE

!This command writes the change
!to EEPROM.
Changes require controller initialization, ok? [Y/(N)] Y
Stopping DUP server...
>>> SHO DSSI
DSSI Node 0 (MDC)
-DIA0 (RF71)
DSSI Node 1 (DATADISK)
-DIA1 (RF71)
DSSI Node 7 (*)

2–4 Installation and Configuration

!The node name has changed from
!R3YBNE to DATADISK.

Installation and Configuration
2.3 Mass Storage Configuration
2.3.2 Changing the DSSI Unit Number
By default, the ISE drive assigns the disk’s unit number to the same value as the
DSSI node address for that drive.
Example 2–2 shows how to change the unit number of a DSSI device. This
example changes the unit number for the RF71 drive at DSSI node address
1 from 1 to 50 (decimal). You must change two parameters: UNITNUM and
FORCEUNI. Changing these parameters overrides the default, which assigns the
unit number the same value as the node address.

Example 2–2 Changing a DSSI Unit Number
>>> SHO DSSI
DSSI Node 0 (MDC)
-DIA0 (RF71)
DSSI Node 1 (R3QJNE)
-DIA1 (RF71)

!The unit number for this drive will be
!changed from 1 to 50 (DIA1 to DIA50).

DSSI Node 7 (*)
>>>
>>> SET HOST/DUP/DSSI 1
Starting DUP server...
Copyright 1988 Digital Equipment Corporation
DRVEXR V1.0 D 5-NOV-1988 15:33:06
DRVTST V1.0 D 5-NOV-1988 15:33:06
HISTRY V1.0 D 5-NOV-1988 15:33:06
ERASE V1.0 D 5-NOV-1988 15:33:06
PARAMS V1.0 D 5-NOV-1988 15:33:06
DIRECT V1.0 D 5-NOV-1988 15:33:06
End of directory
Task Name? PARAMS
Copyright 1988 Digital Equipment Corporation
PARAMS> SHO UNITNUM
Parameter
Current
Default
Type
Radix
--------- ---------------- ---------------- -------- ----UNITNUM
0
0
Word
Dec U
PARAMS> SHO FORCEUNI
Parameter
Current
Default
Type
Radix
--------- ---------------- ---------------- -------- ----FORCEUNI
1
1 Boolean
0/1 U
PARAMS> SET UNITNUM 50
PARAMS> SET FORCEUNI 0
PARAMS> WRITE

!This command writes the changes to EEPROM.

PARAMS> EX
Exiting...
Task Name?
Stopping DUP server...
>>>
>>>SHO DSSI
DSSI Node 0 (MDC)
-DIA0 (RF71)
(continued on next page)

Installation and Configuration 2–5

Installation and Configuration
2.3 Mass Storage Configuration
Example 2–2 (Cont.) Changing a DSSI Unit Number
DSSI Node 1 (R3QJNE)
-DIA50 (RF71)

!The unit number has changed
!and the node ID remains at 1.

DSSI Node 7 (*)

2.3.3 Accessing RF-series Firmware in VMS Through DUP
You can also access the RF-series ISE firmware utilities from the VMS operating
system as well as through the console commands.
Use the VMS operating system to access the ISE firmware if you want to look
up or view parameter settings, but not change them. To change ISE parameter
settings, enter the ISE firmware through the console I/O mode SET HOST/DUP
command.
Load the FYDRIVER using the following commands in SYSGEN:
$ MCR SYSGEN
SYSGEN> LOAD FYDRIVER/NOADAPTER
SYSGEN> CONNECT FYA0/NOADAPTER
SYSGEN> EXIT
$
You can then access the ISE firmware utilities by using the following VMS
command:
$ SET HOST/DUP/SERVER=MSCP$DUP/TASK=PARAMS nodename
2.3.3.1 Allocation Class
When a KA680 system containing ISEs is configured in a cluster, either as a boot
node or a satellite node, you must assign the allocation class in VMS SYSGEN
and for the ISE matching nonzero values. To change the allocation class of the
ISE, use the following commands:
>>> SET HOST/DUP/DSSI <DSSI node number> PARAMS
Starting DUP server..
PARAMS> SET ALLCLASS <allocation class value>
PARAMS> WRITE
Changes require controller initialization, ok? [Y/N] Y
Stopping DUP server..
>>>

2–6 Installation and Configuration

Installation and Configuration
2.4 DSSI Cabling, Device Identity, and Bus Termination

2.4 DSSI Cabling, Device Identity, and Bus Termination
The ISEs in one particular BA440 enclosure are connected to the system
backplane and communicate internally over the backplane. There are no internal
DSSI cables. Externally, a 50-pin cable connects the DSSI bus to other devices,
either hosts or expanders.
There are two DSSI ports in the KA680 system. One DSSI port is routed along
the backplane and exits the enclosure at the left edge from a connector near the
ISE slots. The other DSSI port is configured by means of the DSSI connector on
the H3604 panel. If unused, DSSI connectors must be terminated.
There is no terminator on the KA680. The near-end termination is contained
on the backplane for the internal DSSI bus, and is provided by the pluggable
connectors for the external bus.
All DSSI devices on the same bus must have unique identifiers. On the face
of the H3604 console module, you can see the two DSSI bus node ID plugs
(Figure 1–5). These ID plugs provide an identity for each DSSI bus. Because the
DSSI controllers implemented by the SHAC chips on the KA680 CPU module are
separate, the two ID plugs may be identical.

2.5 KA680 Connectors
The KA680 CPU module uses two connectors, J1 and J2. J1 is a 270-pin
connector that mates with the backplane. J2 is the connector for the 100-pin
ribbon cable that goes to the console module. Users configure the KA680 through
the H3604 console module. Figure 1–3 shows the location of the connectors on
the KA680 module.

Installation and Configuration 2–7

3
Central Processor
The central processor of the KA680 supports the MicroVAX chip subset (plus six
additional string instructions) of the VAX instruction set, and datatypes and full
VAX memory management. It is implemented with a single VLSI chip called the
NVAX (DC246).

3.1 Processor State
The processor state consists of that portion of the state of a process stored in
processor registers rather than in memory. The processor state is composed of
sixteen general-purpose registers (GPRs), the processor status longword (PSL),
and the internal processor registers (IPRs).
Nonprivileged software can access the GPRs and the processor status word (bits
<15:00> of the PSL). The IPRs and bits <31:16> of the PSL can only be accessed
by privileged software. The IPRs are explicitly accessible only by the move to
processor register (MTPR) and move from processor register (MFPR) instructions,
which can be executed only while running in kernel mode.

3.1.1 General-Purpose Registers
The KA680 implements 16 general-purpose registers. as implemented per the
VAX Architecture Reference Manual These registers are used for temporary
storage, accumulators, and base and index registers for addressing. These
registers are denoted R0—R15. The bits of a register are numbered from the
right <0> through <31>. Figure 3–1 shows the general-purpose register format.
Table 3–1 describes the registers.

Figure 3–1 General-Purpose Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

LJ-01323-TI0

Some of these registers have been assigned special meaning by the VAX–11
architecture:

Central Processor 3–1

Central Processor
3.1 Processor State
Table 3–1 General-Purpose Register Description
Register

Mnemonic

Description

R15

Program Counter

The PC contains the address
of the next instruction byte
of the program.

R14

Stack Pointer

The SP contains the address
of the top of the processor
defined stack.

R13

Frame Pointer

The VAX–11 procedure call
convention builds a data
structure on the stack called
a stack frame. The FP
contains the address of the
base of this data structure.

R12

Argument Pointer

The VAX–11 procedure
call convention uses a
data structure called an
argument. The AP contains
the address of the base of
this data structure.

Consult the VAX Architecture Reference Manual for more information on the
operation and use of these registers.

3.1.2 Processor Status Longword
The KA680 processor status longword (PSL) is implemented per the VAX
Architecture Reference Manual, which should be consulted for a detailed
description of the operation of this register. The PSL is saved on the stack
when an exception or interrupt occurs and is saved in the process control
block (PCB) on a process context switch. Bits <15:00> may be accessed by
nonprivileged software, while bits <31:16> may only be accessed by privileged
software. Processor initialization sets the PSL to 041F 000016 . Figure 3–2 shows
the processor status longword format. Table 3–2 lists the bits and definitions.

Figure 3–2 Processor Status Longword

31 30 29 28 27 26 25 24 23 22 21 20
Cur
Mod

MBZ

IPL

MBZ

FPD
TP

PRV
Mod

08 07 06 05 04 03 02 01 00

16 15
MBZ

N Z

DV
FU

LJ-01245-TI0

3–2 Central Processor

Central Processor
3.1 Processor State

Note
VAX Compatibility Mode instructions can be emulated by macrocode, but
the emulation software runs in native mode, so the CM bit is never set.

Table 3–2 explains the properties of each internal process register:
Table 3–2 Internal Process Register Definitions
PSL Data
Bit

Name

Definition

<31>

Compatibility Mode. This bit always reads as zero, loading a one
into this bit is a NOP.

<30>

Trace Pending.

<29:28>

MBZ

Must Be written as Zero.

<27>

FPD

First Part Done.

<26>

Interrupt Stack.

<25:24>

CUR

Current Mode.

<23:22>

PRV

Previous Mode.

<21>

MBZ

Must Be written as Zero.

<20:16>

IPL

Interrupt Priority Level.

<15:8>

MBZ

Must Be written as Zero.

<7>

Decimal Overflow trap enable. This read/write bit has no effect
on KA680 hardware; it can be used by macrocode that emulates
VAX decimal instructions.

<6>

Floating Underflow fault enable.

<5>

Integer Overflow trap enable.

<4>

Trace trap enable.

<3>

Negative condition code.

<2>

Zero condition code.

<1>

Overflow condition code.

<0>

Carry condition code.

3.1.3 Internal Processor Registers
The processor registers that are implemented by the NVAX CPU chip, and those
that are required of the system environment, are logically divided into five
groups, as follows:
•

Normal—Those IPRs that address individual registers in the NVAX CPU chip
or system environment.

•

Bcache tag IPRs—The read/write block of IPRs that allow direct access to the
Bcache tags.

•

Bcache deallocate IPRs—The write-only block of IPRs by which a Bcache
block may be deallocated.

•

Pcache tag IPRs—The read/write block of IPRs that allow direct access to the
Pcache tags.

Central Processor 3–3

Central Processor
3.1 Processor State
•

Pcache data parity IPRs—The read/write block of IPRs that allow direct
access to the Pcache data parity bits.

Each group of IPRs is distinguished by a particular pattern of bits in the IPR
address, as shown in Figure 3–3.
Figure 3–3 IPR Address Space Decoding
Normal IPR Address

SBZ

08 07

25 24 23

IPR Number

SBZ

Bcache Tag IPR Address
05 04

25 24 23 22 21 20 19 18 17 16

31
SBZ

X 0

00
SBZ

Bcache Tag Index

Bcache Deallocate IPR Address
05 04

25 24 23 22 21 20 19 18 17 16

31
SBZ

0 1

Bcache Tag Deallocate Index

00
SBZ

Pcache Tag IPR Address

SBZ

05 04

13 12 11

25 24 23 22 21

SBZ

00
SBZ

Pcache Tag Index

Pcache Set Select (0=Left, L=Right)

Pcache Data Parity IPR Address
13 12 11 10

25 24 23 22 21

31
SBZ

1 1

SBZ

05 04 03 02

Pcache Tag Index

00
SBZ

Sublock Select
Pcache Set Select (0=Left, L=Right)
LJ-01246-TI0

3–4 Central Processor

Central Processor
3.1 Processor State
The numeric range for each of the four groups is shown in Table 3–3.
Table 3–3 IPR Address Space Decoding
IPR Group

Mnemonic1

IPR Address Range
(hex)

Normal

–

00000000..000000FF2 256 individual IPRs

Bcache Tag

BCTAG

01000000..0107FFE02 16K Bcache tag IPRs, each
separated by 20(hex) from the
previous one

Bcache Deallocate

BCFLUSH

01400000..0147FFE02 16K Bcache tag deallocate
IPRs, each separated by
20(hex) from the previous
one

Pcache Tag

PCTAG

01800000..01801FE02 256 Pcache tag IPRs, 128
for each Pcache set, each
separated by 20(hex) from the
previous one

Pcache Data Parity

PCDAP

01C00000..01C01FF82 1024 Pcache data parity IPRs,
512 for each Pcache set, each
separated by 8(hex) from the
previous one

1
2

Contents

The mnemonic is for the first IPR in the block.

Unused fields in the IPR addresses for these groups should be zero. Neither hardware nor microcode
detects and faults on an address in which these bits are nonzero. Although noncontiguous address
ranges are shown for these groups, the entire IPR address space maps into one of these groups. If
these fields are nonzero, the operation of the CPU is UNDEFINED.

Note
The address ranges shown above are those used by the programmer.
When processing normal IPRs, the microcode shifts the IPR number left
by 2 bits for use as an IPR command address. This positions the IPR
number to bits <9:2> and modifies the address range as seen by the
hardware to 0..3FC, with bits <1:0>=00. No shifting is performed for the
other groups of IPR addresses.

Because of the sparse addressing used for IPRs in groups other than the normal
group, valid IPR addresses are not separated by one. Rather, valid IPR addresses
are separated by either 8 or 20(hex). For example, the IPR address for Bcache tag
0 is 01000000 (hex), and the IPR address for Bcache tag 1 is 01000020 (hex). In
this group, bits <4:0> of the IPR address are ignored, so IPR numbers 01000001
through 0100001F all address Bcache tag 0. Similarly, the IPR address for the
first subblock of Pcache data parity is 01C00000 (hex), and the IPR address for
the second subblock of Pcache data parity is 01C00008 (hex).
Processor registers in all groups except the normal group are processed entirely
by the NVAX CPU chip and will never appear on the NDAL (Section 3.11). This
is also true for a number of the IPRs in the normal group. IPRs in the normal
group that are not processed by the NVAX CPU chip are converted into I/O space
references and passed to the system environment via a read or write command on
the NDAL.

Central Processor 3–5

Central Processor
3.1 Processor State
Each of the 256 possible IPRs in the normal group are of longword length, so a
1 KB block of I/O space is required to convert each possible IPR to a unique I/O
space longword. This block starts at address E1000000 (hex). Conversion of an
IPR address to an I/O space address in this block is done by shifting the IPR
address left into bits <9:2>, filling bits <1:0> with zeros, and merging in the base
address of the block. This can be expressed by the equation

"!$#% '&)(*

The actual hardware implementation of this is different in that the IPR number
is shifted left by 2 bits, and bits <31:29,24> are set. There is no multiplying or
adding done as one might conclude from the equation.
Because many of the 256 possible IPRs in the normal group are processed entirely
by the NVAX CPU chip, the corresponding I/O space location in the 1 KB block is
never referenced as a result of an MTPR/MFPR to or from these IPRs. However,
note that a programmer can indeed reference these locations via an explicit
I/O space reference (for example, MOVL). References to this block of I/O space
locations with instructions other than MTPR/MFPR may result in UNDEFINED
behavior.
The processor registers implemented by the NVAX CPU are shown in Table 3–4.
Note
Many of the processor registers listed in Table 3–4 are used internally
by the microcode during normal operation of the CPU, and are not
intended to be referenced by software except during test or diagnosis of
the system. These registers are flagged with the notation ‘‘Testability
and diagnostic use only; not for software use in normal operation.’’
References by software to these registers during normal operation can
cause UNDEFINED behavior of the CPU.

3–6 Central Processor

Central Processor
3.1 Processor State
Table 3–4 Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

Kernel Stack Pointer

KSP

NVAX 1-1

–

Executive Stack Pointer

ESP

NVAX 1-1

–

Supervisor Stack Pointer

SSP

NVAX 1-1

–

User Stack Pointer

USP

NVAX 1-1

–

Interrupt Stack Pointer

ISP

NVAX 1-1

–

Reserved

–

E1000014

Reserved

–

E1000018

Reserved

–

E100001C

P0 Base Register

P0BR

NVAX 1-2

–

P0 Length Register

P0LR

NVAX 1-2

–

P1 Base Register

P1BR

NVAX 1-2

–

P1 Length Register

P1LR

NVAX 1-2

–

System Base Register

SBR

NVAX 1-2

–

System Length Register

SLR

NVAX 1-2

–

CPU Identification

CPUID

NVAX 2-1

–

Reserved

–

E100003C

Process Control Block Base

PCBB

NVAX 1-1

–

System Control Block Base

SCBB

NVAX 1-1

–

I/O Address

Type:
R = Read-only register
RW = Read/write register
W = Write-only register
Impl(emented):
NVAX = Implemented in the NVAX CPU chip
System = Implemented in the system environment
Vector = Implemented in the optional vector unit or its NDAL interface
Cat(egory), class-subclass, where:
class is one of:
1 = Implemented per DEC Standard 032
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation
3 = Not implemented internally; converted to I/O space read or write and passed to system environment
subclass is one of:
1 = Processed as appropriate by Ebox microcode
2 = Converted to Mbox IPR number and processed via internal IPR command
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3
5 = Processed by internal IPR command
6 = May be block decoded; reference causes UNDEFINED behavior
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU
chip
8 = Converted to MFVP MSYNC

(continued on next page)

Central Processor 3–7

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl
1

Interrupt Priority Level

IPL

Cat

I/O Address

NVAX 1-1

–

AST Level

ASTLVL

NVAX 1-1

–

Software Interrupt Request Register

SIRR

NVAX 1-1

–

Software Interrupt Summary Register

SISR

NVAX 1-1

–

Reserved

–

E1000058

Reserved

–

E100005C

Interval Counter Control/Status

ICCS

NCA

2-7

E1000060

Next Interval Count

NICR

NCA

3-7

E1000064

Interval Count

ICR

NCA

3-7

E1000068

Time of Year Register

TODR

SSC

2-3

E100006C

Console Storage Receiver Status

CSRS

SSC

2-3

E1000070

Console Storage Receiver Data

CSRD

SSC

2-3

E1000074

Initialized on reset

(continued on next page)

3–8 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Console Storage Transmitter Status

CSTS

SSC

2-3

E1000078

Console Storage Transmitter Data

CSTD

SSC

2-3

E100007C

Console Receiver Control/Status

RXCS

SSC

2-3

E1000080

Console Receiver Data Buffer

RXDB

SSC

2-3

E1000084

Console Transmitter Control/Status

TXCS

SSC

2-3

E1000088

Console Transmitter Data Buffer

TXDB

SSC

2-3

E100008C

Reserved

–

E1000090

Reserved

–

E1000094

Machine Check Error Register

MCESR

NVAX 2-1

–

Reserved

–

E100009C

Reserved

–

E10000A0

Reserved

–

E10000A4

Console Saved PC

SAVPC

NVAX 2-1

–

Console Saved PSL

SAVPSL

NVAX 2-1

–

(continued on next page)

Central Processor 3–9

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

Reserved

–

Reserved

–

Reserved

–

Reserved

–

E10000B0

–

E10000B4

–

E10000B8

–

E10000BC

–

E10000C0

Reserved

–

E10000C4

Reserved

–

E10000C8

Reserved

–

E10000CC

Reserved

–

E10000D0

Reserved

–

E10000D4

Reserved

–

E10000D8

IORESET 55

SSC

2-3

E10000DC

MAPEN

NVAX 1-2

–

Translation Buffer Invalidate All

TBIA

NVAX 1-1

–

Translation Buffer Invalidate Single3

TBIS

NVAX 1-1

–

Reserved

–

E10000EC

Reserved

–

E10000F0

I/O System Reset Register
13

Memory Management Enable

1
3

Initialized on reset
Change broadcast to vector unit if present

(continued on next page)

3–10 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

System Identification

SID

Translation Buffer Check

TBCHK

IPL 14 Interrupt ACK5

IAK14

IAK15

IAK16

IPL 17 Interrupt ACK

IAK17

Clear Write Buffer5

CWB

Reserved

–

NVAX 1-1

–

SSC

2-3

E1000100

SSC

2-3

E1000104

SSC

2-3

E1000108

SSC

2-3

E100010C

SSC

2-3

E1000110

–

E1000114

Reserved

–

E1000118

Reserved

–

E100011C

IPL 16 Interrupt ACK

I/O Address

NVAX 1-1

IPL 15 Interrupt ACK

Cat

Testability and diagnostic use only; not for software use in normal operation

(continued on next page)

Central Processor 3–11

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

Reserved

–

Reserved

–

Reserved

–

Reserved

–

E1000120

–

E1000124

–

E1000128

–

E100012C

–

E1000130

Reserved

–

E1000134

Reserved

–

E1000138

Reserved

–

E100013C

Reserved

–

E1000140

Reserved

–

E1000144

Reserved

–

E1000148

Reserved

–

E100014C

Reserved

–

E1000150

Reserved

–

E1000154

(continued on next page)

3–12 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

E1000158

Reserved

–

E100015C

Reserved

–

E1000160

Reserved

–

E1000164

Reserved

–

E1000168

Reserved

–

E100016C

Reserved

–

E1000170

Reserved

–

E1000174

Reserved

–

E1000178

Reserved

–

E100017C

Reserved

–

E1000180

Reserved

–

E1000184

Reserved

–

E1000188

Reserved

–

E100018C

(continued on next page)

Central Processor 3–13

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved for VM

–

100

–

E1000190

Reserved for VM

–

101

–

E1000194

Reserved for VM

–

102

–

E1000198

Reserved

–

103

–

E100019C

Reserved

–

104

–

E10001A0

Reserved

–

105

–

E10001A4

Reserved

–

106

–

E10001A8

Reserved

–

107

–

E10001AC

Reserved

–

108

–

E10001B0

Reserved

–

109

–

E10001B4

Reserved

–

110

–

E10001B8

Reserved

–

111

–

E10001BC

Reserved

–

112

–

E10001C0

Reserved

–

113

–

E10001C4

Reserved

–

114

–

E10001C8

Reserved

–

115

–

E10001CC

Reserved

–

116

–

E10001D0

Reserved

–

117

–

E10001D4

(continued on next page)

3–14 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

118

–

E10001D8

Reserved

–

119

–

E10001DC

Reserved

–

120

–

E10001E0

Reserved

–

121

–

E10001E4

Interrupt System Status Register

INTSYS

122

NVAX 2-1

–

Performance Monitoring Facility Count

PMFCNT 123

NVAX 2-1

–

Patchable Control Store Control Register

PCSCR

124

NVAX 2-1

–

Ebox Control Register

ECR

125

NVAX 2-1

–

MTBTAG 126

NVAX 2-1

–

Mbox TB PTE Fill

MTBPTE 127

NVAX 2-1

–

Cbox Control Register

CCTL

160

NVAX 2-5

–

Reserved

–

161

–

NVAX 2-6

–

Bcache Data ECC

BCDECC 162

NVAX 2-5

–

Mbox TB Tag Fill

Bcache Error Tag Status

BCETSTS 163

NVAX 2-5

–

Bcache Error Tag Index

BCETIDX 164

NVAX 2-5

–

Testability and diagnostic use only; not for software use in normal operation

(continued on next page)

Central Processor 3–15

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Bcache Error Tag

BCETAG 165

Bcache Error Data Status

BCEDSTS 166

Bcache Error Data Index

BCEDIDX 167

Bcache Error ECC

BCEDECC 168

Reserved

–

169

Cat

I/O Address

NVAX 2-5

–

NVAX 2-5

–

NVAX 2-5

–

NVAX 2-5

–

NVAX 2-6

–

Reserved

–

170

–

NVAX 2-6

–

Fill Error Address

CEFADR 171

NVAX 2-5

–

Fill Error Status

CEFSTS

172

NVAX 2-5

–

Reserved

–

173

–

NVAX 2-6

–

NDAL Error Status

NESTS

174

NVAX 2-5

–

Reserved

–

175

–

NVAX 2-6

–

NDAL Error Output Address

NEOADR 176

NVAX 2-5

–

Reserved

–

NVAX 2-6

–

NDAL Error Output Command

NEOCMD 178

NVAX 2-5

–

Reserved

–

NVAX 2-6

–

177
179

(continued on next page)

3–16 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

NDAL Error Data High

NEDATHI 180

NVAX 2-5

–

Reserved

–

181

–

NVAX 2-6

–

NDAL Error Data Low

NEDATLO 182

NVAX 2-5

–

Reserved

–

183

–

NVAX 2-6

–

NDAL Error Input Command

NEICMD 184

NVAX 2-5

–

Reserved

–

185

–

NVAX 2-6

–

Reserved

–

186

–

NVAX 2-6

–

Reserved

–

187

–

NVAX 2-6

–

Reserved

–

188

–

NVAX 2-6

–

Reserved

–

189

–

NVAX 2-6

–

Reserved

–

190

–

NVAX 2-6

–

Reserved

–

191

–

NVAX 2-6

–

Reserved

–

192

–

E1000300

Reserved

–

193

–

E1000304

Reserved

–

194

–

E1000308

Reserved

–

195

–

E100030C

(continued on next page)

Central Processor 3–17

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

196

–

E1000310

Reserved

–

197

–

E1000314

Reserved

–

198

–

E1000318

Reserved

–

199

–

E100031C

Reserved

–

200

–

E1000320

Reserved

–

201

–

E1000324

Reserved

–

202

–

E1000328

Reserved

–

203

–

E100032C

Reserved

–

204

–

E1000330

Reserved

–

205

–

E1000334

Reserved

–

206

–

E1000338

Reserved

–

207

–

E100033C

VIC Memory Address Register

VMAR

208

NVAX 2-5

–

VIC Tag Register

VTAG

209

NVAX 2-5

–

VIC Data Register

VDATA

210

NVAX 2-5

–

Ibox Control and Status Register

ICSR

211

NVAX 2-5

–

(continued on next page)

3–18 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl
5

Cat

I/O Address

Ibox Branch Prediction Control Register

BPCR

212

NVAX 2-5

–

Reserved

–

213

–

NVAX 2-6

–

Ibox Backup PC5

BPC

214

NVAX 2-5

–

Ibox Backup PC with RLOG Unwind

BPCUNW 215

NVAX 2-5

–

Reserved

–

216

–

NVAX 2-6

–

Reserved

–

217

–

NVAX 2-6

–

Reserved

–

218

–

NVAX 2-6

–

Reserved

–

219

–

NVAX 2-6

–

Reserved

–

220

–

NVAX 2-6

–

Reserved

–

221

–

NVAX 2-6

–

Reserved

–

222

–

NVAX 2-6

–

Reserved

–

223

–

NVAX 2-6

–

Testability and diagnostic use only; not for software use in normal operation

(continued on next page)

Central Processor 3–19

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Mbox P0 Base Register5

MP0BR

224

NVAX 2-5

–

Mbox P0 Length Register5

MP0LR

225

NVAX 2-5

–

MP1BR

226

NVAX 2-5

–

MP1LR

227

NVAX 2-5

–

Mbox System Base Register

MSBR

228

NVAX 2-5

–

Mbox System Length Register5

MSLR

229

NVAX 2-5

–

MMAPEN 230

NVAX 2-5

–

Mbox Physical Address Mode

PAMODE 231

NVAX 2-5

–

Mbox MME Address

MMEADR 232

NVAX 2-5

–

Mbox MME PTE Address

MMEPTE 233

NVAX 2-5

–

Mbox MME Status

MMESTS 234

NVAX 2-5

–

Mbox P1 Base Register

Mbox P1 Length Register

Mbox Memory Management Enable

Cat

I/O Address

Testability and diagnostic use only; not for software use in normal operation

(continued on next page)

3–20 Central Processor

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

235

–

NVAX 2-6

–

Mbox TB Parity Address

TBADR

236

NVAX 2-5

–

Mbox TB Parity Status

TBSTS

237

NVAX 2-5

–

Reserved

–

238

–

NVAX 2-6

–

Reserved

–

239

–

NVAX 2-6

–

Reserved

–

240

–

NVAX 2-6

–

Reserved

–

241

–

NVAX 2-6

–

Mbox Pcache Parity Address

PCADR

242

NVAX 2-5

–

Reserved

–

243

–

NVAX 2-6

–

Mbox Pcache Status

PCSTS

244

NVAX 2-5

–

Reserved

–

245

–

NVAX 2-6

–

(continued on next page)

Central Processor 3–21

Central Processor
3.1 Processor State
Table 3–4 (Cont.) Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

I/O Address

Reserved

–

246

–

NVAX 2-6

Reserved

–

247

–

NVAX 2-6

–

Mbox Pcache Control

PCCTL

248

NVAX 2-5

–

Reserved

–

249

–

NVAX 2-6

–

Reserved

–

250

–

NVAX 2-6

–

Reserved

–

251

–

NVAX 2-6

–

Reserved

–

252

–

NVAX 2-6

–

Reserved

–

253

–

NVAX 2-6

–

Reserved

–

254

–

NVAX 2-6

–

Reserved

–

255

–

NVAX 2-6

–

Unimplemented

–

100–

–

01000000– –

–

00FFFFFF
See Table 3–3

–

FFFFFFFF
Type:
R = Read-only register
RW = Read/write register
W = Write-only register
Impl(emented):
NVAX = Implemented in the NVAX CPU chip
System = Implemented in the system environment
Vector = Implemented in the optional vector unit or its NDAL interface
Cat(egory), class-subclass, where:
class is one of:
1 = Implemented per DEC Standard 032
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation
3 = Not implemented internally; converted to I/O space read or write and passed to system environment
subclass is one of:
1 = Processed as appropriate by Ebox microcode
2 = Converted to Mbox IPR number and processed via internal IPR command
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3
5 = Processed by internal IPR command
6 = May be block decoded; reference causes UNDEFINED behavior
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU
chip
8 = Converted to MFVP MSYNC

3–22 Central Processor

Central Processor
3.2 Process Structure

3.2 Process Structure
A process is a single thread of execution. The context of the current process is
contained in the process control block (PCB), which is pointed to by the process
control block base register (PCBB). The KA680 implements these structures as
defined in VAX Architecture Reference Manual, which should be referenced for a
description of the PCB and the PCBB.

3.3 Data Types
The KA680 CPU supports the following subset of the VAX data types: The central
processor provides the following subset of the VAX data types:
Byte

Word

Longword

Quadword

Character string

Variable-length bit field

F-floating

G-floating

D-floating

Support for the remaining VAX data types can be provided via macrocode
emulation.

3.4 Instruction Set
The KA680 CPU implements the following subset of the VAX instruction set types
in microcode.
Integer arithmetic and logical

Address

Variable length bit field

Control

Procedure call

Miscellaneous

Operating system support

F_floating

G_floating

D_floating

Queue

Character string
MOVC3
MOVC5
CMPC3 (See Note)
CMPC5 (See Note)
LOCC (See Note)
SCANC (See Note)
SKPC (See Note)
SPANC (See Note)

Note
* These instructions were in the microcode-assisted category on the
KA630-A (MicroVAX II), and therefore had to be emulated.

Central Processor 3–23

Central Processor
3.4 Instruction Set
The NVAX CPU provides special microcode assistance to aid the macrocode
emulation of the following instruction groups:
•

Decimal string

•

CRC

•

EDITPC

The following instruction groups are not implemented, but may be emulated by
macrocode:
•

Octaword

•

Compatibility mode instructions

Appendix H lists the entire KA680 instruction set, indicating which instructions
have microcode assists to speed up macrocode emulation.

3.5 Memory Management
The KA680 implements full VAX Memory Management as defined in the VAX
Architecture Reference Manual. System space addresses are virtually mapped
through single-level page tables, and process space addresses are virtually
mapped through two-level page tables. See the VAX Architecture Reference
Manual for descriptions of the virtual-to-physical address translation process, and
the format for VAX page table entries (PTEs).

3.5.1 Translation Buffer
To reduce the overhead associated with translating virtual addresses to physical
addresses, the NVAX CPU chip employs a 96-entry, fully associative, translation
buffer (TB) for caching VAX PTEs. Each entry can store a PTE for translating
virtual addresses in either the VAX process space, or VAX system space. The
translation buffer is flushed whenever the following actions are performed:
•

Memory management is enabled or disabled [for example, by writes to IPR 56
(MAPEN)].

•

Any page table base or length registers are modified (for example, by writes
to IPRs 8 to 13).

•

Writing to IPR 57 (TBIA).

In addition, individual TB entries may be flushed by writing to IPR 58 (TBIS).
Each entry in the translation buffer is divided into two parts: a 24-bit tag
register and a 27-bit PTE register. The tag register is used to store the virtual
page number (VPN) of the virtual page that the corresponding PTE register
maps, and a valid bit (TB.V) indicating that the tag contains a valid VPN. The
PTE register stores the 21-bit PFN field, the PTE.V bit, the PTE.M bit, and the
4-bit PROT field from the corresponding VAX PTE.
When MAPEN bit is set in the MAPEN IPR (IPR 56), memory management
is enabled and the CPU will perform VAX memory translation from virtual
addresses to physical addresses. The translation buffer is the mechanism by
which the NVAX performs quick virtual-to-physical address translations.

3–24 Central Processor

Central Processor
3.5 Memory Management
Figure 3–4 shows the format of a page table entry and a TB entry.
Figure 3–4 PTE and TB Format
Page Table Entry
31 30
Prot

27 26 25 24
Physical Page Frame Address

M S

Where: V = Valid Bit
Prot = Authorized Access Modes
M = Modify Bit
S = Reserved Bit

TB Entry
54 53 52 51

29 28
Tag

25 24 23 22
Prot

TP_BAR
TBV

00
PFN

TP
Where: = TB Entry Valid Bit
TP =
Even Tag Parity Bit
TP_BAR = Compement of TP
Tag =
Virtual Address<31:9>
Prot =
Authorized Access Modes
M=
Modify Bit
DP =
Even Parity for Validated PTE Field
PFN =
Physical Page Frame Address

LJ-01247-TI0

Note that the TB entry stores all but three bits of the PTE field. The TB entry
does not store the S bit because it is not used, and the TB entry does not store the
upper two bits of the PTE PFN because these bits correspond to a larger physical
address space than NVAX CPU uses. The tag field stores the virtual page frame
address. The TBV bit indicates whether the corresponding entry is valid. If TBV
is set, then PTE<31> is valid because the TB only caches PTEs whose valid bits
are set.
During virtual-to-physical address translation, the contents of the 96 tag registers
are compared with the virtual page number field (bits <31:9>) of the virtual
address of the reference. If there is a match with one of the tag registers, and the
TB.V bit indicates the entry is valid, then a translation buffer "hit" has occurred,
and the contents of the corresponding PTE register are used for the translation.

Central Processor 3–25

Central Processor
3.5 Memory Management
If there is no match, the translation buffer does not contain the necessary VAX
PTE information to translate the address of the reference, and the PTE must be
fetched from memory. Upon fetching the PTE, the translation buffer is updated so
that subsequent references to the same page of memory will hit in the translation
buffer.
TB entries are allocated using an NLU (not-last-used) TB allocation pointer.
The update is achieved by replacing the entry that is selected by the replacement
pointer. The allocation pointer increments in round robin fashion whenever a new
buffer entry is loaded, such as after a TB miss. Because the allocation pointer is
guaranteed not to point to the last entry referenced, this scheme implements a
not-last-used allocation scheme.
The associativity of each TB entry is implemented by the use of comparators on
the TBV and tag fields. When a virtual address is to be translated, each TB tag
comparator, whose corresponding TBV bit is set, looks for a match between the
virtual page frame address and its corresponding tag. If no comparator finds
a match, a "TB miss" condition has occurred in that no TB entry contains a
translation for the specified address.
If one of the entries detects a match ("TB hit"), the PFN, PROT, and M fields of
the corresponding TB entry are read out of the TB and are used to complete the
address translation.
The PROT, and M fields, which are accessed along with the PFN, are used by
the memory management exception detection logic to determine ACV and M=0
conditions.
TB entries can be invalidated in the following ways:
•

An entry can be invalidated by being displaced from the TB by allocation of
another PTE to the same TB entry.

•

An entry can be invalidated by writing to the TBIS IPR (IPR 58). If the
specified TBIS virtual address matches a TB tag, the TBV bit corresponding
to the matched tag is cleared. Clearing the TBV bit invalidates the TB entry.

•

All entries can be invalidated by writing to the TBIA IPR (IPR 57). This
command resets the TBV bit of every TB entry.

3.5.2 30-bit to 32-bit Physical Address Translations
When PAMODE=0, such as is mandatory with the KA680, the NVAX system is
configured such that only 30-bit physical addresses are processed at the program
level. This is done in two ways.
1. When the address translation logic receives a physical address from one of its
reference sources, the mapping is implemented by an address sign extension
scheme involving the upper three address bits. In this scheme, address bits
<31:30> are forced to the state of address<29>.
2. When the virtual/physical address tranlation logic receives a virtual address,
virtual address translation occurs normally without any sign extension of
the resulting physical address. This is possible because the corresponding
sign extension function is preprocessed on the upper three bits of page frame
address, which is written into the TB during the TB tag fill operation.

3–26 Central Processor

Central Processor
3.5 Memory Management
The following two figures show the register format of the TBTAG and TBDATA
IPRs. These two IPRs allow software to directly access the contents of the
translation buffer for diagnostic purposes.
Figure 3–5 Translation Buffer Tag (TBTAG) - IPR 47
00

09 08

31
Virtual Page Number (Write Only)

:TBTAG

MBZ

LJ-01248-TI0

Figure 3–6 Translation Buffer Data (TBDATA) - IPR 59
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
PTE.PFN (Write Only)

MBZ

PTE.M

:TBDATA

(Write Only)

PTE.PROT (Write Only)
PTE.V

(Write Only)
LJ-01249-TI0

Diagnostic software may use IPR 47 (TBTAG) and IPR 59 (TBDATA) to test the
operation of the translation buffer. A write to TBTAG writes bits <31:9> of the
source data into the VPN field of the current tag location and clears the TB.V bit.
A subsequent write to TBDATA interprets the source data as a PTE and writes
PTE.V, PTE.M, PTE.PROT, and PTE.PFN into the current PTE location, sets the
TB.V bit, and increments the NLU pointer.
These registers are provided for diagnostic purposes only and should not be
written during normal operation. Writes to these registers must be done under
very controlled conditions to achieve the desired results. Specifically, the following
restrictions apply:
•

The NLU pointer must be in a known state. A TBIA will initialize the NLU
pointer to the first location in the array.

•

Memory management must be enabled during the use of TBTAG and
TBDATA because writing to MAPEN implicitly does a TBIA and resets
the NLU pointer.

•

Data-stream and instruction-stream references during the use of TBTAG and
TBDATA must not be allowed to change the NLU pointer.
Note
The TBIS, TBIA, TBCHK, TBTAG, and TBDATA IPRs are write-only.
An MFPR instruction used to read any of these registers will cause the
NVAX CPU to initiate a reserved operand fault.

Central Processor 3–27

Central Processor
3.5 Memory Management
3.5.3 Memory Management Control Registers
There are four IPRs that control the memory management unit (MMU):
IPR 56 (MAPEN)
IPR 57 (TBIA)
IPR 58 (TBIS)
IPR 63 (TBCHK)
Memory management can be enabled/disabled via IPR 56 (MAPEN). Writing
0 to this register with an MTPR instruction disables memory management
and writing a 1 to this register with an MTPR instruction enables memory
management. Writes to this register flush the translation buffer. To determine
whether or not memory management is enabled, IPR 56 is read using the MFPR
instruction.
Translation buffer entries that map a particular virtual address can be
invalidated by writing the virtual address to IPR 58 (TBIS) using the MTPR
instruction.
Note
Whenever software changes a valid page table entry for the system or
current process region, or a system page table entry that maps any part
of the current process page table, all process pages mapped by the page
table entry must be invalidated in the translation buffer.

The entire translation buffer can be invalidated by writing a 0 to IPR 57 (TBIA)
using the MTPR instruction.
The translation buffer can be checked to see if it contains a valid translation for
a particular virtual page by writing a virtual address within that page to IPR 63
(TBCHK) using the MTPR instruction. If the translation buffer contains a valid
translation for the page, the condition code V bit (bit<1> of the PSL) is set.
Note
The TBIS, TBIA, and TBCHK IPRs are write-only. The operation of an
MFPR instruction from any of these registers is UNDEFINED.

There are three pairs of base and length registers that specify the base and
length of P0, P1, and S0 space:
•

IPR 8(P0BR) and IPR 9(P0LR)

•

IPR 10(P1BR) and IPR 11(P1LR)

•

IPR 12(SBR) and IPR 13(SLR)

The base and length of the P0, P1, and S0 page tables may be changed by writing
the appropriate address or length to any of the following registers:
IPR 8 (P0BR)
IPR 9 (P0LR)
IPR 10 (P1BR)
IPR 11 (P1LR)
IPR 12 (SBR)
3–28 Central Processor

Central Processor
3.5 Memory Management
IPR 13 (SLR)
Whenever the location or size of the system map is changed by changing the SBR
(IPR 12) or SLR (IPR 13), the entire translation buffer must be cleared. The
NVAX CPU accomplishes this by flushing the TB on any change to SBR, SLR, or
P0BR, P1BR, P0LR, and P1LR.
When a process context is loaded with the LDPCTX instruction, all TB entries
that map process-space pages are automatically cleared. System-space mappings
are preserved.
There are two IPRs that are used by diagnostic software to test the translation
buffer:
IPR 47 (TBTAG) Format shown in Figure 3–5.
IPR 59 (TBDATA) Format shown in Figure 3–6.
For information regarding the use of the V, PROT, and M bit fields, consult the
VAX Architecture Reference Manual.

3.6 Interrupts and Exceptions
Both interrupts and exceptions divert execution from the normal flow of control.
An interrupt is caused by some activity outside the current process and typically
transfers control outside the process (for example, an interrupt from an external
hardware device). An exception is caused by the execution of the current
instruction and is typically handled by the current process (for example, an
arithmetic overflow).

3.6.1 Interrupts
Interrupts can be divided into two classes: nonmaskable and maskable.
Nonmaskable interrupts cause a halt via the hardware halt procedure. The
hardware halt procedure does the following:
•

Saves the PC, PSL, MAPEN<0>, and a halt code in IPRs

•

Raises the processor IPL to 1F

•

Passes control to the resident firmware

The firmware dispatches the interrupt to the appropriate service routine based
on the halt code and hardware event indicators. Nonmaskable interrupts cannot
be blocked by raising the processor IPL, but can be blocked by running out of the
halt protected address space (except those nonmaskable interrupts that generate
a halt code of 3). Nonmaskable interrupts with a halt code of 3 cannot be blocked
because this halt code is generated after a hardware reset.
Maskable interrupts cause the following:
•

The PC and PSL are saved.

•

The processor IPL is raised to the priority level of the interrupt (except
for Q22–bus, mass storage, and network interface interrupts in which the
processor IPL is set to 17, independent of the level at which the interrupt was
received).

•

The interrupt is dispatched to the appropriate service routine through the
system control block (SCB).

Central Processor 3–29

Central Processor
3.6 Interrupts and Exceptions
The various interrupt conditions for the KA680 are listed in Table 3–5 along with
their associated priority levels and SCB offsets. The reader should note that this
table is intended as a quick reference, and may not include all possible causes of
the various interrupts, specifically with regard to error conditions.
Table 3–5 Interrupt Priority Levels
Priority Level

SCB
Offset

Interrupt Condition

Nonmaskable

BDCOK and BPOK negated then asserted on Q22–bus (Powerup)

–

BDCOK negated then asserted while BPOK asserted on Q22–bus
(Powerup)

–

BHALT asserted on Q22–bus

–

BREAK generated by the console device

Unused

–

BPOK negated on Q22–bus

Backup cache addressing errors

–

Backup cache uncorrectable data ECC errors on Bcache read for a
write that hits valid/owned

–

NVAX read timeout or Read Data Error on Oread for a write after
the requested quadword has arrived

–

Illegal length write transaction to memory or I/O

–

Reserved command detected by memory or I/O during write
transaction

–

Pending write times out waiting for disown write

–

Disown write to unowned memory location

–

Main memory NXM errors on writes

–

NDAL parity errors on writes

–

CP-bus NXM/TIMEOUT on a write

–

Q22–bus NXM/NOSACK on a write

–

Q22–bus NOGRANT on a write

–

Uncorrectable memory errors during map read for Q22–bus
address translation

1C:1B

Unused

–

Correctable main memory errors

–

Uncorrectable main memory errors

* These conditions generate a hardware halt procedure with a halt code of 3 (hardware reset).
** These conditions generate a hardware halt procedure with a halt code of 2 (external halt).

(continued on next page)

3–30 Central Processor

Central Processor
3.6 Interrupts and Exceptions
Table 3–5 (Cont.) Interrupt Priority Levels
Priority Level

Interrupt Condition

SCB
Offset

–

Correctable O-bit memory errors

–

Pending read times out waiting for disown write

–

No acknowledgement on returned read data from NMC

–

NDAL data parity errors

–

Primary cache tag or data parity errors

–

Virtual instruction cache tag or data parity errors

–

Backup cache addressing errors

–

Backup cache correctable data ECC errors

–

Backup cache uncorrectable data ECC errors

–

Backup cache correctable tag ECC errors

–

Backup cache uncorrectable data ECC errors

–

Illegal length transaction to memory or I/O space

–

Reserved command to memory or I/O space

–

CP-bus parity errors on I/O read transactions

–

CP-bus ERR_L signal asserted by I/O device during I/O read
transaction

–

CP Bus NXM/TIMEOUTS errors on I/O reads

19:18

Unused

–

BR7 L asserted

Q22–bus
vector
plus
20016

Interval timer interrupt

–

BR6 L asserted

Q22–bus
vector
plus
20016

BR5 L asserted

Q22–bus
vector
plus
20016

* These conditions generate a hardware halt procedure with a halt code of 3 (hardware reset).
** These conditions generate a hardware halt procedure with a halt code of 2 (external halt).

(continued on next page)

Central Processor 3–31

Central Processor
3.6 Interrupts and Exceptions
Table 3–5 (Cont.) Interrupt Priority Levels
Priority Level

Interrupt Condition

SCB
Offset

Console Terminal

F8,FC

–

Programmable Timers

78,7C

–

Mass storage interface one (DSSI port 1)(External)

108

–

Mass storage interface two (DSSI port 2)(Internal)

104

–

Network interface

10C

–

Interprocessor doorbell

204

–

BR4 L asserted

Q22–bus
vector
plus
20016

13:10

Unused

–

0F:01

Software interrupt requests

84-BC

* These conditions generate a hardware halt procedure with a halt code of 3 (hardware reset).
** These conditions generate a hardware halt procedure with a halt code of 2 (external halt).

Note
Because the Q22–bus does not allow differentiation between the four bus
grant levels (for example, a level 7 device could respond to a level 4 bus
grant), the KA680 CPU raises the IPL to 17 after responding to interrupts
generated by the assertion of either BR7_L, BR6_L, BR5_L, or BR4_L.
The KA680 maintains the IPL at the priority of the interrupt for all other
interrupts.

The interrupt system is controlled by three IPRs:
•

IPR 18, the interrupt priority level register (IPLR) (Figure 3–7), is used for
loading the processor priority field in the PSL (bits<20:16>).

•

IPR 20, the software interrupt request register (SIRR) (Figure 3–8), is used
for creating software interrupt requests.

•

IPR 21, the software interrupt summary register (SISR) (Figure 3–9), records
pending software interrupt requests at levels 1 through 15.

The format of these registers is presented in Figure 3–7, Figure 3–8, and
Figure 3–9. Refer to the VAX Architecture Reference Manual for more information
on these registers.

3–32 Central Processor

Central Processor
3.6 Interrupts and Exceptions
Figure 3–7 Interrupt Priority Level Register (IPLR) - IPR 18
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Ignored, Returns 0

PSL<20:16>

:IPLR

LJ-01250-TI0

Figure 3–8 Software Interrupt Request Register (SIRR) - IPL 20
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Ignored

Request

:SIRR

LJ-01251-TI0

Figure 3–9 Software Interrupt Summary Register (SISR) - IPL 21
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
F E

Pending Software Interrupts
D C B A 9 8 7 6 5 4

:SISR

2 1

MBZ
LJ-01252-TI0

3.6.1.1 Power Fail Interrupt
Power fail interrupts are requested to report imminent loss of power to the CPU.
Power fail interrupts are requested via the PWRFL_L pin at IPL 1E (hex) and
are dispatched to the operating system through SCB vector 0C (hex).
The stack frame for a power fail interrupt is shown in Figure 3–10.
Figure 3–10 Power Fail Interrupt Stack Frame
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
PC
PSL

:(SP)

LJ-01317-TI0

Central Processor 3–33

Central Processor
3.6 Interrupts and Exceptions
3.6.1.2 Hard Error Interrupts
Hard error interrupts are requested to report an error that was detected
asynchronously with respect to instruction execution. This results in an interrupt
at IPL 1D (hex) to be dispatched through SCB vector 60 (hex). Typically, these
errors indicate that machine state has been corrupted and that retry is not
possible.
The stack frame for a hard error interrupt is shown in Figure 3–11.
Figure 3–11 Hard Error Interrupt Stack Frame
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
:(SP)

PC
PSL

LJ-01317-TI0

3.6.1.3 Soft Error Interrupts
Soft error interrupts are requested to report errors that were detected, but did
not affect instruction execution. This results in an interrupt at IPL 1A (hex) to be
dispatched through SCB vector 54 (hex).
The stack frame for a soft error interrupt is shown in Figure 3–12.
Figure 3–12 Soft Error Interrupt Stack Frame
00

:(SP)

PC
PSL

LJ-01253-TI0

3.7 Exceptions
The VAX architecture recognizes six classes of exceptions. Table 3–6 lists instances of exceptions
in each class.
Table 3–6 Exception Classes
Exception Class

Instances

Arithmetic traps/faults

Integer overflow trap
Integer divide-by-zero trap
Subscript range trap
Floating overflow fault
Floating divide-by-zero fault
Floating underflow fault
(continued on next page)

3–34 Central Processor

Central Processor
3.7 Exceptions
Table 3–6 (Cont.) Exception Classes
Exception Class

Instances

Memory management exceptions

Access control violation fault
Translation not valid fault
M=0 fault

Operand reference exceptions

Reserved addressing mode fault
Reserved operand fault or abort

Instruction execution exceptions

Reserved/privileged instruction fault
Emulated instruction faults
XFC fault
Change-mode trap
Breakpoint fault
Vector disabled fault

Tracing exceptions

Trace fault

System failure exceptions

Kernel-stack-not-valid abort
Interrupt-stack-not-valid halt
Console error halt
Machine check abort

A trap is an exception occuring at the end of the instruction that caused the
exception. Therefore, the PC saved on the stack is the address of the next
instruction that would normally have been executed.
A fault is an exception that occurs during an instruction. It leaves the registers
and memory in a consistent state so that elimination of the fault condition and
restarting the instruction will give correct results. After the instruction faults,
the PC saved on the stack points to the instruction that faulted.
An abort is an exception that occurs during an instruction. An abort leaves
the value of registers and memory UNPREDICTABLE so that the instruction
cannot necessarily be correctly restarted, completed, simulated, or undone. In
most instances, the NVAX microcode attempts to convert an abort into a fault by
restoring the state that was present at the start of the instruction, which caused
the abort.
The following sections describe only those exceptions that are unique to the
NVAX CPU, or where the VAX Architecture Reference Manual is not clear about
the implementation.

3.7.1 Arithmetic Exceptions
Arithmetic exceptions are detected during the execution of instructions that
perform integer or floating-point arithmetic manipulations. Whether the
exception is reported as a trap or a fault is a function of the specific event.
In any case, the exception is reported through SCB vector 34 (hex) with the stack
frame shown in Figure 3–13. Table 3–7 lists the exceptions reported by this
mechanism.

Central Processor 3–35

Central Processor
3.7 Exceptions
Figure 3–13 Arithmetic Exception Stack Frame
00

31
Type Code

:(SP)

PC
PSL
LJ-01254-TI0

Table 3–7 Arithmetic Exceptions
Type Code
Decimal

Hex

Type

Exception

Trap

Integer overflow

Trap

Integer divide-by-zero

Trap

Subscript range

Fault

Floating overflow

Fault

Floating divide-by-zero

Fault

Floating underflow

3.7.2 Memory Management Exceptions
Memory management exceptions are detected during a memory reference and are
always reported as faults. The three memory management exceptions are listed
in Table 3–8. All three exceptions push the same frame on the stack, as shown
in Figure 3–14. The top longword of the stack frame contains a fault parameter
whose bits are described in Table 3–9.
Table 3–8 Memory Management Exceptions
SCB Vector

Exception

20 (hex)

Access control violation

24 (hex)

Translation not valid

3C (hex)

Modify fault

3–36 Central Processor

Central Processor
3.7 Exceptions
Figure 3–14 Memory Management Exception Stack Frame
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
0

0 0

0 M P

:SP

Some Virtual Address in the Faulting Page
PC
PSL
LJ-01255-TI0

Table 3–9 Memory Management Exception Fault Parameter
Bit

Mnemonic

Meaning

Length violation

PTE reference

Modify or write intent

Always 0

3.7.3 Emulated Instruction Exceptions
The NVAX CPU implements the VAX base instruction group. For certain
instructions outside that group, the NVAX microcode provides support for
the macrocode emulation of instructions. There are two types of emulation
exceptions, depending on whether PSL<FPD> is set at the beginning of the
instruction.
If PSL<FPD>=0 at the beginning of the instruction, the exception is reported
through SCB vector C8 (hex) as a trap with the stack frame shown in
Figure 3–15. The longwords in the stack frame are described in Table 3–10.

Central Processor 3–37

Central Processor
3.7 Exceptions
Figure 3–15 Instruction Emulation Trap Stack Frame

31
Opcode

:(SP)

Old PC
Specifier #1
Specifier # 2
Specifier # 3
Specifier # 4
Specifier # 5
Specifier # 6
Specifier # 7
Specifier # 8
PC
PSL
LJ-01256-TI0

3–38 Central Processor

Central Processor
3.7 Exceptions
Table 3–10 Instruction Emulation Trap Stack Frame
Location

Use

Opcode

Zero-extended opcode of the emulated instruction.

Old PC

PC of the opcode of the emulated instruction.

Specifiers

Address of the specified operand for specifiers of access type write
(.wx) or address (.ax). Operand value for specifiers of access type
read (.rx). For read-type operands whose size is smaller than a
longword, the remaining bits are UNPREDICTABLE. For those
instructions that do not have 8 specifiers, the remaining specifier
longwords contain UNPREDICTABLE values.

PC of the instruction following the emulated instruction.

PSL

PSL saved at the time of the trap.

If PSL<FPD>=1 at the beginning of the instruction, the exception is reported
through SCB vector CC (hex) as a fault with the stack frame shown in
Figure 3–16. In this case, PC is that of the opcode of the emulated instruction.
Figure 3–16 Suspended Emulation Fault Stack Frame
00

31
PC

:(SP)

PSL
LJ-01257-TI0

3.7.4 Vector Unit Disabled Fault
When the NVAX CPU attempts to issue a vector instruction to the optional vector
processor, it will result in this fault because the KA680 does not contain a vector
unit. There are no parameters for this exception (beside the usual PC/PSL pair).

3.7.5 Machine Check Exceptions
A machine check exception is reported through SCB vector 04 (hex) when the
NVAX CPU detects an error condition. The frame pushed on the stack for a
machine check indicates the type of error and provides internal state information
that may help identify the cause of the error. The generic machine check stack
frame is shown in Figure 3–17.

Central Processor 3–39

Central Processor
3.7 Exceptions
Figure 3–17 Generic Machine Check Stack Frame
00

31
Byte Count of Parameters, Excluding This Longword

:(SP)

PC
PSL
LJ-01258-TI0

3.7.6 Console Halts
In certain microcode flows, the NVAX microcode may detect an inconsistency in
internal state, a kernel-mode HALT, or a system reset. In these instances, the
microcode initiates a hardware restart sequence, which passes control to the
console program.
When a hardware restart sequence is initiated, the NVAX microcode saves the
current CPU state, partially initializes the CPU, and passes control to the console
program at physical address E0040000 (hex).
During a hardware restart sequence, the stack pointer is saved in the appropriate
stack pointer IPR (0 through 4), the current PC is saved in IPR 42 (SAVPC), and
the current PSL, halt code, and validity flag are saved in IPR 43 (SAVPSL). The
format of SAVPC and SAVPSL are shown in Figure 3–18.
Figure 3–18 Console Saved PC and Saved PSL

31
Saved PC

:SAVPC

PSL<31:16>

08 07

16 15 14 13
Halt Code

PSL<7:0>

:SAVPSL

MAPEN<0>
Ivalid SAVPSL if 1
LJ-01259-TI0

Console halts are discusssed in detail in Appendix D.

3–40 Central Processor

Central Processor
3.7 Exceptions
3.7.7 Kernel Stack Not Valid Exception
A kernel stack not valid exception occurs when a memory management exception
is detected while attempting to push information on the kernel stack during
microcode processing of another exception. Note that a console halt with an error
code of ERR_INTSTK is taken if a memory management exception is encountered
while attempting to push information on the interrupt stack.
The kernel stack not valid exception is dispatched through SCB vector 08 (hex)
with the stack frame shown in Figure 3–19.
Figure 3–19 Kernel Stack Not Valid Stack Frame
00

:(SP)

PC
PSL

LJ-01260-TI0

3.8 System Control Block (SCB)
The system control block (SCB) consists of two pages in main memory that contain the vectors
by which interrupts and exceptions are dispatched to the appropriate service routines. The SCB
is pointed to by IPR 17, the system control block base register (SCBB). The system control block
base format is shown in Figure 3–20. The description of the format is in Table 3–11.

Figure 3–20 System Control Block Base Register (SCBB) - IPR 17

MBZ

09 08

31 30 29
Physical Longword Address of SCB

MBZ

LJ-01261-TI0

Central Processor 3–41

Central Processor
3.8 System Control Block (SCB)

Table 3–11 The System Control Block Format
SCB
Offset

Interrupt/Exception Name

Type

#
Params

Notes

Passive Release

Interrupt

IPL is raised to request IPL

Machine Check

Abort

Parameters reflect machine state

Kernel Stack Not Valid

Abort

Must be serviced on interrupt
stack

Power Fail

Interrupt

IPL is raised to 1E

Reserved/Privileged Instruction

Fault

Customer Reserved Instruction

Fault

XFC instruction
Not always recoverable

Reserved Operand

Fault/Abort

Reserved Addressing Mode

Fault

Access Control Violation/Vector
Alignment Fault

Fault

Parameters are virtual address,
status code

Translation Not Valid

Fault

–

2 parameters are virtual address,
status code

Trace Pending (TP)

Fault

Breakpoint Instruction

Fault

Unused

—

Compatibility mode in other VAX
systems

Arithmetic

Trap/Fault

Parameter is type code

38-3C

Unused

—

CHMK

Trap

Parameter is sign-extended
operand word

CHME

Trap

Parameter is sign-extended
operand word

CHMS

Trap

Parameter is sign-extended
operand word

CHMU

Trap

Parameter is sign-extended
operand word

Unused

–

Memory Soft Error Notification

Interrupt

58-5C

Unused

–

Memory Hard Error Notification

Interrupt

Unused

–

Vector Unit Disabled

Fault

IPL is 1A
IPL is 1D
Vector instructions
(continued on next page)

3–42 Central Processor

Central Processor
3.8 System Control Block (SCB)
Table 3–11 (Cont.) The System Control Block Format
SCB
Offset

Interrupt/Exception Name

Type

#
Params

6C-74

Unused

–

Notes

Programmable Timer 0

Interrupt

IPL is 14

Programmable Timer 1

Interrupt

IPL is 14

Unused

–

Software Level 1

Interrupt

Software Level 2

Interrupt

Ordinarily used for AST delivery

Software Level 3

Interrupt

Ordinarily used for process
scheduling

90-BC

Software Levels 4-15

Interrupt

Interval Timer

Interrupt

Unused

–

Emulation Start

Fault

Same mode exception, FPD =
0; parameters are opcode, PC,
specifiers

Emulation Continue

Fault

Same mode exception, FPD = 1:
no parameters

108

Mass Storage Interface One
(DSSI PORT 1)

Interrupt

IPL is 14

104

Mass Storage Interface Two
(DSSI PORT 2)

Interrupt

IPL is 14

D8-DC

Unused

–

Network Interface

Interrupt

Unused

–

Console Receiver

Interrupt

IPL is 15

Console Transmitter

Interrupt

IPL is 15

204

Interprocessor Doorbell

Interrupt

IPL is 14

IPL is 16

IPL is 14

Central Processor 3–43

Central Processor
3.8 System Control Block (SCB)
Vectors in the range of 100-FFFC are used to directly vector interrupts from the
external bus. The SCB vector index is determined from bits <15:2> of the value
supplied by external hardware.
The new PSL priority level is determined by either the external interrupt request
level that caused the interrupt or by bit <0> of the value supplied by external
hardware.
If bit<0> is 0, the new IPL level is determined by the interrupt request level
being serviced. IRQ<3> sets the IPL to 1716 ; IRQ<2>, 1616 ; IRQ<1>, 1516 ; and
IRQ<0>, 1416 . If bit<0> of the value supplied by external hardware is 1, then the
new IPL is forced to 1716 .
The ability to force the IPL to 1716 supports an external bus, such as the
Q22–bus, which cannot guarantee that the device generating the SCB vector
index is the device that originally requested the interrupt.
For example, the Q22–bus has four separate interrupt request signals that
correspond to IRQ<3:0> but only one signal to daisy chain the interrupt grant.
Furthermore, devices on the Q22–bus are ordered so that higher priority devices
are electrically closer to the bus master. If an IRQ<1> is being serviced, there is
no guarantee that a higher priority device will not intercept the grant.
Software must determine the level of the device that was serviced and set the IPL
to the correct value. Only device vectors in the range of 100 to FFFC16 should be
used, except by devices emulating console storage and terminal hardware.

3.9 System Identification
The KA680 firmware and operating system software references two registers
to determine the processor on which they are running. The first, the system
identification register (SID), is an internal processor register. The second, the
system identification extension register (SIE), is a firmware register located in
the KA680 EPROM.

3.9.1 System Identification Register
The system identification register (SID), IPR 62, is a read-only register
implemented in the NVAX CPU. This 32-bit, read-only register is used to
identify the processor type and its microcode revision level. The SID longword is
read from IPR 62 using the MFPR instruction. This longword value is processorspecific. The format is shown in Figure 3–21. Bit definitions are listed in
Table 3–12.

3–44 Central Processor

Central Processor
3.9 System Identification
Figure 3–21 System Identification Register (SID) - IPR 62
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
CPU_Type

Reserved

Microcode Rev.

LJ-01262-TI0

Table 3–12 System Identification Register
Field

Name

Description

<31:24> CPU_TYPE

CPU type is the processor-specific identification code.

<23:8>

reserved

Reserved for future use.

<7:0>

VERSION

Version of the microcode.

3.9.2 System Identification Extension (SIE) Register (20040004)
The system identification extension register is an extension of the SID register
and is used to further differentiate between hardware configurations. The SID
register identifies which CPU and microcode are executing, and the SIE register
identifies what module and firmware revision are present. Note that the fields in
this register are dependent on SID<31:24>(CPU_TYPE).
By convention, all MicroVAX systems implement a longword at physical location
20040004 in the firmware EPROM for the SIE register. This 32-bit read-only
register is implemented in the KA680 ROM. Figure 3–22 shows the format of this
register. Table 3–13 lists the definitions of the register bits.

Figure 3–22 System Identification Extension Register (SIE)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Sys_Type

Rev Level

Sys_Sub_Type

Variant

LJ-01263-TI0

Central Processor 3–45

Central Processor
3.9 System Identification
Table 3–13 System Identification Extension Register Bits
Field

Name

Description

31:24

SYS_TYPE

This field identifies the type of system for a specific
processor.
01 : Q22–bus single processor system.

23:16

VERSION

This field identifies the resident version of the firmware
EPROM encoded as two hexadecimal digits. For example,
if the banner displays V5.0, then this field is 50 (hex).

15:8

SYS_SUB_
TYPE

This field identifies the particular system subtype.

7:0

RESERVED

01 : KA650
02 : KA640
03 : KA655
04 : KA670
05 : KA660
06 : KA680
This field is reserved

3.10 CPU References
All references by the CPU can be classified into one of the following groups:
•

Instruction-stream (I-stream) read references.

•

Data-stream (D-stream) read references.

•

Ownership read (OREAD) references.

•

Disown write (WDISOWN) references.

•

Write references.

•

Bad data write cycles (BADWDATA). See Section 4.4 for more information
regarding the use of BADWDATA.

3.10.1 Instruction-Stream Read References
An instruction stream (I-stream) reference is defined as a read reference to
acquire a VAX instruction. Furthermore, a VAX instruction consists of its
opcode, all operand specifiers, and any operands that are necessarily contiguous
with the rest of the instruction stream. Thus, the instruction stream includes
short literals, immediate-mode operands, absolute addresses in absolute mode
addressing, branch displacements, CALLx entry masks, and CASEx tables.
Except for immediate-mode operands and branch displacements, the instruction
stream does not include operands, even ones addressed relative to the PC. Except
for absolute addresses, the instruction stream does not include indirect addresses.
It also does not include EDITPC patterns. All instruction operands and indirect
addresses not considered to be within the instruction stream are considered data,
and are therefore accessed by the NVAX using D-stream read references.
The CPU has an instruction prefetcher for prefetching program instructions
from either cache or main memory. The prefetcher uses a 16-byte (4 longword)
instruction prefetch queue (IPQ). Whenever there is an empty longword in the
IPQ, and the prefetcher is not halted due to an error, the instruction prefetcher
will generate an aligned quadword I-stream read reference.

3–46 Central Processor

Central Processor
3.10 CPU References
3.10.2 Ownership Read References
The NVAX uses ownership read (OREAD) references to gain ownership of a
hexaword (32 bytes) block of memory. OREADs are defined only from memory
space; they are not used in I/O space.
The primary purpose for ownership reads on the KA680 CPU module is to
facilitate the use of a write-back caching scheme. The backup cache on the
KA680 CPU module uses a "write-back" scheme, whereby write transactions
to cached memory locations result in the modification of the cached copy only
(that is, the write transaction does not modify the actual memory location). This
substantially reduces the time required for the write transaction, resulting in a
corresponding improvement in system performance.
This presents a potential problem for memory locations, which may be shared
between the NVAX CPU and the I/O DMA devices, since the Bcache may contain
the only up-to-date copy of a location referenced by a DMA device. Because of
this, the KA680 memory subsystem utilizes the concept of memory ownership. In
this scheme, each hexaword (32 bytes) of main memory has associated with it an
ownership bit. These ownership bits reside on the KA680 CPU module and are
controlled by the NVAX memory controller chip (NMC). Whenever a device on the
module requests a transaction to main memory, the memory controller checks to
see if the hexaword containing the referenced location is owned by another device
(for example, the NVAX CPU or an I/O device). If it is owned, then the requested
transaction is pended until the owner of the hexaword relinquishes ownership of
that hexaword. In this way, the system can maintain memory consistency in the
presence of the NVAX CPU write-back cache.
The NVAX CPU will request ownership of memory locations in two general cases.
The first is when software attempts to write to a location that is not currently
cached in the Bcache AND owned by the CPU. In this case, the NVAX CPU will
issue an OREAD to the memory subsystem to acquire ownership of the referenced
hexaword. In this way, subsequent writes to the owned (and cached) location will
occur only in the cache, and will not update the contents of the actual memory
location. If another device wishes to access the owned hexaword, or if the CPU’s
Bcache determines that it must deallocate the cache block containing the owned
hexaword, then the NVAX CPU will perform a disown write (described below)
of the owned hexaword to memory. The disown write updates memory with the
potentially modified data, and signals the memory subsystem that the NVAX CPU
is relinquishing ownership of that hexaword.
The other case when the NVAX CPU will perform an OREAD to request
ownership of a hexaword is for VAX instructions that perform interlocked
read/modify/write operations on memory. The ownership mechanism is used in
this case to prevent I/O or Q22–bus devices from accessing the relevant memory
location in the middle of the read/modify/write operation.
When memory receives an ownership read, an "owned" bit corresponding to the
hexaword containing the referenced location is set in memory and the read data
is returned. Each hexaword in memory has an ownership bit. The NVAX backup
cache is organized by hexawords also, with an owned bit for each hexaword.
Memory clears the owned bit when a disown write of any length is received for an
owned block.
If the ownership bit is already set in memory when the OREAD arrives, data is
not returned immediately to the commander. Once the node that owns the data
performs a disown write to the owned block, the ownership bit is set in memory
and the data is returned to the commander.

Central Processor 3–47

Central Processor
3.10 CPU References
For more information regarding the use of ownership bits in the KA680 system,
refer to Chapter 5 and Section 4.4.2.

3.10.3 Disown Write References
The disown write (WDISOWN) transaction is the complement to the ownership
read. After the NVAX CPU successfully gains ownership of a block in memory,
it must relinquish ownership when another device (for example, a Q22–bus
DMA device) wants to access the block or when the Bcache needs to do a
deallocate. The NVAX CPU accomplishes this in a way transparent to software
by deallocating the owned hexaword from the Bcache and performing a disown
write to the memory with the latest copy of the data. The memory, which has
been monitoring the bus traffic, notices the disown write from the NVAX CPU
and clears the ownership bit in memory and writes the new data.
The NVAX CPU uses the disown write transaction of hexaword (32 bytes) length
to perform writebacks from the backup cache. This is transparent to software
except in the case of errors, when the logged information could indicate that an
error occured during a disown write transaction.

3.10.4 Data-Stream Read References
Data-stream (D-stream) references are defined as all read references that do not
fall under either OREAD or I-stream categories. Generally, D-stream references
are used by the NVAX CPU to read instruction operands and data from memory.
A more complete list of read references that qualify as D-stream is given below.
•

Operand

•

Page table entry (PTE)

•

System control block (SCB)

•

Process control block (PCB)

When interlocked instructions, such as branch on bit set and set interlock
(BBSSI) are executed, an OREAD/WDISOWN transaction pair is used to prevent
I/O devices from accessing the referenced location in the middle of the instruction.

3.10.5 Write References
Whenever data is stored or moved, and a WDISOWN transaction is not in order,
a normal WRITE reference is generated.

3.11 NVAX Data/Address Lines (NDAL)
3.11.1 NDAL Transactions
The following sections describe the set of NDAL transactions.
In order to maximize the bandwidth of the bus connecting the CPU to the memory
and I/O controllers, the NVAX chip set (NVAX, NMC, NCA) communicate over a
"pended" bus, the NDAL. The main feature of this bus is that devices requesting
read data do not tie up the bus while waiting for the return data. Rather, a
device will issue one of the "read" commands on the NDAL and then relinquish
control of the bus to other devices so that other transactions may be performed.
At the same time, the responder to the first device prepares to send back the data
associated with the read request. Because of the pended nature of the bus, the

3–48 Central Processor

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
NDAL bus command set includes separate transactions for returning data from
an earlier read cycle. Table 3–14 shows the entire set of NDAL commands and
how they are used by NVAX.
In memory space, NVAX issues all reads with hexaword length. Normal writes to
memory space are always quadword length, and disown writes are quadword or
hexaword. When the cache is operating normally, disown writes are only issued
in hexaword length. When the cache is in error transition mode, NVAX issues
disown writes of both hexaword and quadword length. For a discussion of error
transition mode, refer to the section on the backup cache.
When the cache is off, NVAX issues only quadword disown writes. NVAX issues
quadword disown writes only as the result of a VAX interlocked instruction.
In I/O space, the ownership commands (OREAD and Disown Write) are not
defined at all. NVAX issues only quadword operations in I/O space. NVAX never
uses the BADWDATA command in I/O space.

Central Processor 3–49

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
Table 3–14 NDAL Command Usage by NVAX
Address
Space

Command

Used by
NVAX

Length

N/A

Nop

Yes

–

N/A

Reserved

–

Memory

WRITE

Yes

Memory

WDISOWN

Yes

Memory

IREAD

Yes

Memory

DREAD

Yes

Memory

OREAD

Yes

Memory

RDE

–

Memory

WDATA

Yes

–

Memory

BADWDATA Yes

–

Memory

RDR0

–

Memory

RDR1

–

Memory

RDR2

–

Memory

RDR3

–

I/O

WRITE

Yes

I/O

WDISOWN

I/O

IREAD

Yes

I/O

DREAD

Yes

I/O

OREAD

I/O

RDE

–

I/O

WDATA

Yes

–

I/O

BADWDATA No

–

I/O

RDR0

–

I/O

RDR1

–

I/O

RDR2

–

I/O

RDR3

–

3–50 Central Processor

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
3.11.1.1 Reads and Fills
The read address cycle, which is recognized by one of the three read commands
(DREAD, IREAD, or OREAD), is decoded by the NDAL devices that are receiving
NDAL commands (only one of the NDAL chips may drive the bus at a time). The
one recognizing the address latches that address and command. This device is
the responder. The responder uses read data return (RDR) or read data error
(RDE) cycles to return the data. Reads and fills are described in the following
sections. The NVAX CPU never issues the RDR or RDE cycles, since it is never
a direct responder to a read cycle. For examples of when the NVAX CPU may
indirectly respond to a read transaction from the NCA, see the section on disown
writes.
3.11.1.1.1 D-stream Read Requests (DREAD) The NVAX CPU and the NCA
use the DREAD command to request data-stream data from a responder, either
memory or an I/O device. The NVAX CPU may issue DREAD cycles to the NMC
or NCA. The NCA may issue DREAD cycles only to the NMC.
3.11.1.1.2 I-stream Read Requests (IREAD) The IREAD command is used by
the NVAX CPU and the NCA to request instruction-stream data. The NVAX CPU
can request I-stream data from the NMC or the NCA. The NCA can request
I-stream data only from the NMC. For more information regarding the difference
between I-stream and D-stream references, see Section 3.10.
3.11.1.1.3 Ownership Read Requests (OREAD) The NVAX CPU and the NCA
use the OREAD command to gain ownership of a hexaword block of memory.
In addition to facilitating the write-back cache of the NVAX CPU, the memory
ownership concept is used to implement memory interlocks for VAX interlocked
instructions.
OREADs are only defined for memory space; they are not used in I/O space.
When memory receives an ownership read, an "owned" bit is set in memory and
the read data is returned. Each hexaword in memory has an owned bit. The
NVAX backup cache is organized by hexawords also, with an owned bit for each
hexaword. The memory controller clears the owned bit when a disown write of
any length is received at the same block.
If the ownership bit is already set in memory when the OREAD arrives, data
is not returned immediately to the NDAL commander. An example of this is
if an I/O device on one of the CP-buses attempts to access a buffer pointer in
main memory and the referenced location is owned by the NVAX CPU. In this
case, the NMC will notice that the ownership bit for the referenced hexaword
is set and will pend the transaction. Simultaneously, the NVAX CPU, which
constantly monitors the NDAL, has seen the reference to a location it owns, and
will therefore write back the owned hexaword with a WDISOWN cycle. The NMC
will then allow the original transaction from the NCA to complete. The opposite
situation is also possible where the NCA may own a location that the NVAX CPU
needs to access. The NCA does not have a write-back cache like the NVAX CPU,
but the NCA will use the OREAD/WDISOWN transaction pair when performing
interlocked references from I/O devices.

Central Processor 3–51

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
Through this ownership mechanism, the OREAD/WDISOWN transactions
prevent access by the NCA (on behalf of I/O devices) to memory locations that
may have become stale. This occurs because the NVAX CPU has modified the
locations contents in the backup cache, but has not yet updated the actual
memory location.
During normal operation, the NVAX will aquire ownership, via an OREAD, of any
memory space location that it needs to modify. Since this process also allocates
a block in the backup cache for the referenced location, the NVAX CPU will
virtually never need to perform writes directly to memory. Rather, memory will
be modified with the updated values only when the associated Bcache block must
be written back to memory to make room in the Bcache, or because of an I/O
reference to an owned location. Note that I/O space references are never cached,
so writes to I/O space always appear on the NDAL.
3.11.1.1.4 Read Data Return Cycles (RDR0, RDR1, RDR2, RDR3) The Read
Data Return command is used in response to any read request, whether
IREAD, DREAD, or OREAD. Multiple cycles are necessary to transfer all the
quadwords in a given hexaword transaction, and the cycles are not required
to be consecutive. The commander, which has been monitoring the bus traffic
waiting for its return data, latches the information. The responder returns the
commander ID with the returned read data so the commander can recognize the
returned read data it requested.
Because the NDAL is a pended bus, multiple reads may be outstanding at a time.
Because read data return cycles do not have to occur contiguously, it is possible
for read data return cycles resulting from different read requests to take place in
an interleaved fashion.
3.11.1.1.5 Read Data Error Cycles (RDE) RDE is used to notify a commander
of a problem with read data that is being returned. For example, the NMC uses
this command when it encounters an uncorrectable read error while processing a
read request from the NVAX CPU or the NCA.

3.11.1.2 Writes
3.11.1.2.1 Normal Write Transactions (WRITE) These transactions are used to
move a pattern of bytes from an NDAL commander to one of the responders.
Parity must be correct for all bytes sent from any node because all three NVAX
chips check parity across the entire NDAL during every cycle.
If NVAX sees a write on the NDAL, it treats it as an invalidate request. In this
case, the NVAX will perform a lookup of the backup cache tag store to see if the
referenced location is contained in the backup cache. If it is, then the referenced
cache block is invalidated. If the cache block is marked as owned, then the
NVAX CPU also performs a write-back of the block to memory, since the data
may be the only copy of valid data for that memory location.

3–52 Central Processor

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
3.11.1.2.2 Disown Write Transactions (WDISOWN) The disown write
transaction is the complement to the ownership read. After NVAX successfully
gains ownership of a hexaword block in memory, it must relinquish ownership if
an I/O device wants to access the block (through the NCA) or when the Bcache
needs to do a deallocate. The NVAX CPU accomplishes this by performing a
disown write to the memory with the latest copy of the backup cache data.
The memory, which has already pended the I/O device’s transaction, notices
that the CPU’s transaction is a disown write. This condition allows it to clear
the ownership bit in memory and to write the data as requested. Immediately
following this, the memory controller allows the pended I/O device’s transaction
to complete, since the referenced hexaword is no longer owned by the NVAX CPU.
NVAX uses the Disown Write command of hexaword length to perform writebacks from the backup cache. When the cache is off, it uses quadword disown
writes to achieve the effect of a write unlock for VAX interlocked instructions. As
mentioned previously, the NCA also uses the OREAD/WDISOWN transaction pair
when accessing main memory on behalf of I/O devices that use interlocked bus
cycles.
3.11.1.2.3 Write Data and Bad Write Data (WDATA,BADWDATA) The Write
Data command is used during the data cycles of a write if the data is good.
If the data has been corrupted in some way, the command used is Bad Write
Data. An example of the use of BADWDATA is when the backup cache must
deallocate an owned block to make room for new data or because of an I/O
reference to that hexaword, and in the process of performing write-back, the
NVAX CPU encounters uncorrectable errors in the cached data. In this case, the
CPU will use the WDISOWN command, specifying the hexaword being disowned,
followed by four data cycles to transfer each of the four quadwords of data. The
bad quadword(s) will be marked through the use of the BADWDATA command
instead of the WDATA command.
When one quadword of a hexaword write disown is bad, the Bad Write Data
command is only used for that quadword. The Write Data command is used for
the good quadwords. The memory can use this information to distinguish which
quadword of a hexaword block is bad. In addition, a soft error interrupt may be
generated when a BADWDATA cycle is driven on the NDAL by the NCA.

3.11.2 Cache Coherency
Ownership reads and disown writes on the NDAL are intended to support the
NVAX CPU’s writeback cache by attaching an owner status to each block in
physical memory. A block in memory is defined as a hexaword, or 32 bytes.
Once the NVAX CPU owns a block, it may write it repeatedly without accessing
memory. A memory block may be owned either by the memory subsystem or
by the NVAX CPU, but not both at the same time. Ownership is passed from
memory to the NVAX CPU through an Ownership Read command. Ownership is
passed back to the memory through a Disown Write command from the CPU.
The ownership bits in the Bcache and in memory indicate which device owns the
block: the Bcache or the NMC. The ownership bit in the Bcache is set when it
owns the block and is clear when memory (NMC) owns the block. The ownership
bit in memory is set when the Bcache owns the block and clear when memory
owns the block. The ownership bit corresponding to a hexaword of memory may
also be set to indicate that the NCA owns the block. This is possible when the
NCA is accessing memory on behalf of an I/O device that is using interlocked
bus cycles on the CP-bus. In this case, the NCA will always follow the OREAD
transaction immediately with the WDISOWN transaction.

Central Processor 3–53

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
Shared read-only access to a block is permitted only when memory owns it.
Otherwise, the block can only be read by the node that owns the block.
The NVAX can gain ownership and retain it for a very long time. The NVAX CPU
monitors the bus continuously for memory space read-type and write commands
to memory space by the NCA. When the CPU detects a request for a block that it
owns, it will perform the disown write to memory, allowing the original command
to complete successfully. Such NDAL transactions, which take place solely for
the purpose of maintaining the ownership protocol, are referred to as "cache
coherency transactions."
Table 3–15 shows what action is performed in the backup cache based upon the
state of the block in the cache when a particular command is driven onto the
NDAL by the NCA.
Table 3–15 NVAX Backup Cache Invalidates and Write-backs
NDAL Command

Invalid Block

Valid & Unowned

Valid & Owned

IREAD,DREAD

–

Write-back,
set Bcache to
valid-unowned
state

OREAD

–

Invalidate

Write-back,
Invalidate

WRITE

–

Invalidate

Write-back,
Invalidate

WDISOWN

–

The I/O devices connected to the NCA through the CP-buses may cause the
NCA to access memory on their behalf. As these transactions go to memory,
the NVAX CPU recognizes them and performs the appropriate cache coherency
action. The NVAX CPU does not acknowledge the commands, since the memory
interface is the receiver for the transaction. The NVAX CPU distinguishes cycles
driven by devices other than itself by decoding the commander’s ID. The ID
is driven onto the NDAL along with the command, and recognizes those NCA
initiated cycles as cache coherency transactions.

3–54 Central Processor

Central Processor
3.11 NVAX Data/Address Lines (NDAL)
3.11.3 VAX Architecturally-defined Interlocks
A VAX interlocked instruction causes the generation of a read-lock and a writeunlock, which are guaranteed to happen back-to-back. The NDAL does not
explicitly define interlocked transactions. Instead, the Ownership Read command
is used in place of Read Lock and the Disown Write command is used in place of
Unlock Write.
If the interlocked location is already owned in the backup cache, then there is no
need to issue an OREAD on the NDAL, and it is serviced directly by the Bcache.
It is also possible for I/O devices to cause the NCA to issue OREAD/WDISOWN
pairs on the NDAL for the purpose of performing interlocked access to VAX
memory.
3.11.3.1 Ownership and Interlock Transactions
The NVAX CPU does not support interlocks to I/O space. If software attempts to
perform an interlocked instruction on an I/O space address, the NVAX CPU will
use normal DREAD/WRITE accesses to complete the operation. No interlock is
provided.

3.11.4 Errors
The NDAL supports the detection of all single-bit and some multiple-bit
transmission-related error conditions on the NDAL_H, CMD_H, ID_H, and
PARITY_H lines by implementing parity across those lines. Additionally, the
NDAL allows commanders to recover from some memory and I/O-space read/write
class errors.
3.11.4.1 Transaction Timeout
The NVAX CPU and NCA implement timeout counters for each read that they
may have outstanding. The NVAX implements two timeout counters, one for each
possible outstanding read. If a read request times out, it is aborted by the NVAX
and a soft error interrupt is generated. Any missing read data return cycles will
eventually cause that read to timeout in the NVAX CPU. See Section 4.4.10 for
details on how timeout is handled.
Transaction timeout is not a normal occurrence and is expected to happen only on
serious system failures.
3.11.4.2 Nonexistent Memory and I/O
An address that is not implemented in memory on a particular system is known
as nonexistent memory. An I/O address of a device that is not present on a
particular system is known as nonexistent I/O. When software attempts to access
addresses that are nonexistent, an error interrupt will be generated.

Central Processor 3–55

4
KA680 Cache Memory Overview
The NVAX memory subsystem has a hierarchical structure. The VIC, Pcache,
Bcache, Main Memory, and finally the Mass Storage form the hierarchical
memory subsystem of the KA680. The hierarchical order of the levels of KA680
memory is shown in Figure 4–1.
Figure 4–1 KA680 Cache/Memory Hierarchy

Mass Storage
Main Memory
Backup Cache 128 KB
Primary Cache 8KB
VIC

2KB

For I-stream references, the memory hierarchy starts with the VIC, whereas for
D-stream references, the memory hierarchy starts with the Pcache.
References generated by the NVAX CPU are issued to the memory subsystem
at the first hierarchical level, as determined by the reference type (I-stream or
D-stream). The reference will then pass up through the hierarchy until it is
serviced by one of the layers. References serviced at lower layers take less time
than references that must pass to higher layers. For this reason, it is the intent
of the memory subsystem to service most references within the lower layers, thus
maximizing system performance.
By creating successively faster layers of memory hierarchy below the main
memory, the KA680 decreases the average amount of time required to access
information. Because each layer in the hierarchy tends to be smaller in size than
the next higher (slower) layer, there is the problem of allocating space at each
layer for storing references. Furthermore, care must be taken to ensure that the
state of the system is singularly and accurately represented by the combined
contents of the caches and main memory.

KA680 Cache Memory Overview 4–1

KA680 Cache Memory Overview

In the KA680, this issue is most critical between main memory and the backup
and primary caches, because main memory can be accessed by DMA devices
as well as the NVAX CPU. Furthermore, this problem is complicated by the
write-back nature of the backup cache. This write-back mechanism, while
significantly decreasing the latency of write operations, complicates the problem
of maintaining a coherent and consistent representation of main memory in DMA
traffic.
For example, during normal operation, the NVAX CPU and DMA devices will
share access to certain memory locations. In order to guarantee proper operation,
the KA680 provides hardware mechanisms to ensure that DMA updates to main
memory will be invalidated in the primary and backup caches. Furthermore, the
KA680 provides mechanisms to ensure that DMA traffic is presented with correct
data in the presence of the write-back cache. The following sections discuss each
of the caches and how they are used.

4.1 Cacheable References
Any reference that can be stored by the virtual instruction cache, or the primary
or backup caches, is called a cacheable reference. The primary and backup caches
store CPU read references to the VAX memory space (bit <29> of the physical
address = 0) only. They do not store references to the VAX I/O space.
Whenever the CPU generates a noncacheable reference, or a cacheable reference
not stored in any of the three caches, a single hexaword reference of the same
type is generated on the NDAL bus.
Whenever the CPU generates a cacheable reference that is stored in one of the
caches, no reference is generated on the NDAL bus.

4.2 Virtual Instruction Cache
Before any instruction can be executed, it must first be fetched from memory.
The NVAX CPU contains an instruction prefetcher, which fetches sequential
instructions ahead of the instruction currently being executed. This is done in an
attempt to reduce the effective access time of the instruction fetch by pipelining it
with decode and instruction execution. The instruction prefetcher maintains an
instruction prefetch queue (IPQ) of up to 16 bytes (4 longwords) of I-stream data.
In order to fill the IPQ, the prefetcher sends I-stream read requests to the virtual
instruction cache.
The virtual instruction cache (VIC) is a 2 KB, direct-mapped cache for caching
I-stream data. The VIC is located within the NVAX CPU chip. In order to
reduce the overhead associated with virtual-to-physical address translation, the
VIC caches references based on virtual addresses. In the event that the virtual
references made by the instruction prefetcher hit in the VIC, the I-stream data is
loaded from the VIC directly to the IPQ.
If the references made by the instruction prefetcher miss in the VIC, then the
VIC will issue an I-stream read request on behalf of the instruction prefetcher to
the next level of memory hierarchy: the primary cache.

4–2 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.2 Virtual Instruction Cache
4.2.1 Virtual Instruction Cache Organization
The VIC attributes are summarized in Table 4–1.
Table 4–1 VIC Attributes
Attribute

Description

Cache Size

2 KB

Access Type

Direct-mapped

Block Size

32 bytes

Subblock Size

8 bytes

Valid Bits

4 valid bits/cache block = 1 per subblock

Data Parity Bits

4 even parity bits/cache block = 1 per subblock

No. of Tags

64 tags

Tag Parity Bit

1 even parity bit per tag

Fill Algorithm

Fill forward, random cycle allocate if no tag hit or data subblock
valid

Access Size

8 bytes

Bus Size

8 bytes

Prefetching

None

Data Stored

I-stream only

Virtual/Physical

Virtual

The format of each cache row is shown in Figure 4–2. Each cache row stores a
22-bit tag with even parity for the tag, and four quadword subblocks, each with a
valid bit and an even parity bit that covers the data only. During a cache read,
the data, tags, valid and parity bits of the direct-mapped cache block are read.
The tag is compared to bits <31:10> of the virtual address. If the tag matches,
then the data is returned to the instruction prefetch queue. Otherwise, the
request has "missed" in the VIC, and the read request is forwarded to the Pcache.

Figure 4–2 VIC Cache Row Format
31 21 29 00 27 26 63 24 23 22 00 20 19 63 17 16 15 00 13 12 63 10 09 08 00 06 05 63 03 02 01 00
P

Tag

Sub-block
3 Data

Sub-block
2 Data

Sub-block
1 Data

Sub-block
0 Data

287 Bits
LJ-01264-TI0

KA680 Cache Memory Overview 4–3

KA680 Cache Memory Overview
4.2 Virtual Instruction Cache
Macrocode Restriction
To avoid parity errors, the VIC tag arrays, including parity, must be
written with valid data and parity before enabling the VIC. The tag
values in bank 0 must be written with different values than the tag
values in bank 1 so that the tags from both banks do not simultaneously
produce a tag hit.

4.2.2 Virtual Instruction Cache Internal Processor Registers
The VIC contains four internal processor registers, which provide VIC control and
read/write access to the data and tag arrays.
Macrocode Restriction
The VIC_ENABLE bit of the ICSR IPR must be cleared before writing
to the other VIC IPRs VMAR, VDATA, or VTAG. Similarly, the VIC_
ENABLE bit of the ICSR IPR must be cleared before reading from the
VIC IPRs VDATA and VTAG.

4.2.2.1 VIC Virtual Memory Address Register (VMAR) - IPR 208
Figure 4–3 VMAR Register

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
X X

Addr

:VMAR

ROW_INDEX
SUB_BLOCK
LW
LJ-01265-TI0

Table 4–2 VMAR Register
Name

Extent

Type

Description

Longword select bit. Selects longword of
subblock for access to cache array.

SUB_BLOCK

4:3

Subblock select. Selects data subblock
for access to cache array; also latches
bits <4:3> of the virtual address on VIC
parity errors.

ROW_INDEX

10:5

Row select. Row index for read and
write access to cache array; also latches
bits <9:5> of a virtual address, which
resulted in a VIC parity error.
(continued on next page)

4–4 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.2 Virtual Instruction Cache
Table 4–2 (Cont.) VMAR Register
Name

Extent

Type

Description

ADDR

31:11

Error address field. Latches tag portion
of the virtual address, which resulted in
a VIC parity error.

When the VIC is disabled, the VIC memory address register (VMAR) may be used
as an index for direct IPR access to the cache arrays. Bits <9:5> of this register
supply the cache row index, bit <10> selects the bank, bits <4:3> supply the cache
subblock, and bit <2> indicates the longword within a quadword address.
The VMAR IPR also latches and holds bits <31:3> of the virtual address of the
reference that resulted in a parity error on VIC array parity errors.
4.2.2.2 VIC TAG Register (VTAG) - IPR 209
Figure 4–4 VTAG Register
04 03

11 10 09 08 07

31
Tag

1 TP

00
V

:VTAG
LJ-01266-TI0

Table 4–3 VTAG Register
Name

Extent

Type

Description

3:0

Data valid bits. Supply data valid bits
on array read/writes.

7:4

Data parity bits. Supply data parity on
array read/writes.

Tag parity bit. Supplies tag parity on
tag array read/writes.

TAG

31:11

Tag. Supplies tag on tag array
read/writes.

The VTAG IPR provides read and write access to the cache tag array. An IPR
write to VTAG will write the tag, parity, and valid bits for the row indexed by
VMAR<9:5> and the bank selected by VMAR<10>. VTAG<31:10> are written to
the cache tag. VTAG<8> is written to the associated tag parity bit. VTAG<7:4>
are used to write the four data parity bits associated with the indexed cache
row. Similarly, VTAG<3:0> write the four data valid bits associated with the
cache row. VTAG<7:4> and VTAG<3:0> are the data parity and data valid bits,
respectively, for the four quadwords of data in the same row. VTAG<4> and
VTAG<0> correspond to the quadword of data addressed when address bits 4:3 =
00; VTAG<5> and VTAG<1> correspond to the quadword of data addressed when
address bits 4:3 = 01, and so forth.

KA680 Cache Memory Overview 4–5

KA680 Cache Memory Overview
4.2 Virtual Instruction Cache
4.2.2.3 VIC Data Register (VDATA) - IPR 210
Figure 4–5 VDATA Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Data

:VDATA
LJ-01319-TI0

Table 4–4 VDATA Register
Name

Extent

Type

Description

DATA

31:0

Data for data array reads and writes

The VDATA IPR provides read and write access to the cache data array. When
VDATA is written, the cache data array entry indexed by the VMAR IPR is
written with the IPR data. Since the IPR data is a longword, two accesses to
VDATA are required to read or write a quadword cache subblock.
Writes to VDATA with VMAR<2> = 0 simply accumulate the IPR data destined
for the low longword of a subblock in a scratch register internal to the
NVAX CPU. A subsequent write to VDATA with VMAR<2> = 1 triggers a cache
write to the subblock indexed by VMAR.
Reads to VDATA with VMAR<2> = 0 trigger a cache read to the subblock indexed
by VMAR. The low longword of a subblock is returned as IPR read data. A read
of VDATA with VMAR<2> = 1 returns the high longword of the subblock as IPR
data.

4–6 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.2 Virtual Instruction Cache
4.2.2.4 VIC Control and Status Register (ICSR) - IPR 211
Figure 4–6 ICSR Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
0

:ICSR

TPERR_0
DPERR_0
LOCK
ENABLE

LJ-01318-TI0

Table 4–5 ICSR Register
Name

Extent

Type

Description

ENABLE

RW,0

Enable bit. When set, allows cache
access to the VIC. Initializes to 0 on
system reset.

LOCK

Lock bit. When set, validates and
prevents further modification of the
error status bits in the ICSR and the
error address in the VMAR register.
When clear, indicates no VIC parity
error has been recorded and allows ICSR
and VMAR to be updated.

DPERR

Data error bit. When set, indicates data
parity error occurred in data array.

TPERR

Tag error bit. When set, indicates tag
parity error occurred in tag array.

The ICSR IPR provides control and status functions for the VIC. VIC tag and data
parity errors are latched in the read-only bits ICSR<4:3>, respectively. ICSR<2>
is set when a tag or data parity error occurs, and keeps the error status bits
and the VMAR IPR from being modified further. Writing a logic one to ICSR<2>
clears the lock bit and allows the error status to be updated. When ICSR<2> is
clear, the values in ICSR<4:3> are meaningless. When ICSR<2> is set, a VIC
parity error has occurred, and either ICSR<4> or ICSR<3> will be set. This
indicates that the parity error was either a tag parity error or a data parity error,
respectively. ICSR<4:3> cannot be cleared from software. ICSR<0> provides IPR
control of the VIC enable. It is cleared on system reset.

KA680 Cache Memory Overview 4–7

KA680 Cache Memory Overview
4.3 Primary Cache

4.3 Primary Cache
The Pcache is a 2-way set associative, read allocate, no-write allocate, writethrough, physical address cache of I-stream and D-stream data. It stores
8192 bytes (8K) of data and 256 tags corresponding to 256 hexaword blocks (1
hexaword = 32 bytes). Each tag is 20 bits wide, corresponding to bits <31:12> of
the physical address.
There are four quadword subblocks per block with a valid bit associated with
each subblock. The access size for both Pcache reads and writes is one quadword.
Byte parity is maintained for each byte of data (32 bits per block). One bit of
parity is maintained for every tag. The Pcache has a 1-cycle access and a 1-cycle
repetition rate for both reads and writes.
The Pcache represents the first level of D-stream memory hierarchy and the
second level of I-stream memory hierarchy in all NVAX computer systems.
Pcache entries must be invalidated in order to maintain cache coherency with
higher levels of the memory hierarchy. See Section 4.3.2 for more information on
the Pcache.
The Pcache is located within the NVAX CPU chip. Unlike the VIC, the Pcache
is based on physical addresses rather than virtual addresses. The Pcache
handles I-stream requests from the VIC, as well as D-stream requests for
instruction operands. The Pcache uses a write-through scheme for handling
writes to memory locations that are contained in the Pcache. In this scheme, the
write operation updates the contents of the Pcache, and the write operation is
propagated to the next level of memory hierarchy: the backup cache. The Pcache
is maintained as a strict subset of the backup cache.

4.3.1 Primary Cache Organization
Figure 4–7 shows the logical organization of the Pcache.

4–8 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.3 Primary Cache
Figure 4–7 Logical Pcache Organization

Left Bank

Right Bank

Tag

D/DP D/DP D/DP D/DP TP Tag

VB D/DP D/DP D/DP D/DP

Tag

D/DP D/DP D/DP D/DP TP Tag

VB D/DP D/DP D/DP D/DP

Tag

D/DP D/DP D/DP D/DP TP Tag

VB D/DP D/DP D/DP D/DP

Tag

D/DP D/DP D/DP D/DP TP Tag

VB D/DP D/DP D/DP D/DP

.
.
.
127:

Where: A =
TP =
Tag =
VB =
D/DP =

Allocation bit. Indicates whether the left of right bank was last allocated.
1 bit of even tag parity.
20 bits of tag address.
4 valid bits. each bit corresponds to 8 bytes of data.
8 bytes of data with 8 bits of even byte parity (72 total bits).
LJ-01267-TI0

The Pcache is logically organized into 128 direct-mapped indexes, where each
index consists of two blocks, and each block consists of: 20-bit tag, 1-bit tag
parity, 4 valid bits, 256 bits of data, and 32 bits of data parity. In addition, each
index also contains a 1-bit allocation pointer.
The breakdown of address bits for Pcache decoding is shown below:
Figure 4–8 Pcache Address Breakdown

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Tag Address

Index Address

Sub-block Address
Where: Tag Address =
Bits loaded into or compared with tag.
Index Address =
Address 1 of 128 indexes.
Sub-block Address = Addresses 1 of 4 aligned quadwords within the hexaword data block.
LJ-01268-TI0

4.3.2 Pcache Control
The Pcache is controlled through the PCCTL internal processor register. This
IPR controls whether the Pcache is enabled or disabled, as well as controlling
the general mode of operation. As with other internal processor registers, it is
accessible through the MTPR and MFPR instructions. The following diagram
shows the organization of the PCCTL internal processor register.

KA680 Cache Memory Overview 4–9

KA680 Cache Memory Overview
4.3 Primary Cache
Figure 4–9 PCCTL Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
1

:PCCTL

Reserved
Reserved
P_Enable
Bank_SEL
Force_HIT
I_Enable
D_Enable
LJ-01269-TI0

Table 4–6 PCCTL Definition
Name

Extent

Type

Description

D_ENABLE

RW,0

When set, enables Pcache for all
invalidate operations and for all
D-stream read/write/fill operations.
Qualified by other control bits.
When clear, forces a Pcache miss on
all Pcache D-stream read/write/fill
operations. Note, however, that an
ACV/TNV/M=0 condition overrides a
deasserted D_ENABLE because it will
force a Pcache hit condition with D_
ENABLE=0.

I_ENABLE

RW,0

When set, enables Pcache processing of
invalidate, I-stream read and I-stream
cache fills.
When clear, forces a Pcache miss on
I-stream read operations and prevents
state modification due to an I-stream
cache fill operation.
Note, however, that an ACV/TNV/M=0
condition overrides a deasserted I_
ENABLE because it will force a Pcache
hit condition with I_ENABLE=0.

FORCE_HIT

RW,0

When set, forces a Pcache hit on all
reads and writes when Pcache is enabled
for I- or D-stream operation.
This is used for diagnostic purposes so
that the cache data store can be directly
accessed.

BANK_SEL

RW,0

When set with FORCE_HIT=1, selects
the "right bank" of the addressed Pcache
index.
(continued on next page)

4–10 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.3 Primary Cache
Table 4–6 (Cont.) PCCTL Definition
Name

Extent

Type

Description
When clear with FORCE_HIT=1, selects
the "left bank" of the addressed Pcache
index.
This bit is a don’t care when FORCE_
HIT=0.

P_ENABLE

RW,0

When set, enables detection of Pcache
tag and data parity errors.
When deasserted, disables Pcache parity
error detection.

Reserved

7:5

R,1

Unused. Read as ones.

Reserved

R,0

–

Reserved

R,0

Pcache redundancy bit. When set, this
bit indicates that one or more Pcache
redundant elements have been enabled.

Note that Pcache operation is further qualified by the state of PCSTS<0>. If
this bit is nonzero, Pcache operation is automatically forced to behave as if I_
ENABLE=0 and D_ENABLE=0, regardless of the actual state of I_ENABLE and
D_ENABLE. Effectively, this shuts down normal Pcache operation due to the
presence of a previous Pcache parity error.
Based on the bit definitions above, note that Pcache invalidate operations are
only disabled if both D_ENABLE=0 and I_ENABLE=0, or if PCSTS<0> is set.
Also note that Pcache IPR read and write operations are always unconditionally
enabled, regardless of the state of I_ENABLE or D_ENABLE, or PCSTS<0>.
If either D_ENABLE or I_ENABLE are to be toggled to the on state, the Pcache
array must be initialized prior to such action.
When the FORCE_HIT (force hit) bit is set and I-stream or D-stream operation is
enabled, all enabled memory space read and write references are forced to hit in
the Pcache. The BANK_SEL bit specifies which tag of the pair of tags addressed
is forced to hit. Thus when FORCE_HIT=1, the Pcache becomes a 4K directmapped cache with all reads and writes forced to hit in the Pcache. Toggling
BANK_SEL causes the other half of the 8K Pcache to become accessible in this
direct mapped mode. Note that the FORCE_HIT bit only affects memory space
references. I/O space references still miss in the Pcache regardless of the state of
the FORCE_HIT bit.
The FORCE_HIT feature is designed to facilitate testing the Pcache data array
and to make diagnostic tests easily loadable within the Pcache by simple memory
write operations. When FORCE_HIT=0, the Pcache is configured as an 8K 2-way
set associative cache, no reads or writes are forced to hit, and the BANK_SEL bit
is a don’t care.
The P_ENABLE (parity enable) bit allows the detection of Pcache tag and data
parity errors to be enabled or disabled. If P_ENABLE=0, Pcache parity errors
will not be detected. Thus when P_ENABLE=0, no Pcache error will be recorded
in PCSTS, nor will they cause an error interrupt or machine check.
Note however, that when FORCE_HIT=1, Pcache tag parity is never checked
regardless of the state of P_ENABLE.
KA680 Cache Memory Overview 4–11

KA680 Cache Memory Overview
4.3 Primary Cache
4.3.3 Pcache Hit/Miss Determination
4.3.3.1 Hit/Miss Determination by Tag Comparison
For I-stream or D-stream reads or writes, the Pcache must determine if the
referenced data is present in its array. To do this, physical address bits <11:5>
are input to the Pcache row decoders in order to determine which one of the 128
direct-mapped indexes is being addressed. Subsequently, all 627 bits within the
addressed index are accessed by the assertion of the corresponding word line.
The two accessed tag values are simultaneously compared to physical address
bits<31:12>. A Pcache hit condition occurs when all of the following conditions
are simultaneously true:
•

The contents of one of the two addressed tags matches the data on physical
address bits <31:12>.

•

The valid bit corresponding to both the matched tag and to the addressed
quadword subblock (specified by physical address bits<4:3>) is set.

•

The stored tag parity corresponding to the matched tag is the same as the
value calculated from bits <31:12>.

If an address match is detected on one of the tags and the valid bit that
corresponds to both the matched tag and the addressed subblock (specified by
physical address bits <4:3>) is set, then a Pcache hit condition has been detected
on the corresponding Pcache tag. The absence of the Pcache hit condition causes
a Pcache miss condition.
4.3.3.2 Conditions That Force Pcache Miss
The Pcache miss condition is forced to override the tag determination of hit/miss
described above when any one of the following conditions is satisfied:
•

If PCSTS<0> is set, the Pcache miss condition is forced due to a previous
Pcache parity error.

•

If an I-stream read or cache fill operation is accessing the Pcache and I_
ENABLE=0, the Pcache miss condition is forced.

•

If a D-stream read or cache fill operation is accessing the Pcache and D_
ENABLE=0, the Pcache miss condition is forced.

•

If a D-stream read lock operation is executing (such as for an interlocked
instruction), the Pcache miss condition is forced. This guarantees that the
read will propagate to the Bcache where memory ownership can be obtained
for synchronization purposes.

•

If an I-stream cache fill operation is executing, but the reference is
noncacheable, the Pcache miss condition is forced.

•

If a D-stream cache fill operation is executing, but the reference is
noncacheable, the Pcache miss condition is forced.

4–12 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.3 Primary Cache
4.3.3.3 Conditions That Force Pcache Hit
The Pcache hit condition is forced to override the tag determination of hit/miss
described above when any one of the following conditions is satisfied:
•

If a read or write reference has a memory management fault or hard error
associated with it, a Pcache hit condition is forced. NOTE: This force hit
condition takes precedence over any force miss condition described
above.

•

If the operation is a D-stream read, write or WRITE_UNLOCK, and D_
ENABLE=1 and FORCE_HIT=1, the Pcache hit condition is forced on the tag
corresponding to both the addressed Pcache index and the bank specified by
the BANK_SEL bit.

•

If the operation is an I-stream read and I_ENABLE=1 and FORCE_HIT=1,
the Pcache hit condition is forced on the tag corresponding to both the
addressed Pcache index and the bank specified by the BANK_SEL bit.

4.3.4 Pcache Behavior on Write Operations
A Pcache write operation is initiated by a write or WRITE_UNLOCK reference.
A Pcache write begins by determining the Pcache hit or miss condition described
above. If a Pcache hit is detected, the data is selectively written into the
quadword corresponding to both the tag in which the hit occurred and to physical
address bits <4:3>. The data is selectively written according to the length
specified in the instruction causing the write. The corresponding data parity is
also written in the same manner for each corresponding byte that is written.
If a Pcache miss condition occurs, no Pcache write operation takes place.
However, the write reference is forwarded to the Bcache for processing regardless
of the hit/miss condition in the Pcache.

4.3.5 Pcache Replacement Algorithm
When a Pcache miss occurs during a read operation, it must be decided which one
of two blocks will be allocated for the subsequent Pcache fill sequence. When the
Pcache miss occurred because no validated tag field matched the read address,
the state of the corresponding allocation bit indicates which bank (left or right)
should be used for the resulting fill sequence. The value of each allocation bit
changes according to the "not-last-used" algorithm. That is, the allocation bit
always points to the bank within the index that was not last accessed.
When a read miss occurs because no validated tag field matched the read address,
the value of the allocation bit will be used as the bank select input during the
subsequent fill sequence. As each fill operation takes place (that is, as each
quadword comes back from memory), the allocation bit is written to point to the
other bank. This ensures that the next fill operation to this cache entry will be
written to the other bank. Also, during Pcache read or write operations, the value
of the allocation bit is set to point to the opposite bank that was just referenced
because this is now the new "not-last-used" bank.
The one exception to this algorithm occurs during an invalidate. Pcache
invalidates occur because of I/O activity in the system and the need to maintain
the Pcache as a strict subset of the Bcache. When a Pcache invalidate clears
the valid bits of a particular tag within an index, set the allocation bit to point
to the bank select used during the invalidate regardless of which bank was last
allocated. By doing so, it is guaranteed that the next allocated block within the
index will not displace any valid tag because the allocation bit points to the tag
that was just invalidated.
KA680 Cache Memory Overview 4–13

KA680 Cache Memory Overview
4.3 Primary Cache
4.3.6 Pcache Fill Operation
A Pcache fill operation is initiated by an I-stream or D-stream read operation that
missed in the Pcache. A fill is functionally identical to a Pcache write operation
from write reference except for the following differences:
•

The bank within the addressed Pcache index is selected by the following
algorithm. If a validated tag field within the addressed index matches the
cache fill address, then the block corresponding to this tag is used for the fill
operation. If this is not true, then the value of the corresponding allocation
bit selects which block will be used for the fill.

•

The first fill operation to a block causes all four valid bits of the selected bank
to be written so that the valid bit of the corresponding fill data is set and the
other three are cleared. All subsequent fills cause only the valid bit of the
corresponding fill data to be set.

•

Any fill operation causes the fill address bits <31:12> to be written into the
tag field of the selected bank. Tag parity is also written in an analogous
fashion.

•

A fill operation causes the allocation bit to be written with the complement of
the value it had at the time of the reference that missed and caused the fill
sequence.

•

A fill operation forces every bit of the corresponding byte mask field to be set.
Thus, all eight bytes of fill data are always written into the Pcache array on a
fill operation.

4.3.7 Pcache Invalidate Operation
A Pcache invalidate operation is initiated by I/O activity to main memory and
the need to maintain the Pcache as a strict subset of the Bcache. During I/O
activity, the I/O devices may update main memory, which is cached in the Bcache
and possibly the Pcache. When such references occur, the caches must invalidate
their copies of the referenced memory location, because they are now stale. The
invalidate operation is interpreted as a NOP by the Pcache if the address does
not match either tag field in the addressed Pcache index. If a match is detected
on either tag, an invalidate will occur on that tag. Note that this determination
is made based only on a match of the tag field bits rather than on satisfying all
criteria for the Pcache hit condition (Pcache hit factors in valid bits and verified
tag parity into the equation).
When an invalidate is to occur, the four valid bits of the matched tag are written
with zeros and the allocation bit is written with the value of the bank select used
during the current invalidate operation.
Also note that an uncorrectable error, either in the Bcache or in main memory
during a cache fill sequence, causes the cache fill operation to be processed as if it
were an INVAL operation.

4–14 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.3 Primary Cache
4.3.8 Pcache IPR Summary
The following table summaries all IPRs associated with the Pcache:
Table 4–7 Pcache IPRs
Register Name

IPR Address (in hex)

PCADR (quadword address of reference
causing Pcache parity error)

PCSTS (status of Pcache parity error)

PCCTL (control state of Pcache
operation)

PCTAG

01800000..01801FE0

PCDAP

01C00000..01C01FF8

4.3.8.1 PCADR - IPR 240

Figure 4–10 PCADR Register
03 02 01 00

31
Quadword Physical Address Associated with the Recorded Pcache Parity Error

:PCADR

LJ-01270-TI0

4.3.8.2 PCSTS - IPR 241

Figure 4–11 PCSTS Register

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
0

Reserved

:PCSTS

PTE_ER
PTE_ER_WR
LEFT_BANK
RIGHT_BANK
DPERR
LOCK
LJ-01271-TI0

KA680 Cache Memory Overview 4–15

KA680 Cache Memory Overview
4.3 Primary Cache
Table 4–8 PCSTS Description
Name

Extent

Type

Description

LOCK

WC,0

Lock bit. When set, validates
PCSTS<8:1> contents and prevents
modification of these fields.
When clear, invalidates PCSTS<8:1>
and allows these fields and PCADR to be
modified.

DPERR

Data error bit. When set, indicates a
Pcache data parity error.

RIGHT_BANK

Right bank tag error bit. When set,
indicates a Pcache tag parity error on
the right bank.

LEFT_BANK

Left bank tag error bit. When set,
indicates a Pcache tag parity error on
the left bank.

RESERVED

8:4

–

PTE_ER_WR

WC,0

Indicates a hard error on a data read
from a page table entry, which resulted
from a TB miss on a write or WRITE_
UNLOCK.

PTE_ER

WC,0

Indicates a hard error on a data read
from a page table entry.

4.3.8.3 PCCTL - IPR 242
See Figure 4–9 in Section 4.3.2 for information regarding the format and use of
this register.
4.3.8.4 PCTAG - IPRs 0180000016 to 01801FE016
Figure 4–12 PCTAG Register

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Tag

1 1

Valid Bits

:PCTAG

LJ-01272-TI0

4–16 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.3 Primary Cache
Table 4–9 Pcache Tag IPR Format
Name

Extent

Type

Description

Allocation bit corresponding to index of
this tag

Valid bits

4:1

Valid bits corresponding to the four data
subblocks
PCTAG<4> corresponds to uppermost
quadword in block
PCTAG<1> corresponds to lowermost
quadword in block

Even tag parity

Tag

31:12

Tag data

4.3.8.5 PCDAP - IPR 01C0000016 to 01C01FF816

Figure 4–13 PCDAP Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07
0

00
Data_Parity

:PCDAP

LJ-01273-TI0

Table 4–10 Pcache Data Parity IPR Format
Name

Extent

Type

Description

DATA_PARITY

7:0

Even byte parity corresponding to
addressed quadword of data. Bit n
represents parity for byte n of addressed
quadword.

KA680 Cache Memory Overview 4–17

KA680 Cache Memory Overview
4.3 Primary Cache
4.3.9 Pcache IPR Access
For testability reasons, it is important to verify that every Pcache storage bit can
be read and written in both "0" and "1" states. The easiest way to do this is to
directly read and write every bit in the Pcache array. The data field is accessible
through reads and writes to addresses that hit in the Pcache. (The hit condition
can be forced through setting the FORCE_HIT bit in the PCCTL IPR.) The tag
field, tag parity, valid bits, and data parity are directly accessible through MTPR
and MFPR instructions to the Pcache IPRs defined below.
Figure 4–14 IPR Address Space Mapping
Normal IPR Address

SBZ

08 07

25 24 23

SBZ

IPR Number

Pcache TAG IPR Address
13 12 11

25 24 23 22 21

31
SBZ

Where B = 0
1

SBZ

05 04

Pcache Index Address

00
SBZ

Select the Left Bank of the Specified Index
Select the Right Bank of the Specified Index

Pcache Date Parity IPR Address
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
SBZ

Where B = 0
1

SBZ

Pcache index Address

SBA

SBZ

Select the Left Bank of the Specified Index
Select the Right Bank of the Specified Index

SBA = Sublock Address Selection

LJ-01274-TI0

The tag parity bit is included in the Pcache tag IPR format to allow the user to
write bad tag parity into the array in order to verify the tag parity logic. Further,
the valid bits and allocation bit are also included so that the Pcache can be
initialized to a known state.
The Pcache data parity allows the Pcache data parity to be directly read and
written for testability purposes.

4.4 Backup Cache
The following sections describe the organization and operation of the backup
cache.

4–18 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.1 Write-back Cache and Ownership Concepts
There is one fundamental difference between a write-back cache, such as the
Bcache, and a write-through cache, such as the Pcache. When a write is received
by a write-through cache, the data may or may not be written into the cache, but
is always written to memory. When a write is received by a write-back cache, the
write is not necessarily forwarded to memory; the write may be done only into the
cache. The data is written back to memory only if another element in the system
needs that data, or if the block is displaced (deallocated) from the cache.
The NVAX backup cache is a write-back design in which a cache block may exist
in one of three states: invalid, valid-unowned, and valid-owned. A block that is
valid-unowned is a read-only copy of memory data. A block that is valid-owned
may be written by NVAX, and if it has been written since being put into the
cache, is the only up-to-date copy of the data in the system. The NVAX cache
makes no distinction between valid-owned blocks it has written and those it has
not written.
The KA680 system supports the concept of memory ownership by implementing
an ownership bit for every hexaword of main memory. When this memory
receives an ownership read (OREAD) for a hexaword (due to a Bcache write miss
or for VAX interlocked instructions), ownership is passed to the NVAX as the
data is returned from the memory subsystem. If another read request arrives for
that hexaword from a DMA device, memory does not return the data since the
hexaword is not owned by memory but by the NVAX. The NVAX CPU recognizes
the second read request as a cache coherence transaction and writes back the
data from its cache, using the Disown Write (WDISOWN) command. The memory
subsystem will then forward the data to the requesting DMA device.
During write operations, the NVAX CPU issues an OREAD to the memory
subsystem and receives ownership for blocks that miss in the Bcache. After
gaining ownership of the hexaword and allocating it into the Bcache, the
NVAX CPU performs the desired write to that block in the backup cache.
The NVAX CPU relinquishes ownership of the data by performing a WDISOWN
write-back of the block when it sees an access to that hexaword on the NDAL bus
from a DMA device.

4.4.2 Backup Cache Overview
The backup cache (Bcache) is direct-mapped, with quadword access size and a
hexaword (32 bytes) block size. The Bcache allocates on reads and writes, and
uses a write-back protocol. Bcache tags and cache data are stored in static RAMs
that reside on the CPU module. The NVAX CPU implements the control for the
Bcache tags and data.
The Bcache and Pcache communicate internally to the NVAX CPU in such a
way as to maintain the Pcache as a strict subset of the Bcache. This is done
through the use of "invalidate" commands sent automatically from the Bcache
to the Pcache whenever the Bcache must invalidate a block. The Bcache will
invalidate a block in response to DMA activity to the corresponding memory
location, or to make room in the cache for new data. In the case of Bcache
blocks that contain data for NVAX-owned memory locations, the process of
invalidating the block involves a write-back of the data contained in the cache
to the corresponding memory location. The write-back operation simultaneously
relinquishes ownership of the hexaword.
The flow of memory transactions within the NVAX CPU is as follows:

KA680 Cache Memory Overview 4–19

KA680 Cache Memory Overview
4.4 Backup Cache
I-stream read requests generated within the NVAX are first issued to the VIC.
If the data is found there, then the request is satisfied. If the request misses in
the VIC, then the request is forwarded to the Pcache. Since the VIC stores only
I-stream data, all D-stream requests bypass the VIC and start at the Pcache. If
the request hits in the Pcache, then the NVAX uses this data. Otherwise, the
request is forwarded to the Bcache. If the read request hits in the Bcache, then
the NVAX uses this data and simultaneously copies it into the Pcache to speed up
future references to this data. If the request misses in the Bcache as well, then
an IREAD or DREAD cycle is issued to the memory subsystem on the NDAL bus.
When the data comes back from the memory subsystem, the Pcache, Bcache, and
possibly the VIC each allocate a block and fill it with this data. Note that the
VIC caches only I-stream data. Likewise, reads that hit in the Bcache will also
cause fills in the Pcache, and if I-stream, the VIC as well.
Normal (that is, not disown writes) write transactions generated within the
NVAX CPU cause cache lookups in the Pcache and Bcache. If the location to be
written is found in the Bcache and is marked in the Bcache as owned by the
NVAX CPU, then the write transaction will update only the Bcache and Pcache
entries and will not be sent to the memory subsystem. Note that on writes,
the Pcache is updated only if the referenced location was already cached in the
Pcache.
If the location to be written is cacheable but is not currently cached in the
Bcache, or is cached but not marked as owned by the NVAX CPU, then
the NVAX CPU will issue an OREAD on the NDAL bus to gain ownership of
the location. When the memory subsystem returns the data corresponding to
the OREAD, the NVAX CPU will allocate a block in the Bcache if necessary,
and will set the corresponding ownership bit in the Bcache. The setting of this
ownership bit in the Bcache indicates to the NVAX CPU that it may freely update
the contents of the cache without compromising the consistency of memory. The
write transaction that initially caused the OREAD then completes, updating only
the Bcache and Pcache entries. Since the data is now owned by the NVAX CPU,
subsequent writes to that location will not result in NDAL cycles, since the data
is only updated in the cache. The resulting speedup of write transactions and
the conservation of NDAL bus bandwidth are the primary reasons for using the
write-back algorithm in the Bcache. Note that under normal conditions, the
memory ownership mechanism and the write-back nature of the Bcache is totally
transparent to software.

4.4.3 Backup Cache Operating Modes
The backup cache has four distinct modes of operation.
•

Cache on. Normal operation.

•

Cache off. Reset puts the backup cache into the OFF state. The backup cache
may be enabled/disabled (turned ON/OFF) by software through the Backup
Cache Control IPR. Cache off mode is described in Section 4.4.13.1.

•

Force hit. This forces all memory space reads and writes forwarded to the
Bcache to hit in the Bcache. This mode is used for testing and initialization
purposes. Force hit mode is described in Section 4.4.13.2.

•

Error transition mode. The Bcache enters error transition mode (ETM) upon
recognition of some error conditions or when put into ETM explicitly by an
IPR write. Error transition mode is described in Section 4.4.13.3.

4–20 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.4 NVAX Backup Cache Organization and Interface
The NVAX backup cache is configurable based on the size and speed of the
cache RAMs used to implement the cache on the board. Because of this, the
configuration register must be written with the appropriate information based on
the size and speed of the Bcache RAM chips used on the KA680. This function is
performed by the console firmware.
The KA680 has a 128 kilobyte Bcache. The NVAX CPU provides a control register
by which it can be configured with the size of the Bcache. This is controlled by
the SIZE field in the CCTL register, as described in Section 4.4.8.1. Firmware
configures the NVAX CPU to operate with the amount of Bcache memory provided
on the module.

Table 4–11 Backup Cache Size and RAMs Used
Cache Size

Tag RAM Size

Data RAM Size

Number of Tags

Valid Bits
Per Tag

128 kilobytes

4K x 4

16K x 4

The cache has a block size of 32 bytes and has no subblocks. The data bus to the
cache is 8 bytes wide, so in order to read out an entire block, 4 accesses are done.
Each block contains 32 bytes of data and has associated with it a tag, a valid bit,
and an owned bit. ECC protection is provided on each quadword in the cache.
ECC protection is also provided on the tag store.
Each address bit serves either as an index bit or as a tag bit. Table 4–12 shows
how the bits are used.
Table 4–12 Tag and Index Interpretation Based on Cache Size
Cache Size

Tag Bits Used

Index Bits Used

128 kilobytes

Tag<28:17>

Index<16:5>

Note that bits <31:29> are "don’t cares" with respect to the mapping of tags and
index bits because the KA680 is operated with the NVAX CPU in 30-bit address
mode.
Bit <29> is a "don’t care" because cacheable references always have bit <29>=0.
For example, they are always in VAX memory space. With the NVAX CPU in
30-bit mode, Bit <29>=1 indicates I/O space references, which are not cacheable.
The NVAX CPU also requires software to program the backup cache speed as
dictated by the speed of the RAM chips used on the board. The TAG_SPEED and
DATA_SPEED fields of the Bcache control register, CCTL, are used to control the
number of NVAX cycles used by the Cbox to access the RAMs. These bit fields
are written by firmware with the values appropriate to the module configuration.

KA680 Cache Memory Overview 4–21

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.5 Backup Cache Block Diagrams
Figure 4–15 and Figure 4–16 show the connections to the tag store and data
RAMs, and the way the address is used for the 128-kilobyte cache used on the
KA680.
Figure 4–15 Tags and Data for 128-Kilobyte Cache

Tag Index<16:5>

TAG STORE
5 PARTS,

Valid Bit

Owned Bit

4K×4

ECC<5:0>

Tag<28:17>

Data Index<16:3>

DATA STORE
18 PARTS,

16K×4

ECC<7:0>

(128KB)

Data<63:00>

Figure 4–16 Address Used for 128-Kilobyte Cache

31 30 29 28
X

X X

05 04 03 02

19 18
Tag-12 Bits

Data and Tag Store Index-12 Bits

Unused

Used to Address Data Quadword Within Hexword
Unused for Tag Store
LJ-01276-TI0

4–22 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.6 Backup Cache Data Block Allocation
4.4.6.1 Read References
On cacheable read references that are not in the Pcache, the request is forwarded
to the Bcache internally to the NVAX CPU. If the requested quadword cannot be
found in the Bcache, a read request is sent from the NVAX CPU to the memory
subsystem. The length of the request is a hexaword, which is the same size as
the Bcache and Pcache block size. Before the request is sent, however, the Bcache
and Pcache each allocate a block for the new data. When the data returns from
memory, copies are made in both the Bcache and Pcache to reduce latency on
future references. Note that if the Bcache block being displaced by the new data
is valid and has its owned bit set, then the displaced block will be written back
to memory via a disown write transaction on the NDAL bus before the read for
the cache fill is issued. This updates the displaced hexaword in memory with
the possibly modified cached copy, and relinquishes ownership of that hexaword
location. Since the Bcache is direct-mapped, that is, it has only one bank, there is
no need to decide which bank to allocate for the fill.
4.4.6.2 Write References
The Bcache performs allocates on writes. Write references to cacheable memory
locations do not propagate directly out to memory unless the Bcache has
been disabled by clearing CCTL<ENABLE>. If the hexaword being written is
contained in the Bcache and is owned by the NVAX CPU, then the write is done
only to the Bcache entry. If the referenced hexaword is not in the Bcache, or if
it is in the Bcache but is not owned by the NVAX CPU, then ownership of the
hexaword will be obtained by issuing an ownership read on the NDAL bus to the
memory subsystem. Once ownership has been obtained, the write will proceed as
described above, updating only the Bcache.
Write references will update the Pcache only if the reference is already cached
there. The Pcache does not perform allocations on writes.

4.4.7 Effects of I/O Traffic on the Backup Cache
In the following paragraphs, the term "DMA device" or "DMA traffic" refer to the
Q22–bus, DSSI bus, or Ethernet interfaces.
The NVAX CPU monitors all DMA traffic to main memory. For each reference,
the NVAX CPU will check the contents of the backup cache to see if it contains
the hexaword being referenced. If the referenced hexaword is not in the Bcache,
then the NVAX CPU takes no further action. If, however, the referenced
hexaword is currently cached, the specific actions taken thereafter depend on
the type of DMA reference and whether the referenced hexaword is owned by the
NVAX CPU.
If the Bcache contains the hexaword referenced by the I/O device, but the Bcache
block is not marked as "owned," then the NVAX CPU will invalidate the Bcache
entry only if the DMA reference was a write. Note that in this case the Pcache
is also checked for the referenced hexaword, and the appropriate Pcache block
is invalidated if found. No cache entries are invalidated due to reads from DMA
devices.
If the Bcache contains the hexaword referenced by the I/O device, and the Bcache
block is marked as "owned," then two things happen. First, when the reference
from the DMA device is received by the memory subsystem, the reference will
be pended in the NMC memory controller because the referenced hexaword is

KA680 Cache Memory Overview 4–23

KA680 Cache Memory Overview
4.4 Backup Cache
not currently owned by the memory subsystem. Simultaneously, the NVAX CPU
determines that it owns the hexaword referenced by the DMA device, and will
write back the Bcache block to memory using an ndal disown write transaction
(WDISOWN), relinquishing ownership of the hexaword in the process. The
memory controller will respond to the disown write by updating the contents of
main memory with the value from the Bcache, then allowing the DMA reference
to complete.

4.4.8 Backup Cache Internal Processor Registers
The Bcache processor registers that are implemented by the NVAX CPU are
logically divided into three groups, as follows:
•

Normal—Those IPRs that address individual registers in the NVAX CPU chip
or system environment.

•

Bcache tag IPRs—The read-write block of IPRs that allow direct access to the
Bcache tags.

•

Bcache deallocate IPRs—The write-only block of IPRs by which a Bcache
block may be deallocated.

Each group of IPRs is distinguished by a particular pattern of bits in the IPR
address, as shown in Figure 4–17.
Figure 4–17 IPR Address Space Decoding as Seen by Software

Normal IPR Address

SBZ

08 07

25 24 23

IPR Number

SBZ

Bcache Tag IPR Address
05 04

25 24 23 22 21 20 19 18 17 16

31
SBZ

0 X

0 0

Bcache Tag Index

00
SBZ

Bcache Deallocate IPR Address
05 04

25 24 23 22 21 20 19 18 17 16

31
SBZ

X 0

Bcache Tag Deallocate Index

00
SBZ
LJ-01277-TI0

4–24 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
The numeric range for each of the three groups is shown in Table 4–13.
Table 4–13 IPR Address Space Decoding - KA680
IPR Group

Mnemonic1

IPR Address Range
(hex)

Contents

Normal

–

00000000..000000FF 256 individual IPRs

Bcache Tag

BCTAG

01000000..0101FFE02 4K Bcache tag IPRs, each
separated by 20(hex) from the
previous one

Bcache Deallocate

BCFLUSH

01400000..0141FFE02 4K Bcache tag deallocate IPRs,
each separated by 20(hex)
from the previous one

1
2

The mnemonic is for the first IPR in the block.

Unused fields in the IPR addresses for these groups should be zero. Neither hardware nor microcode
detects and faults on an address in which these bits are nonzero, and they are ignored with respect to
the tag or data location that is accessed.

KA680 Cache Memory Overview 4–25

KA680 Cache Memory Overview
4.4 Backup Cache
Because of the sparse addressing used for IPRs in groups other than the normal
group, valid IPR addresses are not separated by one. Rather, valid IPR addresses
are separated by 20(hex). For example, the IPR address for Bcache tag 0 is
01000000 (hex), and the IPR address for Bcache tag 1 is 01000020 (hex). In
this group, bits <4:0> of the IPR address are ignored, so IPR numbers 01000001
through 0100001F all address Bcache tag 0.
Processor registers in all groups except the normal group are processed entirely
by the NVAX CPU chip and will never appear on the NDAL. This is also true for
a number of the IPRs in the normal group. IPRs in the normal group that are
not processed by the NVAX CPU chip are converted into I/O space references and
passed to the system environment via a Read or Write command on the NDAL.
The Bcache processor registers implemented by the NVAX CPU are are shown in
Table 4–15.
Table 4–15 Bcache/NDAL Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

Bcache Control Register

CCTL

160

NVAX 2-5

Reserved for NVAX

–

161

–

NVAX 2-6

Bcache Data ECC

BCDECC 162

NVAX 2-5

Bcache Error Tag Status

BCETSTS 163

NVAX 2-5

Bcache Error Tag Index

BCETIDX 164

NVAX 2-5

Bcache Error Tag

BCETAG

165

NVAX 2-5

Bcache Error Data Status

BCEDSTS 166

NVAX 2-5

Bcache Error Data Index

BCEDIDX 167

NVAX 2-5

Bcache Error Data ECC

BCEDECC 168

NVAX 2-5

Reserved for NVAX

–

169

–

NVAX 2-6

Reserved for NVAX

–

170

–

NVAX 2-6

Fill Error Address

CEFADR

171

NVAX 2-5

Fill Error Status

CEFSTS

172

NVAX 2-5

Reserved for NVAX

–

173

–

NVAX 2-6

NDAL Error Status

NESTS

174

NVAX 2-5

Reserved for NVAX

–

175

–

NVAX 2-6

NDAL Error Output Address

NEOADR 176

NVAX 2-5

Reserved for NVAX

–

NVAX 2-6

177

NDAL Error Output Command

NEOCMD 178

NVAX 2-5

Reserved for NVAX

–

179

–

NVAX 2-6

NDAL Error Data High

NEDATHI 180

NVAX 2-5

Reserved for NVAX

–

181

–

NVAX 2-6

NDAL Error Data Low

NEDATLO 182

NVAX 2-5

4–26 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–15 Bcache/NDAL Processor Registers
Number
Register Name

Mnemonic (Dec) (Hex) Type Impl

Cat

Reserved for NVAX

–

183

–

NVAX 2-6

NDAL Error Input Command

NEICMD 184

NVAX 2-5

Reserved for NVAX

–

185

–

NVAX 2-6

Reserved for NVAX

–

186

–

NVAX 2-6

Reserved for NVAX

–

187

–

NVAX 2-6

Reserved for NVAX

–

188

–

NVAX 2-6

Reserved for NVAX

–

189

–

NVAX 2-6

Reserved for NVAX

–

190

–

NVAX 2-6

Reserved for NVAX

–

191

–

NVAX 2-6

Bcache Tag-KA680 (01000000 - 0101FFE0 HEX)

BCTAG

–

NVAX 2-5

Bcache Deallocate-KA680 (01400000 - 0141FFE0
HEX)

BCFLUSH –

–

NVAX 2-5

If a write-only NVAX processor register is read, the Cbox returns
UNPREDICTABLE data. Reading an unimplemented NVAX processor register
returns UNPREDICTABLE data; if an unimplemented register is written, the
write is discarded and normal operation continues.
If software attempts to access an IPR, specifying an address that is not within the
NVAX block of IPR addresses, the reference will be converted to an I/O space read
or write. In this case, the NVAX merges the IPR address with E1000000 hex,
effectively adding the base I/O space address of the IPR block to the IPR address.
This is done in hardware by forcing bits <31:29> and bit <24> to 1s. (The other
upper bits are expected to be received as 0s.)
From this point on, the transaction is treated as an I/O space transaction by the
NVAX. It sends the request off-chip to the NDAL. When the data returns, it is not
cached by the NVAX. I/O space reads and writes are never cached in the primary
cache or the backup cache.

KA680 Cache Memory Overview 4–27

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.8.1 Bcache Control IPR (CCTL)
CCTL is a read/write register that contains bits controlling the behavior of
the Bcache and related portions of the NVAX CPU. The bits are detailed in
Figure 4–18 and Table 4–16.
Figure 4–18 IPR Format of CCTL

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
X X X X X X X X

X X X X X

SW_ETM

ENABLE

HW_ETM

TAG_SPEED
DATA_SPEED
SIZE
FORCE_HIT
DISABLE_ERRORS
SW_ECC
TIMEOUT_TEST
DISABLE_PACK
FORCE_NDAL_PERR
LJ-01278-TI0

4–28 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–16 CCTL
Name

Extent

Type

Description

ENABLE

RW,0

Turns the Bcache on and off.

TAG_SPEED

RW,0

Controls time NVAX allows to access the
tag RAMs.

DATA_SPEED

3:2

RW,0

Controls time NVAX allows to access the
data RAMs.

SIZE

5:4

RW,0

Selects between backup cache sizes.

FORCE_HIT

RW,0

Forces memory reads and writes to hit
in the backup cache.

DISABLE_ERRORS

RW,0

Disables all backup cache ECC errors.

SW_ECC

RW,0

Enables use of ECC check bits as given
by software for the tag and data.

TIMEOUT_TEST

RW,0

Puts the NDAL read timeout timers into
test mode.

DISABLE_PACK

RW,0

Disables the write packer.

FORCE_NDAL_PERR

RW,0

Forces a parity error in the command
field of the next outgoing NDAL
transaction.

SW_ETM

Used by software to put the backup
cache into ETM.

HW_ETM

Used by hardware to put the backup
cache into ETM.

ENABLE
When ENABLE=1, the backup cache is enabled for operation. When ENABLE=0,
the backup cache is off and all references are treated as misses and are not looked
up in the backup cache. When the backup cache is off, FORCE_HIT, SW_ETM,
and HW_ETM are ignored. System reset clears this bit so that the Bcache is off
when the chip is reset.
TAG_SPEED
The NVAX provides this bit to configure the NVAX to function properly with
Bcache tag RAM chips of various speeds. This bit will select the mode of Bcache
operation that corresponds to the speed of the RAM chips used on the module.
Note
Improper setting of these bits can prevent the NVAX CPU from
functioning properly.

This bit is cleared on system reset and should not be set to a value other than
that recommended in Table 4–17. Table 4–17 shows the relationship of the value
of TAG_SPEED and the access time of the tag RAMs, given in NVAX cycles. This
is the total RAM access time including internal NVAX processing time. Reset
clears this bit so that the tag access repetition rate is 3 cycles when the chip is
reset. See Appendix J.

KA680 Cache Memory Overview 4–29

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–17 TAG_SPEED
Tag Read

Tag Write

TAG_SPEED

(rep rate)

Comments

3 Cycles

–

4 Cycles

May not be used when DATA_
SPEED=00

DATA_SPEED
The NVAX provides this bit to configure the NVAX to function properly with
Bcache data RAM chips of various speeds. This bit will select the mode of Bcache
operation that corresponds to the speed of the Bcache data RAM chips used on
the module.
Note
Improper setting of this bit can prevent the NVAX CPU from functioning
properly.

This bit is cleared on system reset and should not be set to a value other than
that recommended in Table 4–17. Table 4–18 shows the relationship of the value
of DATA_SPEED and the access time of the DATA RAMs, given in NVAX cycles.
This is the total RAM access time including internal NVAX processing time.
Reset clears this bit so that the Bcache data access repetition rate is 2 cycles
when the chip is reset.
Table 4–18 DATA_SPEED
Data Read

Data Write

DATA_SPEED<1:0>

(rep rate)

Comments

2 Cycles

3 Cycles

May not be used when
TAG_SPEED=1

3 Cycles

4 Cycles

–

4 Cycles

5 Cycles

–

Unused

–

SIZE
These two bits are used to program the size of the Bcache. Backup cache size
is programmed by using the SIZE bits, as shown in Table 4–19. These bits are
cleared on reset so that when the chip is reset, the correct setting is selected by
default.
Note
On the KA680, specifying any value other than that for the 128-kilobyte
cache is strictly forbidden, because it will prevent operation.

4–30 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–19 SIZE
SIZE<1:0>

Backup Cache Size

128 kilobytes

FORCE_HIT
When FORCE_HIT is set, all memory references, both D-stream and I-stream
reads and writes, are forced to hit in the backup cache. The tag store state is not
changed but data is always read or written. Reset clears this bit.
The backup cache must be enabled when the cache is used in FORCE_HIT mode.
This mode provides the capability for directly accessing the Bcache data store,
and is expected to be used for testing purposes only.
DISABLE_ERRORS
When DISABLE_ERRORS is set, all ECC errors from the backup cache are
ignored. The backup cache data syndrome is loaded into the BCEDECC IPR on
every cache access; the behavior of BCETSTS, BCETIDX, BCETAG, BCEDSTS,
and BCEDIDX is unpredictable. This feature allows operation of the backup
cache even if the error detection and correction logic is faulty. It also allows
access to the backup cache syndrome for the purposes of testing the ECC logic.
Reset clears this bit.
SW_ECC
When SW_ECC is clear, the NVAX CPU generates correct ECC check bits for all
writes to the tag store and data RAMs. When SW_ECC is set, the NVAX does not
generate the check bits when the backup cache is written with data, but uses the
check bit values as specified by software in the BCDECC register.
When SW_ECC is set and the tag store is written using an IPR write to BCTAG,
the NVAX uses the check bits for the tag store as given through the IPR write.
The value of SW_ECC does not affect tag store transactions other than IPR
writes.
Reset clears this bit.
TIMEOUT_TEST
When TIMEOUT_TEST is set, the NVAX uses the internal clock to clock its read
timeout counter. When TIMEOUT_TEST is clear, the NVAX uses an internal
time base clock its timeout counters. Reset clears this bit. The effect of setting
this bit is to cause reads on the NDAL to timeout much sooner than they would if
this bit were clear. This is useful primarily for testing purposes. This bit should
not be set during normal operation.
DISABLE_PACK
The NVAX normally packs consecutive memory space writes to the same
quadword into one write, thereby saving Bcache or NDAL bus bandwidth,
depending on whether the referenced hexaword is cached. When DISABLE_
PACK is set, the NVAX does not pack quadword writes together. Instead, the
write packing logic inside the NVAX CPU passes every write directly to its
destination: either the Bcache or the memory subsystem. When the bit is clear,
the NVAX packs writes together to maximize performance. DISABLE_PACK is
intended for testing purposes only. Reset clears this bit.

KA680 Cache Memory Overview 4–31

KA680 Cache Memory Overview
4.4 Backup Cache
FORCE_NDAL_PERR
When a 1 is written to FORCE_NDAL_PERR, a parity error is caused in the
command field of the next outgoing NDAL transaction. Setting this bit causes
only one parity error. Another parity error will be produced with the bit is cleared
and set again by software.
Reset clears this bit.
SW_ETM
This is a software-writable bit to put the backup cache into error transition mode.
When the cache is on and software ascertains that the cache is producing errors,
it can set this bit in order to turn off the cache while ensuring cache coherency.
Software can then flush owned data through use of the Bcache deallocate IPR,
BCFLUSH. In this manner, the unique data can be extracted from the cache
before it is turned off completely.
HW_ETM
Hardware sets this bit when an uncorrectable error is detected in the backup
cache tag store or data RAMs, unless DISABLE_ERRORS is set. Hardware sets
the bit to put the backup cache into error transition mode.
Software clears HW_ETM by writing a 1 to it.
4.4.8.2 Backup Cache Data ECC IPR (BCDECC)

Figure 4–19 Format of the BCDECC

31 30 29 28 27 26 25
X X

X X X X

06 05 04 03 02 01 00

22 21 20 19 18 17 16 15 14 13 12 11 10 09
ECCHI

X X X X X

X X X X X X X

ECCLO

X X

X X X X
LJ-01279-TI0

The ECCHI field corresponds to data check bits <7:4>. The ECCLO field
corresponds to data check bits <3:0>.
This register is written by software. It is a write-only register.
Software writes BCDECC using an MTPR instruction. The value in the register
is then used to explicitly write ECC into the data RAMs during any write of the
data RAMs, but only if SW_ECC is set in the control register. If SW_ECC is not
set, hardware ignores the value in BCDECC and generates the check bits to be
written using the ECC syndrome generator.
One use of BCDECC is to allow software to explicitly write bad ECC into the data
RAMs in order to test the Bcache error detection logic.
Reset does not affect this register.

4–32 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.8.3 Backup Cache Tag Store Error Registers (BCETSTS, BCETIDX, BCETAG)
On some tag store errors, hardware overwrites the corrupted values so that they
cannot be diagnosed by reading the tag store directly. For this reason, there
are tag store error registers that hold the relevant data so that software can
understand the problem.
The tag store error registers are loaded when any tag store error occurs. The
status bits in BCETSTS indicate what sort of error happened. Correctable errors
are indicated by the CORR bit; the UNCORR and BAD_ADDR errors are both
uncorrectable errors.
If no error is yet logged in the registers, the registers are loaded when either a
correctable or an uncorrectable error occurs. Once the registers are loaded with
information from a correctable error, they are locked against further correctable
errors, and are only loaded again if an uncorrectable error happens. At this time,
either UNCORR or BAD_ADDR is set. The LOCK bit in BCETSTS is set as well.
In this way, information from the first correctable error is held in the registers,
and is only overwritten if an uncorrectable error happens later.
The error registers are cleared and unlocked by software. If the error registers
hold data from a noncorrectable error and yet another noncorrectable error
happens before the error registers are unlocked, the LOST_ERR bit is set. This
indicates to software that it does not have sufficient information in the error
registers to recover from all uncorrectable errors that have occurred.
4.4.8.3.1 Bcache Error Tag Status (BCETSTS) The BCETSTS register gives
the general status of an error in the tag store, indicating the transaction taking
place at the time and the type of error. The register is written by hardware and
read by software. Hardware does not clear the error bits in this register; this
must be done by software using write-one-to-clear to the bottom five bits of the
register.
Figure 4–20 IPR Format of BCETSTS
05 04 03 02 01 00

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09
X X X X X X X X X X X X X X X X X X X X X X

TS_CMD

LOCK
CORR
UNCORR
BAD_ADDR
LOST_ADDR
LJ-01280-TI0

KA680 Cache Memory Overview 4–33

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–20 Bcache Tag Store Status IPR Format
Name

Extent

Type

Description

LOCK

Indicates that BCETSTS, BCETIDX,
and BCETAG are locked.

CORR

Indicates that a correctable ECC error
was encountered.

UNCORR

Indicates that an uncorrectable ECC
error was encountered.

BAD_ADDR

Indicates that an addressing error was
detected. This is an uncorrectable error.

LOST_ERR

Indicates that more than one
uncorrectable error occurred, which
was not recorded in the error registers.

TS_CMD

9:5

Indicates what tag store command was
being processed at the time the error
occurred.

LOCK
Whenever the tag store error registers are locked due to an uncorrectable error,
the LOCK bit is set. At this time, either UNCORR or BAD_ADDR is also set to
indicate the type of uncorrectable error. When the LOCK bit is set, the BCETSTS,
BCETIDX, and BCETAG registers are all locked. Clearing the lock bit unlocks all
three registers. The LOCK bit is set by hardware and it is cleared by software. It
is a write-one-to-clear bit.
CORR
CORR is set when the tag store ECC decoder detects a correctable error. When
this occurs, the Bcache tag store error registers are loaded and are locked against
further correctable errors. They are not locked against an uncorrectable error
that follows.
If a correctable error is followed by an uncorrectable error, the CORR bit remains
set.
The CORR bit is set by hardware and it is cleared by software. It is a write-oneto-clear bit.
UNCORR
UNCORR is set when the tag store ECC decoder detects an uncorrectable error.
When this occurs, the Bcache tag store error registers are loaded and locked.
The UNCORR bit and the BAD_ADDR bit are exclusive: only one of them is set
for a given error that sets the LOCK bit. If the other type of error occurs later,
the related bit is not set since the register is already locked. In this case, LOST_
ERR is set instead.
The UNCORR bit is set by hardware and it is cleared by software. It is a writeone-to-clear bit.
BAD_ADDR
BAD_ADDR is set when the tag store ECC decoder detects an error in the address
bit, indicating some problem with the address lines going to the tag RAMs. This
is an uncorrectable error; thus, when it occurs, the Bcache Tag Store Error
registers are loaded and locked.

4–34 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
The UNCORR bit and the BAD_ADDR bit are exclusive: only one of them is set
for a given error that sets the LOCK bit. If the other type of error occurs later,
the related bit is not set since the register is already locked. In this case, LOST_
ERR is set instead.
The BAD_ADDR bit is set by hardware and it is cleared by software. It is a
write-one-to-clear bit.
LOST_ERR
LOST_ERR indicates that after the first uncorrectable error was recorded in the
tag store error registers, an additional uncorrectable error occurred for which
state was not saved. LOST_ERR is set by hardware and is cleared by software.
It is a write-one-to-clear bit.
TS_CMD
The five bit field, TS_CMD, indicates what the tag store was doing when the error
was detected. Its values are listed in Table 4–21.
Table 4–21 Interpretation of TS_CMD
TS_CMD

Name

Tag Store Operation

00111

DREAD

Data-stream tag lookup

00011

IREAD

Instruction-stream tag lookup

00010

OREAD

Ownership-read tag lookup for a write or a READ_
LOCK

01000

WUNLOCK

Ownership-read tag lookup for a WRITE_UNLOCK

01101

R_INVAL

Cache coherency tag lookup as the result of NDAL
DREAD or IREAD

01001

O_INVAL

Cache coherency tag lookup as the result of NDAL
OREAD or WRITE

01010

IPR_DEALLOC

Tag lookup for an explicit IPR deallocate operation

There are three tag store operations that do not cause any sort of errors: tag
store update after a fill, IPR write of the tag store, and IPR read of the tag store.
Thus, these commands will not appear in BCETSTS.
4.4.8.3.2 Bcache Error Tag Index (BCETIDX) This register is loaded and locked
when a tag store error occurs. If a correctable error is followed by a second error
that is not correctable, the register is loaded with information from the second,
more serious error. Except for this case, once it is locked, it is not changed until
software explicitly unlocks the register. This register is written by hardware and
read by software.
Figure 4–21 Backup Tag Store Error Address IPR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
Backup Cache Tag Store Address

LJ-01324-TI0

KA680 Cache Memory Overview 4–35

KA680 Cache Memory Overview
4.4 Backup Cache
BCETIDX contains the complete hexaword address corresponding to a tag store
request that resulted in an error. Since the full address is saved, both the cache
index and the cache tag of the request are known. Thus, this register shows what
index was being accessed when the error occurred as well as showing what the
tag of the request was. Software can compare this tag with the actual tag read
from the RAMs, which is saved in BCETAG.
4.4.8.3.3 Bcache Error Tag (BCETAG) This register is loaded when a tag store
error occurs. It is locked when an uncorrectable error occurs on a tag store access.
Once the register is locked, it is not overwritten until it is unlocked by software.
BCETAG is written by hardware and read by software. It is a read-only register
from the software point of view.
The register holds the data that was read from the tag store and produced the
error, as shown in Figure 4–22.
Figure 4–22 IPR Format of BCETAG
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
ECC

Tag

VALID
OWNED
LJ-01281-TI0

Table 4–22 BCETAG IPR Format
Name

Extent

Type

Description

VALID

Valid bit

OWNED

Ownership bit

ECC

16:11

ECC check bits

TAG

31:17

Backup cache tag

VALID
VALID is the bit read from the tag RAMs, which indicates whether the block is
valid in the Bcache.
OWNED
OWNED is the bit read from the tag RAMs, which indicates whether the Bcache
(NVAX) owns the memory hexaword contained in this Bcache block.
ECC
The ECC field contains the check bits as read from the tag RAMs during the
tag access that produced the error. The code used for tag ECC is shown in
Figure 4–23. The check bit marked with a "1" in each row is generated by a
parity tree whose inputs are the Tag, Valid, Owned, and AP (address parity) bits,
which are marked with a "1" in that row.

4–36 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Figure 4–23 Tag Store Error Correcting Code Matrix

Syndrome

Generated Check Bits

Tag Bits

C1 C0 C2 C3 C4 C5 0

V 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 AP

0 0

1 1

0 1

1 1

0 1

1 0

1 1

Nibble 0

Nibble 1

Nibble 2

Nibble 3

Nibble 4

Nibble 5, Three Bits Only
Not Stored
Even Parity - C0, C2, C3, C5
Odd Parity - C1, C4
Sn = (Generated Cn) XOR (Stored Cn)
LJ-01282-TI0

In a tag store read operation, a nonzero syndrome indicates an error. If the
syndrome generated matches one of the columns in the matrix, the error is
correctable and the matching column indicates the bit to be corrected. Any
syndrome value that is nonzero and does not match a column in the matrix
indicates an uncorrectable error.
Odd parity is used for check bits 1 and 4 to protect against the all-zeros failure
mode. Otherwise, all-zeros would be a valid code word. The choice of odd and
even parity bits prevents all-ones from being a valid code word as well.
TAG
The TAG field of BCETAG is the cache tag as read from the tag RAMs. It must
be interpreted based on the cache size being used, as shown in Table 4–23. When
certain address bits are not used as tag bits for the cache size given, their value
in BCETAG is 0.
Table 4–23 TAG Interpretation
Cache Size

Tag Bits Used

Unused Tag Bits

128 KB (KA680)

TAG<28:17>

TAG<31:29>

KA680 Cache Memory Overview 4–37

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.8.4 Backup Cache Data RAM Error Registers (BCEDSTS, BCEDIDX, BCEDECC)
The data RAM error registers hold data relevant to errors in the backup cache
data RAMs so that software can understand the problem.
BCEDSTS holds the general status of the problem. BCEDIDX holds the data
RAM index being used when the problem occurred. BCEDECC holds the
syndrome bits as calculated on the data, which was read from the RAMs when
the problem occurred.
If no error is yet logged in the data RAM error registers, the registers are loaded
when either a correctable or an uncorrectable error occurs. Once the registers are
loaded with information from a correctable error, they are locked against further
correctable errors, and are only loaded again if an uncorrectable error happens.
If an uncorrectable error happens, the LOCK bit in BCEDSTS is set and the
registers are not overwritten until software clears the error bits. In this way,
information from the first correctable error is held in the registers, and is only
overwritten if an uncorrectable error happens later.
If the registers are locked, any subsequent noncorrectable error causes the LOST_
ERR bit to be set, but does not modify any other information in the registers.
LOST_ERR indicates to software that it does not have sufficient information in
the error registers to recover from all uncorrectable errors that have occurred.
Of the backup cache data RAM error registers, only BCEDSTS is writable by
software. Software clears the error and LOCK bits, which re-enables all the data
RAM error registers to record the next error that occurs.
4.4.8.5 Bcache Error Data Status (BCEDSTS)
Figure 4–24 IPR Format of BCEDSTS

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11
X X X X X X X X X X X X X X X X X X X X

08 07 06 05 04 03 02 01 00

DR_CMD

LOCK
CORR
UNCORR
BAD_ADDR
LOST_ERR
LJ-01283-TI0

4–38 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–24 Bcache Data RAM Status IPR Format
Name

Extent

Type

Description

LOCK

Lock bit. Indicates that the BCEDSTS,
BCEDIDX, and BCEDECC registers are
locked.

CORR

Indicates that a correctable ECC error
was encountered.

UNCORR

Indicates that an uncorrectable ECC
error was encountered.

BAD_ADDR

Indicates that an addressing error was
detected.

LOST_ERR

Indicates that a second, uncorrectable
error occurred; it was not recorded in the
error registers.

DR_CMD

11:8

Indicates what command was being
processed at the time the error occurred.

The LOCK bit is set when an error that was not correctable has occurred. If the
CORR bit is set, the data ram error registers are locked unless an uncorrectable
error occurs. On an uncorrectable error, the LOCK bit is set and the registers are
permanently locked until unlocked by software.
LOCK
Whenever the data RAM error registers are loaded with an uncorrectable error,
the LOCK bit is set. At this time either UNCORR or BAD_ADDR is also set
to indicate the type of uncorrectable error. When the LOCK bit is set, the
BCEDSTS, BCEDIDX, and BCEDECC registers are all locked. Clearing the
lock bit unlocks all three registers. The LOCK bit is set by hardware and it is
cleared by software. It is a write-one-to-clear bit.
CORR
CORR is set when the data ECC decoder detects a correctable error. When this
occurs, the Bcache data error registers are loaded and locked against further
correctable errors. The CORR bit is set by hardware and it is cleared by software.
It is a write-one-to-clear bit.
UNCORR
UNCORR is set when the data ECC decoder detects an uncorrectable error. When
this occurs, the Bcache data error registers are loaded and locked. The UNCORR
bit is set by hardware and it is cleared by software. It is a write-one-to-clear bit.
BAD_ADDR
BAD_ADDR is set when the data ECC decoder detects an error in the address bit,
indicating some problem with the address lines going to the data RAMs. This is
an uncorrectable error; thus, when it occurs, the Bcache data error registers are
loaded and locked. The BAD_ADDR bit is set by hardware and it is cleared by
software. It is a write-one-to-clear bit.
LOST_ERR
LOST_ERR indicates that after the first uncorrectable error was recorded in the
data error registers, an additional uncorrectable error occurred for which state
was not saved. LOST_ERR is set by hardware and is cleared by software. It is a
write-one-to-clear bit.

KA680 Cache Memory Overview 4–39

KA680 Cache Memory Overview
4.4 Backup Cache
DR_CMD
The DR_CMD field indicates what the data RAMs were doing when the error was
detected. Its values are listed in Table 4–25.
Table 4–25 Interpretation of DR_CMD
DR_CMD<11:7>

Name

Data RAM Operation

0111

DREAD

Data lookup for a D-stream read.

0011

IREAD

Data lookup for an I-stream read.

0100

WBACK

Data lookup for a write-back.

0010

RMW

Data lookup for a read-modify-write. Done for
normal writes and WRITE_UNLOCKs.

There are two data RAM operations that do not cause any sort of errors: full
quadword writes and fills. Thus, these commands will not appear in BCEDSTS.
DR_CMD is only written by hardware. It is read-only for software.
4.4.8.5.1 Bcache Error Data Index (BCEDIDX) This register holds the index of
a data RAM transaction; it is loaded when an error is detected on a data RAM
access. The index loaded due to a correctable error is not overwritten unless an
uncorrectable error occurs afterwards. If an uncorrectable error occurs, BCEDIDX
is loaded and locked. BCEDIDX is unlocked by software; the LOCK bit is in the
BCEDSTS register.
BCEDIDX is read-only from software’s point of view.
Figure 4–25 BCEDIDX

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
0

Backup Cache Data RAM Index

Undefined (KA680)
LJ-01284-TI0

BCEDIDX must be interpreted based on the cache size being used, as shown in
Table 4–26. When certain address bits are not used as index bits for the cache
size given, their value in BCEDIDX is undefined.
Table 4–26 BCEDIDX Interpretation
Cache Size

Index Bits Used

Undefined Index Bits

128 KB (KA680)

BCEDIDX<16:3>

BCEDIDX<20:17>

4–40 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.8.6 Bcache Error Data ECC (BCEDECC)
This register holds the syndrome as calculated on the backup cache data and
check bits, and is loaded when an error occurs on a data RAM access. Once
loaded, it follows the same lock rules that the other Bcache data error registers
follow. It is unlocked by software. The lock bit is in the BCEDSTS register.
When DISABLE_ERRORS is set, BCEDECC is loaded on every quadword read
from the cache. This provides a way of testing the ECC logic by reading the
results of the syndrome calculation.
BCEDECC is read-only from software’s point of view.
Figure 4–26 Format of the BCEDECC Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
X X X X X X

ECCHI

X X X X X X X X X X X X

ECCLO

X X X X X X
LJ-01325-TI0

The ECCHI field corresponds to syndrome bits <7:4>. The ECCLO field
corresponds to syndrome bits <3:0>.
The code used for data ECC is shown in Figure 4–27. The check bit (C), which is
marked with a "1" in each row, is generated by a parity tree whose inputs are the
data bits marked with a "1" in that row.
Figure 4–27 Backup Cache Data Store Error Correcting Code Matrix

DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD D
DDD
0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 6CCC CCCC C 6 6 6 A
01 2345 6789 0123 4567 8901 2345 6789 0123 4567 8901 2345 6789 0012 3456 7123 P

1101
1010
0111
0100
1111
1111
1011
0000

0001
0010
1100
1111
0101
1010
1111
1111

0001
0010
1100
1111
1001
0110
0000
0000

0011
0100
1000
0001
0111
1101
0100
1111

1110
1011
0101
0010
0001
0100
1000
0000

1101
1010
0111
0001
0100
1000
1101
1111

1101
1010
0111
0001
0100
1000
0010
0000

1100
1011
0111
0001
1000
0010
0100
0000

0011
0100
1000
0001
0111
1101
1011
0000

0010
0100
1001
0001
1101
1011
1000
1111

0010
0100
1001
0001
1101
1011
0111
0000

1101
1011
0110
0001
0010
0100
0111
1111

1110
1011
0101
1111
0110
1001
1111
0000

1010
1101
0111
0001
1000
0100
1101
1111

1110
1101
0011
1111
0110
1001
0000
1111

0100
1010
0001
1000
0000
0000
1000
0000

0000
0000
0000
1000
0100
0010
0001
0000

0000
0000
0000
0100
0010
0001
0111
1111

1
1
1
0
1
1
0
0

S0
S1
S2
S3
S4
S5
S6
S7

AP is not stored in the RAMS.
Even parity - C0, C1, C2, C4, C5, C6
Odd parity - C3, C7
Sn = (Generated Cn) XOR (Stored Cn)
LJ-01286-TI0

As in tag store ECC, any syndrome value not matching a column in the table
indicates an uncorrectable error. Odd parity is used in check bits 3 and 7 to
prevent all-ones and all-zeros from being valid code words.

4.4.9 Fill Error Registers (CEFADR, CEFSTS)
Some errors are related to outstanding reads to memory. These errors may be
diagnosed using the CEFSTS and CEFADR registers. CEFSTS holds general
information about the type of read outstanding; CEFADR holds the address of the
outstanding read.

KA680 Cache Memory Overview 4–41

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.9.1 Bcache Error Fill Status (CEFSTS)
The CEFSTS register holds information related to a problem on a read that was
sent to memory. If a read request to memory times out or is terminated with an
error, the CEFSTS register and the CEFADR register are loaded and locked.
The register is read-write. Only the lowest five bits may be written, and then
only to clear them after an error. The lowest five bits are write-one-to-clear.
Figure 4–28 IPR Format of CEFSTS
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
X

X X

X X X

X X

RDLK
LOCK
TIMEOUT
RDE
LOST_ERR
ID0
IREAD
OREAD
WRITE
TO_MBOX
RIP
OIP
DNF
RDLK_FL_DONE
REQ_FILL_DONE
COUNT
UNEXPECTED_FILL
LJ-01287-TI0

4–42 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–27 Fill Error Status IPR Format
Name

Extent

Type

Description

RDLK

Indicates that a READ_LOCK was in
progress.

LOCK

Indicates that an error occurred and
the register is locked.

TIMEOUT

Fill failed due to transaction timeout.

RDE

Fill failed due to read data error.

LOST_ERR

Indicates that more than one error
related to fills occurred.

ID0

NDAL identification bit for the read
request.

IREAD

This is an I-stream read from the
Mbox, which may be aborted.

OREAD

This is an outstanding OREAD.

WRITE

This read was done for a write.

TO_MBOX

Data is to be returned to the Mbox.

RIP

READ invalidate pending.

OIP

OREAD invalidate pending.

DNF

Do not fill - data not to be written into
the cache or validated when the fill
returns.

RDLK_FL_DONE

Indicates that the last fill for a READ_
LOCK arrived.

REQ_FILL_DONE

Indicates that the requested quadword
was successfully returned from the
NDAL.

COUNT

16:15

For a memory space transaction,
indicates how many of the fill
quadwords have been successfully
returned. For I/O space, is set to 11
when the transaction starts since only
one quadword will be received.

UNEXPECTED_FILL

Set to indicate that an unexpected fill
was received on the NDAL.

RDLK
RDLK is set to show that a READ_LOCK is in progress. This bit is write-one-toclear.
The effect of performing a write-one-to-clear to this bit is to clear the VALID bit
for an entry that had its RDLK bit set; this has the effect of clearing out the
FILL_CAM entry. This is the same action taken when a WRITE_UNLOCK is
received.
This bit is normally not read as a one by software, because the NVAX microcode
ensures that the READ_LOCK-WRITE_UNLOCK sequence is an indivisible
operation. If, however, the first quadword of a READ_LOCK is returned
successfully and then the transaction either times out or is terminated in read
data error (RDE), CEFSTS is loaded with the RDLK bit set.

KA680 Cache Memory Overview 4–43

KA680 Cache Memory Overview
4.4 Backup Cache
LOCK
The LOCK bit is set when a read transaction that has been sent to memory
terminates in read data error or in timeout. At the same time, all information
corresponding to the read is loaded from the FILL_CAM into the CEFSTS
register. When the LOCK bit is set, one of TIMEOUT, RDE, or UNEXPECTED_
FILL is also set to indicate the type of error. Once the LOCK bit is set, none of
the information in CEFSTS or CEFADR changes, with the possible exception of
LOST_ERR, until the LOCK bit is cleared.
Hardware sets the LOCK bit and software clears it by writing a one to that
location.
TIMEOUT
TIMEOUT is set when a read transaction that was sent to the NDAL times out
for some reason. When TIMEOUT is set, the LOCK bit is also set.
Hardware sets the TIMEOUT bit and software clears it by writing a one to that
location.
RDE
RDE (read data error) is set when a read transaction that was sent to the NDAL
terminates in RDE. This could happen because of an uncorrectable main memory
error, or in the case of I/O addresses, it could mean some type of I/O error. When
the RDE bit is set, the LOCK bit is also set.
Hardware sets the RDE bit and software clears it by writing a one to that
location.
LOST_ERR
The LOST_ERR bit is set when CEFSTS is already locked and another RDE,
TIMEOUT, or UNEXPECTED_FILL error occurs. This indicates to software that
multiple errors have happened and state has not been saved for every error.
Hardware sets the LOST_ERR bit and software clears it by writing a one to that
location.
ID0
ID0 corresponds to the NDAL signal, ID_H, which was issued with the read that
failed. According to NDAL protocol, the NVAX, as well as other NDAL devices,
may have up to two outstanding transactions. Since memory reads are pended,
the NVAX could have issued up to two read requests before the error occurred.
This bit tells software which of the two NDAL transactions is associated with the
error.
IREAD
IREAD indicates that the transaction in error was an IREAD.
OREAD
OREAD indicates that the transaction in error was an OREAD (ownership read);
the OREAD may have been done for a write, a READ_LOCK, or a read modify.
WRITE
WRITE indicates that the transaction in error was an OREAD done because of a
write request.
TO_MBOX
TO_MBOX indicates that data returning for the read was to be sent to the Mbox.
The Mbox is the part of the NVAX CPU that contains the virtual/physical address
translation logic as well as the Pcache.
4–44 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
RIP
RIP (read invalidate pending) is set when the NVAX observes a DMA read
transaction on the NDAL to a memory location for which the NVAX is currently
acquiring ownership (that is, the OREAD transaction has already been sent to
the memory subsystem). This triggers a write-back of the block when the OREAD
fill data arrives; a valid copy of the data is kept in the cache.
OIP
OIP (OREAD invalidate pending) is set when a cache coherency transaction due
to an OREAD or a WRITE on the NDAL is requested for a block that has OREAD
fills outstanding at the time. This triggers a write-back and invalidate of the
block when the fill data arrives.
DNF
DNF (do not fill) is set when data for a read is not to be written into the Bcache.
This is the case when the cache is off, in ETM, or when the read is to I/O space.
The assertion of this bit prevents the block from being validated in the cache.
RDLK_FL_DONE
This bit is set in the fill cam when a READ_LOCK hits in the Bcache or the last
fill arrives from the BIU for a READ_LOCK. Once this is set, the corresponding
WRITE_UNLOCK is allowed to proceed. This overrides the FILL_CAM block
conflict on the WRITE_UNLOCK, which is inevitable since the READ_LOCK is
held in the FILL_CAM until the WRITE_UNLOCK is done.
REQ_FILL_DONE
This bit is set when the requested quadword of data was successfully received
from the NDAL. This information is provided to facilitate error handling.
COUNT
These two bits indicate how many of the expected four quadwords have been
returned successfully from memory for this read. If they are 00(BIN), no
quadwords have returned, if they are 01(BIN), one quadword has returned,
and so forth. If the entry was for a quadword read, the count bits are set to
11(BIN) when the reference is sent out.
UNEXPECTED_FILL
This bit is set to indicate that an RDE or RDR cycle was received on the NDAL
with an ID for which the FILL_CAM entry was not valid. When UNEXPECTED_
FILL is set, CEFSTS and CEFADR are loaded and locked.
4.4.9.2 Fill Error Address (CEFADR)
The CEFADR register holds the address of a fill that ended in an error condition.
It is loaded when an error is detected on a fill. It is a read-only register.
CEFADR is locked when CEFSTS is locked.

KA680 Cache Memory Overview 4–45

KA680 Cache Memory Overview
4.4 Backup Cache
Figure 4–29 IPR Format of CEFADR
03 02 01 00

31
Fill Error Address

LJ-01288-TI0

4.4.10 NDAL Error Registers (NESTS, NEOADR, NEOCMD, NEDATHI,
NEDATLO, NEICMD)
The NDAL error registers hold information related to NDAL errors. NESTS,
NDAL error status, holds error bits relating to any problems encountered.
NEOADR, NDAL error output address, holds the address corresponding to the
cycle that was in error. NEOCMD, NDAL error output command, holds the
command bits corresponding to the cycle in error.
NEDATHI, NDAL error data high longword, and NEDATLO, NDAL error data
low longword, hold the data from an NDAL cycle where NVAX detected a parity
error on the bus. NEICMD, NDAL error input command, holds the command bits
corresponding to a cycle with a parity error.
4.4.10.1 NDAL Error Status IPR (NESTS)
The NESTS register holds information about any errors that happened on the
NDAL. All six bits in this register are write-one-to-clear. Reset does not affect
this register. Powerup does not initialize the register.

4–46 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Figure 4–30 IPR Format of NESTS
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
X X X X X X X X X X X X X X X X X X X X X X X X X X

NOACK
BADWDATA
LOST_OERR
PERR
ICON_PERR
LOST_PERR
LJ-01289-TI0

Table 4–28 NESTS IPR Format
Name

Extent

Type

Description

NOACK

Indicates that an outgoing NVAX NDAL
cycle was not acknowledged by any of
the other NDAL devices. This bit locks
NEOADR and NEOCMD.

BADWDATA

Indicates that an outgoing NDAL
data cycle was accompanied by the
BADWDATA command. This bit locks
NEOADR and NEOCMD.

LOST_OERR

Indicates that multiple outgoing errors,
either NOACK or BADWDATA, were
detected.

PERR

Indicates that a parity error was
detected on the NDAL. This bit locks
NEDATHI, NEDATLO, AND NEICMD.

INCON_PERR

Inconsistent parity error. This means
that although NVAX detected a parity
error, some other device apparently
did not and acknowledged the NDAL
transaction.

LOST_PERR

Indicates that multiple NDAL parity
errors were detected.

NOACK
NOACK is set when NVAX detects that the NDAL signal "ACK_L" was not
asserted by any receiving device on the NDAL for an outgoing NVAX cycle. When
NOACK is set, NEOADR and NEOCMD are locked so that software can read
them to see what transaction was being attempted when the error occurred.
NOACK is set on any outgoing NVAX cycle that is not acknowledged, whether it
was an address cycle or a data cycle. The information that is locked in NEOADR
and NEOCMD corresponds to the address cycle of the transaction. For example,
if an outgoing write data cycle is not acknowledged, the address cycle for that
write operation is saved in NEOADR and NEOCMD.

KA680 Cache Memory Overview 4–47

KA680 Cache Memory Overview
4.4 Backup Cache
NOACK is not set if there was a previous BADWDATA. If a BADWDATA cycle is
NOACK’d, both BADWDATA and NOACK are set.
NOACK is cleared by write-one-to-clear.
BADWDATA
BADWDATA is set when the BIU receives data for a write-back from the cache
that had an uncorrectable ECC error, and thus is being issued on the NDAL with
the BADWDATA command. When BADWDATA is set, NEOADR and NEOCMD
are locked so that software can read them to retrieve the information about the
failure.
The address for the write operation is captured in NEOADR, and the command
information for the cycle is captured in NEOCMD.
NOACK is not set if there was a previous BADWDATA. If a BADWDATA cycle is
NOACK’d, both BADWDATA and NOACK are set.
LOST_OERR
LOST_OERR is set when NOACK or BADWDATA is already set and another one
of those errors occurred. It notifies software that state was saved only for the
first outgoing error.
LOST_OERR is cleared by a write-one-to-clear.
PERR
PERR is set when NVAX detects a parity error on the NDAL. When PERR is set,
NEDATHI, NEDATLO, and NEICMD are locked so that software can read them
to see what was on the NDAL when the error occurred.
Since NVAX calculates parity on every cycle, PERR will be set on both its own
transfers and the transfers of other devices that fail the parity check.
PERR is cleared by a write-one-to-clear.
INCON_PERR
INCON_PERR (inconsistent parity error) is set when an NDAL parity error
is detected on a cycle, which is also acknowledged with the NDAL signal
"ACK_L." This means that NVAX detected a parity error but some other device
acknowledged the transfer.
INCON_PERR is only set in conjunction with PERR. It is not set unless PERR is
set. If one NDAL parity error has already occurred, setting PERR, but INCON_
PERR was not set for that cycle, a subsequent cycle with an inconsistent parity
error will not cause INCON_PERR to be set.
INCON_PERR is cleared by a write-one-to-clear.
LOST_PERR
LOST_PERR is set when PERR is already set and another NVAX transfer fails
the parity check. LOST_PERR notifies software that multiple NVAX transfers
have failed the parity check; state was saved only for the first.
LOST_PERR is cleared by a write-one-to-clear.

4–48 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.10.2 NDAL Error Output Address IPR (NEOADR)
The NEOADR register is loaded for every address cycle that the NVAX drives
onto the NDAL unless it is locked. It is loaded during the cycle when the
corresponding ACK_L should be asserted on the NDAL. It is locked when the
NOACK bit in the NESTS register is set.
When NEOADR is locked, it contains the address information for the first
transaction that failed. If it is read when it is not locked, it contains information
from the last address cycle that was acknowledged on the NDAL.
The format of NEOADR matches the low longword of the NDAL during an
address cycle.
NEOADR is read-only to software.
Figure 4–31 IPR Format of NEOADR
00

31
NDAL Address

LJ-01290-TI0

4.4.10.3 NDAL Error Output Command (NEOCMD)
The NEOCMD register is loaded and locked exactly as NEOADR is loaded and
locked. The format of NEOCMD is similar to that of the high longword of the
NDAL during an address cycle. The high quadword byte enable positions are
NOT included, since NVAX only uses quadword byte-enabled transactions. The
NDAL ID and command are added in the lower seven bits of the longword.
Figure 4–32 IPR Format of NEOCMD
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
LEN X

X X X

04 03

08 07 06
BYTE_EN

00
CMD
LJ-01291-TI0

Table 4–29 NEOCMD IPR Format
Name

Extent

Type

Description

CMD

3:0

NDAL command as driven by NVAX
during the transaction.

6:4

Commander ID as driven by NVAX
during the transaction.

BYTE_EN

15:8

Byte enable as driven by NVAX during
the transaction.

LEN

31:30

Length of the NDAL transaction.

KA680 Cache Memory Overview 4–49

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.10.4 NDAL Error Input Command (NEICMD)
NEICMD, NEDATHI, and NEDATLO are loaded at the same time and they are
locked at the same time. They are all loaded when a parity error occurs; at this
time the PERR bit is set in NESTS, which locks the three registers. If a second
NDAL parity error happens, the registers are not loaded again. They are not
loaded again until after they are unlocked when software clears PERR.
NEICMD contains the NDAL signals CMD_H<3:0>, ID_H<2:0>, and PARITY_
H<2:0> from the failed transfer.
NEICMD is a read-only register.
Figure 4–33 IPR Format of NEICMD
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09
X X X X X X X X X X

X X X X X

X X

04 03

07 06

Parity

00
CMD
LJ-01292-TI0

PARITY
The PARITY field corresponds to the NDAL lines PARITY_H<2:0>.
ID
The ID field corresponds to the NDAL lines ID_H<2:0>.
CMD
The CMD field corresponds to the NDAL lines CMD_H<3:0>.
4.4.10.5 NDAL Error Data High and NDAL Error Data Low (NEDATHI and NEDATLO)
NEDATHI and NEDATLO behave similarly to NEICMD. They capture NDAL_
H<63:0> during a cycle with a parity error. NEDATHI contains the high longword
of data from the NDAL (NDAL_H<63:32>); NEDATLO contains the low longword
of data from the NDAL (NDAL_H<31:0>).
The format of NEDATHI and NEDATLO must be interpreted based on the CMD
found in NEICMD. If the CMD field shows that the cycle was a data cycle, the
registers contain two longwords of data. If the CMD field shows that the cycle
was an address cycle, the registers are in the format of an NDAL address cycle,
as shown in Figure 4–34 and Figure 4–35.
Figure 4–34 NEDATHI, Address Cycle Format
31 30 29
LEN

Undefined

08 07

24 23
BYTE_EN

Undefined

LJ-01293-TI0

4–50 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Figure 4–35 NEDATLO, Address Cycle Format
00

31
Address

LJ-01294-TI0

4.4.11 Backup Cache Tag Store Access Through IPR Reads and Writes
(BCTAG)
Direct access to the backup cache tag store is provided to aid in error recovery
and diagnosis and to assist testing. These accesses work whether the cache is on
or off, in ETM or in force hit mode.
If there is a valid FILL_CAM entry for the same cache block that is being
accessed through an IPR read or write, the IPR read or write is stalled until the
fills return and the FILL_CAM entry is no longer valid.
When the backup cache tag store is being accessed through IPR reads and writes,
address bits <24:22> = 100 (BINARY). Address bits <18:5> (KA680) or <18:5>
(KA680) are used as the index into the tag store RAMs; these indicate which
backup cache location is to be written or read.
Figure 4–36 Backup Cache Tag Store IPR Addressing Format

05 04

25 24 23 22 21 20 19 18 17 16

31
SBZ

0 X

BCtag Index

01 00
SBZ

LJ-01295-TI0

The format for reading and writing the backup cache tag store as an IPR is
described in Figure 4–37 and Table 4–30.
Figure 4–37 IPR Format of the Backup Cache Tag Store

31 30 29 28
X X X

11 10 09 08 07 06 05 04 03 02 01 00

19 18 17 16
Tag

ECC

X X X X X X X X X

VALID
OWNED
LJ-01296-TI0

KA680 Cache Memory Overview 4–51

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–30 Bcache Tag IPR Format
Name

Extent

Type

Description

VALID

Valid Bit

OWNED

Ownership Bit

ECC

16:11

RW1

ECC Check Bits

TAG

28:17

Tag Data

The ECC bits are written from the value given in the MTPR instruction only if the SW_ECC bit of
the CCTL IPR is set. Otherwise, the Cbox generates and writes correct ECC for the tag, owned and
valid values.

Table 4–31 Tag and Index Interpretation for BCTAG IPR
Cache Size

Tag Bits Used

Index Bits Used

128 KB (KA680)

TAG<28:17>

Index<16:5>

The tag store must be initialized to a known state when the chip is powered up.
This is done through the MTPR instruction to BCTAG.
When the tag store is read, the ECC check bits are read out directly from the tag
store in the format shown. ECC is not checked on IPR accesses to the tag store;
no errors can occur during these accesses.
Some care must be taken if IPR reads of the tag store are done while other
transactions are in progress. The tag information read out may not be what
the programmer expects if cache misses or cache coherency transactions are in
progress on the block being read. For example, if a cache miss is in progress, the
new tag will be in the tag store but the valid and owned bits will be clear.

4.4.12 Backup Cache Deallocates Through IPR Access (BCFLUSH)
The backup cache deallocate IPR is a write-only register that software uses to
explicitly request the deallocation of a cache block. For example, this register
may be used when hardware has put the cache into ETM and software wants to
request write-back of the owned blocks to memory.
If there is a FILL_CAM entry for the same cache block that is being flushed, the
flush is stalled until the fills return and the FILL_CAM entry is no longer valid.
Figure 4–38 Backup Cache Deallocate IPR Addressing Format

25 24 23 22 21 20 19 18 17 16

31
SBZ

0 0

Bcache Tag Deallocate Index

05 04

00
SBZ
LJ-01297-TI0

When BCFLUSH is written, the NVAX accesses the Bcache tag store. If the block
is invalid, no further action is taken. If the block is valid but not owned, the
NVAX invalidates the entry in the Bcache tag store, as well as the corresponding
Pcache entry if it exists. If the block is valid and owned, the NVAX invalidates

4–52 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
the Pcache entry if it exists, performs a write-back of the Bcache data, and
invalidates the Bcache entry in the tag store.
This behavior takes place whether the cache is on, off, in ETM, or in FORCE_HIT
mode. In FORCE_HIT mode, BCFLUSH does a real lookup of the tag store and
does not force the access to hit. Software must take care not to force deallocates
when cache state is not consistent with the state of memory. For example, when
the cache is off, valid and owned bits may be set for blocks that are no longer
up-to-date with respect to memory.
When a deallocate is done, the VALID and OWNED bits will be cleared
as necessary, and the value of the stored TAG is modified. Its value is
UNPREDICTABLE. Correct ECC is stored on the tag store entry.
A BCFLUSH operation never changes the data stored in the data RAMs.
Errors are detected and reported during BCFLUSH operations.
The index given is interpreted as in Table 4–31, based on the size of the cache.
BCFLUSH may be used when the Bcache is on, because the Pcache is kept
a subset of the Bcache during these operations. However, new blocks may be
allocated due to memory reads and writes as the cache is being flushed.

4.4.13 Bcache Abnormal Conditions
This section describes the various modes of Bcache behavior as well as Cbox
response when it detects an error.
The Bcache has four operating states that are controlled by the following bits in
the CCTL register: ENABLE, FORCE_HIT, SW_ETM, and HW_ETM. The four
states are ON, OFF, ETM, and FORCE_HIT. The four states are determined and
prioritized as follows:
1. OFF. If the ENABLE bit is cleared in CCTL, the Bcache is OFF and those
conditions take precedence.
2. FORCE_HIT. If the ENABLE bit is set and FORCE_HIT is set, the Bcache is
in FORCE_HIT mode and those conditions take precedence.
3. ETM. If the ENABLE bit is set, FORCE_HIT is cleared, and either SW_ETM
or HW_ETM is set. The cache is in ETM mode and those conditions take
precedence.
4. ON. If the ENABLE bit is set and FORCE_HIT, SW_ETM, and HW_ETM are
cleared, the cache is ON.
The ON state is the normal operating condition of the cache. OFF, FORCE_HIT,
and ETM modes are described in the following sections.
4.4.13.1 NVAX Behavior When the Backup Cache is OFF
The backup cache may be off for two reasons: the chip has just powered up, or
software has disabled the cache by clearing the ENABLE bit in the Bcache control
register.
When the cache is off, no accesses to the backup cache are done. Errors are not
detected and cache state is UNCHANGED unless explicitly changed by software
through IPR reads and writes.

KA680 Cache Memory Overview 4–53

KA680 Cache Memory Overview
4.4 Backup Cache
When the backup cache is off, all cache lookups due to DMA cycles on the NDAL
are forwarded as invalidates to the Pcache, since the data may be valid in the
Pcache. All reads that miss in the Pcache go directly to the NDAL. Cache fills
returning from the memory subsystem are sent directly to the Pcache without
incurring the overhead of Bcache access. All writes go directly to the NDAL.
When the cache is off, VAX interlocked instructions that generate atomic
read/write pairs become hexaword ownership read/quadword disown write on
the NDAL.
All writes issued from NVAX when it is operating without a backup cache are of
quadword length. Memory reads are of hexaword length since the Pcache block
size is a hexaword. Even if the Pcache is off, a hexaword of data is returned to
the Mbox.
A VAX instruction that generates read references with modify intent normally
generates an OREAD on the NDAL if it misses in the Bcache. However, when the
Bcache is off, a normal DREAD is used on the NDAL.

4–54 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.13.2 NVAX Behavior When the Backup Cache is in FORCE_HIT Mode
FORCE_HIT mode is intended to be used for testing purposes only. It is used
when the cache is enabled.
When FORCE_HIT is set, all memory space reads and writes to the Bcache, both
I-stream and D-stream, are forced to hit. Tag store state is not changed at all;
the data RAMs are accessed as if the tag store access produced an owned-valid
hit. DMA I/O references on the NDAL are treated as they are when the Bcache
is off. They are not looked up in the backup cache; they are all forwarded to the
Pcache as invalidates, and Bcache state is not changed as the result of the DMA
references.
When the Bcache is in FORCE_HIT mode, deallocates are not done. Even if the
tag matches and the VALID and OWNED bits are set, the block is not written
back. The implication of this is that if FORCE_HIT mode is being used, the
Bcache must be flushed of all owned blocks beforehand.
Tag store and data RAM ECC errors are detected in FORCE_HIT mode if
DISABLE_ERRORS in the CCTL register is not set, resulting in the usual
error handling.
As an example of the use of FORCE_HIT mode, suppose the ECC logic for the
data RAMs is to be tested. Put the cache in FORCE_HIT mode. Set SW_ECC in
the Bcache control register. Write the desired ECC into BCDECC. Do a write to
a memory location that maps to the desired Bcache block, and the location will
be written using ECC from BCDECC rather than from NVAX-generated ECC.
Suppose the ECC written is such that when the data is read, an ECC error will
be flagged.
Now perform a read of the same memory while FORCE_HIT is still set. The
read will result in a Bcache data ECC error, showing that the logic is working
correctly. The data RAM error registers may be read and will correspond to the
induced error.
4.4.13.3 NVAX Behavior When the Backup Cache is in Error Transition Mode
When the NVAX detects certain errors, it puts itself into error transition mode
(ETM).
The goals of the Bcache design during ETM are the following:
1. Preserve the state of the Bcache as much as possible for diagnostic software.
2. Honor references that hit owned blocks in the backup cache since this is the
only source of data in the system.
3. Respond to NDAL DMA references normally (that is, write-back owned
blocks that are referenced by DMA devices), and perform invalidates on
DMA-referenced cached unowned blocks.
Once the NVAX enters error transition mode, it remains in ETM until software
explicitly disables or enables the Bcache. To ensure Bcache coherency with
main memory, the Bcache must be completely flushed of valid blocks before it is
re-enabled because some data can become stale while the cache is in ETM.
Table 4–32 describes how the backup cache behaves while it is in ETM.

KA680 Cache Memory Overview 4–55

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–32 Backup Cache Behavior During ETM
—————————–Cache
Response——————————————-

Cache
Transaction

Miss

Valid Hit

Owned Hit

CPU IREAD,DREAD

Read from memory

Read from
cache

CPU READ_LOCK

Read from memory

Force block
write-back,
read from
memory1

CPU Write

Write to memory

Force block
write-back,
write to
memory1

CPU WRITE_
UNLOCK

Write to memory

Write to
cache1

Fill (from read started
before ETM)

—-Normal cache behavior—-

Fill (from read started
during ETM)

—-Do not update backup cache; return data to Mbox—-

NDAL DMA reference

—-Normal cache behavior—-

Done to preserve write ordering

Any reads or writes that do not hit valid-owned during ETM are sent to memory;
read data is retrieved from memory, and writes are written to memory, bypassing
the Bcache entirely.
The cache supplies data for IREADs, DREADs, and dread modifies that hit
valid-owned; this is normal cache behavior.
If a write hits a valid-owned block in the cache, the block is written back to
memory and the write is also sent to memory.
If a READ_LOCK hits valid-owned in the cache, a write-back of the block is
forced and the READ_LOCK is sent to memory (as an OREAD on the NDAL).
Data returning from the memory subsystem as the result of any type of read
originated before the Bcache entered ETM are processed in the usual fashion. If
the returning cache fill is a result of a write miss, the write data is merged, as
usual, as the requested fill returns. Fills caused by any type of read originated
during ETM are not written into the Bcache or validated in the tag store.
During ETM, the state of the cache is modified as little as possible. Table 4–33
shows how each transaction modifies the state of the cache.

4–56 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–33 Backup Cache State Changes During ETM
————————-Cache State
Modified—————————————–

Cache
Transaction

Miss

Valid Hit

Owned Hit

CPU IREAD,DREAD

None

None.

CPU READ_LOCK

None

Clear
VALID and
OWNED;
change
TS_ECC
accordingly.

CPU Write

None

Clear
VALID and
OWNED;
change
TS_ECC
accordingly.

CPU WRITE_
UNLOCK

None

Write new
data; change
DR_ECC
accordingly.

Fill (from read started
before ETM)

Write new TS_TAG, TS_VALID,
TS_OWNED, TS_ECC, DR_DATA, DR_ECC

Fill (from read started
during ETM)

———————————–None———————————-

NDAL DMA
transaction

—————-Clear VALID and OWNED;
change TS_ECC accordingly—————–

4.4.14 How to Turn the Bcache Off
Because the Bcache is a write-back cache, care must be taken to maintain cache
coherency when turning it off.
If the cache is running normally and software wishes to turn it off, it must do the
following:
1. Write to CCTL register to set SW_ETM. In this mode, the Bcache will not
allocate any new blocks and will send all DMA-caused Bcache lookups to the
Pcache as invalidates.
2. Use the BCFLUSH register to flush all owned blocks out of the cache.
3. Turn off the Bcache by writing the CCTL register to clear ENABLE and
SW_ETM simultaneously. If an error was encountered during the deallocate
process, HW_ETM may be set. If so, it should be cleared as well.
If the Bcache encounters an uncorrectable ECC error, the NVAX sets HW_ETM
in the CCTL register. If software wishes to turn off the cache, it must do the
following:
1. Use the BCFLUSH register to flush all owned blocks out of the cache.
2. Write CCTL to clear ENABLE and clear HW_ETM simultaneously. This
turns off the Bcache.

KA680 Cache Memory Overview 4–57

KA680 Cache Memory Overview
4.4 Backup Cache
If Bcache errors are occurring only in part of the cache, software may be able to
avoid the portion of the cache that is in error by disabling it through the use of
the SIZE field in CCTL. If part of the cache is failing, a smaller cache size may
be selected so that only part of the cache RAMs is being used. The cache must be
flushed before changing the cache size so that the tags are correct.
This works only if the smallest cache size is not being used, and if the failing
areas of cache do not fall within the range of the smaller cache size selected.

4.4.15 How to Turn the Bcache On
When NVAX powers up, garbage data is stored in the Bcache tags and data. This
would result in ECC errors if the cache were turned on immediately.
Through IPR writes, every Bcache tag store entry must be written with cleared
OWNED and VALID bits. The value written to the tag is irrelevant, as long as
correct ECC is written to the tag store.
Once the tag store has been initialized, the cache may be enabled by setting
ENABLE in the CCTL register.
It is not strictly necessary to initialize the Bcache data RAMs with correct ECC
on powerup. ECC errors in the data RAMs are ignored if the corresponding tag
store entry is invalid. Since data RAM ECC errors are not detected on fills, the
cache data is self-initializing.
FORCE_HIT mode may be used to initialize the Bcache data RAMs with correct
ECC. If full quadword writes are used, no data RAM errors will be detected
during this process, since the RAMs are written without being read first. If
partial quadword writes are used, errors will be detected because of the readmodify-write that is necessary. If the programmer sets the DISABLE_ERRORS
bit in the CCTL register, the NVAX will ignore these errors.
If the Bcache is in ETM, it may be incoherent with respect to memory because
of how it treats writes that hit valid but not owned in the cache (Table 4–32). In
addition, the Pcache, if enabled, is no longer a subset of the backup cache. The
procedure for turning on the Pcache and the Bcache as described in this section
must be followed.
If the Bcache is operating normally and is turned off for some reason, the
programmer must ensure that when it is re-enabled, all the OWNED and VALID
bits are cleared.

4.4.16 Backup Cache Errors
In general, the NVAX logs as much state as possible concerning errors and
notifies the Ebox and/or Mbox that an error has occurred. For every error, the
NVAX does at least one of the following to notify software of the error: hard error
interrupt, soft error interrupt, or machine check exception. The backup cache
goes into error transition mode when it detects any uncorrectable error from the
cache RAMs.

4–58 KA680 Cache Memory Overview

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–34 Backup Cache ECC Errors and NVAX CPU Error Responses
General Problem

Specific Situation and Action Taken by NVAX CPU

Correctable ECC
error in the data
RAMs

Read hit for writeback or read hit for
deallocate IPR

Soft error interrupt. The data for the
write-back is corrected and the write-back
continues normally.

Read hit for Pcache
miss

Soft error interrupt.

Read for write hit

Soft error interrupt. The corrected data is
merged with the write data and written
into the RAMs.

Miss

No error is reported.

Read for write-back
or deallocate IPR

Soft error interrupt, puts backup cache
into ETM. The data cycle command for the
NDAL is changed to BADWDATA and the
write-back continues normally.

VALID-OWNED or
VALID-UNOWNED
read for Pcache miss

Soft error interrupt, puts backup cache into
ETM.

VALID-OWNED
DREAD_LOCK, first
quadword fails

Soft error interrupt, puts backup cache into
ETM.

VALID-OWNED
DREAD_LOCK
for Pcache miss,
quadword other than
the first one fails

Soft error interrupt, puts backup cache into
ETM.

Read for write, validowned hit, or write
unlock

Hard error interrupt, puts backup cache
into ETM. When the error is detected, write
data has already been merged with the
corrupted data.

Uncorrectable ECC
error in the data
RAMs (includes
addressing errors)

The NVAX inverts three of the ECC
check bits (bits 3,6,7), which gives a
high probability that when the data is
read again, an uncorrectable error will be
detected.
Correctable ECC
error in the tag
store

Miss

No error is reported.

Any read or write
except WUNLOCK;
hit or miss

NVAX takes a soft error interrupt, assumes
the transaction missed, and sends a READ
or an OREAD to memory. If the location
was owned, making a deallocate necessary,
the outgoing address is corrected for the
write-back.
Note that if the transaction actually hitowned, the READ or OREAD is sent to the
NDAL followed by a write-back of the same
block. The errored location is corrected by
hardware when the tag and valid bit are
written for the fill.
(continued on next page)

KA680 Cache Memory Overview 4–59

KA680 Cache Memory Overview
4.4 Backup Cache
Table 4–34 (Cont.) Backup Cache ECC Errors and NVAX CPU Error Responses
General Problem

Uncorrectable ECC
error in the tag
store (includes
addressing errors)

Specific Situation and Action Taken by NVAX CPU
DMA cache
coherence
transaction miss

Soft error interrupt. Hardware does not
correct the bad location; it may be done by
software.

DMA cache
coherence
transaction hit

Soft error interrupt. Writes the corrected
tag, valid, and owned bits back into the tag
store when invalidating the entry. Uses
corrected address for the write-back if
necessary.

Read for Pcache miss

Soft error interrupt. Backup cache put into
ETM. The read is sent to memory; if the
backup cache actually owned the block, the
read will time out.

Write

Soft error interrupt. Backup cache put into
ETM. The OREAD for the write is sent to
memory. If the cache actually owned the
block, the read will time out and the write
will then be sent to memory. The write will
then time out as well unless error handling
software cleans up the problem.
If the cache did not own the block, the
OREAD will complete, the write will be
merged with it, and the merged data will
be written to the cache.

4–60 KA680 Cache Memory Overview

WRITE_UNLOCK

No tag store lookup is done, so this case
does not occur.

DMA cache
coherence
transaction

Soft error interrupt. Backup cache put
into ETM. Transaction is treated as a
miss with regard to the backup cache; the
invalidate is forwarded to the Pcache if the
cache coherence transaction were due to an
OREAD or a WRITE.

KA680 Cache Memory Overview
4.4 Backup Cache
4.4.16.1 Backup Cache Errors Incurred While in Error Transition Mode
Table 4–35 describes error handling when the backup cache is already in ETM.
Note
The table below only describes ETM error cases that differ from error
handling when the cache is in normal mode.

Table 4–35 Backup Cache ECC Error Handling During ETM
General Problem

Specific Situation and Action Taken by NVAX CPU

Uncorrectable ECC
error in the data
RAMs (includes
addressing errors)

Read for WRITE_
UNLOCK, VALIDOWNED hit

Hard error interrupt. When the error
is detected, write data has already been
merged with the corrupted data.
The NVAX inverts three of the ECC
check bits (bits 3,6,7), which gives a
high probability that when the data is
read again, an uncorrectable error will be
detected.

Uncorrectable ECC
error in the tag
store (includes
addressing errors)

Write

Soft error interrupt. The write is sent
to memory. If the cache actually owned
the block, the write will time out in the
memory interface unless software forces the
Cbox to disown the block.
If the cache did not own the block, the
system handles the write as it normally
does for a cache that is off.

WRITE_UNLOCK

Soft error interrupt. The write is sent to
memory as a quadword length WDISOWN.
Since the READ_LOCK was done just
previously, memory always believes that
the Bcache owns the block.
In most cases, the cache itself does not have
a record of owning the block since a READ_
LOCK to an owned block during ETM
forces a write-back of the block. In these
cases, the WRITE_UNLOCK handling is
very consistent.
There is only one case where the cache
does own the block: if we entered ETM on
or after the READ_LOCK and before the
WRITE_UNLOCK. In this case, the cache
may contain previously written data that is
not now reflected into memory. This may
be handled by software.

KA680 Cache Memory Overview 4–61

5
KA680 Main Memory System
The main memory system is implemented in the NVAX memory controller chip
(NMC). The NMC communicates with the MS690 memory boards over the MS690
memory interconnect. Up to four MS690 memory boards are supported, for a
maximum of 512 MB of main memory.
The NMC serves as an interface between the NDAL and the NVAX memory
interconnect. The NMI is comprised of the set of signals leading from the NMC
to the memory modules, and provides a 64-bit path to the memory modules. The
arbiter for the NDAL is also built into the NMC.

5.1 Overview of the NVAX Memory Subsystem Support Functions
There are two chips that support the memory subsystem:
•

The NVAX memory controller chip (NMC).

•

The GMI memory interface chip (GMX).

5.1.1 The NMC Chip
The NMC controls and passes data to or from one, two, three, or four buffered
memory modules using a bank interleaved memory access. It responds to
commands from the CPU and the I/O adaptor (NCA). The NMC is never a
commander on the NDAL.
The memory interconnect to the NMC supports the MS690 64-bit memory
modules.
The MS690 memory module can have one or two banks of 1 Mb or 4 Mb DRAMs.
Each bank consists of 72-1 Mb or 72-4 Mb Fast page mode 100 ns RAS access
time DRAMs. Of the 72 RAMs, 64 are used to store data. The remaining 8 RAMs
are used for storing ECC bits.
A given memory module is always populated with only one size of DRAM chips.
The size of the memory bank is determined by reading the configuration from the
memory modules. A single memory module has two banks of memory in which
each bank is 16 MB or 64 MB for 1 Mb and 4 Mb DRAMs, respectively.
There is one ownership bit (O-bit) for each hexaword of data in memory. These
ownership bits are implemented on the CPU module and are distinct from the
MS690 memory boards. The CPU uses ownership reads (OREADs) to obtain
ownership of a hexaword of data that it wishes to modify. Interlocked reads
are also done as OREADs. I/O devices use OREADs to perform interlock read
transactions. The ownership bits are set as a result of OREADs issued on the
NDAL and are cleared by a disown write. The control signals for the O-bits are
provided by a separate port on the NMC.

KA680 Main Memory System 5–1

KA680 Main Memory System
5.1 Overview of the NVAX Memory Subsystem Support Functions
The CPU uses I-stream or D-stream reads to read locations that it will not
modify, and ownership reads to access locations it wishes to modify (when the
backup cache is on). The I/O devices use D-stream reads to do reads without
locks, and ownership read/disown write pairs to implement locked transactions.

5.1.2 The GMX Chip
The GMX is a 20-bit data multiplexer and transceiver that buffers DRAMs on
a memory module. It also includes support for a high-speed memory diagnostic
function. It is the interface between the CMOS NMI and the TTL DRAM array.

5.2 Overview of NMC-supported NDAL Transactions
The NDAL is a 64-bit pended, synchronous bus with multiplexed data and
address lines and centralized arbitration. All the components that interface to it
use four clock signals from the NVAX CPU chip. The NMC is the arbiter and the
default bus master. The following transactions are supported on the NDAL:
•

IREAD, I-stream read.

•

DREAD, D-stream read (no lock or ownership).

•

OREAD, D-stream read ownership.

•

RDE, read data error.

•

WRITE, write masked (no disown or unlock).

•

WDISOWN, disown write. These transactions use WDATA cycles to transmit
write data. If the data is in error, a BADWDATA cycle is used instead.

•

RDR0,RDR1,RDR2,RDR3, read data return (0 to 3).

•

NOP.

5.3 Overview of NMI Transactions
The NMC performs the following transactions on the NMI:
•

Quadword, octaword, and hexword OREADs, IREADs, and DREADs

•

Longword, quadword, octaword, and hexword WRITEs (masked, no disown or
unlock)

•

Quadword and hexword disown writes

•

Signature read

•

Memory refresh

•

Fast diagnostic test mode read or write

5.4 NMC Architectural Overview
The NVAX memory controller (NMC) serves as an interface between the NDAL
(NVAX data-address lines) and the memory subsystem over a private interconnect
(NMI), which is 64 bits. The NMC also serves as the arbiter for the nodes on the
NDAL. The NMC is made up of five major sections - the NDAL interface, the
memory interface, the control and status registers, the transactions handler, and
the NDAL arbiter. This section describes these five sections and their interaction.

5–2 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
5.4.1 NDAL Bus Interface Architecture
The system has three nodes on the NDAL - the NMC, the NVAX CPU, and
the NCA (CP-bus adapter). The NVAX CPU and the NMC can do memory
transactions on the NDAL, but only the CPU can do I/O transactions. The NMC
services all memory transactions (address<31:29>= 000..110) and I/O transactions
written within its I/O space (address 2101 0000 - 2101 804C, 2100 0110). The
NMC supports the following transactions on the NDAL:
•

OREAD - ownership read

•

IREAD - I-stream read

•

DREAD - D-stream read

•

WDISOWN - disown write

•

WRITE - masked write

Every transaction on the NDAL is decoded and loaded into an appropriate input
queue in the NMC. The NMC has four input queues; CPU_QUE, IO1_QUE, IO2_
QUE, and WB_QUE. The CPU_QUE, IO1_QUE, and IO2_QUE queues (these
will be collectively referred to as non-writeback queues, or NWB_QUEs) buffer up
non-writeback transactions - OREADs, IREADs, DREADs, WRITEs. All disown
writes (WDISOWN) are buffered in the writeback queue - WB_QUE. All four
queues have one entry each.
5.4.1.1 The Non-Writeback Queues
Every NWB_QUE entry contains an address packet, a data packet, a valid bit,
a pending bit, and two mark bits. Figure 5–1 illustrates the organization of the
NDAL IN_QUEs in the NMC.
The address packet consists of the following:
•

Address - 32 bits

•

Command - 4 bits

•

Commander ID - 3 bits

•

Byte mask - 16 bits

•

Transfer length - 2 bits

The data packet in the IO1_QUE and IO2_QUE consists of 4 quadwords of data
and the corresponding parity information. The data packet in the CPU_QUE
consists of one quadword and the corresponding parity. The CPU_QUE data
packet is only one quadword wide because during normal operation, the only
writes coming from the NVAX CPU and going to memory will be write-backs,
which will go into the write-back queue. The CPU_QUE will only be used when
the Bcache is off or in error transition mode. In this case, the NVAX CPU writes
are all of quadword length.

KA680 Main Memory System 5–3

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–1 NDAL IN_QUEs in the NMC
IO2_VALID
CPU_MARK
IO1_MARK
IO2_PEND
D

TIMER

IO2_QUE

IO1_VALID
CPU_MARK
IO2_MARK
IO1_PEND
D

TIMER

IO1_QUE

NDAL

NMC I N T E R N A L

CPU_VALID
IO1_MARK

DATAPATH

IO2_MARK
CPU_PEND
D

TIMER

CPU_QUE

WB_VALID
D

WB_QUE

The valid bit is set whenever a transaction is loaded into the queue. This
also asserts a request to an internal arbiter, SEL_TRANS, which selects the
transactions to be serviced by the NMC according to their priority. The valid bit
is set until the transaction can be completed in memory. Refer to Section 5.4.9.1
for details.
When a memory transaction is serviced, and the corresponding hexaword
is owned by another NDAL node, a pending bit is set in the NWB_QUE
corresponding to that memory transaction. This bit is set until the corresponding
disown write is received. Every NWB_QUE is also associated with a pending
timer that counts the number of cycles a transaction has been waiting for a
disown write.
Each NWB_QUE entry has two mark bits corresponding to the other two NWB_
QUEs. For instance, the CPU_QUE has two mark bits - IO1_MARK and IO2_
MARK; the IO1_QUE has mark bits CPU_MARK and IO2_MARK; and the IO2_
QUE has mark bits CPU_MARK and IO1_MARK. These mark bits are used to
preserve ordering of the NDAL transactions. Ordering of transactions on the
NDAL has to be preserved because not all devices use interlocked transactions for
synchronization; some devices use memory reads, IO reads/writes, or interrupts.
The NMC does not monitor all these synchronization events on the NDAL and
therefore has to maintain order of transactions to the same hexaword address.
This is done in the following way.

5–4 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
When the NMC sees a non-writeback memory transaction on the NDAL from a
node, it performs a hexaword address compare between the incoming address
and the addresses stored in valid entries of the NWB_QUEs corresponding to
the other two commander nodes on the NDAL. If there is a match, the mark
bit corresponding to the commander ID of the incoming transaction is set in the
NWB_QUE that matched. The incoming transaction will not be serviced by the
NMC until all transactions marked for its ID have been serviced. For example,
the CPU does a read to hexaword H1. H1 is compared with the addresses in
IO1_QUE and IO2_QUE. Suppose address H1 corresponds to a valid address in
IO1_QUE. The CPU_MARK bit is set in IO1_QUE. The CPU read from H1 is not
serviced by the NMC until the transaction from IO1_QUE is done. In this way,
the ordering of NDAL transactions is maintained by the NMC.
5.4.1.2 The Write-back Queue
WB_QUE contains an address packet, a hexaword data packet, and a valid bit
similar to the NWB_QUEs.
When a memory space disown write (WDISOWN) happens on the NDAL, the
NMC compares the hexaword address of the disown write to valid addresses
in the NWB_QUEs. If there is a match, and the corresponding transaction is
pending, the transaction is selected for completion along with the disown write.
This is described in greater detail in Section 5.4.9. The NMC allows disown
writes to bypass non-writeback transactions.
WB_QUE is given the highest priority by the NMC, except when Q22–bus devices
are accessing main memory. In this case, the CP-bus connected to the CQBIC is
given highest priority. This is done to reduce the latency on Q22–bus transactions
to main memory.
5.4.1.3 The OUT_QUE
When a read is serviced by the NMC, data to be returned on the NDAL is loaded
into an "outgoing" data queue, the OUT_QUE. The OUT_QUE is unloaded when
the NDAL is granted to the NMC. It can store up to 6 entries; each entry consists
of 64 bits of data, the commander ID, error information, and the quadword
number. Parity is generated as the information is sent from the OUT_QUE into
the output pad latch. Data from the OUT_QUE is returned in the order in which
it was loaded; the requested data is always returned first. Data is not necessarily
returned in consecutive cycles.

5.4.2 Memory Interface Architecture
The NMC supports up to 128 MB of memory using 1 Mb DRAMs only and up to
512 MB of memory using 4 Mb DRAMs only. The minimum memory increment
is 16 MB with 1 Mb DRAMs and 64 MB with 4 Mb DRAMs. The maximum
available physical memory is divided into 8 sets. Each set is 16 MB if memory is
made up of 1 Mb DRAMs and 64 MB if memory is made up of 4 Mb DRAMs. The
NMC supports the use of 1 Mb DRAM-based memory modules with 4 Mb-based
memory modules in the same system.
The NMC supports a single error correcting/double error detecting/single symbol
detecting (SEC/DED/SSD) code on memory data. On the 64-bit MS690 memory
modules, 72 bits are implemented - 64 bits for data and 8 ECC check bits.
Every hexaword in memory has a corresponding ownership bit (O-bit) associated
with it. Single error correction on the O-bits is done by generating 4 ECC check
bits across 8 O-bits. Since the system can support up to 512 MB of main memory,
corresponding to 16M hexawords, there are 16M O-bits implemented on the CPU
module. The NMC provides a separate O-bit port to access the O-bit memory.
KA680 Main Memory System 5–5

KA680 Main Memory System
5.4 NMC Architectural Overview
The NMI supports 2-way memory interleaving. Pagemode operation of the
DRAMs is used within a transaction but not across transactions. The NMC
provides the basic control and timing for data memory and ownership bit memory.
For details about the organization of the memory modules and the NMI interface,
refer to Section 5.6.
5.4.2.1 Data Memory Addressing
The NVAX memory space ranges from address<31:29> = 000 to address<31:29>
= 110. The NVAX CPU is configured in 30-bit address mode; therefore, the
maximum memory space it can support is 512 MB (bits <31:30> are ignored).
Each set of memory can be mapped anywhere in this 512 MB of NVAX memory
space (see the following paragraph). If a set is made up of 1 Mb DRAMs (16
MB set), 24 bits of the address are required to reference a byte within the set.
Address bits <23:0> are used for this purpose. Address bits <28:24> are used to
select the appropriate set. These bits contain the base address of this set. If a
set is made up of 4 Mb DRAMs (64 MB set), 26 bits of the address are required
to reference a byte within the set. Address bits <25:0> are used for this purpose.
Address bits <28:26> are used to select the appropriate set. These bits contain
the base address of this set.
A set can therefore be configured to map to any value of bits 28:24 if it is made
up of 1 Mb DRAMs (bits 28:26 if it is made up of 4 Mb DRAMs). This base
address mapping is stored in a corresponding configuration register. When a
validated base address value matches the incoming address, the corresponding
set is selected for reading or writing. Refer to Section 5.4.2.3 and Table 5–1 for
further details.
5.4.2.2 Memory Set Organization
A memory set can be 16 MB or 64 MB. Each set on an MS690 memory module is
made up of two banks of 72 DRAMs each. These banks are quadword interleaved;
bit <3> of the address is used to select between even and odd banks. When bit
<3> is 0, the even bank is selected; when bit <3> is 1, the odd bank is selected.
Figure 5–2 illustrates this.
Figure 5–2 Data Memory Addressing

Odd Bank

Even Bank

CASB (Address Bit 3 = 1)

CASA (Address Bit 3 = 0)

RAS <0>

RAS <0>
1M(4M) X 72

1M(4M) X 72

LJ-01456-TI0

5–6 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
The following table shows the NDAL to memory address mapping for 1 Mb and 4
Mb DRAMs.
Table 5–1 Memory Address Mapping for Data
DRAM Size

Base Address

Row Address<10:0>

Column Address<10:0>

<31:24>

<23:14>

<13:4>

<31:26>

<25, 23:14>

<24, 13:4>

5.4.2.3 Memory Configuration
The NMC supports eight memory sets. Corresponding to each set is
a configuration register and a signature register (Section 5.4.8.1.1 and
Section 5.4.8.1.2). MEMCON0 and MEMSIG0 correspond to memory set 0,
MEMCON1 and MEMSIG1 correspond to memory set 1, and so on. By loading
the appropriate address in the corresponding configuration register, a set can be
mapped to any 16 MB (for 1 Mb DRAMs) or 64 MB (for 4 Mb DRAMs) segment
of the NVAX memory space. For instance, a base address of 0 in MEMCON7
would map bank set 7 to the lowest 16 MB (for 1 Mb DRAMs) or 64 MB (for 4 Mb
DRAMs) of NVAX memory space.
Memory banks can be made up of 1 Mb DRAMs or 4 Mb DRAMs. The size of
each memory bank can be obtained by using the following 2-step procedure:
1. Software reads the corresponding memory signature register (one of
MEMSIG0 - MEMSIG7). This would cause the NMC to read the signature of
the appropriate memory set and return it on the NDAL.
2. Software should then determine from this signature the type of memory set
on the selected module, and then program the memory configuration register
appropriately. Also stored in each memory configuration register is the base
address to which each memory set responds, and a valid bit to indicate that
the contents of the associated memory configuration register (MEMCON0 MEMCON7) is valid.
A signature of 11 (binary) indicates that the corresponding set is not present in
the system. The total number of sets in the system can be determined by keeping
count of the number of signatures with no sets. Having determined the number of
sets and their sizes, software can program the base addresses in the base address
registers.
The signatures that will be returned for each of the four possible memory
configurations a memory set may have are listed in Table 5–2.
Table 5–2 Memory Signature Configurations
Signature with 1 Mb DRAMs

Signature with 4 Mb DRAMs

5248AA92

2D875565

WARNING
The NMC requires that all sets with 4 Mb DRAMs be mapped on aligned
64 MB boundaries. This is a requirement because of the way the row
and column addresses are generated from the incoming address. Refer to
Section 5.4.2.1 for details. To enable this, all bank sets of 4 Mb DRAMs
should be mapped to lower addresses than sets of 1 Mb DRAMs.

KA680 Main Memory System 5–7

KA680 Main Memory System
5.4 NMC Architectural Overview
For example, consider a system with two bank sets of memory, where the
first set is made up of 1 Mb DRAMs and the second is made up of 4 Mb
DRAMs. MEMCON2, which corresponds to set 2 (the 4M bank is on the
second memory module), should be mapped to base address <31:26> =
000000 and MEMCON0, which corresponds to set 0 (the 1M bank is on
the first memory module), should be mapped to base address <31:24> =
00000100. If the base addresses were programmed the other way, the 4M
set would start on an unaligned 4 MB boundary.

5.4.2.4 Ownership Bit Memory Organization and Addressing
During normal operation, the function of O-bit memory is totally transparent to
software. The O-bit memory serves to maintain a working record of ownership of
each hexaword of main memory to prevent simultaneous write access by both the
NVAX CPU and the NCA (acting on behalf of an I/O device). This is necessary
because of the write-back protocol used by the CPU’s Bcache.
Every hexaword in memory has one ownership bit associated with it. 16M O-bits
are implemented, thus supporting a maximum main memory of 512 MB.
O-bit memory is implemented on the CPU module. The NMC provides a separate
port for this O-bit memory. The organization and addressing of this memory
is different from that of the data memory. Eight O-bits are stored in every
O-bit memory location. The NMC accesses eight O-bits at a time, and based
on address<7:5>, decides which of the eight O-bits corresponds to the current
hexaword. This scheme requires two 1M banks of 8 O-bits each to support a total
of 16M O-bits; thus requiring six 1 Mb x 4 DRAMs. Each bank of O-bits has a
separate CAS. The O-bit memory addresses are independent of memory address
mapping. All O-bits are addressed using physical addresses from the NDAL.
Address bits <7:5> are used to select a particular O-bit in the 8-bit field. Address
bit<26> is used to select the O-bit bank. Address bits <28,27,25:8> are used to
address locations in the DRAMs.
Table 5–3 and Figure 5–3 illustrate the mapping scheme.

5–8 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–3 O-bit Port Addressing
O_MD<11:8>

O_MD<7:4>

O_MD<3:0>

O_CAS_L<0> (ADDRESS<26> = 0 )

O_MA<9:0>

O _ R A S _ L , O_WE_L

256K X 4
256K X 4

256K X 4

OR
OR

1M X 4

256K X 4

1M X 4

O_CAS_L<1> (ADDRESS<26> = 1 )

256K X 4
OR
OR

1M X 4

Table 5–3 O-bit Port Address Mapping
Maximum Main Memory

O-bit Row Address<9:0> 1

O-bit Column
Address<9:0>2

512 MB

<28,25:17>

<27,16:8>

1
Address<26> determines the O-bit bank to be selected. If address<26> is 0, O_CAS_L<0> is asserted;
if address<26> is 1, O_CAS_L<1> is asserted.
2

Address<7:5> are used to select one of the eight O-bits in the 8-bit field.

KA680 Main Memory System 5–9

KA680 Main Memory System
5.4 NMC Architectural Overview
5.4.3 NMI Transactions
The NMC supports the following transactions on the NMI:
•

Refresh

•

Signature read

•

Data read

•

Unmasked data write

•

Masked data write

•

Nonexistent memory access

5.4.3.1 Refresh
The NMC provides the mechanism to refresh the DRAMs for the data and
ownership memories. If 1 Mb DRAMs are used, every row has to be refreshed
once every 8 ms. If 4 Mb DRAMs are used, every row has to be refreshed
once every 16 ms. This means that the interval between refreshes of two
consecutive rows has to be 15.62 µs. When idle, the NMC generates a new
refresh transaction every 13.44 µs. If a refresh request happens during a
transaction, that transaction is completed before the refresh transaction is done
on the NMI. The NMC allows a margin of 2.18 µs over the DRAM specification
for this reason. The NMC has an internal refresh interval timer that initiates a
refresh transaction every 320 NDAL cycles. The NMC also provides the refresh
address for the DRAMs on the MA<10:0> lines. It contains a 10-bit binary
counter, the refresh address counter, which generates consecutive addresses for
every refresh. 1 Mb DRAMs need a 9-bit refresh address; 4 Mb DRAMs need a
10-bit refresh address. The 1 Mb DRAMs are thus refreshed at twice the rate of
the 4 Mb DRAMs.
An O-bit memory refresh is done along with a data memory refresh. Refresh
address <9:0> is mapped onto O_MA<9:0>.
5.4.3.2 Signature Read
A signature read transaction is initiated by doing a read to one of the memory
signature registers, MEMSIG0-7. On these transactions, there is no O-bit access.
Data received from the memory module is returned unchanged on the NDAL.
5.4.3.3 Read/Write Transactions
The NMC does quadword, octaword, or hexaword read transactions, and
longword, quadword, octaword, or hexaword write transactions on the NMI. The
NMI memory is quadword interleaved. Consecutive quadwords in 64-bit mode are
read/written from/to the even and odd banks of each memory set. A transfer on
the NMI is defined as one access from/to the DRAMs. A quadword transaction is
one transfer, an octaword two, and a hexaword four; a longword write transaction
is implemented as a read-modify-write. The requested data is always accessed
first. The NMC uses page mode of the DRAMs to do a multitransfer transaction
but it does not use page mode between two transactions.
•

When the NMC starts a memory read transaction on the NMI, it
simultaneously issues an O-bit read of the ownership RAMs on the CPU
module. If the transaction is a memory read and the O-bit is set, the
transaction is kept pending. The read data is discarded and subsequent
transfers are aborted. (Refer to Section 5.4.9 for details.)

5–10 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
•

If the NDAL transaction being serviced is an unmasked write, the write
is done in parallel with an O-bit read. If the hexaword being written is
found to be owned, the write is aborted after the first transfer, and is kept
pending. (Refer to Section 5.4.9.) The first transfer can be done before it is
known whether the location is owned because even if it is owned, since the
NDAL transaction was an UNMASKED write, the entire hexaword will be
overwritten as soon as the disown write comes from the owner. Therefore, it
is all right to allow the first data transfer to take place to the memory before
it is known whether the location is owned.

•

If the NDAL transaction is a masked write, a single transfer read is done
and the O-bit is read in parallel. If the write is not owned, it is completed by
merging the write data with the data from memory and writing it back. If the
write data is owned, it is aborted after the read and kept pending.

•

If the NDAL transaction that is being serviced is a disown write, and it is
found to be unowned when the O-bit is read, an error is flagged but the write
is completed.

•

If a write transaction has a completely masked transfer (all corresponding
byte masks are equal to 0; no bytes will be written), then the CAS
corresponding to that transfer is not asserted (that is, no write is done to
the DRAMs).

5.4.3.4 Nonexistent Memory Access
If the incoming address bits <28:24> (<28:26> for 4 Mb DRAMs) do not match any
of the programmed base addresses in the memory configuration register, the NMC
memory interface flags an error by returning read data error NDAL cycle on a
read or requesting a hard error interrupt (SCB offset=6016 ) on writes. In every
case, the NMC responds to the NDAL transaction regardless of the fact that it
is to nonexistent memory. This prevents errors in the NVAX CPU resulting from
NDAL timeouts on read transactions.

5.4.4 Error Checking for Data Memory
The NMC implements a single bit error correcting, double bit error detecting,
single symbol (nibble) error detecting (SEC/DED/SSD) code across 64 bits of
memory data (Figure 5–4). On memory write transactions, the NMC generates
ECC on the outgoing data and writes it into memory along with the data. On
memory read transactions, the NMC reads the memory data, generates the
corresponding ECC, compares the generated check bits with the incoming check
bits, and generates a syndrome. If the syndrome is a 0, there is no error in the
incoming data. If the syndrome matches a column in the code of Figure 5–4,
there is a correctable error in the corresponding data bit. The NMC returns the
corrected data. If the syndrome is not 0 and does not match any of the columns,
then the error is uncorrectable.
If, during a write transaction, there is a parity error in the NDAL data, or if
an illegal command is received on an NDAL write data cycle, or a BADWDATA
NDAL command (Section 3.11) is received on the NDAL, then the NMC forces
incorrect check bits in memory. This is done by inverting the three least
significant check bits. When, at a later stage, this data is read from memory,
an uncorrectable syndrome of 0716 will be received.

KA680 Main Memory System 5–11

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–4 SEC/DED/SSD Code Used in the NMC

DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DCCC CCCC CDDD
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 6BBB BBBB B 6 6 6
0123 4567 8901 2345 6789 0123 4567 8901 2345 6789 0123 4567 8901 2345 6789 0012 3456 7123

1101
1010
0111
0001
1111
1111
1110
0000

0001
0010
1100
1111
1001
0110
0000
0000

1101 1101 1100 1110
1011 1010 1011 1101
0110 0111 0111 0011
0001 0001 0001 1111
0010 0100 1000 0110
0100 1000 0010 1001
1000 0010 0100 1111
0000 0000 0000 0000

0011
0100
1000
0001
0111
1101
1011
0000

0010
0100
1001
0001
1101
1011
0111
0000

0001 1101
0010 1011
1100 0110
1111 0001
1001 0010
0110 0100
1111 0111
1111 1111

1101
1010
0111
0001
0100
1000
1101
1111

1100
1011
0111
0001
1000
0010
1011
1111

1110
1101
0011
1111
0110
1001
0000
1111

0011
0100
1000
0001
0111
1101
0100
1111

0010
0100
1001
0001
1101
1011
1000
1111

0100
1010
0001
1000
0000
0000
1000
0000

0000
0000
0000
1000
0100
0010
0001
0000

0000
0000
0000
0100
0010
0001
0111
1111

S0
S1
S2
S3
S4
S5
S6
S7 *

S0, S1, S2, S4, S5, S6 ---- Even Parity
---- Odd Parity
S3, S7

*S7 Depends on Data Bits <63:32> Only.
LJ-01321-TI0

5.4.5 Error Checking for Ownership Bit Memory
The NMC supports single error correction across eight O-bits in memory. An
O-bit memory read/write accesses eight O-bits and four ECC check bits. During
an O-bit read transaction, the NMC generates the check bits on the incoming
O_MD<7:0> (the eight O-bits being read) and XORs them with the received check
bits, O_MD<11:8>. If the resulting syndrome is 0, there is no error in the data.
If the syndrome matches any of the columns in Figure 5–5, then the error is
correctable. This code does not detect all multiple bit errors. Other than single
bit errors the NMC detects the all 0s and all 1s failures on O_MD<11:0>.
Figure 5–5 Single Error Correcting Code for O-bit Memory
CCCC
DDDDDD DD B B B B
01234567 0123
11101001
11010110
10110101
01111010

1000
0100
0010
0001

S0
S1
S2
S3

LJ-01322-TI0

5.4.6 Memory Diagnostic Support
The NMC facilitates data memory testing in two ways - fast diagnostic mode, and
diagnostic check bit mode. These modes can be used separately or simultaneously.
The NMC allows memory error detection to be disabled to allow testing the check
bit memory DRAMs. The NMC does not have to be in either of the two diagnostic
modes for memory error dectection to be disabled. It can be disabled by setting
MMCDSR<DIS_MEM_ERR_DETECT>.

WARNING
Both of these modes are for diagnostic purposes only; they should not be
set during normal system operation.

5–12 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
5.4.6.1 Fast Diagnostic Mode
Fast diagnostic mode allows main memory to be tested at a fast rate by reading,
writing, and comparing locations from more than one memory bank at a time.
The NMC enters fast diagnostic mode when MMCDSR bit<FAST_DIAG_MODE>
is set. (Refer to Table 5–8.) The implementation of fast diagnostic mode is the
same as that in the PELE system. (Refer to the GMX specification.) When the
NMC is in fast diagnostic mode, it sets MODE_SEL<1> to "1" on every read
or write transaction. If at the same time the FDM second pass bit is set in
MMCDSR (Table 5–8), MODE_SEL<0> is also set to "1".
5.4.6.2 Diagnostic Check Bit Mode
Diagnostic check bit mode enables software to force an arbitrary value on the
data memory check bits. Diagnostic check bit mode can be entered by setting
MMCDSR bit<DIAG_CKB_MODE>. (Refer to Table 5–8.)
When diagnostic check bit mode is set, on a memory write transaction, the check
bit field in MMCDSR<MEM_DIAG_CKBS> is written to memory instead of the
check bits generated by the ECC logic. The check bits received on a memory
read transaction can be obtained by reading MMCDSR<MEM_DIAG_CKBS> or
MMCDSR<MEM_CHECK_BITS>, regardless of the value of MMCDSR<DIAG_
CKB_MODE>.
Memory tests using diagnostic check bit mode should be run from the ROM with
both the Pcache and Bcache off. This forces all memory reads to be of quadword
length and is required when using diagnostic check bit mode. The NMC only
logs the check bits corresponding to the first two transfers of a memory read
transaction. If software wants to read the memory check bits, it should read the
corresponding memory location and immediately follow it up with an MMCDSR
read. This is necessary to ensure that the read check bits loaded in MMCDSR
correspond to the correct read data. The NMC logs the diagnostic check bits on
any memory read transactions, including the read part of a masked write.

5.4.7 Ownership Bit Memory Diagnostic Support
The NMC provides 4K quadword aligned registers (O-bit data registers) to access
the O-bit memory in I/O space. These registers range from 2101 0000 - 2101
7FFF. The NMC supports a maximum of 2M O-bit locations. These locations
can be made up of 512 segments, where each segment consists of 4K O-bit
locations. One of the 4K NMC O-bit data registers corresponds to 512 possible
O-bit locations, one for each segment. The segment number can be specified in an
O-bit address and mode register. Bits <14:3> of the addresses of MODRs along
with the segment number in the O-bit address and mode register are used to
specify an O-bit location.
The address and mode register also contains a 3-bit mask field to specify a
particular O-bit within an O-bit memory location.
O-bit memory can be accessed in one of 5 modes - reconstruction mode, memory
test mode with ECC, memory test mode with forced check bits, fast memory test
mode with ECC, and fast memory test mode with forced check bits.
To perform a diagnostic operation on O-bit memory, software should load the
appropriate address and mode in the O-bit address and mode register (MOAMR),
and then do a read or a write to the appropriate O-bit data register. The different
O-bit diagnostic modes are described in the following sections.

KA680 Main Memory System 5–13

KA680 Main Memory System
5.4 NMC Architectural Overview
5.4.7.1 Reconstruction Mode
This mode allows software to change the value of a particular O-bit. The O-bit
address register should be loaded with the segment address corresponding to that
O-bit, the mask should be written, and the mode should be set to reconstruction.
Then, software should do a write transaction to the corresponding O-bit data
register. This would cause the NMC to do a read-modify-write transaction on
O-bit memory location and update the O-bit.
A read in this mode results in the entire O-bit field being returned on bits <11:0>.
5.4.7.2 Memory Test Mode with ECC
This mode allows software to overwrite the data part of an O-bit memory location
without the check bits. The check bits are generated by the ECC logic. A write to
an O-bit data register in this mode forces the data bits <7:0> to be written onto
the corresponding O-bit memory location.
A read in this mode results in the entire O-bit field being returned.
5.4.7.3 Fast Memory Test Mode with ECC
The fast memory test mode with ECC allows software to overwrite O-bit memory
data as in memory test mode with ECC. In this mode, two locations are written
and read. When a write is done to an O-bit I/O address in this mode, data from
bits <7:0> and <19:12> is written to two consecutive O-bit memory locations,
respectively.
A read of the O-bit data register in this mode returns data from two consecutive
O-bit locations in bits <11:0> and <23:12>, respectively.
5.4.7.4 Memory Test Mode with Forced Check Bits
This mode allows software to overwrite one entire O-bit memory location (eight
O-bits plus four check bits) with any desired pattern. A write to an O-bit
data register in this mode forces the data bits <11:0> to be written onto the
corresponding O-bit memory location.
A read of the O-bit data register in this mode results in a read of the
corresponding O-bit memory location. The data that is read from O-bit memory is
returned on bits <11:0>.
5.4.7.5 Fast Memory Test Mode with Forced Check Bits
The fast memory test mode with forced check bits allows software to overwrite
O-bit memory locations as in memory test mode with forced check bits. In this
mode, two locations are written and read. When a write is done to an O-bit
data register in this mode, data from bits <11:0> and <23:12> is written to two
consecutive O-bit memory locations, respectively.
A read of the O-bit register in this mode returns data from two consecutive O-bit
locations on bits <11:0> and <23:12>, respectively.

5.4.8 I/O Section
This section consists of the control and status registers (NMC_CSRs) and the
decoders for I/O and memory addresses. It does the following operations:
•

CSR reads

•

CSR writes

5–14 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
•

Clear write buffer

The I/O space of the NMC is defined as 2101 0000 - 2101 804C, 2100 0110 (hex);
the NMC acknowledges these I/O addresses only.
5.4.8.1 Registers
The NMC has 21 control and status registers (NMC_CSRs) that can be read
or written by the CPU. These CSRs are addressed as aligned longwords only.
Quadword reads or writes to NMC_CSRs are not supported.
In addition, it has 4K O-bit data registers, which are quadword-aligned.
All the NMC_CSRs are cleared on power-up reset, unless otherwise specified in
the following description. Write operations to read-only registers do not cause any
errors and are responded to as a normal operation; however, the operation does
not alter any NMC register contents. Table 5–4 lists all the registers and their
addresses. Included in this list is the clear write buffer register.
Table 5–4 NMC Registers
Number

Name

Address

No. of
Registers

MEMCON0-7

Memory Configuration Registers

2101 8000 - 801C

MEMSIG0-7

Memory Signature Registers

2101 8020 - 803C

MEAR

Error Address Information Registers

2101 8040

MESR

Error Status Register

2101 8044

MMCDSR

Mode Control and Diagnostic Register

2101 8048

MOAMR

O-bit Address and Mode Register

2101 804C

MEMCON0-19

NMC Registers

2101 8000 - 804C

MCWB

Clear Write Buffer Register

2100 0110

MODRs

O-bit Data Registers

2101 0000 - 7FFF

5.4.8.1.1 Memory Configuration Registers (MEMCON0 - MEMCON7) The NMC
supports up to 8 memory sets of 16 MB with 1 Mb DRAMs and 64 MB with 4
Mb DRAMs. Each set is associated with one software programmable register.
Each register stores set specific information consisting of a set base address, a set
enable, and the set signature. These registers are written following a signature
read transaction from MEMSIG0-7 and the computation of the base addresses.
The following is a description of all the bit fields in these registers.

KA680 Main Memory System 5–15

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–6 Memory Configuration Registers
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

6 5

32/64-BIT

MODE

SIGNATURE

BASE ADDRESS

BASE ADDRESS V A L I D

MEMCON0-7 :

2101 8000 -

2101 801C

Table 5–5 Memory Configuration Registers, MEMCON0-7
Register Field

Bits

Type, Reset
State

Base Address
Valid / Set
Enable

RW, 0

Unused

30:29

MBZ, 0

This field reads as 0.

Base Address

28:24

RW, 0

Specifies the memory base address of the related set. If
the RAM size of the set is 1 Mb, then all 5 bits are used
in the address comparison. If the RAM size of the set
is 4 Mb, then only bits <28:26> are used in the address
comparison. In either case, all 5 bits can be read and
written. See Section 5.4.2.1 and Section 5.4.2.3 for
details on the use of the base address.

Unused

23:3

MBZ, 0

This field reads as 0.

Description
This read/write bit indicates that the base address
programmed in bits <28:24> and the signature in bits
<2:1> are valid. This bit is cleared on powerup. It
should be set when the base address and the signature
are written to enable addressing of the set. In addition,
this bit may be used by diagnostics to selectively disable
sets.

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

5–16 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–5 (Cont.) Memory Configuration Registers, MEMCON0-7
Register Field

Bits

Type, Reset
State

Signature

2:1

RW, 0

Must be 1

RW, 0

Description
Indicates the RAM size of the corresponding memory
set. It has to be written to by software after doing a
signature read of the corresponding set.
Value

Configuration

Unassigned

RAM size 1 Mb

RAM size 4 Mb

Nonexistent bank

This bit must be set to a 1 by software. This bit, when
clear, specifies memory controller operation to be 32bit mode. when set, it indicates 64-bit mode. Since the
KA680 only supports 64-bit memory, this bit must be set
to a 1 by ROM software during power-up initialization
to enable operations with memory.

5.4.8.1.2 Memory Signature Registers (MEMSIG0 - MEMSIG7) Each set of
physical memory banks has a signature register associated with it. MEMSIG0
corresponds to set 0, MEMSIG1 to set 1, and so on. A read from any of these
registers causes the NMC to do a signature read transaction on the NMI to the
corresponding set. The information returned on a read to these registers should
be written by software to the appropriate bits in the corresponding memory
configuration register (MEMCON0-7). For instance, a read from MEMSIG0
would return the signature of memory set 0; this should be written by software to
MEMCON0.
The signature information includes the size of the DRAMs used to make up that
memory set and the width of memory data, if the set is present in memory. If the
set is not present, a value of FFFFFFFF (hexadecimal) is returned as read data.
During system power-up configuration and self-test, the ROM software reads
the signature values. Based on the signature that is returned read from each
MEMSIG register, the corresponding MEMCON register should be programmed
accordingly. Table 5–2 shows the two possible values that will be returned when
a MEMSIG register is read for an existing memory set.
5.4.8.1.3 Error Address Information Register (MEAR) When an error is logged
by the NMC in MESR, the corresponding address and commander ID are logged
in MEAR. This information is loaded by the first error and is not changed until
all the error bits are cleared. These registers are read-only and have valid
information only when an error bit is set in MESR.

KA680 Main Memory System 5–17

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–7 Error Address Information Register

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

MEAR :

6 5

LONGWORD ERROR ADDRESS

2101 8040

Table 5–6 Error Address Information Register, MEAR
Register Field

Bits

Type, Reset
State

Description

Unused

MBZ, 0

This bit is unused and is read as 0.

30:28

RO, 0

This field contains the ID of the commander
corresponding to the transaction in error. The ID is
logged on NDAL errors only; memory errors do not log
the ID.

Error Address

27:3

RO, 0

This field contains the hexaword address at which the
error occurred. This field is always logged.

Error Address

2:1

RO, 0

This field indicates the quadword at which the error
occurred.
This field is logged on memory errors.
This field is logged on NDAL write data parity errors,
and on NDAL illegal write command errors.
This field is not valid on unowned disown write errors
and disown write timeout errors. The address is valid
up to the hexaword only.
This field is not valid on nonexistent memory errors.

Error Address

RO, 0

This bit indicates the longword address of a memory
transaction with an error.
This bit is not valid on NDAL errors.

RO—Read-only
RW—Read/write
WC—Write one-to-clear

5.4.8.1.4 Error Status Register (MESR)
MESR.

5–18 KA680 Main Memory System

The NMC reports error information in

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–8 Error Status Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

6 5

LOST_MEM_SOFT_ERR
OB_FATAL_ERR
OB_CORR_ERR
OB_SYNDROME
LOST_MEM_HARD_ERR
MEM_SOFT_ERR
MEM_HARD_ERR

MEM_SYNDROME
MEM_NXM
NDAL DATA P A R I T Y ERR
NDAL_ILLEGAL_WR_CMD
TRANS_TIM_OUT
DISOWN_UNOWNED
NO_ACK_ERR
BAD_NDAL_ERR
RESERVED_CMD
LOST_NDAL_SOFT_ERR
LOST_NDAL_HARD_ERR
ERROR SUMMARY

MESR :

2101 8044

Table 5–7 Error Status Register, MESR
Register Field

Bits

Type, Reset
State

Error Summary

RO, 0

This bit is "1" when any error is logged by the
NMC in this register. It is clear when all the
error bits are cleared.

LOST_NDAL_HARD_
ERR

WC, 0

This bit is set if a pending transaction times
out, a disown write is found to be unowned,
or a nonexistent address is received on the
NDAL, and MEAR cannot be loaded because
of a previous error that has not been cleared.

LOST_NDAL_SOFT_ERR

WC, 0

This bit is set if a an NDAL data parity
error or an illegal write command is detected
on the NDAL, and MEAR cannot be loaded
because of a previous error that has not been
cleared and soft error logging is enabled
(MMCDSR<EN_SOFT_ERR_LOG> is 1). This
bit is also logged if an NDAL data parity error
or an illegal write data command is detected
on the NDAL and soft error logging is disabled
(MMCDSR<EN_SOFT_ERR_LOG> is 0).

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

KA680 Main Memory System 5–19

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–7 (Cont.) Error Status Register, MESR
Register Field

Bits

Type, Reset
State

NDAL_RESERVED_CMD

WC, 0

This bit is set when the NMC receives a
reserved command on the NDAL. The address
is not logged in MEAR.

BAD_NDAL_ERR

WC, 0

This bit is set when the NMC receives a
parity error on an NDAL address cycle or if it
receives an illegal length code on an otherwise
valid transaction. The address is not logged
in MEAR.

NO_ACK_ERR

WC, 0

This bit is set when the NMC does not receive
ACK_L when it returns read data on the
NDAL. The address is not logged in MEAR.

DISOWN_UNOWNED

WC, 0

This bit is set if the NMC receives a disown
write to an unowned location and MEAR can
be loaded with the address information.

PEND_TRANS_TIM_OUT

WC, 0

This bit is set when a pending transaction
times out waiting for the corresponding
disown write, and the address can be saved in
MEAR.

NDAL_ILLEGAL_WR_
CMD

WC, 0

This bit is set by the NMC when it receives a
command other than WDATA or BADWDATA
on the data part of an NDAL write, and
MEAR is free to load address information.

NDAL_DATA_PAR_ERR

WC, 0

This bit is set if a parity error is detected
on the NDAL during a data cycle of a write
transaction, and if MEAR is free to load the
address information.

Unused

MBZ, 0

This bit reads as 0.

MEM_NXM

WC, 0

This bit is set if the address received on
the NDAL is in memory space, but does not
match any of the programmed banks in the
NMC memory configuration registers. It is set
only if MEAR can be loaded with new address
information.

MEM_SYNDROME

19:12

RO, 0

This field stores the memory error syndrome
and is loaded when an ECC data memory
error is detected on the NMI. The syndrome is
logged only when the corresponding memory
error is not logged as a lost error.

MEM_HARD_ERR

WC, 0

This bit is set if an uncorrectable ECC error
occurred during a memory read transaction,
and if MEAR can be loaded with address
information.

MEM_SOFT_ERR

WC, 0

This bit is set if a correctable ECC error
occurred during a memory read or a masked
write transaction, or if an uncorrectable error
occurred during a masked write transaction,
and if MEAR can be loaded with address
information.

Description

(continued on next page)

5–20 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–7 (Cont.) Error Status Register, MESR
Register Field

Bits

Type, Reset
State

LOST_MEM_HARD_ERR

WC, 0

This bit is set if an uncorrectable ECC error
occurred during a memory read transaction,
and if MEAR could not be loaded with address
information because a previous error bit had
been logged in MESR.

OB_SYNDROME

8:5

RO, 0

This field stores the O-bit error syndrome
when an error is detected in O-bit memory
reads. The O-bit syndrome is logged only
when the corresponding O-bit error is not
logged as a lost error.

OB_CORR_ERR

WC, 0

This bit is set if a correctable O-bit memory
error occurred during an O-bit read
transaction, and if MEAR can be loaded with
address information.

OB_FATAL_ERR

WC, 0

This bit is set if the O-bit ECC logic detects a
syndrome of 1111(binary), indicating that the
incoming 12-bit O-bit data has an all 1s or all
0s failure. No address information is logged.

LOST_MEM_SOFT_ERR

WC, 0

This bit is set when: a correctable error occurs
during a memory read or a masked write
transaction, a correctable error occurs on an
O-bit read transaction, or an uncorrectable
data memory error occurs on a masked write
transaction, and a previous error has been
logged in MEAR and soft error logging is
enabled (MMCDSR<EN_SOFT_ERR_LOG> is
1). This bit is also set when: a correctable
error occurs during a memory read or a
masked write transaction, a correctable error
occurs on an O-bit read transaction, or an
uncorrectable data memory error occurs on
a masked write transaction and soft error
logging is disabled (MMCDSR<EN_SOFT_
ERR_LOG> is 0), irrespective of the state of
other error bits in MESR.

Unused

1:0

MBZ, 0

This field is unused.

Description

5.4.8.1.5 Mode Control and Diagnostic Status Register (MMCDSR) NMC
operating modes are controlled by bits in this register. In addition, this register
is used for storing diagnostic status information. The following is a description of
all the bit fields in this register.

KA680 Main Memory System 5–21

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–9 Mode Control and Diagnostic Status Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

6 5

FRC_REFRESH
DIS_REFRESH
FRC_WRONG_PAR_DATA_IN
FRC_WRONG_PAR_ADDR_IN
FRC_WRONG_PAR_DATA_OUT
REF_INTERVAL_SEL
DIS_MEM_ERR_DETECT
TIMEOUT_SCALER

MEM_CHECKBITS

MEM_DIAG_CHECKBITS

FLSH_BCACHE
EN_SOFT_ERR_LOG
QBUS_ON_IO1
DIAG_CHECKBIT_MODE
FDM_SECOND_PASS
FAST_DIAG_MODE

MMCDSR :

2101 8048

Table 5–8 Mode Control and Diagnostic Status Register, MMCDSR
Register Field

Bits

Type, Reset
State

FAST_DIAG_
MODE

RW, 0

This bit provides the mechanism for speeding
up initial diagnostic testing of memory. This bit
indicates to the NMC that it is in fast diagnostic
mode.

FDM_SECOND_
PASS

RW, 0

In a system with two sets of memory banks, fast
diagnostic mode has to be done in two passes.
This bit has to be set when the second pass of
the test has to be run. This bit is valid only when
MMCDSR<FAST_DIAG_MODE> is set.

DIAG_CKB_MODE

RW, 0

When set to 1, this bit enables the contents of
MMCDSR <MEM_DIAG_CKBS> to be driven onto
the check bit field of the memory data, instead of
the normal ECC check bits. When this bit is a 0,
the contents of MMCDSR<MEM_DIAG_CKBS>
are ignored during memory write transactions.
MMCDSR<MEM_DIAG_CKBS> should be valid
when this bit is set.

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear

(continued on next page)

5–22 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–8 (Cont.) Mode Control and Diagnostic Status Register, MMCDSR
Register Field

Bits

Type, Reset
State

QBUS_ON_IO1

RW, 0

This bit is used by the NMC to indicate on which CPbus the Q22–bus interface (CQBIC) resides. THIS
BIT IS CLEARED ON POWERUP AND MUST NOT
BE CHANGED.

EN_SOFT_ERR_
LOG

RW, 0

When this bit is a 0, NDAL and memory-related soft
errors are detected but no information is logged in
MEAR and MESR, and S_ERR_L is not asserted.
If the error happened on the NDAL, MESR<LOST_
NDAL_SOFT_ERR> is logged; if the error happened
in memory, the MESR<LOST_MEM_SOFT_ERR>
is logged. When this bit is 1, all the soft errors
are logged normally as described in the description
of MESR, and S_ERR_L is asserted whenever a
correctable error occurs. This bit does not affect
hard error logging.

FLUSH_BCACHE

RO, 0

When this bit is set by software, the NMC asserts
the CPU_WB_ONLY signal on the NDAL, which
informs the NVAX CPU to refrain from performing
non-writeback transactions on the NDAL. The
purpose of this bit is to allow the Bcache to be
flushed without creating excessive NDAL traffic
that might otherwise adversely affect the latency of
devices on CP1 and CP2 (namely, the Q22–bus).

Unused

RW, 0

–

MEM_DIAG_CKB

24:17

RW, 0

This field is ignored on memory write transactions
when diagnostic check mode (MMCDSR<DIAG_
CKB_MODE>) is cleared. During diagnostic check
bit mode, the bits in this field are written to memory
instead of the check bits generated by the ECC logic.

Description

A read of MMCDSR returns the check bits
corresponding to the first transfer of a memory
read transaction that happened prior to this NMC_
CSR read. This field is loaded on memory reads or
masked write transactions.
MEM_CHECKBITS

16:9

RO, 0

This field contains the memory check bits
corresponding to the second transfer of a memory
read transaction that happened prior to this NMC_
CSR read. This field is loaded on memory reads or
masked write transactions.

TIMEOUT_
SCALER

8:7

RW, 0

This 2-bit field is used as a prescaler to the disown
write timeout counter.
Value

Timer Count

µs (36 ns)

µs (42 ns)

2600

93.6

109.2

1600

57.6

67.2

800

28.8

33.6

400

14.4

16.8

(continued on next page)

KA680 Main Memory System 5–23

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–8 (Cont.) Mode Control and Diagnostic Status Register, MMCDSR
Register Field

Bits

Type, Reset
State

DIS_MEM_ERR

RW, 0

When this bit is 1, memory error detection and
correction is disabled. All memory error related
logging in MEAR and MESR is disabled. S_ERR_
L does not assert on correctable errors in memory
data; S_ERR_L does not assert on uncorrectable
errors in the read data of a masked write. A read
data error response is not returned on the NDAL
when uncorrectable errors occur in memory read
data.

REF_INT_SEL

RW, 0

When this bit is 1, the NMC uses an alternate
refresh interval for use in conjunction with NDAL
cycle times longer (slower) than 42 ns. Because
the KA680 and KA680 CPU modules operate at 42
ns NDAL cycle times or faster, this bit should not
be set by software because it will cause excessive
memory refresh cycles and subsequently reduce
system performance.

FRC_WRONG_
PAR_DATA_OUT

RW, 0

When set to 1, this bit forces the NDAL parity
generator to generate incorrect parity on the
command and ID field of a read data return cycle.
This will cause the commanders to not ACK the
response and timeout, waiting for the appropriate
data. The wrong parity is forced for one NMC
responder transaction only. This bit is self-clearing;
it is always read as 0. This bit is for test purposes
only and should not be set during normal system
operation.

FRC_WRONG_
PAR_ADDR_IN

RW, 0

When set to 1, this bit forces the NDAL parity
generator in the NMC to generate incorrect parity
on the command and ID field of an address cycle
addressed to it. This results in the NMC detecting
incorrect parity on incoming transactions, thus
causing it to not ACK the commander and assert S_
ERR_L. The wrong parity is forced for one NDAL
transaction (not a NOP) only. This bit is selfclearing. It is always read as 0. This bit is for test
purposes only and should not be set during normal
system operation.

FRC_WRONG_
PAR_DATA_IN

RW, 0

When set to 1, this bit forces the NDAL parity
generator to generate incorrect parity on the
command and ID field of a write data. This causes
the NMC to respond to the cycle with ACK_L, but
assert S_ERR_L and force incorrect check bits in
memory data. The wrong parity is forced for one
NDAL data cycle only. This bit is self-clearing; it
is always read as 0. This bit is for test purposes
only and should not be set during normal system
operation.

Description

(continued on next page)

5–24 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–8 (Cont.) Mode Control and Diagnostic Status Register, MMCDSR
Register Field

Bits

Type, Reset
State

DIS_REFRESH

RW, 0

This bit, when set to 1, disables memory refresh
transactions, irrespective of the state of MMCDSR
<FRC_REFRESH>, the force refresh bit. It also
clears the refresh interval and address counters
to 0. This functionality has been added for test
purposes only and should not be used in normal
system operation.

FRC_REFRESH

RW, 0

When this bit is cleared to 0, the refresh control logic
behaves normally and refreshes are done on the NMI
when the refresh interval timer overflows. When
this bit is set to 1, it forces the memory interface of
the NMC to do continuous memory refreshes as long
as there are no requests for memory transactions.
If the memory is requested to do a read, write, or
signature read transaction, the stream of memory
refreshes is interrupted.

Description

5.4.8.1.6 O-bit Address and Mode Register (MOAMR) This register, along with
the O-bit data register, facilitates initialization and testing of O-bit memory. This
register stores the address and mode of operation.
Figure 5–10 O-bit Address and Mode Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

6 5

O - B I T O P E R A T I O N MODE
O - B I T MASK

O - B I T SEGMENT ADDRESS
DIS_OB_ERR
IGNORE_OB_MODE

MOAMR :

2101 804C

KA680 Main Memory System 5–25

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–9 O-bit Address and Mode Register, MOAMR
Register Field

Bits

Type, Reset
State

Description

Unused

31:17

MBZ, 0

This field is read as 0.

Ignore O-bit Mode

RW,0

Setting this bit causes the memory controller
to ignore the state of the ownership bits when
processing memory transactions. This bit is for
diagnostic purposes only and should not be set under
normal conditions.

Disable O-bit
Errors

RW,0

Setting this bit causes the memory controller to
ignore any ECC errors in the O-bits when processing
memory transactions. This bit is for diagnostic
purposes only and should not be set under normal
conditions.

O-bit Segment
Address

14:6

RW, 0

This field contains the segment address
corresponding to the O-bit to be accessed.

O-bit Mask

5:3

RW, 0

This field contains the O-bit mask. It is used in
reconstruction mode to specify the O-bit to be
accessed.

O-bit Operation
Mode

2:0

RW, 0

This field indicates the mode of operation on a read
or write of the O-bit data registers. The following is
the assignment of bits<2:0> in this field.
Value

O-bit Mode

000

Reconstruction mode

001

Unassigned

010

Memory test mode

011

Fast memory test mode

100

Unassigned

101

Unassigned

110

Memory test mode with forced check bits

111

Fast memory test mode with forced check
bits

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

5.4.8.1.7 O-bit Data Registers (MODRs) There are 4K O-bit data registers; each
register corresponds to one of 512 O-bit memory locations. The NMC uses the
segment number provided in the O-bit address and mode register to determine
the appropriate O-bit location addressed. A read or write from/to an O-bit data
register causes the NMC to do a read/write from/to the O-bit memory location
whose segment number corresponds to the value in the O-bit address and mode
register.

5–26 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–11 O-bit Data Registers
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9

6 5

O-BIT FIELD 0

O-BIT FIELD 1

MODR :

2101 0000

2 1 0 1 7FFC

Table 5–10 O-bit Data Registers, MODR
Register Field

Bits

Type, Reset
State

Description

Unused

31:24

MBZ, 0

This field is read as 0.

O-bit Field 1

23:12

RW, 0

This field is used in fast memory test only. It
contains the O-bit field (O-bits + check bits) for
the second O-bit location to be read/written in fast
memory test mode.
When the force check bits mode is disabled in the
O-bit address and mode register, only bits <19:12> of
this field are valid.

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

KA680 Main Memory System 5–27

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–10 (Cont.) O-bit Data Registers, MODR
Register Field

Bits

Type, Reset
State

O-bit Field 0

11:0

RW, 0

Description
This field contains the value for the O-bit field to
be used in the first part of a fast O-bit test mode
transaction, memory test mode, and reconstruction
mode.
A read of MODRs returns the entire O-bit location in
fast memory test, memory test, and reconstruction
mode.
A write to this field in reconstruction mode requires
valid data in the appropriate O-bit only. A write to
this field in O-bit memory test or fast O-bit memory
test mode with the force check bits mode disabled
requires valid data in bits <7:0> only. A write to this
field in O-bit memory test or fast O-bit memory test
mode requires valid data in all 12 bits.

5.4.8.1.8 Clear Write Buffer Register (NMC_CSR20) The clear write buffer
register address, 2100 0110, is in the NVAX CPU IPR address range. It is
longword-aligned. A read or write to this register is required to flush any CPU
write buffers in the NMC. The NMC buffers up CPU writes in its CPU_QUE
and CPU disown writes in WB_QUE. Since the CPU_QUE of the NMC is one
deep and WB_QUE is given the highest priority by the NMC, all writes and
write-backs from the CPU that happened before a clear write buffer transaction
on the NDAL are completed in memory before the clear write buffer is serviced
by the NMC. Thus, the NMC does not need to take any special action on a clear
write buffer transaction. A read from NMC_CSR20 returns all zeros as the data;
a write does nothing.

5.4.9 NMC Transaction Handling
The previous sections in this chapter described the architecture and organization
of four major blocks in the NMC: the NDAL interface, the memory interface, the
O-bit interface, and the I/O interface. This section describes the fifth block in the
NMC, the transaction handler. Figure 5–12 illustrates the organization of these
five blocks.

5–28 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Figure 5–12 NMC Block Diagram

SEL_TRANS
ADDRESS
MUX

IO1_QUE
REFRESH
ADDRESS

TRANSACTION
SEQUENCER

IO2_QUE

ADDRESS

PEND_BUF

&
INTERVAL
OUTPUT PAD L A T C H
CONTROL

MERGE

CPU_QUE

WR_DATA

CUR_BUF

I N P U T PAD L A T C H

PAD L A T C H
& PARITY

NDAL
WB_QUE

USED ON
READ-MODIFY-WRITE

ECC L O G I C
MEMORY

T R A N S A C T I O N HANDLER

TIMING
GENERATOR

IN
OUT
CONTROL

CONTROL

IO
SEQUENCER

DATA
REGISTERS

CORRECTION
LOGIC
+
LATCH

OUT_QUE
PAD L A T C H
& PARITY

I O INTERFACE

MEMORY I N T E R F A C E

NDAL I N T E R F A C E
WRITE
ECC

N_ARB

READ
ECC

NDAL A R B I T E R
O - B I T I O ADDRESS

O - B I T ADDRESS
&
CONTROL

O - B I T INTERFACE

The transaction handler consists of an internal arbiter. The data path of the
transaction handler includes a current transaction buffer and one pending
transaction buffer. These blocks are described in greater detail in the following
sections.
5.4.9.1 NMC Internal Arbitration
Transactions loaded into the IN_QUEs of the NDAL interface of the NMC are
selected for servicing by an internal arbiter. This internal arbiter can get up to
four requests, one from each of the three NWB_QUEs, and one from WB_QUE.
In the absence of memory accesses from the Q22–bus, the WB_QUE is given
the highest priority, and the three NWB_QUEs are given equal priority; they
are serviced in round-robin. When Q22–bus devices are accessing main memory,
IO2_QUE is given a higher priority over WB_QUE (which helps reduce Q22–bus
latency), and transactions from IO1_QUE and CPU_QUE are not selected unless
they are marked.

KA680 Main Memory System 5–29

KA680 Main Memory System
5.4 NMC Architectural Overview
5.4.9.2 Transaction Handler Datapath
When a transaction is selected for processing by the NMC, the information from
the corresponding NMC’s IN_QUE entry is loaded into the current transaction
buffer, CUR_BUF. CUR_BUF contains all the information that an IN_QUE entry
contains.
When a disown write transaction is received on the NDAL, and there is a
transaction pending to the same hexaword in one of the NWB_QUEs, the address
information and data (writes only) for that transaction are loaded into a "pending
buffer"- PEND_BUF, and the corresponding pending, valid, and mark bits for that
entry are cleared.

5.4.10 NMC Transactions
This section describes how the various transactions are handled by the NMC.
5.4.10.1 Ownership Read
When an ownership read transaction is received in CUR_BUF, the data read and
the O-bit read are started in parallel.
If the corresponding O-bit is not set, indicating that the hexaword can be owned
by the requesting commander, the hexaword of data is loaded into the OUT_
QUE as it is received from memory with the requested quadword loaded first.
The O-bit is set by the memory interface after it checks the memory data for
errors. The O-bit is only set when there are no uncorrectable errors in the
requested memory data or the O-bit field. As a performance enhancement, the
O-bit interface unconditionally sets the O-bit after every OREAD transaction; if
later a memory data uncorrectable error is found, the original state of the O-bit is
restored. The corresponding IN_QUE entry is cleared as soon as the transaction
handler determines that the hexaword is not owned.
If the corresponding O-bit is set, indicating that the hexaword is owned by
another device, the "pending bit" is set in the appropriate NWB_QUE, the
pending timer for that queue is started, and the read is aborted on the NMI.
5.4.10.2 Memory Read
The flow for the memory read is the same as that of the OREAD, the only
difference being that the O-bit is not set at the end of the read.
5.4.10.3 Memory Write
On a memory write transaction, the data write and the O-bit read are done in
parallel, instead of reading the O-bit first and doing the write only if the O-bit is
cleared. Starting the write and the O-bit read in parallel saves time on writes
that are not owned.
If the hexaword is not owned (the corresponding O-bit is clear), the write is
completed. The corresponding IN_QUE entry is cleared as soon as the transaction
handler finds out that the transaction is not owned.
If the hexaword is owned (the corresponding O-bit is set), the write is aborted
(after one transfer on an unmasked write, or after the read part of a masked
write), the corresponding pending bit is set, and the pending timer is started.
At this point, some of the data corresponding to the aborted write is written to
memory. This results in an apparent memory incoherency. However, since the
corresponding hexaword is owned by some other node, the data in memory is stale
anyway and has to be updated. The disown write flow ensures the coherence of
memory.

5–30 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
5.4.10.4 Disown Write
Disown writes can be quadword or hexaword writes. A quadword disown write
may be a write unlock from the NCA on behalf of an I/O device, or it could be
from the CPU (when the Bcache is off or in error transition mode). The CPU
may also do a quadword disown write instead of a hexaword disown if it has
seen one of the other commanders do a hexaword write to the same location;
in this case, it masks out all the data. The reason for this optimization is as
follows: if the CPU owns a hexaword of memory, and it sees on the NDAL a
hexaword write transaction (from the NCA) to that location, then according to
NDAL protocol it must relinquish ownership of the hexword via a disown write
transaction (WDISOWN). Recall, however, that the hexaword write from the
NCA will be queued up in the NMC, waiting for the WDISOWN from the CPU.
Since whatever value the CPU specifies in the WDISOWN would be immediately
overwritten by the NCA’s pending hexaword write, the CPU saves three NDAL
cycles by only writing a quadword of data with the WDISOWN transaction.
When the NMC’s transaction sequencer receives a disown write, it checks the
state of the pending bits in the NWB_QUEs to see if there are any pending reads
or writes to that hexaword.
If there are no pending transactions, the memory write and an O-bit read are
started in parallel. If the hexaword is not owned, an error is flagged but the data
write is completed. If the O-bit is set, the write is completed and the O-bit is
cleared. The corresponding IN_QUE entry is cleared as soon as the O-bit read is
complete.
If a write is pending to the same hexaword, the IN_QUE entry corresponding to
the pending write is cleared by the transaction handler. Merging of data occurs
according to the byte masks of the pending write, and the data is written to
memory. The data in memory is overwritten by the merged data, and memory
coherence is preserved.
If the pending transaction is a read, and the disown write is a hexaword, read
data is returned as the disown write is written to memory. If the disown write
is a quadword, the read is done from memory, and the write data is merged with
the appropriate quadword and returned on the NDAL. If the pending transaction
is a normal memory read, the O-bit is cleared at the end of the disown write. If
the pending transaction is a ownership read, the O-bit is set at the end of the
disown write if no uncorrectable memory errors have been found in the requested
quadword.

5.4.11 I/O Transactions
The NMC supports I/O reads or writes to its internal registers only. No ownership
protocol is supported on I/O addresses. Ownership reads or disown writes to I/O
space are treated as normal reads and writes.

5.4.12 NMC Error Handling
Errors in the NMC can be of two types—NDAL-related errors and memory-related
errors. These are described in the following tables.

KA680 Main Memory System 5–31

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–11 NDAL-related Errors and NMC Responses
Description of Error

Specific Situation

Action Taken by NMC

NMC detects a parity
error on an NDAL cycle

Presumed address cycle,
not an NMC write data
cycle

Soft error interrupt on reads, both
hard and soft error interrupt on writes;
MESR<BAD_NDAL_ERR> logged. No
address information is logged.

Presumed data cycle
on a write; address has
been received previously

Soft error interrupt; logs the error
in MESR<NDAL_DATA_PAR_ERR>.
Memory write is done and incorrect
check bits are forced in memory data.
CSR writes are aborted, no write is
done, soft error interrupt. Quadword
address and commander ID are logged
in MEAR.

NMC detects an illegal
length on an NDAL
address cycle to its
address space

Presumed address cycle

ACK_L not asserted; S_ERR_L
asserted; MESR<BAD_NDAL_ERR>
logged. No address information is
logged.

NMC detects a reserved
command on an NDAL
cycle

Presumed address cycle

Soft error interrupt on reads to NMC,
hard error interrupt on writes to NMC;
MESR<RESERVED_CMD> is logged.
No address information is logged.

Illegal write data CMD

Data cycles on writes

Write for the specified length is done;
incorrect check bits are loaded in
memory for the quadword with the
incorrect command; soft error interrupt.
Error logged in MESR<ILLEGAL_WR_
CMD>. On CSR write transactions, a
soft error interrupt is requested, and
the write is aborted. Quadword error
address and commander ID are logged.

No acknowledgement
when requested read
data is returned by the
NMC

IREAD, DREAD

Soft error interrupt is requested; logs
the error in MESR<NO_ACK_ERR>.
No address logged; the corresponding
commander should log the address
information. All read data is returned.

OREAD

Soft error interrupt is requested; logs
the error in MESR<NO_ACK_ERR>.
No address information is logged; the
corresponding commander should log
address information. All read data is
returned. Does not affect the setting of
the O-bit.

Write

Hard error interrupt is requested; logs
the error information in MESR<PEND_
TRANS_TIM_OUT>. Hexaword address
and ID are logged. Transaction is
aborted.

Read

Read data error transaction returned
on requested quadword. Log the
error information in MESR<PEND_
TIM_OUT>. Hexaword address and
commander ID are logged.

Pending transaction
times out waiting for
disown write

(continued on next page)

5–32 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–11 (Cont.) NDAL-related Errors and NMC Responses
Description of Error

Specific Situation

Action Taken by NMC

Disown write to an
unowned location

WDISOWN

Hard error interrupt requested. Do
the write. Pending transactions
will be completed. Log the error
in MESR<DISOWN_UNOWNED>.
Hexaword address and commander ID
are logged.

Nonexistent memory
address

Read

Read data error returned on requested
data. Error logged in MESR<MEM_
NXM>. Hexaword address and
commander ID are logged.

Write

Hard error interrupt is requested.
Error logged in MESR<MEM_NXM>.
Hexaword address and commander ID
are logged.

Table 5–12 Memory-related Errors and NMC Responses
Description of Error

Specific Situation

Action Taken by NMC

NMC detects an
uncorrectable data
memory error

Owned reads,
Owned masked writes

The NMC does not flag any errors and does not log
any bits in this case. A memory transaction to a
location that is found to be owned is not completed
until the corresponding disown write happens. The
data in memory is stale, and the disown write may
overwrite it, thus writing correct data over the stale
data with errors. No error will be logged in this
case. If the disown write does not overwrite this
location (quadword disown), then the uncorrectable
data memory error is found again, and will be
flagged and logged this time.

Memory reads (not
owned)

Read data error is returned on that transfer;
subsequent transfers are aborted. Error is logged in
MESR<MEM_HARD_ERR>. Longword address is
logged.

OREADs (not owned)

Read data error is returned on that transfer;
subsequent transfers are aborted. Error is logged
in MESR<MEM_HARD_ERR>. Longword address
is logged. O-bit not set if error occurred on the
requested quadword.

Masked memory disown
writes

S_ERR_L is asserted; the write corresponding to
that transfer does not happen. If a read is pending
to that location, RDE is returned on the read. In
this case, no error interrupt is requested. Error is
logged in MESR<MEM_SOFT_ERR>. Longword
address is logged.

Masked memory writes,
no disown (not owned)

Soft error interrupt is requested; the write
corresponding to that transfer does not happen.
Error is logged in MESR<MEM_SOFT_ERR>.
Longword address is logged.
(continued on next page)

KA680 Main Memory System 5–33

KA680 Main Memory System
5.4 NMC Architectural Overview
Table 5–12 (Cont.) Memory-related Errors and NMC Responses
Description of Error

Specific Situation

Action Taken by NMC

NMC detects a fatal
O-bit error

All transactions

An O-bit fatal error is flagged when the NMC
does an O-bit read transaction that has an error
syndrome of 1111 (binary). This syndrome is
received if the O-bit read returns all 0s or all 1s
in the 12-bit field. When this error happens, the
NMC requests a hard error interrupt, and logs
MESR<OB_FATAL_ERR> bit. No address is logged,
and the transactions are completed as if there were
no error.

NMC detects a
correctable data memory
error

Memory reads

Data is corrected and returned on the NDAL. Soft
error interrupt requested. Data is not changed in
memory. Error is logged in MESR<MEM_CORR_
ERR>. Longword address is logged.

Masked memory writes

Soft error interrupt is requested; read data is
corrected and merged with write data and retired
to memory. Error is logged in MESR<MEM_CORR_
ERR>. Longword address is logged.

Read, writes

Soft error interrupt is requested. Error is logged
in MESR<OB_CORR_ERR>. Hexaword address is
logged in MEAR.

NMC detects a
correctable error in
O-bit field

5.4.13 NDAL Arbitration
The three nodes on the NDAL request the bus whenever they have a transaction
to perform on the NDAL. A commander could initiate a transaction or a responder
could be responding to a pending transaction. The NMC is a responder only, the
NVAX CPU is a commander only, and the NCA can be both a commander and
responder, although not during the same transaction. The NMC contains the
arbiter (N_ARB) for the NDAL. Arbitration is done in parallel with data transfer
cycles using a set of lines dedicated specifically for arbitration. They are detailed
in this section.
The NMC request is asserted a cycle before quadword read data is loaded into the
OUT_QUE. The N_ARB priority scheme is discussed in this section.
When WB_QUE is full, the N_ARB does not grant the bus to any node except the
NMC.
When a non-writeback transaction is recieved by the NMC, the WB_ONLY signal
corresponding to that commander is asserted. N_ARB does not grant the bus to
that node for the next cycle.
The NMC is given the highest priority by N_ARB. The two I/O ports of the NCA
are given the second priority; they are serviced with a round-robin scheme. The
NVAX CPU has the lowest priority. Table 5–13 indicates the priority of the NDAL
arbiter.
Table 5–13 NDAL Arbitration Priority
Priority

Node

NMC

IO1, IO2

CPU

5–34 KA680 Main Memory System

KA680 Main Memory System
5.4 NMC Architectural Overview
The NMC request is never ignored by N_ARB. If no node requests the NDAL, the
NMC is given the grant (it is the default bus master of the NDAL).

5.5 NMC Initialization
5.5.1 Internal Register States
The following list describes the state of each NMC_CSR when NDAL_RESET_L
asserts.
•

Memory configuration registers (MEMCON0 - MEMCON7) :
These registers are cleared to 0.

•

Memory signature registers (MEMSIG0 - MEMSIG7) :
These registers are virtual registers in the NMC and have no power-up value.

•

Error address information register (MEAR) :
This register is cleared to 0.

•

Error status register (MESR) :
This register is cleared to 0.

•

Mode control and diagnostic status register (MMCDSR):
This register is cleared to 0.

•

O-bit address and mode register (MOAMR):
This register is cleared to 0.

•

O-bit data registers (MODRs):
These registers are virtual registers in the NMC and have no value on reset.

5.5.2 Counter States
The following list describes the state of all the counters in the NMC when NDAL_
RESET_L asserts.
•

Pending transaction timers :
These timers are cleared to the ZERO state: the prescaler is also cleared to 0
so that the timeout interval is 2600 cycles.

•

Refresh interval timer:
This timer is cleared to the ZERO state.

•

Refresh address counter:
This counter is cleared to 0 so that the first refresh address after NDAL_
RESET_L deasserts is 0.

5.6 Memory Subsystem Organization
The NMC supports a 64-bit memory interconnect.

5.6.1 64-bit Interconnect
The memory subsystem consists of up to four memory modules having up to four
72-bit banks each (64 bits data and 8 bits ECC). There can be a total of up to 16
banks of memory. The memory banks are 2-way interleaved. This requires that
each module has an even number of banks. The following discussion refers to
bank pairs. The module organization is shown in Figure 5–13.

KA680 Main Memory System 5–35

KA680 Main Memory System
5.6 Memory Subsystem Organization
Up to 512 MB of ECC memory can be supported by the KA680 when using
memory modules populated with 4 Mb DRAMs. KA680 memory systems can
also contain a mixture of 4 Mb and 1 Mb based memory modules, although the
maximum memory will be lower than 512 MB when one or more 1 Mb based
modules are used.
The NVAX memory space is mapped to the physical memory using the memory
configuration registers in the NMC. The NMC requires that all bank pairs with
4 Mb DRAMs be mapped on aligned 64 MB boundaries. To enable this, all bank
pairs with 4 Mb DRAMs should be mapped to addresses lower than the 1 Mb
DRAMs.

5.6.2 GMX Chip
Each memory module has four transceiver chips (GMX) that perform data
multiplexing between the NMI bus and the DRAM array. The GMX chips
also perform other functions such as memory signature read and fast memory
diagnostics.
Each GMX has four data bus ports—BMD0A<19:0>, BMD0B<19:0>,
BMD1A<19:0>, and BMD1B<19:0>. On the MS690 memory modules, all the
GMX’s BMD lines are connected to one bank of DRAMs each. Thus, 64-bit MS690
memory boards have four GMX chips to handle the 72 data and ECC bits.

5–36 KA680 Main Memory System

KA680 Main Memory System
5.6 Memory Subsystem Organization
Figure 5–13 Memory Organization with 64-bit Interconnect
RASTIME

RAS_TIME_L
RAS1_L

BUFFER &
DRIVE
RAS_EN_L<1:0>

CASB
RAS_TIME_H

X
RAS0_L

CASB_L

[OR]

BUFFER &
DRIVE

CASB_H
CASA_L
RAS_TIME_L

CASB_L
CONFIG<2:0>

BANK_SEL<3:1>

MODE_SEL<1:0>

N
M

BIDI[0]<1:0>

RAS_EN_L<1:0>

WE_L

BUFFER &
DRIVE

WE_L

BANK_SEL<3:1>

BMDA<71:36>

BIDO[0]<1:0>

WE_H

BANK

MD<71:36>

BMDB<71:36>

BANK

SE_H

N
M
X

MODE_SEL<1:0>

BIDI[0]<1:0>

RAS_EN_L<1:0>

BMDA<35:0>

BIDO[0]<1:0>

RAS_TIME_L

BANK

MD<35:0>

BMDB<35:0>

BANK

SE_H

N
M
X

CONFIG<2:0>
CASB_L
CASA_L

CASA_H
MA<10:0>

CASA

CASA_L

RAS_EN_L<1:0>

BUFFER &
DRIVE

RAS0_L
RAS_TIME_L
X

MA
BUFFER &
DRIVE

MA
( T O A L L RAMS)

2
RAS1_L

[OR]

KA680 Main Memory System 5–37

6
KA680 I/O Subsystem
The I/O subsystem is controlled by the NVAX I/O adapter chip (NCA). The NCA
is a 339-pin custom VLSI chip packaged in a PGA package. The NCA functions
as a bidirectional bus adapter between the NDAL and two CVAX-compatible
peripheral buses : the CP1-bus on port 1 and the CP2-bus on port 2. On the
NDAL, the NCA supports the NVAX CPU chip and the NVAX memory controller
chip (NMC). On the CP1-bus and CP2-bus, the NCA supports the shared host
adapter chip (SHAC), the second generation Ethernet controller (SGEC), the
system support chip (SSC), and the CMOS Q22–bus adapter chip (CQBIC).

6.1 NCA Overview
The NCA provides a bidirectional interface between the NDAL and two CVAXcompatible peripheral (CP) buses: the CP1-bus on NCA port 1 and the CP2-bus
on NCA port 2. The NVAX CPU, the NVAX memory controller (NMC), and the
NCA are connected to the NDAL bus.
The CP1 and CP2 are CVAX-compatible peripheral (CP) buses for the system’s
DMA I/O devices and program-controlled I/O devices.
The NCA supports the CQBIC, the SSC, the SGEC, and two SHACs on the CP
buses.

6.2 I/O System Configuration
The I/O bus configuration used on the KA680 is shown in Chapter 1. In this
configuration, the Q22–bus, SSC, and the console firmware ROMs reside on the
CP2-bus of the NCA. They are isolated in this manner in order to minimize the
latency incurred when the KA680 is responding to Q22–bus transactions as a
slave.

KA680 I/O Subsystem 6–1

KA680 I/O Subsystem
6.3 NCA Chip Architecture

6.3 NCA Chip Architecture
The NCA serves as a bidirectional adapter between the NVAX DAL (NDAL) and
two CVAX peripheral buses (CP1 on port 1 and CP2 on port 2). The four major
functional blocks of the NCA chip are listed below:
•

NDAL interface (Section 6.3.2)

•

CP1 interface (Section 6.3.3)

•

CP2 interface (Section 6.3.3)

•

Registers (Section 6.3.4)

Figure 6–1 shows the organization of the NCA.
The following sections describe each functional block and its interactions, and the
NCA addressing. A discussion on error handling is also included at the end of
this section.
The NDAL and CP1 and CP2 interface sections are further divided into master
and slave subsections. Information transfer between the different sections of
the NCA occurs via two buses—TO_NDAL and TO_CDAL. TO_NDAL transfers
information to the NDAL interface from both CP-bus interfaces. The TO_CDAL
transfers information from the NDAL interface to other sections of the chip. In
addition, there are two more buses : TO_CP1 and TO_CP2, which transfer NVAX
initiated I/O transactions information to the respective CP-bus interface.

6–2 KA680 I/O Subsystem

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Figure 6–1 NCA Block Diagram

NDAL I N T E R F A C E
MASTER

PAD L A T C H

NDAL

CONTROL

ARBITER

NDAL MASTER
NDAL

NDAL S L A V E
QWDATA
ADDRESS

SLAVE
I N P U T PAD
& PARITY

IO_RW

CONTROL

R E C E I V E BUFFER

REGISTERS
NCA_CSR0
NCA_CSR1
NCA_CSR2
NCA_CSR3
NCA_CSR4
NCA_CSR5
NCA_CSR6
ICCS
NICR
ICR

INTERRUPT
HANDLER

PORT2
PORT1

INDAL
TO_NDAL

PARITY
GEN

TRANSMIT
BUFFER
CP2_IORBUF
CP2
MASTER

CP1_IORBUF

QWDATA

CP1
MASTER

NRA

TIMER

TIMER
PARITY
GEN/CHK

OUTPUT PAD

MASTER

CONTROL

OUTPUT PAD

CP2_DAL
CP1_DAL

MT
CP2_RBUF

TIMER

CP1_RBUF

TIMER
PARITY
GEN/CHK

SLAVE
CONTROL

SLAVE

QWDATA2
QWDATA1
ADDRESS

CP2_MEMRD

CP2_WBUF

CP1_MEMRD

CP1_WBUF

CONTROL

I N P U T PAD

ADDRESS
QWDATA1
QWDATA2

VALID BITS
FOR EVERY
LONGWORD

I N P U T PAD

CP2

CP1

INTERFACE
CP2
SLAVE

CP1
SLAVE

INTERFACE

KA680 I/O Subsystem 6–3

KA680 I/O Subsystem
6.3 NCA Chip Architecture
TERMINOLOGY
For the rest of this manual, the following terms are commonly used to
refer to NCA ports.
•

CP1—means port 1 of the NCA where CP1-bus is connected

•

CP2—means port 2 of the NCA where CP2-bus is connected

•

CP—means both CP1 and CP2

6.3.1 NCA Addressing
The NCA responds to addresses on the NDAL that access devices on the CP1-bus,
CP2-bus, or internal registers in the NCA. These addresses and their destinations
are summarized in Table 6–1.
Table 6–1 NCA Addresses
Address Range (hex)

Destination

2000 0000 - 2000 3FFF

CP2 device addresses

2000 4000 - 2000 FFFF

CP1 device addresses

2001 0000 - 20FF FFFF

CP2 device addresses

2100 0000 - 2100 005F

Not Acknowledged

2100 0060 - 2100 0063

SRM ICCS Register

2100 0064 - 2100 0067

SRM NICR Register

2100 0068 - 2100 006B

SRM ICR Register

2100 006C - 2100 00FF

Not Acknowledged

2100 0100 - 2100 010F

Interrupt Vector Read addresses

2100 0110 - 2101 FFFF

Not Acknowledged

2102 0000 - 2102 001F

NCA internal registers

2102 0020 - 2102 FFFF

Not Acknowledged

2103 0000 - 2103 FFFF

CP2 device addresses if IO2_ID_EN is set, else Not
Acknowledged

2104 0000 - 27FF FFFF

CP1 device addresses

2800 0000 - 2FFF FFFF

CP2 device addresses

3000 0000 - 3FFF FFFF

CP2 device addresses if IO2_ID_EN is set, else Not
Acknowledged

6.3.2 NDAL Interface
The NDAL interface section is made up of the NDAL master and slave interface
subsections.
6.3.2.1 NDAL Slave Interface
The NCA’s NDAL slave interface continuously monitors the NDAL for
transactions addressed to the NCA. Parity is checked on the NDAL<63:0>,
CMD_H<3:0>, and ID_H<2:0> for valid parity. If there is no parity error and the
transaction is addressed to the NCA, the NCA acknowledges with the assertion of
ACK_L. The information is then placed into one of the following queues : IO_RW,
CP1_RBUF, or CP2_RBUF. IO_RW queue is described below and the other two
buffers are described in their respective sections.

6–4 KA680 I/O Subsystem

KA680 I/O Subsystem
6.3 NCA Chip Architecture
•

IO_RW - IO_RW is a 4-entry deep queue that holds the transactions
addressed to the NCA I/O space ports 1 and 2. Each entry contains quadword
address, quadword data (for I/O write only), a valid bit, a port ID (CP1
or CP2), and a transaction token. The IO_RW is a common pool of I/O
transactions for both port 1 and port 2. An I/O transaction is stored into
the IO_RW queue whenever an entry becomes "empty." The CP1 and CP2
interfaces examine the IO_RW entries to determine if there is a pending
transaction for their ports. This is accomplished by the valid bit, the port
ID, and the transaction token. Since the IO_RW is 4-entry deep, two bits
are maintained as the token. The token of each entry is compared with the
expected token of each CP port controllor. When there is a match in any one
of the four entries, the port controllor initiates the transaction on the bus. By
doing so, CP1 and CP2 are operated independently and the utilization of the
queue is optimized. The expected token of CP1 (CP2) is incremented (mod 4)
after each transaction.
When the IO_RW queue has four valid entries (queue is full), the IO1_
SUPPRESS_L signal is asserted to the NMC, which asserts the CPU_
WB_ONLY to the NVAX CPU. The NVAX CPU is then expected to perform
WDISOWN operations only on the NDAL (that is, the NVAX CPU will not
drive any transactions on the NDAL other than WDISOWNs). This prevents
the NCA IO_RW queue from overflowing.
Note
The NCA supports only longword and quadword transactions to the I/O
space.

6.3.2.2 NDAL Master Interface
The NDAL master interface is responsible for initiating DMA read and write
operations on the NDAL, as well as returning I/O read data to the CPU. The
information for all NDAL master transactions comes from the CP1, CP2, and
register sections. The following is the list of transactions and the buffers from
which the transactions are initiated:
•

CP1 DMA write (CP1_WBUF)

•

CP1 DMA read (CP1_MEMRD)

•

CP1 I/O read data return (CP1_IORBUF)

•

CP2 DMA write (CP2_WBUF)

•

CP2 DMA read (CP2_MEMRD)

•

CP2 I/O read data return (CP2_IORBUF)

•

CSR read data return (TRANSMIT BUFFER)

The master control block in the NDAL master interface contains the bus interface
and arbitration units. The bus interface unit requests NDAL bus ownership when
any of the NDAL master buffers contains valid information, and sequences the
transaction when the NCA is granted the ownership of the NDAL.

KA680 I/O Subsystem 6–5

KA680 I/O Subsystem
6.3 NCA Chip Architecture
The arbitration unit follows a fixed priority for initiating transactions on
the NDAL when more than one transaction is pending. The CP1 and CSR
transactions are arbitrated in the following priority, from highest to lowest :
1. CP1 memory read
2. CP1 memory write
3. CP1 I/O read data return
4. CSR and SRM interval timer read data return
The CP2 transactions are arbitrated in the following priority, from highest to
lowest :
1. CP2 memory read
2. CP2 memory write
3. CP2 I/O read data return

Note
The NCA only initiates one transaction for each NDAL bus grant;
however, it may retain bus ownership for additional NDAL cycles to
return I/O, CSR, or VAX interval timer read data after completing the
original transaction. This is to prevent the lower priority transaction from
starving.

6.3.3 CP1 and CP2 Interface
Because both the CP1 and CP2 interfaces are copies of each other, the two
interfaces will be discussed as CP.
The CP interface section is made up of the master and slave interface subsections.
6.3.3.1 CP Master Interface
The CP master interface is responsible for initiating I/O read and write operations
on the CP buses. Address and/or data information for these transactions comes
from the IO_RW queue of the NDAL slave section.
CP_IORBUF - CP_IORBUF is a single entry buffer that holds I/O read data
returned from the CP bus. It holds up to a quadword of data and has a valid bit.
When the buffer is valid, CP_IORBUF sends a request to the NDAL master
arbitration unit. When the transaction is granted to the CP_IORBUF, the
quadword data, the command bits, the ID bits, and the parity bits are driven
onto the NCA’s internal TO_NDAL bus and then onto the NDAL when IO1_
GRANT_L is asserted by the NMC.

6–6 KA680 I/O Subsystem

KA680 I/O Subsystem
6.3 NCA Chip Architecture
6.3.3.2 MT and NRA Timers
The CP master interface also contains the "no response abort" (NRA) and master
transaction (MT) timers. The NRA timer times out 2 µs (assuming 70 ns CP-bus
cycle) after the NCA initiates an I/O transaction on the CP-bus. If the NRA timer
times out before the NCA receives a response from an I/O device, the NCA aborts
the transaction on the CP-bus (no response abort). The MT timer has 4 settings
: 144, 1440, 14400, and 144000 cycles, which translate to 10.08 µs, 100.8 µs,
1.008 ms, and 10.08 ms for 70 ns CP-bus cycle time. During an I/O transaction
initiated by the CP master interface to the CP-bus, the timer times out if the
master interface does not receive any response.
The purpose of the MT and NRA timers is to prevent either of the CP-buses from
becoming "hung" due to hardware or software errors. The NRA timer prevents a
CP-bus from hanging due to a software error in which an access to a nonexistent
I/O address is attempted. Each of the devices on the CP-bus with the exception of
the SSC asserts a "not_me" signal during such accesses. When all the "not_me"
signals on the CP-bus are asserted, external logic generates an NRA input to
the NCA, to inform it that none of the devices on the corresponding CP-bus have
claimed ownership of the issued address. Since the SSC does not implement a
"not_me" signal, the NCA will wait 2 µs to give the SSC a chance to respond to
the transaction before the NRA timer expires. If the SSC does not complete the
transaction within this time, then a no response abort takes place and the I/O
transaction is terminated.
The purpose of the MT timer is to prevent either of the CP-buses from becoming
"hung" in the situation when a hardware error has occurred. In such cases, it is
possible that one of the chips connected to the CP-bus in question could fail to
assert its "not_me" signal, indicating that it intends to respond to the transaction.
If the chip in question fails to respond to the transaction, presumably due to a
hardware failure, the MT timer will expire, thus aborting the I/O transaction and
preventing the associated CP-bus from becoming "hung."
6.3.3.3 CP Slave Interface
The CP slave interface responds to DMA transactions on the CP-bus. This
subsection features three queues:
•

CP_WBUF - CP_WBUF is a 2-entry deep queue that holds the DMA write
transaction information. Each entry contains one quadword address and two
quadword data elements, together with a valid bit. The address element
contains information for setting up the NVAX address cycle while the data
element contains the write data and a BDATA bit, which is set if bad parity
is found in the corresponding quadword of write data on the CP bus. The
entry is validated when the DMA address and all the DMA write data have
been loaded into CP_WBUF. When the contents of one or more entries is
valid, a request is sent to the NDAL arbitration unit. The CP_WBUF entry is
invalidated when the write transaction corresponding to this entry is initiated
on the NDAL.

•

CP_MEMRD - On DMA reads, the slave interface places the read address
in CP_MEMRD, a quadword address buffer that holds the information for
setting up the NDAL address cycle. The valid bit for this buffer is set after
ensuring that the DMA read address does not hit in CP_WBUF. If the DMA
read address hits in CP_WBUF, the validation of the CP_MEMRD entry is
held off until CP_WBUF is flushed. When the valid bit is set, a request is
sent to the NDAL arbitration unit.

KA680 I/O Subsystem 6–7

KA680 I/O Subsystem
6.3 NCA Chip Architecture
•

CP_RBUF - This buffer holds the DMA memory read data that it receives
from the NDAL slave interface. This is a hexword data buffer that is
organized as longwords (that is, every longword contains a valid bit). The
NCA prefetches (programmable) DMA memory read data up to an octaword.
As the requested read data is returned to the DMA device on the CP-bus, the
associated valid bit is cleared.

As a CP-bus slave, the NCA accepts all transactions addressed in the memory
space. The NCA will signal an error to the CP-bus master on DMA transactions
addressed in VAX I/O space.

6.3.4 Registers
This section describes the NCA’s internal registers. The NCA has seven control
and status registers (NCA_CSR) and three interval clock registers. These ten
registers are longword-aligned. The NCA supports only I/O write to one register
per transaction by the NVAX CPU. However, quadword read by the NVAX CPU
of two NCA registers per transaction is allowed.
All the registers are cleared on power-up reset, unless otherwise specified in the
following description. Write operations to read-only registers do not cause any
errors and are responded to as normal operations; however, the operations do not
alter any of the register contents.
The register block also contains a receive buffer and a transmit buffer. The
receive buffer is used to store the register address in register read (and data, if
register write). The transmit buffer is used to store the read data of a register
read transaction while the register block is waiting to return the data to the
NDAL. If the I/O address happens to be NCA’s CSR or interval timer address,
the NCA’s CSR control logic sequences the read or write to the appropriate
register. On reads, the read data together with the CMD and ID is placed in the
transmit buffer and the valid bit is set in the transmit buffer. Once this occurs,
the transmit buffer sends a request to the NDAL arbitration unit in the NDAL
master interface. When the NCA is granted the mastership of the NDAL, the
data, CMD, and ID are driven onto NDAL. On writes, the write data is written
into the appropriate register.

6–8 KA680 I/O Subsystem

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Table 6–2 NCA CSR and Interval Timer Registers
Number

Name

Address

No. of
Registers

CESR

Error status register

2102 0000

CMCDSR

Mode control and diagnostic register

2102 0004

CSEAR1

CP1 slave error address register

2102 0008

CSEAR2

CP2 slave error address register

2102 000C

CIOEAR1

CP1 I/O error address register

2102 0010

CIOEAR2

CP2 I/O error address register

2102 0014

CNEAR

NDAL error address register

2102 0018

ICCS

Interval clock control status register

2100 0060

NICR

Next interval count register

2100 0064

ICR

Interval count register

2100 0068

Interrupt acknowledge registers

2100 0100 010F

These are virtual registers and they are read-only.

NCA_
CSR7-10

6.3.4.1 Control and Status Registers
The NCA has seven CSRs, the functions of which are decribed below.
6.3.4.2 Error Status Register (CESR)
The NCA reports error information in CESR.

KA680 I/O Subsystem 6–9

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Figure 6–2 Error Status Register
31

C P 1 N O N - E X I S T E N T I O ERROR
C P 1 I O ERROR
C P 1 I O READ P A R I T Y ERROR
C P 1 BUS ERROR
C P 1 DMA P A R I T Y ERROR
C P 1 I O L O S T ERROR
C P 1 DMA L O S T ERROR
C P 1 MT T I M E O U T ERROR
C P 2 N O N - E X I S T E N T I O ERROR
C P 2 I O ERROR
C P 2 I O READ P A R I T Y ERROR
C P 2 BUS ERROR
C P 2 DMA P A R I T Y ERROR
C P 2 I O L O S T ERROR
C P 2 DMA L O S T ERROR
C P 2 MT T I M E O U T ERROR
CP1 PREL
CP2 PREL
NDAL P R E L
NDAL P A R I T Y ERROR
NDAL NO ACK ERROR
NDAL C P 1 T I M E O U T ERROR
NDAL C P 2 T I M E O U T ERROR
NDAL I L L _ L E N G T H
NDAL RESERVED CMD
NDAL L O S T ERROR
RDR NO ACK ERROR
ERROR SUMMARY

CESR :

2102 0000

Table 6–3 Error Status Register, CESR
Register Field

Bit

Type, Reset
State

Error Summary

RO, 0

This bit is "1" when any error is logged by the
NCA in this register, with the exception of
CESR<25>, which does not affect this bit. It
is cleared when all the error bits are cleared.

Unused

30:28

MBZ, 0

These bits are read as 0.

RDR NO_ACK Error

WC, 0

This bit is set if NCA does not receive ACK_L
when it is initiating an RDRx to the NDAL. No
address is logged when this bit is set.

NDAL Lost Error

WC, 0

This bit is set if an error condition described in
CESR<23:21> occurs and CESR<21> is already
set. When this bit is set, CNEAR contains the
address of the previous error condition that has
not been cleared at the time the current error
condition happens. It is possible that this bit
is set but all the error bits in CESR<23:21>
are cleared because of the asynchronous events.
When this happens, the CNEAR may contain an
invalid address.

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

6–10 KA680 I/O Subsystem

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Table 6–3 (Cont.) Error Status Register, CESR
Register Field

Bit

Type, Reset
State

NDAL Reserved cmd

WC, 0

This bit is set when the NDAL interface detects
a reserved command during any NDAL cycle and
this bit is not already set. No address is logged
when this bit is set.

NDAL Ill_length

WC, 0

This bit is set when the NDAL interface detects
an illegal length during an NDAL transaction
addressed to the NCA and when this bit is not
already set. No address is logged when this bit is
set.

NDAL CP2 Timeout Error

WC, 0

This bit is set if not all requested read data
is returned from the memory within the
NDAL cycles specified by the NDAL timer
prescaler (CMCDSR<11:10>) for the DMA read
transactions initiated on the CP2-bus, and this
bit is not already set.

NDAL CP1 Timeout Error

WC, 0

NDAL NO_ACK Error

WC, 0

This bit is set if no ACK_L is received during
an NCA-initiated memory transaction and
this bit is not already set. CNEAR contains
the error address when this bit is set and
CMCDSR<23:22> are not set.

NDAL Parity Error

WC, 0

This bit is set if NCA detects an NDAL parity
error on any NDAL cycles and this bit is not
already set. No address is logged when this bit is
set.

Unused

MBZ, 0

This bit is read as 0.

NDAL PREL

WC, 0

This bit is set when there is no XA (that is,
CMCDSR<8> is set) present and there is no
pending interrupts at both the CP1 and CP2 port
at the priority level indicated by the interrupt
vector read on the NDAL. No address is logged
when this bit is set.

CP2 PREL

WC, 0

This bit is set when an interrupt vector read is
initiated on the CP2-bus and either CP2_ERR_L
is asserted or CP2 master transaction (MT) timer
times out. In either case, the NCA returns to the
NDAL with RDR and NDAL bit<33,01> set to 1.
No address is logged when this bit is set.

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

KA680 I/O Subsystem 6–11

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Table 6–3 (Cont.) Error Status Register, CESR
Register Field

Bit

Type, Reset
State

CP1 PREL

WC, 0

This bit is set when an interrupt vector read is
performed on the CP1-bus and either CP1_ERR_
L is asserted or CP1 master transaction (MT)
timer times out. In either case, the NCA returns
to the NDAL with RDR and NDAL bit<33,01> set
to 1. No address is logged when this bit is set.

CP2 MT Timeout Error

WC, 0

This bit is set if the I/O read or write transaction
initiated by the NCA to the CP2-bus causes
the CP2 master transaction (MT) timer to time
out and this bit is not already set. CIOEAR2
contains the I/O error address when this bit is set
and CESR<10:8> are not set.

CP2 DMA Lost Error

WC, 0

This bit is set if CESR<12> is already set and
either a DMA device initiates an I/O transaction
on the CP2-bus or the CP2 interface detects a
parity error on a DMA write data. When this bit
is set, CSEAR2 contains an address for a previous
error that has not been cleared at the time the
current error condition happens. It is possible
that this bit is set but the error bit in CESR<12>
is cleared because of the asynchronous events.
When this happens, the CSEAR2 may contain an
invalid address.

CP2 IO Lost Error

WC, 0

This bit is set if any bit in CESR<15,10:8>
is already set and any of the error conditions
described in CESR<15,10:8> occurs. When this
bit is set, CIOEAR2 contains an address for a
previous error that has not been cleared at the
time the current error condition happens. It is
possible that this bit is set but all the error bits
in CESR<15,10:8> are cleared because of the
asynchronous events. When this happens, the
CIOEAR2 may contain an invalid address.

CP2 DMA Parity Error

WC, 0

This bit is set if the NCA detects a parity error
in the DMA write data on the CP2-bus. CSEAR2
contains the DMA write address when this bit is
set.

CP2 Bus Error

WC, 0

This bit is set if a DMA device on the CP2-bus
initiates an I/O transaction or a transaction with
one of the reserved commands. No address is
logged when this bit is set.

CP2 IO Read Parity Error

WC, 0

This bit is set if the NCA detects a parity error
in the I/O read data on the CP2-bus. CIOEAR2
contains the I/O error address when this bit is set
and CESR<15,9:8> are not set.

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

6–12 KA680 I/O Subsystem

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Table 6–3 (Cont.) Error Status Register, CESR
Register Field

Bit

Type, Reset
State

CP2 IO Error

WC, 0

This bit is set if an NCA-initiated transaction,
read or write, on the CP2-bus results in CP2_
ERR_L assertion. CIOEAR2 contains the
I/O error address when this bit is set and
CESR<15,10,8> are not set.

CP2 Nonexistent IO Error

WC, 0

This bit is set if CP2_NRA timer times out and
CP2_NRA pin is asserted on an NCA-initiated I/O
transaction on the CP2-bus. CIOEAR2 contains
the I/O error address when this bit is set and
CESR<15,10:9> are not set.

CP1 MT Timeout Error

WC, 0

This bit is set if the I/O read or write transaction
initiated by the NCA to the CP1-bus causes the
CP1 master transaction (MT) timer to times
out and this bit is not already set. CIOEAR1
contains the I/O error address when this bit is set
and CESR<2:0> are not set.

CP1 DMA Lost Error

WC, 0

This bit is set if CESR<4> is already set and
either a DMA device initiates an I/O transaction
on the CP1-bus or the CP1 interface detects a
parity error on a DMA write data. When this
bit is set, CSEAR1 contains an address for a
previous error that has not been cleared at the
time the current error condition happens. It is
possible that this bit is set but the error bit in
CESR<4> is cleared because of the asynchronous
events. When this happens, the CSEAR1 may
contain an invalid address.

CP1 IO Lost Error

WC, 0

This bit is set if any bit in CESR<7,2:0> is
already set and any of the error conditions
described in CESR<7,2:0> occurs. When this
bit is set, CIOEAR1 contains an address for a
previous error that has not been cleared at the
time the current error condition happens. It
is possible that this bit is set but all the error
bits in CESR<7,2:0> are cleared because of the
asynchronous events. When this happens, the
CIOEAR1 may contain an invalid address.

CP1 DMA Parity Error

WC, 0

This bit is set if the NCA detects a parity error
in the DMA write data on the CP1-bus. CSEAR1
contains the DMA write address when this bit is
set.

CP1 Bus Error

WC, 0

This bit is set if a DMA device on the CP1-bus
initiates an I/O transaction or a transaction with
one of the reserved commands. No address is
logged when this bit is set.

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

(continued on next page)

KA680 I/O Subsystem 6–13

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Table 6–3 (Cont.) Error Status Register, CESR
Register Field

Bit

Type, Reset
State

CP1 IO Read Parity Error

WC, 0

This bit is set if the NCA detects a parity error
in the I/O read data on the CP1-bus. CIOEAR1
contains the I/O error address when this bit is set
and CESR<7,1:0> are not set.

CP1 IO Error

WC, 0

This bit is set if an NCA-initiated transaction,
read or write, on the CP1-bus results in CP1_
ERR_L assertion. CIOEAR1 contains the
I/O error address when this bit is set and
CESR<7,2,0> are not set.

CP1 Nonexistent IO Error

WC, 0

This bit is set if CP1_NRA timer times out and
CP1_NRA pin is asserted on an NCA-initiated I/O
transaction on the CP1-bus. CIOEAR1 contains
the I/O error address when this bit is set and
CESR<7,2:1> are not set.

Description

RO—Read-only
RW—Read/write
WC—Write one-to-clear
MBZ—Read-only, read as 0

6.3.4.3 Mode Control and Diagnostic Register (CMCDSR)
The NCA operating modes are controlled by information in this register. In
addition, this register is used for storing diagnostic status information. The
following is a description of all the bit fields in the register.
Figure 6–3 Mode Control and Diagnostic Status Register

FORCE C P 1 BUS OWNER
FORCE C P 2 BUS OWNER
FORCE W R I T E BUFFER H I T
E N A B L E PREFETCH
FORCE WRONG NDAL S L A V E P A R I T Y
FORCE WRONG NDAL MASTER P A R I T Y
FORCE WRONG C P 1 BUS P A R I T Y
FORCE WRONG C P 2 BUS P A R I T Y
I O 2 I D ENABLE
C Q B I C MODE
NDAL T I M E R PRESCALER
C P 1 I V R T I M E R PRESCALER
C P 2 I V R T I M E R PRESCALER
CP1 INTERRUPT
CP2 INTERRUPT

CMCDSR :

6–14 KA680 I/O Subsystem

2102 0004

KA680 I/O Subsystem
6.3 NCA Chip Architecture
Table 6–4 Mode Control and Diagnostic Status Register, CMCDSR
Register Field

Bit

Type, Reset
State

Description

Unused