Digital PDFs

MISC-6840850E

August 1991

1022 pages

Original

51MB

Document:	NVAX CPU Chip Functional Specification
Order Number:	MISC-6840850E
Revision:
Pages:	1022
Original Filename:

OCR Text

NVAX CPU Chip
Functional Specification·
The NVAX CPU Chip is a high-perform~r..ce,single-chipimplerru:tntatioI1 of the,· VAX Ar~itecture for use in
low-end and mid-range systems.
:"

Revlslon/Update Information:

This is Revision 12 of this specification, wtiichsUP$r~d.esJ1evi,sion 1.1 released in August 1991. The inform ation in this speelfication)eflects pass 2 of
the NVAX CPU chip. Only the Electrioal Charact~ti.sti¢s:,Ctita:pter was updated
from:,f1evision'·1.1 to Revision 1.2.

DIGITAL CONFIDENTJA'C'
' .: '. .~_'-:. ,.' ~_

'.: ,!'"

l.J

"_"'~" ....• :>.\' " , '

This information shall not be discloSed to persons otherthan.~~GITAL:emptoy.es;br·\1erirJ.y.;d-tStribute.d ~ithin '
DIGITAL. Distribution is restricted to persons auth.?r~ed aOO ;~signat~ by tmt·'o.tjgif1alij1g'btg~~iz~~qn ... 1hi$> ..
document shall not be transmitted ,electronically, copied unle~"auti:lo~~igh1atinffOf9ariizatioFi~'orleft
unattended. When not in use, this doelim&rit§hafI'-'be stored;'in al()Ckecr*-r.s~~;:atr••·; The"-restrictionsare
enforced until this document is reclassif!,~~by:the~~,inating .organizati!?",!:, '~'. ~:-"'~::::';11;0:'.:;~'·<:· "~0i;C :',. '.. :.
•

,~...~.

\: ': .

.:. ..... ~

•

..~., . . '... Semiconductor- Engi'A$sring Group
Digital Equipment CorpOteit~on, HudsonrMasSClchusetts

December 1991

The drawings and specificatio:ns in this document are the property of Digital Equipment Corporation and
shall not be reproduced or copied or used in whole or in part as the basis for the manufacture or sale of
items without written permission.
The information in this document may be changed without notice and is not a commitment by Digital
. Equipment Corporation. Digital Equipment Corporation is not responsible for any errors in this document.
This specification does not describe any program or product that is currently available from Digital
Equipment Corporation, nor is Digital Equipment Corporation committed to implement this specification
in any program or product.' -Digital Equipment Corporation makes no commitment that this document
accurately describes any product it might ever make.
Copyright C1989, 1990, 1991 by Digital Equipment Corporation
All Rights Reserved
Printed in U .SA

:~ ,

" The fonowing are trademarks ot:Digttal Equipment Corporation:

.
ULTRIX
ULTRIX-32
,

DEC
DECnet
DECUS
MicroVAX
MicroVMS
PDP

UNIBUS
VAX

VAXBI
VAXcluster

VAXstation

VMS
VT

Contents
INTRODUCTION

1-1

1.1

SCOPE AND ORGANIZATION OF THIS SPECIFICATION

1-1

1.2

RELATED DOCUMENTS

1-1

1.3

TERMINOLOGY AND CONVENTIONS
1.3.1
Numbering
UNPREDICTABLE and UNDEFINED
1.3.2
Ranges and Extents
1.3.3
1.3.4
Must be Zero (Mal)
1.3.5
Should be Zero (SBl)
1.3.6
Register Format Notation
1.3.7
TIming Diagram Notation

CHAPTER 1

1.4

;:)'

1-1
1-1
1-1
1-2
1-2
1-2
1-2
1-5

REVISION HISTORY

1-6

ARCHITECTURAL SUMMARY

2-1

OVERVIEW

2-1

VISIBLE STATE
Virtual Address Space
Physical Address Space
2.2.2.1
Physical Address Control Registers • 2-4
2.2.3
Registers

2-1
2-1
2-2
2-4

2.3

DATA TYPES

2-6

2.4

INSTRUCTION FORMATS AND ADDRESSING MODES
2.4.1
Opcode Formats
2.4.2
Addressing Modes
2.4.3
Branch Displacements

2-8
2-8
2-8
2-11

2.5

INSTRUCTION SET

2-11

2.6

MEMORY MANAGEMENT
2.6.1
Memory Management Control Registers
2.6.2
System Space Address Translation
2.6.3
Process Space Address Translation
2.6.3.1
PO Region Address Translation • 2-28
2.6.3.2
P1 Region Address Translation • 2-29
Page Table Entry
2.6.4
Translation Buffer
2.6.5

2-25
2-25
2-26
2-28

EXCEPTIONS AND INTERRUPTS
Interrupts
2.7.1.1
Interrupt Control Registers • 2-34

2-33
2-33

CHAPTER 2

2.1
2.2

2.2.1
2.2.2

2.7

2-31
2-32

2.7.1

1 ,.. ~ ,.:.': ...:,~,;'" i.:~ ".,~.

;

. ~~

DIGITAL CONFIDENTIAL

Iii

Contents

2.7.2

Exceptions

2.7.2.1
2.7.2.2
2.7.2.3
2.7.2.4
2.7.2.5
2.7.2.6
2.8

SYSTEM CONTROL BLOCK
2.8.1
System Control Block Vectors
2.8.2
System Control Block Layout

2-41
2-41
2-42

2.9

CPU IDENTIFICATION

2-44

2.10

SYSTEM IDENTIFICATION

2-44

2.11

PROCESS STRUCTURE

2-46

2.12

PROCESSOR REGISTERS

2-49.

2.13

110 SPACE ADDRESSES

2-61

2.14

REVISION HISTORY

2-62

NVAX CHIP INTERFACE

3-1

3.1

INTRODUcnoN

3-1

3.2

NVAX CPU PINOUT
3.2.1
NDAL Signals and nmlng
3.2.1.1
P%CPU_REQ_L • 3-6
P%CPU_HOLD_L· 3-7
3.2.1.2
3.2.1.3
POkCPU_SUPPRESS_L • 3-7
3.2.1.4
POkCPU_GRANT_L • 3-7
3.2.1.5
POkCPU_WB_ONLY_L • 3-7
3.2.1.6
POkNDAL_H<63:0> • 3-7
3.2.1.7
POkCMD_H<3:O> • 3-7
3.2.1.8
POklD_H<2:0> • 3-7
3.2.1.9
POkPARITY_H<2:0> • 3-7
3.2.1.10
POkACK_L • 3-7
3.2.2
Clocking signals
3.2.2.1
POkOSC_H, POkOSC_L • 3-8
3.2.2.2
POkOSC_TC1_H, POkOSC_TC2_H • 3-8
3.2.2.3
POkOSC_TEST_H • 3-8
POkPHI12_0UT_H, POkPH123_0UT_H, POkPHI34_0UT_H,
3.2.2.4
POkPHI41_0UT_H • 3-8
POkPHI12_IN_H, POkPHI23_IN_H, POkPHI34_IN_H,
3.2.2.5
P%PHI41_IN_H • 3-8
3.2.2.6
POkASYNC_RESET_L • 3-8
3.2.2.7
PO/oSYS_RESET_L • 3-9
3.2.3
Interrupt and Error Signals
3.2.3.1
PO/oMACHINE_CHECK_H • 3-9
3.2.3.2
PO/oIRQ_L<3:O> • 3-9
3.2.3.3
POkH_ERR_L • 3-9
3.2.3.4
POkS_ERR_L • 3-9
3.2.3.5
P%INT_TIM_L • 3-10
3.2.3.6
POkPWRFL_L • 3-10

CHAPTER 3

2-35

Arithmetic Exceptions • 2-36
Memory Management Exceptions • 2-37
Emulated Instruction Exceptions • 2-38
Vector Unit Disabled Fault • 2-40
Machine Check Exceptions • 2-40
Console Halts • 2-40

3-1

3-4

3-8

3-9

DIGITAL CONFIDENllAL

Contents

3.2.4

3.2.5

3.3
~

3.2.3.7
POkHALT_L • 3-10
Cache Interface signals
3.2.4.1
POkTS_INDEX_H<20:5> • 3-10
3.2.4.2
POkTS_OE_L • 3-10
3.2.4.3
POkTS_WE_L • 3-10
3.2.4.4
POkTS_TAG_H<31:17> • 3-12
3.2.4.5
POkTS_ECC_H<5:0> • 3-12
3.2.4.6
POkTS_OWNED_H • 3-12
3.2.4.7
POkTS_VALlD_H • 3-12
3.2.4.8
POkDR_INDEX_H<20:3> • 3-12
3.2.4.9
POkDR_OE_L • 3-12
3.2.4.10
POkDR_WE_L • 3-12
3.2.4.11
POkDR_DATA_H<63:0> • 3-12
3.2.4.12
POkDR_ECC_H<7:O> • 3-12
Test Pins
3.2.5.1
POkTEST_DATA_H • 3-13
3.2.5.2
POkTEST_STROBE_H • 3-13
3.2.5.3
POkDISABLE_OUT_L • 3-13
3.2.5.4
POkTEMP_H • 3-13
3.2.5.5
POkTMS_H • 3-13
3.2.5.6
POkTCK_H • 3-13
3.2.5.7
POkTDI_H • 3-13
3.2.5.8
POkTDO_H • 3-14
3.2.5.9
POkPP_CMD_H<2:0> • 3-14
3.2.5.10
P%PP_DATA_H<11:0> • 3-14

THE NDAL
3.3.1
Terms
3.3.2
NDAL Clocking
NDAL Arbitration
3.3.3
3.3.3.1
NDAL Arbitration Signals • 3-19
3.3.3.1.1
PO/oCPU_REQ_L • 3-19
3.3.3.1.2
101 - REQ_L • 3-19
3.3.3.1.3
102_REQ_L • 3-20
3.3.3.1.4
PO/oCPU_HOLD_L • 3-20
3.3.3.1.5
101_HOLD_L • 3-20
102_HOLD_L· 3-20
3.3.3.1.6
3.3.3.1.7
P%CPU_SUPPRESS_L • 3-20
3.3.3.1.8
101_SUPPRESS_L • 3-21
3.3.3.1.9
102_SUPPRESS_L • 3-21
3.3.3.1.10
PO,4CPU_GRANT_L • 3-21
3.3.3.1.11
101_GRANT_L • 3-21
3.3.3.1.12
102_GRANT_L • 3-21
3.3.3.1.13
PO,4CPU_WB_ONLY_L • 3-21
3.3.3.1.14
101_WB_ONLY_L • 3-22
3.3.3.1.15
102_WB_ONLY_L • 3-22
3.3.3.2
NDAL Arbitration liming • 3-22
3.3.3.3
NDAL Suppress and Its liming • 3-24
3.3.3.4
NDAL Arbitration Rules • 3-24

DIGITAL CONFIDENTIAL

3-10

... '..,.",.,

3-13

t.:.'":,

3-15
3-17
3-18
3-18

Contents

3.3A

3.3.5

3.3.6
3.3.7
3.3.8
3.3.9
3.3.10

3.3.11

NDAL Information Transfer
3.3.4.1
POkNDAL_H<63:0> • 3-27
3.3.4.1.1
Address Field • 3-27
3.3.4.1.2
Byte Enable Field • 3-29
3.3.4.1.2.1
110 space writes • 3-33
3.3.4.1.3
Length Field • 3-33
3.3.4.2
P%CMD_H<3:0> • 3-33
3.3.4.3
POkID_H<2:0> • 3-35
3.3.4.4
POkPARITY_H<2:0> • 3-35
3.3.4.5
P%ACK_L • 3-36
NDAL Transactions
3.3.5.1
Reads and Fills • 3-41
3.3.5.1.1
Dstream Read Requests (DREAD) • 3-41
3.3.5.12
Istream Read Requests (IREAD) • 3-41
3.3.5.1.3
Ownership Read Requests (OREAD) • 3-41
3.3.5.1.4
How memory handles reads to Owned blocks • 3-42
3.3.5.1.5
Read cycle description and timing • 3-42
3.3.5.1.6
Read Data Return cycles (RDRO, RDR1, RDR2,
RDR3) • 3-44
3.3.5.1.7
Read data error cycles (ROE) • 3-44
3.3.5.1.8
Read data cycle description and timing • 3-45
3.3.5.1.9
Read Transaction Examples • 3-45
3.3.5.1.9.1
Ouadword Read and Fill • 3-45
3.3.5.1.9.2 Multiple Ouadword Reads • 3-47
3.3.52
Writes· H9
3.3.5.2.1
Normal Write Transactions (WRITE) • 3-49
3.3.5.22
Disown Write Transactions (WDISOWN) • 3-49
3.3.5.2.3
Write Data and Bad Write Data (WDATA,BADWDATA) • 3-49
3.3.5.2.4
Write transaction description and timing • 3-49
3.3.5.2.5
Write Transaction Examples • 3-50
3.3.5.2.5.1
Ouadword Writes • 3-50
3.3.5.2.5.2 Multiple Ouadword Writes • 3-52
3.3.5.3
NOPs· 3-53
Cache Coherency
Interrupts
Clear Write Buffer
VAX. archltecturally-deflned Interlocks
3.3.9.1
Ownership and Interlock transactions • 3-56
Errors
3.3.10.1
Transaction Timeout • 3-57
3.3.10.2
Non-existent memory and VO • 3-58
3.3.10.3
Error Handling • 3-58
3.3.10.4
Error Recovery • 3-63
NDAL Initialization

3-27

3-38

3-54
3-55
3-55
3-56
3-57

3-64

3.4

THE XMI-2 NVAX. SYSTEM
Cache coherency In the XMl2 system
3A.1

3-65
3-65

3.5

THE LOWEND NVAX SYSTEM - OMEGA

3-67

3.6

RESOLVED ISSUES

3-68

3.7

NVAX. CHIP INTERFACE SIGNAL NAME CROSS-REFERENCE

3-70

3.8

REVISION HISTORY

3-72

DIGITAL CONFIDENTIAL

Contents

CHAPTER 4
4.1

CHIP OVERVIEW

4-1
4-1
4-2

4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6

NVAX CPU CHIP BOX AND SECnON OVERVIEW
Thelbox
The Ebox and Mlcrosequencer
The Fbox
The Mbox
The Cbox
Major Internal Buses

4-4
4-4
4-4

REVISION HISTORY

4-6

MACROINSTRUCTION AND MICROINSTRUCTION PIPELINES

5-1

5.1

INTRODUCTION

5-1

5.2

PIPELINE FUNDAMENTALS
5.2.1
The Concept of a Pipeline
5.2.2
Pipeline Flow
Stalls and exceptions in an Instruction Pipeline
5.2.3

5-1
5-1
5-3

NVAX CPU PIPELINE OVERVIEW
Normal Macroinstruction Execution
5.3.1.1
The Ibox • 5-8
5.3.1.2
The Microsequencer • 5-9
5.3.1.3
The Ebox • 5-9
5.3.1.4
The Fbox • 5-10
5.3.1.5
The Mbox • 5-10
5.3.1.6
The Cbox • 5-11
5.3.2
Stalls In the Pipeline
5.3.2.1
SO Stalls • 5-12
5.3.22
S1 Stalls • 5-12
5.3.2.3
S2 Stalls • 5-13
5.3.2.4
S3 Stalls • 5-14
5.3.2.5
S4 Stalls • 5-15
5.3.3
exception Handling
5.3,3.1
Interrupts • 5-17
5.3.32
Integer Arithmetic Exceptions • 5-17
5.3.3.3
Floating Point Arithmetic Exceptions • 5-17
5.3.3.4
Memory Management Exceptions • 5-18
5.3.3.5
Translation Buffer Miss • 5-19
5.3.3.6
Reserved Addressing Mode Faults • 5-19
5.3.3.7
Reserved Operand Faults • 5-20
5.3.3.8
Exceptions Occurring as the Consequence of an
Instruction • 5-20
5.3.3.9
Trace Fault • 5-20
5.3.3.10
Conditional Branch Mispredict • 5-20
5.3.3.11
First Part Done Handling • 5-21
5.3.3.12
Cache and Memory Hardware Errors • 5-21

5-6
5-8

4.2

CHAPTER 5

5.3

5.3.1

5.4

REVISION HISTORY

DIGITAL CONFIDENTIAL

4-3
4-3

5-5

5-11

5-16

5-22

vii

Contents

CHAPTER 6

MICROINSTRUCTION FORMATS

6-1

EBOX MICROCODE
6.1.1
Data Path Control
6.1.2
Mlcrosequencer Control

6-1
6-1

6-3

6.2

IBOX CSU MICROCODE

6-4

6.3

IBOX INSTRUCTION ROM AND CONTROL PLAS

6-5

6.4

REVISION HISTORY

6-8

6.1

CHAPTER 7 THE IBOX
7.1

7.2

7.3

vIII

7-1

OVERVIEW
7.1.1
Introduction
7.1.2
Functional Overview
The Pipeline
7.1.3

7-1
7-1
7-2

7-4

INSTRucnON STREAM PREFETCHING
7.2.1
The VIC
7.2.1.1
VIC Control • 7-7
7.2.1.2
VIC_Reads· 7-8
7.2.1.3
VIC Fills • 7-8
7.2.1.4
VIC Writes • 7-9
7.2.1.5
VIC Bypass • 7-9
7.2.1.6
VIC Hits Under Miss • 7-10
7.2.1.7
VIC Exceptions and Errors • 7-10
7.2.1 .8
PC Load Effects • 7-10
7.2.1.9
E%STOP_IBOX_H Effects • 7-11
7.2.1.10
Prefetch Stop Conditions • 7-12
7.2.1.11
Prefetch Start Conditions • 7-12
7.2.1 .12
Prioritized List of Prefetch Start/stop Conditions • 7-12
7.2.1.13
VIC Enable • 7-13
7.2.1.14
VIC Flushing • 7-13
7.2.1.15
Flushing IREFs • 7-13
7.2.1.16
VIC Control and Error Registers • 7-14
7.2.1.17
VIC Performance Monitoring Hardware • 7-16
7.2.2
The Prefetch Queue
7.2.2.1
PC load effects • 7-17
INSTRUCnON PARSING
7.3.1
VAX Instruction Format
The Instruction Burst Unit
7.3.2
7.3.2.1
Specifier Identification • 7-21
7.3.2.2
Operand Access Types • 7-23
7.3.2.3
DL stall • 7-24
7.3.2.4
Driving SPEC_CTRL • 7-24
7.3.2.5
PC and Delta_PC • 7-24
7.3.2.6
Branch Displacement Processing • 7-25
7.3.2.7
Ebox Assist Processing • 7-25
7.3.2.8
Reserved Addressing Modes • 7-26
7.3.2.9
Quadword Immediate Specifiers • 7-26
7.3.2.10
Index Mode Specifiers • 7-27
7.3.2.11
Loading a new opcode • 7-27
7.3.2.12
Reserved Opcodes • 7-28

7-5
7-5

7-17

7-17
7-19
7-19

DIGITAL CONFIDENTIAL

Contents

7.3.3

7.4

7.3.2.13
Instruction Parse Completion • 7-28
7.3.2.14
Operands with Access Type VR and VM • 7-28
7.3.2.15
I%IMEM_MEXC_H and I%IMEM_HERR_H • 7-28
7.3.2.16
IBU stop and restart conditions • 7-29
7.3.2.17
First Part Done (FPD) Set • 7-29
The Instruction Issue Unit
7.3.3.1
Issue Stall • 7-30
7.3.3.2
PC Queue and PC loads • 7-31

OPERAND SPECIFIER PROCESSING
7.4.1
Operand Queue Unit
7.4.1.1
Source Queue Interface • 7-34
7.4.1.1.1
Short Literal Specifiers (Modes 0 .. 3) • 7-36
7.4.1.1.2
RMODE Specifiers (Mode 5) • 7-36
7.4.1.1.3
Index Mode Specifiers (Mode 4) • 7-36
7.4.1.1.4
All Other Addressing Modes • 7-36
7.4.1.2
Destination Queue Interface • 7-37
7.4.1.2.1
RMODE Specifiers (Mode 5) • 7-38
7.4.1.2.2
Index Mode Specifiers (Mode 4) • 7-38
7.4.1.2.3
All Other Addressing Modes • 7-38
7.4.1.3
Queue Entry Allocation • 7-38
7.4.1.4
MD Allocation • 7-39
7.4.1.5
Specifier Bus Enable • 7-39
7.4.1.6
E%STOP_IBOX and Branch Mispredict • 7-39
7.4.2
Complex Specifier Unit
7.4.2.1
CSU Microcode Control • 7-40
7.4.2.2
CSU Pipeline • 7-41
7.4.2.2.1
S1 Pipeline Stage • 7-41
7.4.2.2.2
S2 Pipeline Stage • 7-45
7.4.2.2.3
S3 Pipeline Stage • 7-48
7.4.2.3
RlOG • 7-51
7.4.2.4
Branch Mispredict effects • 7-52
7.4.2.5
E%STOP_IBOX Effects • 7-52
RSVD~DDR_FAULT effects • 7-52
7.4.2.6
7.4.2.7
CSU Microcode Restrictions • 7-53
7.4.2.8
Ibox IPR Transactions • 7-53
7.4.2.8.1
IPR Reads • 7-53
7.4.2.8.2
IPR Writes • 7-54
Scoreboard Unit
7.4.3
7.4.3.1
E%STOP_IBOX and Branch Mispredict PC load
Effects • 7-55

7-30

7-32
7-32

7-40

7-54

7.5

BRANCH PREDICTION
Branch Prediction Unit
7.5.1
7.5.1.1
The Branch Prediction Algorithm • 7-55
7.5.1.2
The Branch History Table • 7-56
7.5.1.3
Branch Prediction Sequence • 7-56
7.5.1.4
The Branch Queue • 7-57
7.5.1.5
Branch Mispredict • 7-58
7.5.1.6
Branch Stall • 7-58
7.5.1.7
PC loads • 7-58
7.5.1.8
Branch Prediction IPR Register • 7-59

7-55
7-55

7.6

PC LOAD EFFECTS
Mispredlct PC Loads
7.6.1

7~1

DIGITAL CONFIDENTIAL

7~2

Contents

7.6.2

Ebox PC Loads

7-62

E%STOP_IBOX EFFECTS

7-63

7.8.1

INmALIZATlON
Mechanisms for lbox State Reset

7-64
7-64

7.9.1
7.9.2
7.9.3
7.9.4
7.9.5

ERRORS, EXCEPTIONS, AND FAULTS
Overview
Istream Memory Errors
Dstrum Memory Errors
Reserved Opcode Faults
Reserved Addressing Mode Faults

7-64
7-64
7-64
7-65
7-65
7-65

7.10

IBOX SIGNAL NAME CROSS-REFERENCE

7-67

7.11

TESTABILITY
Overview
7.11.1
7.11.2
Internal Scan Register and Data Reducer
Parallel Port
7.11.3
7.11.4
Architectural Features

7-68
7-69
7-69
7-69
7-70

7.12.1

PERFORMANCE MONITORING HARDWARE
Signals

7-70
7-70

REVISION HISTORY

7-71

THE EBOX

8-1

8.1

CHAPTER OVERVIEW

8-1

8.2

INTRODUCTION

8-1

8.3

CHAPTER STRUCTURE

8-4

EBOX OVERVIEW
Mlcroword Fields
8.4.1.1
Microsequencer Control Fields • 8-6
8.4.2
The Register File
8.4.3
ALU and Shifter
8.4.3.1
Sources of ALU and Shifter Operands • 8-6
8.4.3.2
ALU Functions • 8-7
8.4.3.3
Shifter Functions • 8-7
8.4.3.4
Destinations of ALU and Shifter Results • 8-7
8.4.4
Ibox-Ebox Interface
Other Registers and States
8.4.5
Ebox Memory Access
8.4.6
CPU Control Functions
8.4.7
8.4.8
Ebox Pipeline
8.4.9
Pipeline Stalls
Mlcrotraps, Exceptions, and Interrupts
8.4.10

8-4
8-4

8-7
8-9
8-9
8-9
8-10
8-10
8-11

EBOX DETAILED FUNCTIONAL DESCRIPTION

8-13

7.7
7.8
7.9

7.12
7.13
CHAPTER 8

8.4

8.4.1

8.5

8-6
8-6

DIGITAL CONFIDENTIAL

Contents

8.5.1

8.5.2
8.5.3

8.5.4

8.5.5

8.5.6
8.5.7
8.5.8
8.5.9
8.5.10

8.5.11
8.5.12

8.5.13
8.5.14

8.5.15

DIGITAL CONFIDENTIAL

Register File
8.5.1.1
Register Groups • 8-13
8.5.1.2
Access Ports • 8-14
8.5.1.3
Register File Bypass Paths • 8-14
8.5.1.4
Write Collisions • 8-16
8.5.1.5
Valid, Fault, and Error Bits • 8-16
Constant Generation
The ALU
8.5.3.1
ALU Condition Codes • 8-19
8.5.32
SMUL Step Definition • 8-20
8.5.3.3
UDIV Step Definition • 8-20
The Shifter
8.5.4.1
Shifter Condition Codes • 8-22
8.5.4.2
Shifter Sign • 8-23
RMUX and E_BUS%WBUS_L
8.5.5.1
RMUX Produced Memory Request Signals • 8-24
8.5.5.2
RMUX Produced E_BUs%WBUS_L Related
Information • 8-24
VA Register
Q Register
Bypassing of Results
Result Destinations
Miscellaneous Ebox Registers and States
8.5.10.1
PSL • 8-27
8.5.10.1.1
Condition Code Alteration • 8-28
8.5.10.1.2
Trace and Trace Pending Bits • 8-29
8.5.10.2
SC • 8-29
8.5.10.3
INT.SYS • 8-30
8.5.10.4
MMGT.MODE • 8-30
8.5.10.5
State Flags • 8-30
8.5.10.5.1
E%MACHINE_CHECK_H • 8-31
8.5.10.5.2
State Rags and Pipeline Abort • 8-31
8.5.10.6
DL Part of the Instruction Context Register • 8-32
8.5.10.7
Mask Processing Unit • 8-32
Branch Condition Evaluator
Miscellaneous Ebox Operand Sources
8.5.12.1
S+PSW_EX • 8-36
8.5.12.2
Population Counter • 8-36
8.5.12.3
RN.MODE.OPCODE· 8-36
8.5.12.4
PMFCNT Register • 8-37
VAX Restart Bit
Ebox-Mlcrosequencer Interlace
8.5.14.1
Instruction Context Register • 8-38
8.5.14.2
Microtest Fields • 8-39
8.5.14.3
Miscellaneous Microsequencer Signals • 8-40
8.5.14.4
Miscellaneous Ebox-to-Microsequencer Signals • 8-41
Ebox-Ibox Interlace
8.5.15.1
Ibox Counters • 8-43
8.5.15.2
Source Queue • 8-43
8.5.15.3
Destination Queue • 8-44
8.5.15.4
Miscellaneous Queue Retire Information • 8-45
8.5.15.5
Branch Queue • 8-46
8.5.15.6
Operand and Branch Buses • 8-46

8-13

8-17
8-18

8-21

8-23

8-25
8-25
8-26
8-27
8-27

8-34
8-35

8-37
8-38

8-42

Contents

8.5.16

8.5.17

8.5.18
8.5.19

8.5.20

8.5.21
8.5.22

8.5.23
8.5.24
8.5.25

8.5.26

xII

8.5.15.7
Retire Queue • 8-47
8.5.15.8
Field Queue • 8-48
8.5.15.9
Retiring Instructions • 8-49
8.5.15.10 First Part Done • 8-49
8.5.15.11 Ebox to Ibox Commands and IPR Accesses • 8-49
8.5.15.12 Loading The PC • ~50
8.5.15.13 Ebox to Ibox Rush Signals • ~O
8.5.15.14 Detecting lbox Incurred Faults and Errors • 8-51
Ebox-Fbox Interface
8.5.16.1
Fbox Opcode and Operand Delivery • ~2
8.5.16.2
Fbox Result Handling • 8-53
8.5.16.3
Fbox Store Stall • ~3
8.5.16.4
Fbox Destination Scoreboard. • 8-54
8.5.16.5
Fbox Fault and Error Management • ~6
8.5.16.6
Ebox to Fbox Commands • ~6
8.5.16.7
Summary of Fbox-Ebox Signals • ~7
8.5.16.8
Fbox Disabled Mode • 8-58
Ebox-Mbox Interface
8.5.17.1
10 Read Synchronization • 8-63
8.5.17.2
Mbox-Ebox signals • 8-84
8.5.17.3
Ibox IPR Access and LOAD PC • 8-66
Ebox Vector Support
Fault and Trap Management
8.5.19.1
Faults and Errors Detected in S4 • 8-68
8.5.19.1 .1
Coordinating Ebox and Fbox Faults and Errors • 8-68
8.5.19.1 .2
Breaking the S4 Stall • 8-09
8.5.19.2
Faults and Errors detected in S3 • 8-69
8.5.19.3
Integer Overflow and Branch Mispredict Traps • 8-69
8.5.19.4
Ebox Microtrap Handling • 8-70
8.5.19.5
Coincidence of Branch Mispredict Trap with other Traps • 8-70
8.5.19.6
Possible Microtrap Requests • ~71
8.5.19.7
Fbox Fault Reporting • ~71
Ebox Stalls
8.5.20.1
The STALL Microword • 8-74
8.5.20.2
Field Queue Stall • ~75
8.5.20.3
Ebox Stall Conditions • 8-75
8.5.20.4
Fbox and RMUX Related Stall Conditions • 8-76
Miscellaneous Operations
Ebox IPRs
8.5.22.1
IPR 7C (hex), Patchable Control Store Control Register • 8-80
8.5.22.2
IPR 70 (hex), Ebox Control Register • 8-81
Initialization
Timing
Error Detection
8.5.25.1
S3 Stall limeout • 8-84
8.5.25.1 .1
Testing the S3 Stalllimeout Timer • 8-86
Testability
8.5.26.1
Parallel Port Test Features • 8-87
8.5.26.2
E%WBUS_H<31 :0> LFSR • 8-90

8-52

8-59

8-67
8-67

8-72

8-77
8-79

8-84
8-84
8-84

8-87

DIGITAL CONFIDENTIAL

Contents

8.5.27

8.5.28
8.5.29
CHAPTER 9

9.1
9.2

Microcode Restrictions
8.5.27.1
Register Access Restriction • 8-91
8.5.27.2
FLUSH.PAQ Restriction • 8-91
8.5.27.3
Memory access restrictions • 8-91
8.5.27.4
Shifter Restrictions • 8-91
8.5.27.5
SHIFT.SIGN Restriction • 8-92
8.5.27.6
MMGT.MODE Restrictions • 8-92
8.5.27.7
MPU Restrictions • 8-92
8.5.27.8
Microbranch Condition Restrictions • 8-92
8.5.27.9
Ibox IPR read restriction • 8-92
8.5.27.10 RETIRE.lNSTRUCTION • 8-92
8.5.27.11 VAX Restart Bit Restriction • 8-92
8.5.27.12 Q Register Interaction With SMUL.STEP and
UDIV.STEP • 8-92
8.5.27.13 UDIV/SMUL Restrictions • 8-93
8.5.27.14 F.DEST.CHECK Restrictions • 8-93
8.5.27.15 Fbox Operand Delivery Restriction • 8-93
8.5.27.16 RMUX control Restrictions • 8-93
8.5.27.17 Control Bits • 8-93
8.5.27.18 Microtrap Dispatch and RESET.CPU Restrictions • 8-93
8.5.27.18.1
Microtrap Flows • 8-93
8.5.27.18.2 MISC/RESET.CPU Restrictions • 8-94
8.5.27.18.3 Asynchronous Hardware Error Microtrap Restriction • 8-94
8.5.27.18.4 Rrst Part Done Dispatch Restriction • 8-94
8.5.27.19 PSL Use Restrictions • 8-94
8.5.27.20 S+PSW Restrictions • 8-96
8.5.27.21 RN.MODE.OPCODE Restrictions • 8-96
Signal Name Cross-Reference
Revision History

8-91

8-97
8-99

THE MICROSEQUENCER

9-1

OVERVIEW

9-1

FUNCTIONAL DESCRIPTION
Introduction
Control Store
9.2.2.1
Patchable Control Store • 9-3
Loading the Patchable Control Store • 9-3
9.2.2.1.1
Microsequencer Control Field of Microcode • 9-8
9.2.2.2
9.2.2.2.1
Jump Format • 9-9
9.2.2.2.2
Branch Format • 9-10
9.2.2.3
M IB Latches • 9-1 0
Next Address Logic
9.2.3
9.2.3.1
CAL and CAL INPUT BUS • 9-11
9.2.3.1.1
Microtest Bus • 9-12
9.2.3.2
Microtrap Logic • 9-13
9.2.3.2.1
Microtraps • 9-13
9.2.3.2.2
Microtrap Request liming • 9-15
9.2.3.2.3
Prioritization of Microtraps • 9-15
Erroneous Microtrap Interruption • 9-16
9.2.3.2.4
Microtrap Detection Abort Effects • 9-17
9.2.3.2.5
9.2.3.3
Last Cycle Logic • 9-18
9.2.3.3.1
Interrupts • 9-19
9.2.3.3.2
Trace Fault • 9-1 9

9-1
9-1
9-3

9.2.1
9.2.2

DIGITAL CONFIDENTIAL

9-11

xiii

Contents

9.2.4

9.2.3.3.3
First Part Done • 9-19
9.2.3.3.3.1
Interaction with Reserved Instructions • 9-19
9.2.3.3.4
Instruction Queue • 9-20
9.2.3.3.4.1
Instruction Context Latches • 9-22
9.2.3.4
Microstack • 9-22
Stall Logic

9.3

INITIALIZAnON

9-24

9.4

MICROCODE RESTRICTIONS

9-25

9.5

TESTABIUTY
9.5.1
Test Address
9.5.2
MlB Scan Chain

9-25
9-25
9-26

9.6

SIGNAL CROSS REFERENCE

9-30

9.7

REVISION HISTORY

9-33

CHAPTER 10 THE INTERRUPT SECTION

10-1

10.1

OVERVIEW

10-1

10.2

INTERRUPT SUMMARY
External Interrupt Requests Received by Edge-SensHlve Logic
10.2.1
External Interrupt Requests Received by Level-Sensltlve Logic
10.2.2
Internal Interrupt Requests
10.2.3
Special Considerations for Interval Timer Interrupts
10.2.4
10.2.5
Priority of Interrupt Requests

10-1
10-2
10-2
10-4
10-5

INTERRUPT SECTION STRUCTURE
10.3.1
Edge Detect and Synchronization Logic
10.3.1.1
Edge Detect Circuitry • 10-8
10.3.1.2
Interrupt Synchronization • 10-9
10.3.2
Interrupt State Register
10.3.3
Interrupt Generation Logic

10-8
10-8

10-9
10-10

10.4

EBOX MICROCODE INTERFACE

10-12

10.5

PROCESSOR REGISTER INTERFACE

10-13

10.6

INTERRUPT SECTION INTERFACES
Ebox Interface
10.6.1
10.6.1.1
Signals From Ebox • 10-14
H)"'6.1.2
Signals To Ebox • 10-14
M1crosequencer Interface
10.6.2
10.6.2.1
Signals from Microsequencer • 10-14
10.6.2.2
Signals To Microsequencer • 10-15
Cbox Interface
10.6.3
10.6.3.1
Signals From Cbox • 10-15
Ibox Interface
10.6.4
10.6.4.1
Signals From Ibox • 10-15
10.6.5
Mbox Interface
10.6.5.1
Signals From Mbox • 10-15
10.6.6
Pin Interface
10.6.6.1
Input Pins • 10-15
10.6.7
Signal Dictionary

10-14
10-14

10.3

xlv

9-24

10-6

10-14

10-15
10-15
10-15
10-15
10-15

DIGITAL CONFIDENTIAL

Contents

REVISION HISTORY

10-17

THE FBOX

11-1

11.1

OVERVIEW

11-1

11.2

INTRODUCTION

11-1

11.3

FBOX FUNCTIONAL OVERVIEW
Fbox Interface
11.3.1
Divider
11.3.2
Stage 1
11.3.3
Stage 2
11.3.4
Stage 3
11.3.5
Stage 4
11.3.6

11-2
11-3
11-4
11-4
11-4
11-4
11-4

11.4

FBOX-EBOXINTERFACE
Opcode Transfers to the Fbox
11.4.1
Operand Transfers to the Fbox
11.4.2
11.4.3
SummarY of Fbox Input Stage Stall Rules
11.4.4
Fbox Result Transfers to the Ebox
11.4.5
Fbox Pipeline Stalls
Fbox Reset and Flush
11.4.6
11.4.7
Summary of Fbox-Ebox Signals
11.4.8
Fbox Instruction Set

11-4
11-5
11-6
11-7
11-8
11-10
11-11
11-11
11-12

11.5

DIVIDER
11.5.1
11.5.2

11-15
11-15
11-16

10.7

CHAPTER 11

Introduction
Overview

11.6

INTERFACE SIGNAL TIMING DIAGRAMS

11-17

11.7

DIVIDER OPERATION

11-17

11.8

DIVIDER IMPLEMENTATION
11.8.1
Divider Fraction Data Path
11 .8.1.1
Divisor Register - DVR • 11-20
11 .8.1 .2
Divider Array • 11-20
11.8.1.2.1
DCSA and DSEL • 11-20
11.8.1.2.2
LAT1· 11-21
11.8.1.2.3
R2D and DCSAF· 11-21
11 .8.1.2.4
DFB and SHF • 11-21
CPA· 11-22
11.8.1.2.5
11.8.1.3
Ouotient Recoding and Quotient Registers • 11-23
11.8.1.3.1
OS21 and OREC • 11-24
11 .8.1.3.2
OM and OS registers • 11-24
11.8.1.3.3
OSEL and TSF· 11-25
11.8.2
Divider Control
11 .8.2.1
Divider Control Blocks • 11-26
11 .8.2.1 .1
Control Sequencer • 11-26
11.8.2.1.2
Opcode Information Latches • 11-27
11 .8.2.1 .3
Divider Behavior during ABORT • 11-27
11 .8.2.1 .4
Data path Control Drivers • 11-27
11 .8.2.2
Summary of Divider Stage Outputs • 11-27
11 .8.2.3
Data Valid Logic • 11-28

11-19
11-19

DIGITAL CONFIDENTIAL

11-25

Contents

11.8.3

11-28

11.9

STAGE 1

11-28

11.10

SECnON IMPLEMENTATION DESCRIPTION
11.10.1
Fraction Datapath
11.10.2
Integer Overflow - IOVF
11.10.3
Input Selector - ISEL
Adder
11.10.4
Recoder Selector - RSEL
11.10.5
11.10.6
SRECODER
11.10.7
Multiplier 'TWo's Complement Register - MTCR<18:0>
Recoder
11.10.8
11.10.9
PHI_4 LATCHES
11.10.10 Recoder Register - MRECR[0:6]<5:0>
Multiplier Initial Partial Product Selector and Register - MlPPR
11.10.11
11.10.12 Multiplier Row 1 Selector and Register - MRW1 R
11.10.13 Multiplier Row 2 Selector and Register - MRW2R
11.10.14 Selector and Register - FD1 R
11.10.15 Selector and Register - FD2R

11-29
11-29
11-31
11-31
11-31
11-32
11-32
11-32
11-32
11-32
11-33
11-33
11-33
11-33
11-33
11-33

11.11

EXPONENT DATAPATH
Stage 1 Exponent Processor Block diagram
11.11.1
Exponent Adders
11.11.2
11.11.3
Constants
Zero Detection
11.11.4
11.11.5
Exponent Adder 1
11.11.6
Exponent Adder 2
Exponent Difference Detection
11.11.7
Output Selector
11.11.8

11-35
11-35
11-36
11-36
11-37
11-37
11-37
11-38
11-38

11.12

SIGN DATAPATH

11-39

11.13

STAGE 1 CONTROL
11.13.1
Divide Instruction

11-39
11-39

11.14

FRACTION DATAPATH OPERATION SUMMARY

11-40

11.15

FRACTION DATAPATH EXCEPTION SUMMARY

11-40

11.16

EXPONENT DATAPATH OPERATION SUMMARY

11-42

11.17

EXPONENT DATAPATH EXCEP110N SUMMARY
Passthru Signals
11.17.1

11-43
11-43

11.18

STAGE 2
11.18.1
11.18.2

Introduction
MUL Instruction Flows

11-44
11-44
11-44

STAGE 2 IMPLEMENTATION DESCRIPTION
Fraction Datapath
11.19.1
MSEL - Multiplier Selector
11.19.2
11.19.3
MROW1 - Multiplier Row 1
MROW2 - Multiplier Row 2
11.19.4
MARRAY - Multiplier Array
11.19.5

11-47
11-47
11-49
11-49
11-50
11-50

11.19

xvi

Exponent and Sign Data Path

DIGITAL CONFIDENTIAL

Contents

11.19.6
11.19.7
11.19.8
11.19.9
11.19.10
11.19.11
11.19.12
11.19.13
11.19.14
11.19.15
11.19.16
11.19.17
11.19.18
11.19.19
11.19.20
11.19.21
11.19.22
11.19.23
11.19.24
11.19.25
11.19.26
11.19.27
11.19.28
11.19.29
11.19.30
11.20

STAGE 3
11.20.1
11.20.2

11.20.3
11.20.4

11.20.5

11.20.6

DIGITAL CONFIDENTIAL

MILSBSR<S:O> - Multiplier Integer LSB Sum Register
MILSBCR<4:0> - Multiplier Integer LSB Carry Register
RSHIFT - Right Shifter
RSHFTOR<AO:B58> - Right Shifter Output Register
SDEC - Shift Decoders
SDECOR<57:0> - Shift Decoder Output Register
DETL - Detection Logic
DETLOR<BO:B57> - Detection Logic Output Register
L 1DETL - Leading 1 Detection Logic
LSSEL - Left Shift Selector
LSENC - Left Shift Encoder
LSHR<57:0> - Left Shifter Control Register
FD1 SEL - Fraction Data 1 Selector
FD1 R<AO:B58> - Stage 2 Fraction Data 1 Register
FD2R<AO:B58> - Stage 2 Fraction Data 2 Register
Exponent Datapath
Zero Detection
Exponent Adder 1
Floating Overflow and Underflow Detection
Output Selector
ED2R<5:0> - Exponent Data 2 Register
Sign Datapath
Control
11.19.28.1 Datapath Control Signals Output from Control Block • 11-58
Stage 2 Fraction Datapath Operation Summary
Passthru Signals
Introduction
Stage 4 Bypass
11.20.2.1 Stage 4 Bypass Request • 11-64
11.20.2.2 Stage 4 Bypass Abort • 11-64
11.20.2.3 Stage 3 Response to FBOX Purge • 11-64
Section Implementation Description
11.20.3.1 Block Diagrams • 11-65
Fraction Datapath
11.20.4.1 Normalizer Input Selection • 11-69
11.20.4.2 Left Shifter • 11-69
11.20.4.3 Adder Input Selection • 11-70
11.20.4.4 Adder • 11-70
11.20.4.5 Mini-Round Incrementers • 11--72
11.20.4.6 Output Selector • 11-72
11.20.4.7 Fraction Datapath Operation Summary (Normal Operating
Mode): • 11-73
Exponent Datapath
11.20.5.1 Constants • 11-74
-11.20.5.2 Zero Detection • 11-74
11.20.5.3 Exponent Adder 1 • 11-75
11.20.5.4 Output Selector • 11-75
11.20.5.5 Exponent Datapath Operation Summary (Normal Operating
Mode): • 11-77
Sign Datapath

11-50
11-51
11-51
11-51
11-51
11-51
11-52
11-52
11-52
11-52
11-53
11-53
11-53
11-53
11-53
11-54
11-54
11-55
11-55
11-55
11-55
11-56
11-57
11-60
11-62
11-63
11-63
11-63

11-64
11-69

11-74

11-77

xvii

Contents

11.20.7

Control
11.20.7.1 Miscellaneous Control Signals • 11-78
11.20.7.2 Oata_Valid • 11-78
11.20.7.3 Fault Bits and NEW_FOP • 11-78
11.20.7.4 Signs_NoCEql, Fb_Neg4 • 11-79
11.20.7.5 Integer Overflow Logic • 11-79
11.20.7.6 Cin_BSS • 11-80
11.20.7.7 SeLOther • 11-80
11.20.7.8 Left Shifter Input Selection Signals • 11-80
11.20.7.9 Osel1_Zero • 11-81
11.20.7.10 0se11_Ed1r • 11-81
11.20.7.11 MULL Adder • 11-81

11.21

STAGE 4

11-$1

11.22

FRACTION DATAPATH
11.22.1
Fraction Implementation Descrl ptlon
11.22.2
Fraction Operation

11-$2
11-$3
11-84

11.23

EXPONENT DATAPATH
11.23.1
Exponent Block Description
11.23.2
Exponent Operation
11.23.3
Floating Overflow and Underflow Detection
11.23.4
Output Selector

11-86
11-$7
11-$7
11-$7
11-$8

11.24

CONTROL
11.24.1
Control Block Description
11.24.2
Control Block Implementation

11-90
11-90
11-90

11.25

MISCELLANEOUS AND SIGN LOGIC
11.25.1
Miscellaneous Sign Logic Implementation
11.25.2
Sign and Negative Result Logic
11.25.3
Integer Overflow
11.25.4
Zero Result
11.25.5
Reserved Operand
11.25.6
Floating Divide by Zero

11-91
11-91
11-92
11-93
11-95
11-96
11-96

11.26

FBOX TESTABIUTY
11.26.1
FBOX_Test Control Signals
11.26.2
FBOX_Test Mode Description
11.26.2.1 FBOX Section Operation During FBOX_Test Mode • 11-97
11.26.3
Revision History

11-97
11-97
11-97

CHAPTER 12 THE MBOX

xvIII

11-77

11-99
12-1

12.1

INTRODUCTION

12-1

12.2

MBOX STRUCTURE
12.2.1
IREF_LATCH
12.2.2
SPEC_QUEUE
12.2.3
EM_LATCH
VAP_LATCH
12.2.4
12.2.5
MME_LATCH
12.2.6
RTY_OMISS_LATCH
12.2.7
CBOX_LATCH

12-2
12-6
12-8
12-9
12-11
12-12
12-14
12-16

DIGITAL CONFIDENTIAL

Contents

12.2.8
12.2.9
12.2.10
12.2.11
12.2.12
12.2.13
12.2.14
12.2.15
12.3

PA_QUEUE
TB
MME_DATAPATH
ARBITRATION LOGIC
S6_PIPELATCH
DMISS_LATCH and IMISS_LATCH
MD_BUS_ROTATOR
Pcache

REFERENCE PROCESSING
12.3.1
REFERENCE DEFINITIONS
12.3.2
SIMPLE MBOX PIPELINE FLOW
12.3.3
REFERENCE ORDER RESTRICTIONS
12.3.3.1
No D-stream hits under O-stream misses • 12-26
12.3.3.2
No I-stream hits under I-stream misses • 12-26
12.3.3.3
Maintain the order of writes • 12-27
12.3.3.4
Maintain the order of Cbox references • 12-27
12.3.3.5
Preserve the order of Ibox reads relative to any pending Ebox
writes to the same quadword address • 12-27
12.3.3.6
110 Space Reads from the Ibox must only be executed when
the Ebox is executing the corresponding instruction • 12-27
12.3.3.7
Reads to the same Pcache block as a pending read/fill
operation must be inhibited • 12~8
12.3.3.8
Writes to the same Pcache block as a pending readltill
operation must be inhibited until the readlfill operation
completes • 12-28
12.3.4
REFERENCE ARBITRATION
12.3.4.1
Arbitration Priority • 12~8
12.3.4.2
Arbitration Algorithm • 12-29
12.3.5
READS
12.3.5.1
Generic Read-hit and Read-miss/Cache_fili
Sequences • 12-30
12.3.5.1.1
Returning Read Data • 12-31
12.3.5.1.1.1 Pcache Data Bypass • 12-31
12.3.5.2
I-stream Read Processing • 12-31
12.3.5.2.1
I-stream Read Hits • 12-31
12.3.5.2.2
I-stream Read Misses • 12-32
12.3.5.2.3
1/0 Space I-stream Reads • 12--32
12.3.5.3
D-stream Read Processing • 12--32
12.3.5.3.1
Reads under Rlls • 12--33
12.3.5.4
110 Space Reads • 12-33
12.3.6
WRITES
12.3.6.1
Destination Specifier Writes • 12-35
12.3.6.2
Explicit Writes • 12-36
12.3.6.3
Writes to 110 Space • 12--36
12.3.6.4
Byte Mask Generation • 12-36
12.3.7
IPR PROCESSING
12.3.7.1
MBOX IPRs • 12-37
12.3.7.2
Hardware MBOX IPR Format • 12-46
12.3.7.3
IPR Reads • 12-47
12.3.7.3.1
Mbox IPR Reads • 12-48
12.3.7.3.2
Non-Mbox IPR Reads • 12-48
12.3.7.4
IPR WRITES • 12-48
12.3.7.4.1
Mbox IPR Writes • 12-48

DIGITAL CONFIDENTIAL

12-17
12-18
12-18
12-18
12-18
12-19
12-20
12-21
12-23
12-23
12-24
12-25

12-28

12-30

12-34

12-37

xix

Contents

12.3.8
12.3.9
12.3.10
12.3.11

12.3.12

12.3.13
12.3.14
12.3.15
12.3.16
12.3.17

12.3.18

12.3.19

12.3.20
12.3.21

12.4

12.3.7.4.2
Non-Mbox IPR Writes • 12-49
LOAD_PC
INVALIDATES
CACHE FILL COMMANDS
MME CHECK COMMANDS
12.3.11.1 MME_CHK· 12-50
12.3.11.2 PROBE· 12-50
TB Fills
12.3.12.1 TB Tag Rlls • 12-51
12.3.12.2 TB PTE Rlls • 12-52
TBIS
TBIP
TBIA
STOP_SPEC_Q
UNALIGNED REFERENCES
12.3.17.1 Unaligned Reads • 12-56
12.3.17.2 Unaligned Writes • 12-56
12.3.17.3 Byte Mask Generation for Unaligned Writes • 12-57
12.3.17.4 Unaligned Destination Specifier Writes • 12-58
12.3.17.5 Implication of Ebox unaligned references on
M%EM_LAT_FUU._H • 12-58
ABORTING REFERENCES
12.3.18.1 Conditions for Aborting References • 12-59
12.3.18.1.1 Aborting to Maintain Reference Order Restrictions • 12-59
12.3.18.1.2 Aborting due to lack of hardware resources • 12-62
12.3.18.1.3 Aborting due to memory management operation • 12-63
12.3.18.1.4 Aborting due to an external flush condition • 12-63
MBOX PIPELINE DEADLOCK AVOIDANCE SCENARIOS
12.3.19.1 Unaligned Reference Deadlock Condition • 12-04
12.3.19.2 READ_LOCKlWRITE_UNLOCK Deadlock Condition • 12-64
THESPEC_Q_SYNC_CTR
FLUSHING REFERENCES FROM THE MBOX PIPE
12.3.21.1 Ibox Rushes • 12-66
12.3.21.2 Ebox Rushes • 12-67
12.3.21 .2.1 Rushing due to E%EM_ABORT_L • 12-67
12.3.21 .2.2 Rushing due to E%FLUSH_MBOX_H • 12-67
12.3.21.2.3 Ebox Rushing of the PA_QUEUE • 12-68

THE PCACHE
12.4.1
PCCTL
12.4.2
Pcache HltlMiss Determination
12.4.2.1
HitlMiss Determination by Tag Comparison • 12-72
12.4.2.2
Conditions which force Pcache Miss • 12-72
12.4.2.3
Conditions which force Pcache Hit • 12-73
12.4.3
Pcache Read Operation
12.4.4
Peaehe Write Operation
12.4.5
Pcache Replacement Algorithm
12.4.6
Pcache Fill Operation
12.4.7
Pcache Invalidate Operation
12.4.8
PcachelPRAecess
12.4.9
Peache IPR Summary
12.4.10
Pcache States Resulting In UNPREDICTABLE operation
12.4.11
Pcache Redundancy Logie

12-49
12-49
12-50
12-50

12-51

12-54
12-54
12-55
12-55
12-55

12-58

12-63

12-65
12-66

12-70
12-71
12-72

12-73
12-74
12-74
12-74
12-75
12-75
12-76
12-77
12-71

DIGITAL CONFIDENTIAL

Contents

12.5

MEMORY MANAGEMENT
12.5.1
NVAX MEMORY STRUCTURE
12.5.1.1
Virtual Address Space • 12-80
12.5.1.2
Physical Address Spaces • 12-81
Physical Address Space Mappings • 12-81
12.5.1.2.1
ADDRESS TRANSLATION AND THE TB • 12-83
12.5.1.3
12.5.1.4
30-bit to 32-bit Physical Address Translations • 12-85
12.5.1.5
MEMORY MANAGEMENT EXCEPTIONS • 12-85
12.5.1.5.1
MME_DATAPATH • 12-85
12.5. 1.5.1. 1 MME Register File • 12-86
12.5. 1.5.1.2 MME ALU • 12-87
12.5.1.5.1.3 MME_SEQ· 12-88
12.5.1.5.2
TB MISS SEQUENCE • 12-91
12.5.1.5.2.1 Single Miss Sequence • 12-91
12.5.1.5.2.2 Double Miss Sequence • 12-92
12.5.1.5.3
ACVITNVIM=O • 12-93
12.5.1.5.3.1 ACVITNVIM=O Fault Handling: • 12-93
12.5.1.5.3.2 ACV detection: • 12-94
12.5. 1.5.3.3 TNV detection • 12-94
12.5.1.5.3.4 M=O detection: • 12-95
12.5.1.5.3.5 Recording ACVITNVIM=O Faults • 12-95
12.5.1.5.3.6 ACVITNVIM=O MME_DATAPATH Sequence • 12-97
12.5.1.5.3.7 Microcode Invocation of ACVITNVIM=O • 12-98
12.5.1.5.3.8 Microcode Processing of ACVITNVIM=O: • 12-99
12.5.1.5.3.9 Pipeline Implications of ACVITNVIM=D condition • 12-100
12.5.1.5.3.9.1 Pipeline Effects for MME Faults on Write
References • 12-100
12.5.1.5.3.9.2 Pipeline Effects for MME Faults on Read
References • 12-100
12.5. 1.5.3.9.3 Pipeline Effects of E%A.USH_MBOX_H on MME State • 12-100
12.5.1.5.3.9.4 Pipeline Effects ofE%FLUSH_MBOX_H on "'''''ME_TRAP_L • 12-101
12.5.1.5.4
Cross Page Sequence • 12-102

12-79
12-80

12.6

MBOX ERROR HANDLING

12-103
12-103
12-103

12.6.1
12.6.2

12.6.3

12.6.4

12.6.5

DIGITAL CONFIDENTIAL

Types of Errors Handled
T8 parity error detection
12.6.2.1
TB tag parity error detection • 12-103
12.6.2.2
TB data parity error detection • 12-104
Pcache parity error detection
12.6.3.1
Pcache tag parity error detection • 12-104
12.6.3.2
Pcache data parity error detection • 12-105
Recording Mbox errors
12.6.4.1
TBSTS and TBADR • 12-106
12.6.4.2
PCSTS and PCADR • 12-107
Mbox Error Processing
12.6.5.1
Processing TB parity errors • 12-108
12.6.5.2
Processing Pcache parity errors • 12-109
12.6.5.3
Processing Cbox errors on Mbox-initiated read-like
sequences • 12-110
12.6.5.3.1
Cbox-detected ECC errors • 12-110
12.6.5.3.2
Cbox-detected hard errors on requested fill data • 12-110
12.6.5.3.3
Cbox-detected hard errors on non-requested fill
data • 12-111

12-104

12-105

12-108

xxi

Contents

12.6.5.3.4
12.6.5.4
12.7

MBOX INTERFACES
12.7.1
IBOX INTERFACE
12.7.1.1
Signals from lbox • 12-116
12.7.1.2
Signals to lbox • 12-116
EBOX INTERFACE
12.7.2
12.7.2.1
Signals from Ebox • 12-117
12.7.2.2
Signals to Ebox • 12-117
INTERRUPT SECnON INTERFACE
12.7.3
12.7.3.1
Signals to Interrupt Section • 12-118
USEQINTERFACE
12.7.4
12.7.4.1
Signals to Useq • 12-118
12.7.5
CBOX INTERFACE
12.7.5.1
Signals from Cbox • 12-118
12.7.5.2
Signals to Cbox • 12-119

12-116
12-116

12-117

12-118
12-118
12-118

12.8

INITIALIZATION
Power-up Initialization
12.8.1
Initialization by Microcode and Software
12.8.2
12.8.2.1
Pcache Initialization • 12-121
12.8.2.2
Memory Management Initialization • 12-121

12-120
12-120
12-120

12.9

MBOX TESTABIUTY FEATURES
Internal Scan Register and Data Reducers
12.9.1
12.9.2
Nodes on Parallel Port
12.9.3
Nodes on Top Metal
Architectural features
12.9.4
12.9.4.1
Translation Buffer Testability • 12-124
12.9.4.2
Pcache Testability • 12-125
12.9.5
M-BOX Miscellaneous Features

12-122
12-122
12-123
12-124
12-124

MBOX PERFORMANCE MONITOR HARDWARE
12.10.1
TB hit rate Performance Monitor Modes
12.10.1.1 TB hit rate for PO/P1 I-stream Reads • 12-127
12.10.1.2 TB hit rate for POIP1 D-stream Reads • 12-127
12.10.1.3 TB hit rate for SO I-stream Reads • 12-127
12.10.1.4 TB hit rate for SO D-stream Reads • 12-127
Pcache hit rate Performance Monitor Modes
12.10.2
12.10.2.1 Pcache hit rate for I-stream Reads • 12-127
12.10.2.2 Pcache hit rate for D-stream Reads • 12-128
Unaligned reference statistics
12.10.3

12-126
12-126

12.10

xxII

Microcode Invocation on Cbox-detected Hard
Errors • 12-111
Mbox Error Processing Matrix • 12-112

12-125

12-127

12-128

12.11

MBOX SIGNAL NAME CROSS-REFERENCE

12-129

12.12

REVISION HISTORY

12-132

DIGITAL CONFIDENTIAL

Contents

CHAPTER 13 THECBOX

13-1

13.1

TERMINOLOGY

13-1

13.2

FUNCTIONAL OVERVIEW OF THE CBOX AND BACKUP CACHE
13.2.1
The Cbox and the System
13.2.2
Wrlteback Cache and Ownership Concepts
Backup Cache Operating Modes
13.2.3

13-1
13-2
13-3
13-3

13.3

NVAX BACKUP CACHE ORGANIZATION AND INTERFACE
Backup Cache Interface
13.3.1
13.3.1.1
POkTS_INDEX_H<20:S> • 13-10
13.3.1.2
POkTS_OE_L • 13-11
13.3.1.3
POkTS_WE_L • 13-11
13.3.1.4
POkTS_TAG_H<31 :17> • 13-11
13.3.1.5
POkTS_ECC_H<S:O> • 13-12
13.3.1.6
POkTS_OWNED_H • 13-12
13.3.1.7
POkTS_VALlD_H • 13-12
13.3.1.8
POkDR_INDEX_H<20:3> • 13-12
13.3.1.9
POkDR_OE_L • 13-13
13.3.1.10 POkDR_WE_L • 13-13
13.3.1.11 POkDR_DATA_H<63:0> • 13-13
13.3.1.12 P%DR_ECC_H<7:0> • 13-13
Backup Cache Block Diagrams
13.3.2

13-4
13-10

THE CBOX DATAPATH
Mbox Interface
13.4.1
13.4.1.1
Mbox to Cbox Transactions • 13-26
13.4.1.1.1
The IREAD_LATCH and the DREAD_LATCH • 13-26
13.4.1.1.2
WRITE_PACKER and WRITE_QUEUE • 13-27
13.4.1.2
Cbox to Mbox Transactions • 13-30
13.4.1.2.1
CM_OUT_LATCH • 13-32
13.4.1.2.2
FILL_DATA_PIPE1 and FILL_DATA_PIPE2 • 13-33
13.4.1.2.3
IREAD Aborts • 13-35
13.4.2
ECC Datapaths
13.4.2.1
Backup Cache Tag Store ECC • 13-36
13.4.2.2
Backup Cache Data Store ECC • 13-39
The BIU
13.4.3
13.4.3.1
NDAL_IN_QUEUE • 13-42
NON_WRITEBACK_QUEUE· 13-44
13.4.3.2
13.4.3.3
WRITEBACK_QUEUE • 13-44
13.4.3.4
limeout counters • 13-46
13.4.3.5
BIU clocking: Relating internal cycles to external
cycles • 13-50
13.4.4
The FILL_CAM
13.4.4.1
Block-conflict in the FILL_CAM • 13-54
13.4.4.2
The FILL_CAM and DREAD_LOCKs • 13-54

13-19
13-24

13.4

13.5

CBOX INTERNAL PROCESSOR REGISTERS

DIGITAL CONFIDENTIAL

13-14

13-36

13-42

13-53

13-56

xxiii

Contents

13.5.1

13.5.2
13.5.3

13.5.4

13.5.5

xxiv

Cbox Control IPR (CCTL)
13.5.1.1
ENABLE • 1~2
13.5.1.2
TAG_SPEED • 13-62
13.5.1.3
DATA_SPEED • 13-62
13.5.1.4
SIZE • 13-63
13.5.1.5
FORCE_HIT • 13-63
13.5.1.6
DISABLE_ERRORS • 13-63
13.5.1.7
SW_ECC • 13-63
13.5.1.8
TIMEOUT_TEST • 13-64
13.5.1.9
DISABLE_PACK • 13-64
13.5.1.1 0 PM~CCESS_TYPE • 13-64
13.5.1.11 PM_HIT_TYPE· 13-64
13.5.1.12 FORCE_NDAL_PERR· 13-64
13.5.1.13 SW_ETM· 13-64
13.5.1.14 HW_ETM· 13-64
IPR A2 (hex), BCDECC
Backup Cache Tag Store Error Registers (BCETSTS, BCETIDX,
BCETAG)
13.5.3.1
Beache Error Tag Status (BCETSTS) • 13-66
13.5.3.1.1
LOCK • 13-67
13.5.3.1.2
CORR ·1~7
13.5.3.1.3
UNCORR • 13-67
13.5.3.1.4
BAD_ADDR • 13-67
13.5.3.1.5
LOST_ERR • 13-08
13.5.3.1.6
TS_CMD • 13-68
13.5.3.2
8cache Error Tag Index (BCETIDX) • 13-68
13.5.3.3
Beaehe Error Tag (BCETAG) • 13-69
13.5.3.3.1
VALID • 13-70
13.5.3.32
OWNED • 13-70
13.5.3.3.3
ECC • 13-70
13.5.3.3.4
TAG • 13-70
Backup Cache Data RAM Error Registers (BCEDSTS, BCEDIDX,
BCEDECC)
13.5.4.1
Beache Error Data Status (BCEDSTS) • 13-71
LOCK • 13-72
13.5.4.1.1
13.5.4.1.2
CORR • 13-72
13.5.4.1.3
UNCORR • 13-72
13.5.4.1.4
BAD_ADDR • 13-72
13.5.4.1.5
LOST_ERR • 13-73
13.5.4.1.6
DR_CMD • 13-73
13.5.4.2
Beaehe Error Data Index (BCEDIDX) • 13-73
13'.5.4.3
Beaehe Error Data ECC (BCEDECC) • 13-74
Fill Error Registers (CEFADR, CEFSTS)
13.5.5.1
Cbox Error Fill Status (CEFSTS) • 13-76
13.5~5.1 .1
RDLK • 13-77
13.5.5.12
LOCK • 13-77
13.5.5.1.3
TIMEOUT • 13-77
13.5.5.1 .4
ROE • 13-78
13.5.5.1.5
LOST_ERR • 13-78
13.5.5.1.6
100 • 13-78
13.5.5.1.7
IREAD • 13-78
13.5.5.1.8
OREAD • 13-78
13.5.5.1.9
WRITE • 13-78
13.5.5.1.10 TO_MBOX· 13-78

13-61

13-65
13-66

13-71

13-76

DIGITAL CONFIDENT.AL

Contents

13.5.6

13.5.7
13.5.8

RIP • 13-78
13.5.5.1.11
13.5.5.1.12 OIP· 13-78
13.5.5.1.13 DNF· 13-79
13.5.5.1.14 RDLK_FL_DONE· 13-79
13.5.5.1.15 REO_Flll_DONE· 13-79
13.5.5.1.16 COUNT· 13-79
13.5.5.1.17 UNEXPECTED_FilL· 13-79
13.5.5.2
Fill Error Address (CEFADR) • 13-79
NDAL Error Registers (NESTS, NEOADR, NEOCMD, NEDATHI,
NEDATLO, NEICMD)
13.5.6.1
NDAl Error Status IPR (NESTS) • 13-81
NOACK • 13-82
13.5.6.1.1
13.5.6.1.2
BADWDATA • 13-82
13.5.6.1.3
LOST_ OERR • 13-82
13.5.6.1.4
PERR • 13-82
13.5.6.1.5
INCON_PERR • 13-83
13.5.6.1.6
LOST_PERR • 13-83
13.5.6.2
NDAL Error Output Address IPR (NEOADR) • 13-83
13.5.6.3
NDAL Error Output Command (NEOCMD) • 13-83
13.5.6.4
NDAL Error Input Command (NEICMD) • 13-84
13.5.6.4.1
PARITY • 13-85
13.5.6.4.2
10 • 13-85
CMD • 13-85
13.5.6.4.3
13.5.6.5
NDAL Error Data High and NDAL Error Data Low (NEDATHI
and NEDATLO) • 13-85
Backup Cache Tag Store Access Through IPR Reads and Writes
(BCTAG)
Backup cache deallocates through IPR access (BCFLUSH)

13-81

13-87
13-89

13.6

CBOX CONTROL DESCRIPTION

13-90

13.7

TRANSACTION DESCRIPTIONS
13.7.1
IPR Reads and IPR Writes
13.7.2
I/O Space
13.7.3
Clear Write Buffer
Memory Read Hit
13.7.4
13.7.5
Read Miss and Fill
13.7.6
Write Hit
13.7.7
Write Miss
13.7.8Deallocates Due to CPU Reads and Writes
13.7.9
DREAD_LOCK and WRITE_UNLOCK

13-94
13-94
13-94
13-94
13-96
13-97
13-97
13-98
13-98
13-98

13.8

CACHE COHERENCY

13-99

13.9

ABNORMAL CONDITIONS
13.9.1
Cbox Behavior When the Backup Cache is OFF
13.9.2
Cbox Behavior When the Backup Cache is In FORCE_HIT Mode
13.9.3
Cbox Behavior When the Backup Cache Is In Error Transition Mode
13.9.4
Cbox transition Into Error Transition Mode
13.9.5
How to turn the Bcache off
13.9.6
How to turn the Bcache on
13.9.7
Assertion of POkCPU_WB_ONLY_L
13.9.8
Backup Cache Errors
13.9.9
Backup Cache Errors Incurred While In Error Transition Mode

13-101
13-103
13-104
13-104
13-106
13-108
13-108
13-109
13-111
13-114

DIGITAL CONFIDENTIAL

xxv

Contents

13.9.10

NDAL Parity Errors

13-114

13.10

TESTABILITY
13.10.1
Parallel port
13.10.2
Internal scan chain

13-115
13-115
13-116

13.11

PERFORMANCE MONITORING

13-118

13.12

INITIALIZATION

13-119

13.13

CBOX INTERFACES

13-120

13.14

RESOLVED ISSUES

13-124

13.15

NVAX CBOX SIGNAL NAME CROSS-REFERENCE

13-125

13.16

REVISION HISTORY

13-128

CHAPTER14

VECTOR INTERFACE

14-1

14.1

DESCRIPTION

14-1

14.2

REVISION HISTORY

14-4

ERROR HANDLING

15-1

15.1

TERMINOLOGY

15-1

15.2

ERROR HANDLING INTRODUCnON AND SUMMARY

15-1

15.3

ERROR HANDLING AND RECOVERY
15.3.1
Error State Collection
15.3.2
Error Analysis
15.3.3
Error Recovery
15.3.3.1
Special Considerations for Cache and Memory Errors • 15-9
15.3.3.1.1
Cache Coherence in Error Handling • 15-10
15.3.3.1.1.1 Cache Enable, Disable, and Flush Procedures • 15-10
15.3.3.1.1.1.1 Disabling the NVAX Caches for Error Handling (Leaving the
Bcache in ETM) • 15-11
15.3.3. 1.1.1.2 Flushing and Disabling the Bcache • 15-11
15.3.3.1.1.1.3 Enabling the NVAX Caches • 15-11
15.3.3.1.2
Special Writeback Cache Recovery Situations and
Procedures • 15-12
15.3.3.1.2.1 Bcache Uncorrectable Error During Writeback • 15-12
15.3.3.1.2.2 Memory State • 15-12
15.3.3.1.2.2.1 Accessing Memory State • 15-13
15.3.3.1.2.2.2 Repairing Memory State (Fill Errors) • 15-13
15.3.3.12.2.3 Repairing Memory State (Tagged-Bad Locations) • 15-14
15.3.3.1.2.3 Extracting Data from the Bcache • 15-14
15.3.3.12.4 Address Determination Procedure for Recovery from
Uncorrectable Bcache Data RAM Errors • 15-15
15.3.3.1.2.5 Special Address Determination Procedure for Recovery
from Uncorrectable Bcache Tag Store Errors • 15-15
15.3.3.1.3
Cache and TB Test Procedures • 15-16
15.3.4
Error Retry
15.3.4.1
General Multiple Error Handling Philosophy • 15-17
15.3.4.2
Retry Special Cases • 15-18

15-3
15-3
15-7
15-8

CHAPTER 15

xxvi

15-17

DIGITAL CONFIDENTIAL

Contents

15.4

CONSOLE HALT AND HALT INTERRUPT

15-19

15.5

MACHINE CHECKS
15.5.1
Machine Check Stack Frame
15.5.2
Events Reported Via Machine Check Exceptions
15.5.2.1
MCHK_UNKNOWN_MSTATUS • 15-33
15.5.2.2
MCHK_INT.ID_VALUE • 15-33
15.5.2.3
MCHK_CANT_GET_HERE • 15-33
15.5.2.4
MCHK_MOVC.STATUS • 15-33
15.5.2.5
MCHK_ASYNC_ERROR • 15-34
15.5.2.5.1
TB Parity Errors • 15-34
15.5.2.5.2
Ebox S3 Stall Timeout Error • 15-34
15.5.2.6
MCHK_SYNC_ERROR • 15-35
15.5.2.6.1
VIC Parity Errors • 15-36
15.5.2.6.2
Bcache Data RAM Uncorrectable ECC Errors and
Addressing Errors • 15-36
15.5.2.6.3
Bcache Lost Data RAM Access Error • 15-37
15.5.2.6.4
NDAL I-Stream or D-Stream Read or D-Stream Ownership
Read Timeout Errors • 15-37
15.5.2.6.5
NDAL I-Stream or D-Stream Read or D-Stream Ownership
Read Data Errors • 15-39
15.5.2.6.6
Lost Bcache Fill Error • 15-41
15.5.2.6.7
Unacknowledged NDAL I-Stream or D-Stream Read or
D-Stream Ownership Read • 15-41
15.5.2.6.8
Lost NDAL Output Error • 15-42
15.5.2.6.9
PTE read errors • 15-43
15.5.2.6.9.1 PTE Read Errors in Interruptable Instructions • 15-43
15.5.2.6.9.2 Bcache Data RAM Uncorrectable EGG Errors and
Addressing Errors on PTE Reads • 15-44
15.5.2.6.9.3 NDAL PTE Read Timeout Errors • 15-45
15.5.2.6.9.4 NDAL PTE Read Data Errors • 15-46
15.5.2.6.9.5 Unacknowledged NDAL PTE Read • 15-47
15.5.2.6.9.6 Multiple Errors Which interfere with Analysis of PTE Read
Error· 15-47
15.5.2.7
Inconsistent Status in Machine Check Cause Analysis • 15-47

15-22
15-22
15-24

15.6

POWER FAIL INTERRUPT

15-48

15.7

HARD ERROR INTERRUPTS
15.7.1
Events Reported Via Hard Error Interrupts
15.7.1.1
Uncorrectable Data Errors and Addressing Errors During Write
or Write-Unlock Processing • 15-51
15.7.1.2
Lost Bcache Data RAM Hard Errors • 15-53
15.7.1.3
Bcache Timeout or Read Data Error in Quadword OREAD RII
After Write Data Merged • 15-53
15.7.1.3.1
Unexpected RII Error • 15--54
15.7.1.3.2
Lost Bcache RII Error • 15-54
15.7.1.4
NDAL No-ACK During WRITE or WDISOWN • 15-55
15.7.1.5
Lost NDAL No-ACK Hard Errors • 15-55
15.7.1.6
System Environment Hard Error Interrupts • 15-55
15.7.1.7
Inconsistent Status in Hard Error Interrupt Cause
Analysis • 15-56

15-49
15-49

15.8

SOFT ERROR IN'rERRUPTS

15-57

DIGITAL CONFIDENTIAL

xxvii

Contents

15.8.1

xxvIII

Events Reported Via Soft Error Interrupts
15-57
15.8.1.1
VIC Parity Errors • 15-69
15.8.1.2
Pcache Parity Errors • 15-69
15.8.1.3
Bcache Tag Store Uncorrectable Errors • 15-69
15.8.1.3.1
Case: BCETSTS<TS_CMD>=WUNLOCK • 15-70
15.8.1.3.2
Case:
BCETSTS<TS_CMD>=DREAD,IREAD,OREAD • 15-70
15.8.1.3.3
Case: BCETSTS<TS_CMD>=R_INVAL,O_INVAL,IPR_DEALLOCATE • 15-]
Lost Bcache Tag Store Errors • 15-71
15.8.1.4
Bcache Tag Store Correctable ECC errors • 15-71
15.8.1.5
Lost Bcache Tag Store Correctable ECC errors • 15-72
15.8.1.6
15.8.1.7
Bcache Data RAM Correctable ECC Errors • 15-72
Lost Bcache Data RAM Correctable ECC Errors • 15-72
15.8.1.8
Bcache Data RAM Uncorrectable ECC Errors and Addressing
15.8.1.9
Errors on I-Stream or D-Stream Reads • 15-73
15.8.1.10 Bcache Data RAM Uncorrectable ECC Errors and Addressing
Errors on Writebacks • 15-73
15.8.1.11 Lost Bcache Data RAM Errors With Possible Lost
Writebacks • 15-74
15.8.1.12 Lost Beache Data RAM Errors Without Lost
Writebacks • 15-75
15.8.1.13 NDAL I-Stream or D-Stream Read or D-Stream Ownership
Read limeout Errors • 15-76
15.8.1.14 NDAL I-Stream or D-Stream Read or D-Stream Ownership
Read Data Errors • 15-77
15.8.1.15 Lost Bcache Fill Error • 15-79
15.8.1.16 Unacknowledged NDAL I-Stream or D-Stream Read or
D-Stream Ownership Read • 15-79
15.8.1.17 Lost NDAL Output Error • 15-80
15.8.1.18 PTE read errors • 15-80
15.8.1.18.1 Bcache Data RAM Uncorrectable ECC Errors and
Addressing Errors on PTE Reads • 15-81
15.8.1.18.2 NDAL PTE Read Timeout Errors • 15-82
15.8.1.18.3 NDAL PTE Read Data Errors • 15-83
15.8.1.18.4 Unacknowledged NDAL PTE Read • 15-84
15.8.1.18.5 Multiple Errors Which interfere with Analysis of PTE Read
Error • 15-84
15.8.1.19 NDAL Parity Errors • 15-84
15.8.1.20 Lost Parity Errors • 15-85
15.8.1.21 System Environment Soft Error Interrupts • 15-85
15.8.1.22 Inconsistent Status in Soft Error Interrupt Analysis • 15-85

15.9

KERNEL STACK NOT VALID EXCEPTION

15-87

15.10

ERROR RECOVERY CODING EXAMPLES

15-88

15.11

MISCELLANEOUS BACKGROUND INFORMATION
Note On Tagged-Bad Data Mechanisms
15.11.1
Note On Ownership Mechanism
15.11.2

15-88
15-88
15-88

15.12

REVISION HISTORY

15-90

DIGITAL CONFIDENTIAL

Contents

CHAPTER 16

CHIP INITIAUZATION

16-1

16.1

OVERVIEW

16-1

16.2

HARDWAREIMICROCODE INITIALIZATION

16-1

16.3

CONSOLE INITIALIZATION

16-2

16.4

CACHE INITIALIZATION

16-3

16.5

MISCELLANEOUS INFORMATION

16-6

16.6

REVISION HISTORY

16-7

CHAPTER 17 CHIP CLOCKING

17-1

17.1

OVERVIEW OF THE NVAX CLOCKING SYSTEM

17-1

17.2

RECEIVING THE NVAX EXTERNAL OSCILLATOR SIGNAL
The System Environment
17.2.1
17.2.2
The Chip Test Environment

17-1
17-1 .
17-2

17.3

ON-CHIP CLOCKS
17.3.1
Clock GeneratlonlDlstrlbutlon Overview
Global Clock Distribution
17.3.2
Section Clock Distribution
17.3.3
17.3.4
Global Clock Waveforms
17.3.5
Section Clock Waveforms
17.3.6
Clock Skews and Rise/Fail Times of the Section Clocks

17-3
17-3
17-5
17-5
17-5
17-6
17-7

17.4

THE NDAL INTERFACE TIMING SYSTEM
17.4.1
NDAL Clocks
17.4.2
Controlling Inter-Chlp Clock Skew

17-7
17-7
17-7

17.4.2.1
17.4.2.2
17.4.3
17.4.4

Self Skew • 17-8
Inter-Clock Skew • 17-9

Driving and Receiving NDAL signals
Information Transfer between the NDAL clock system and the on-chip
clock system

17-9
17-9

17.5

INITIALIZING THE NVAX SYSTEM.
17.5.1
Internal NVAX Reset
17.5.2
Generation of Clocks During Power-up
Clock Generator Reset
17.5.3

17-9
17-10
17-11
17-11

17.6

NVAXCLOCK SECTION SIGNAUPIN DICTIONARY
17.6.1
Schematic - Behavioral Translation
17.6.2
Behavloral- Schematic Translation

17-14
17-14
17-15

17.7

REVISION HISTORY

17-16

DIGITAL CONFIDENTIAL

x).lx

Contents

CHAPTER 18

PERFORMANCE MONITORING FACILITY

18-1

18.1

OVERVIEW

18-1

18.2

SOFTWARE INTERFACE TO THE PERFORMANCE MONITORING FACILITY
18.2.1
Memory Data Structure
18.2.2
Memory Data Structure Updates
18.2.3
Configuring the Performance Monitoring Facility
182.3.1
Ibox Event Selection • 18-4
18.2.3.2
Ebox Event Selection • 18-4
18.2.3.3
Mbox Event Selection • 18-5
18.2.3.4
Cbox Event Selection • 18-6
18.2.4
Enabling and Disabling the Performance Monitoring Facility
18.2.5
Reading and Clearing the Performance Monitoring Facility Counts

18-1
18-1
18-2
18-3

18-6
18-7

HARDWARE AND MICROCODE IMPLEMENTATION OF THE PERFORMANCE
MONITORING FACILITY
Hardware Implementation
18.3.1
18.3.2
Microcode Interaction with the Hardware

18-8
18-10
18-11

REVISION HISTORY

18-12

18.3

18.4

CHAPTER 19 TESTABILITY MICRO-ARCHITECTURE

xxx

19-1

19.1

CHAPTER OVERVIEW

19-1

19.2

THE TESTABILITY STRATEGY

19-1

19.3

TEST MICRO-ARCHITECTURE OVERVIEW

19-2

19.4

PARALLEL TEST PORT
Parallel Port Operation
19.4.1

19-3
19-4

19.5

TEST PADS

19.6

SYSTEM PORT

19.7

SERIAL P-CACHE PORT

19-7

19.8

IEEE 1149.1 (JTAG) SERIAL TEST PORT
19.8.1
TAP Controller State Machine
19.8.2
Instruction Register
Bypass Register
19.8.3
19.8.4
Control Dispatch Logic
19.8.5
Initialization

19-7
19-9
19-11
19-12
19-12
19-16

19.9

BOUNDARY SCAN REGISTERS
Boundary Scan Register Cells
19.9.1
Boundary Scan Register Organization
19.9.2

19-16
19-16
19-19

19.10

INTERNAL SCAN REGISTER AND LFSR REDUCER
19.10.1
Internal Scan Register Cells
19.10.2
Internal Scan Register Organization

19-22
19-22
19-23

19.11

OUTPUT PIN TRI-STATE CONTROL

19-23

19.12

OPERATING SPEED OF TEST LOGIC

19-24

19.13

REVISION HISTORY

19-25

DIGITAL CONFIDENTIAL

Contents

CHAPTER 20

ELECTRICAL CHARACTERISTICS

20-1

20.1

INTRODUCTION

20-1

20.2

NVAX DC OPERATING CHARACTERISTICS
Maximum Ratings
20.2.1
Pin Driver Impedance
20.2.2
Pin Capacitance
20.2.3
20.2.4
Pin Operating Levels

20-1
20-1
20-3
20-4
20-4

20.3

NVAX AC OPERATING CHARACTERISTICS
AC Conditions of Test
20.3.1
NDAL nmlng Specification
20.3.2
20.3.3
BCACHE llmlng Specification
Other Pin Timing Specifications
20.3.4
20.3.4.1
Clock liming • 20-22
20.3.4.2
Reset Timing • 20-23
20.3.4.3
Interrupt, Error, and Test Pin liming • 20-24

20-7
20-7
20-9
20-11
20-22

20.4

REVISION HISTORY

20-26

APPENDIX A
A.1

PROCESSOR REGISTER DEFINITIONS

A-1

REVISION HISTORY

A-19

INDEX

FIGURES
1-1

1-3

1-2

nmlng Diagram Notation

1-5

2-1

Virtual Address Space Layout

2-2

32-blt Physical Address Space Layout

2-3

30-blt Physical Address Space Layout

2-3

2-4

IPR E7 (hex), PAMODE

2-4

2-5

General Purpose Registers

2-5

2-6

Processor Status Longword Fields

2-5

2-7

Data Types

2-6

2-8

Opcode Formats

2-8

2-9

Addressing Modes

2-9

2-10

Branch Displacements

2-11

IPR 38 (hex), MAPEN

2-25

2-12

IPR 3A (hex), TBIS

2-25

2-13

IPR 39 (hex), TBIA

2-26

2-14

IPR OC (hex), SBR and IPR OD (hex), SLR

2-27

2-15

System Space Translation Algorithm

2-28

2-16

IPR 08 (hex), POBR and IPR 09 (hex), POLR

2-29

2-17

PO Space Translation Algorithm

2-29

2-18

IPR OA (hex), P1 BR and IPR OB (hex), P1 LR

2-30

DIGITAL CONFIDENTIAL

xxxi

Contents

2-19
2-20
2-21
2-22

PTE Format (21-blt PFN)
PTE Format (25-blt PFN)
Minimum Exception Stack Frame

2-23

General Exception Stack Frame

2-24
2-25

IPR 12 (hex), IPL
IPR 14 (hex), SIRR
IPR 15 (hex), SISR
ArHhmetic Exception Stack Frame

2-26
2-27
2-28
2-29
2-30
2-31

2-30
2-31
2-31
2-33
2-33
2-35
2-35
2-35
2-37
2-38
2-39
2-40

Memory Management exception Stack Frame
Instruction Emulation Trap Stack Frame
Suspended Emulation Fault Stack Frame
Generic Machine Check Stack Frame
IPR 2A (hex), SAVPC and IPR 2B (hex), SAVPSL
IPR 11 (hex), SCBB
System Control Block Vector
IPR OE (hex), CPUID
IPR 3E (hex), SID
IPR 10 (hex), PCBB

2-40
2-41
2-41
2-42
2-44
2-45
2-47

Process Control Block
IPR Address Space Decoding

2-48
2-49

3-1
3-2
3-3
3-4
3-5
3-6
3-7
3-8

NDAL Pin Timing Relative to the NDAL CLOCKS

NDAL Arbitration timing
NDAL Suppress timing
Address Cycle Format
Physical Address Space Layout
NDAL Memory Address Interpretation

3-5
3-11
3-19
3-23
3-25
3-27
3-28
3-29

3-9
3-10
3-11

3-17

POkACK_L Timing
NDAL Read timing
RDE example
NDAL Fill timing
Quadword Read and Fill
Read command on the NDAL
Read data return without using HOLD
Read data return using HOLD
NDAL Write timing

3-37
3-43
3-45
3-46
3-47
3-47
3-48
3-48
3-51

3-18
3-19
3-20
3-21
3-22

Quadword write on the NDAL
Hexaword write on the NDAL
Octaword write on the NDAL
NVAX XMI-2 System Block Diagram
XMI2 Unlock Write example

3-52
3-52
3-53
3-65
3-66

2-32
2-33
2-34
2-35
2-36
2-37
2-38
2-39

3-12
3-13
3-14
3-15
3-16

xxxII

P1 Space Translation Algorithm

Bcache Pin Timing Relative to INTERNAL NVAX Clocks (14ns system)
NDAL Arbitration Block Diagram

DIGITAL CONFIDENTIAL

Contents

~23

4-1

NVAX Lowend System Block Diagram
NVAX CPU Block Diagram

5-1
5-2

Non-Plpellned Instruction execution
Partlally-Plpellned Instruction Execution

3-67
4-2
5-2
5-2

5-3

Fully-Plpellned Instruction Execution

5-3

5-4

5-7
5-8

Simple Three-Segment Pipeline
Information Flow Against the Pipeline
Stalls Introduced by Backward Pipeline Flow
Buffers Between Pipeline Segments
NVAX CPU Pipeline

6-1
6-2

Ebox Data Path Control, Standard Format
Ebox Data Path Control, Special Format

6-1
6-2

6-3

Ebox Mlcrosequencer Control, Jump Format
Ebox Microsequencer Control, Branch Format
Ibox CSU Format

6-4
6-4
6-5

6-6
7-1
7-2
7-3
7-4
7-5

Ibox Instruction ROM Format
Ibox Block Diagram
VIC Block Diagram
VIC Cache Row Format
IPR DO (hex), VMAR
IPR D1 (hex), VTAG

6-6
7-2
7-6
7-7
7-14
7-15

7-6

IPR D2 (hex), VDATA
IPR D3 (hex), ICSR
Prefetch Queue Block Diagram
SourcelDestlnation Queue Entry Formats
Microword Format
Complex Specifier Unit Control Path Block Diagram
Complex Specifier Unit Data Path Block Diagram
Branch Table Entry Format

7-15
7-16
7-18
7-33
7-40
7-42
7-51
7-56

IPR D4 (hex), BPCR
Ebox Block Diagram
SMUL Step Operation
UDIV Step Operation
S+PSW Format
RN.MODE.OPCODE E_BUSOkBBUS_L<31 :0> Source
A Source Queue Entry
A Destination Queue Entry
Ebox Pipeline Latches

7-60
8-3
8-20

IPR 7C (hex), PCSCR
IPR 7D (hex), ECR
NVAX Timeout Counters
EOfoWBUS_H LFSR Block Diagram
PMFCNT Processor Register in EOfoWBUS_H<31:0> LFSR Format

8-80
8-82
8-85
8-90
8-91

5-5
5-6

6-4
6-5

7-7
7-8
7-9
7-10
7-11
7-12
7-13
7-14
8-1
8-2

8-3
8-4
8-5

8-6
8-7
8-8
8-9
8-10
8-11
8-12
8-13

DIGITAL CONFIDENTIAL

5-4
S-5
5-6

5-7

8-21
8-36
8-37
8-44
8-45
8-73

xxxiii

Contents

Mlcrosequencer Block Diagram

Microcode Mlcrosequencer Control Field Formats
Instruction Queue Entry Format

9-3
9-4

xxxiv

Instruction Context Format

Mlcrostack Organization

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

Parallel Port Output Format
Interrupt SCB Vector Offset
Interrupt Section Block Diagram
IPR 7A (hex), INTSYS
Fbox block diagram
Fbox Execute Cycle Diagram
Opcode Transfers to the Fbox
Divider Array Block Diagram
Input Signals from Input Interface
Result Transfer to Stage-l
Divider Fraction Data Path
CPA Block Diagram
Divider Sequencer State Transition Table
Fraction Datapath Block Diagram
Recoder Block Diagram
Stage 1 Exponent Processor Block diagram
Sign Datapath Block Diagram

11-14
11-15

Fraction Datapath Operation Table

11-16

Exponent Datapath Operation Table

Fraction Datapath Exception Summary

11-17

Exponent Datapath Exception Table

11-18

Stage 2 Fraction Datapath Block Diagram

11-19

Stage 2 Exponent Datapath Block Diagram

11-20

Sign Datapath Block Diagram

11-21

Control Block Diagram

11-22

Fraction Datapath Operation Summary

11-23

Stage 2 Exponent Datapath Operation Summary

11-24

Stage 3 Fraction Datapath Block Diagram

11-25
11-26

Stage 3 Fraction Mlnl-round Block Diagram
Stage3 Exponent Datapath Block Diagram

11-27
11-28

Fraction Datapath Operation Summary
Fraction Datapath Block Diagram

11-29
11-30

Block Diagram of Exponent Processor
Control Block Diagram

11-31

Miscellaneous Pia Block Diagram

12-1
12-2

Mbox Block Diagram
Iref Latch

12-3

Spec Queue

9-2
9-8
9-20
9-22
9-23
9-26
10-3
10-8
10-12
11-2
11-3
11-7
11-17
11-18'
11-19
11-22
11-23
11-26
11-30
11-34
11-35
11-39
11-40
11-41
11-42
11-43
11-47
11-54
11-56
11-57
11-60
11-62
11-66
11-67
11-68
11-73
11-82
11-86
11-90
11-91
12-3
12-7
12-8

DIGITAL CONFIDENTIAL

Contents

12-4

EM_LATCH

12-10

12-5

VAP_LATCH

12-11

12-6

MME_LATCH

12-13

12-7

RTY_DMlSS_LATCH

12-15

12-8

CBOX_LATCH

12-16

12-9

PA_QUEUE

12-17

12-10

DMISS_LATCH and IMlSS_LATCH

12-19

12-11

MD_BUS_ROTATOR

12-21

12-12

Basic Mbox Timing

12-25

12-13

2 Processor Synchronization Example

12-26

12-14

Memory Scoreboard Example

12-27

12-15

Barrel Shifter Function

12-35

12-16

IPR EO (hex), MPOBR

12-38

12-17

IPR E1 (hex), MPOLR

12-38

12-18

IPR E2 (hex), MP1 BR

12-39

12-19

IPR E3 (hex), MP1 LR

12-39

12-20

IPR E4 (hex), MSBR

12-39

12-21

IPR E5 (hex), MSLR

12-39

12-22

IPR E6 (hex), MMAPEN

12-40

12-23

IPR E7 (hex), PAMODE

12-40

12-24

IPR E8 (hex), MMEADR

12-41

12-25

IPR E9 (hex), MMEPTE

12-41

12-26

IPR EA (hex), MMESTS

12-41

12-27

IPR EC (hex), TBADR

12-42

12-28

IPR ED (hex), TBSTS

12-42

12-29

IPR F2 (hex), PCADR

12-43

12-30

IPR F4 (hex), PCSTS

12-43

12-31

IPR F8 (hex), PCCTL

12-44

12-32

IPRs 01800000 thru 01801 FEO (hex), PCTAG

12-45

12-33

IPRs 01COOOOO thru 01C01FF8 (hex), PCDAP

12-46

12-34

MPOLA Register

12-46

12-35

MP1 LA Register

12-47

12-36

MSLR Register

12-47

12-37

MP1 BR Register

12-47

12-38

TB_TAG_FILL Format (from MME_LATCH)

12-52

12-39

TB_TAG_FILL Format (from EM_LATCH): IPR 7E (hex), MTBTAG

12-52

12-40

TB_PTE_FILL Data Format (from MME_LATCH)

12-53

12-41

TB_PTE_FILL Data Format (from EM_LATCH): IPR 7F (hex), MTBPTE

12-54

12-42

PA_QUEUE conflict detection

12-60

12-43

Logical Pcache Organization

12-70

12-44

Peache Address Breakdown

12-71

12-45

IPR Address Space Mapping

12-76

12-46

Pcache Address Redundancy Mapping

12-78

DIGITAL CONFIDENTIAL

xxxv

Contents

12-47

Virtual Address Space Layout

12-80

12-48

Physical Address Space of the NVAX Hardware

12-81

12-49

3O-blt Physical Address Mapping

12-82

12-50

32-blt Physical Address Mapping

12-83

12-51

PTE and TB format

12-84

12-52

12-86

12-53

MME Datapath
MME Sequences

12-54

MME Sequences Cont'd

12-55

IPR EA (hex), MMESTS

12-56

IPR ED (hex), TBSTS

12-57

IPR F4 (hex), PCSTS

13-1

The Cbox In the System

13-2

Backup Cache Tag RAM Pin Timing

13-8

12-106
12-107

13-3

Backup Cache Data RAM Pin Timing

13-9

13-4
13-5

Tags and Data for 128-Kllobyte Cache

13-14

Address as used for 128-Kllobyte Cache

13-15

13-6

Tags and Data for 256-Kllobyte Cache

13-16

13-7

Address as used for 256-Kllobyte Cache

13-8

Tags and Data for 512-Kllobyte Cache

13-16
13-17

13-9

Address as used for 512-Kllobyte Cache

13-17

13-10

Tags and Data for 2-Megabyte Cache

13-18

13-11

Address as used for 2-Megabyte Cache

13-18

13-12
13-13

Cbox block diagram with DATA_BUS
Cbox block diagram with ADDRESS_BUS

13-22
13-23

13-14

Mbox Interface

13-24

13-15

B%S6_DATA_Hc63:O> bypass timing

13-16

M%ABORT_CBOX_IRD_H Timing

13-33
13-35

13-17

Tag Store ECC Block Diagram

13-37

13-18

Tag Store Error Correcting Code Matrix

13-38

13-19

Data RAM ECC Block Diagram

13-40

13-20

Backup Cache Data Store Error Correcting Code Matrix

13-41

13-21

NVAX Timeout Counters

13-22

BIU cycle counts
NVAX time relative to NDAL time

13-47
13-50

13-23
13-24

13-51

IPR Address Space Decoding as seen by Software

13-56

(PR AO (hex), CCTL
Format of the BCDECC

13-61
13-65

IPR A3 (hex), BCETSTS

13-66

13-25
13-26
13-27
13-28

IPR A4 (hex), BCETlDX
IPR A5 (hex), BCETAG

13-69

13-29

xxxvi

12-89
12-90
12-95

13-69

13-30
13-31

IPR A6 (hex), BCEDSTS
IPR A7 (hex), BCEDIDX

13-71
13-74

13-32

IPR A8 (hex), BCEDECC

13-75

DIGITAL CONFIDENTIAL

Contents

13-33
13-34

IPR AC (hex), CEFSTS
IPR AB (hex), CEFADR

13-76
13-80

13-35
13-36

IPR AE (hex), NESTS
IPR BO (hex), NEOADR

13-81
13-83

13-37
13-38
13-39
13-40
13-41
13-42

IPR B2 (hex), NEOCMD
IPR B8 (hex), NEICMD
IPR B4 (hex), NEDATHI
Backup Cache Tag Store IPR Addressing Format
IPRs 01000000 thru 011FFFEO (hex), BCTAG

13-84
13-85
13-86
13-86
13-87
13-87

13-43
15-1

IPRs 01400000 thru 015FFFEO (hex), BCFLUSH
IPR 2A (hex), SAVPC

13-89
15-19

15-2
15-3
15-4
15-5
15-6
15-7
15-8
15-9
15-10

IPR 2B (hex), SAVPSL
IPR 26 (hex), MCESR
Machine Check Stack Frame
Cause Parse Tree for Machine Check Exceptions
Power Fall Interrupt Stack Frame

15-19
15-22
15-23

15-11

Kernel Stack Not Valid Stack Frame
NVAX CPU Interface Circuitry
On-Chip XOR Test Functionality Waveforms
On-Chip Clock Distribution
Global Clock Wavefonns
Relationship of Internal and NDAL Clock Cycles
Self Skew
System Reset nmlng

17-1
17-2
17-3
17-4
17-5
17-6
17-7
17-8
17-9
18-1
18-2
18-3
18-4
18-5
19-1
19-2
19-3
19-4
19-5
19-6
19-7

IPR B6 (hex), NEDATLO

Hard Error Interrupt Stack Frame
Cause Parse Tree for Hard Error Interrupts
Soft Error Interrupt Stack Frame
Cause Parse Tree for Soft Error Interrupts

15-26
15-48
15-49
15-50
15-67
15-58
15-87
17-2
17-3
17-4
17-6
17-8
17-8
17-10

Clock State During Initial Power-up
Clock Generator Reset Timing
Performance Monitoring Data Structure Base Address
Per-CPU Performance Monitoring Data Structure
IPR 3D (hex), PME
IPR 7B (hex), PMFCNT In PMF Format
Performance Monitoring Hardware Block Diagram
Test Interface Unit

17-11
17-13
18-2

Internal Scan Register Operation nming

19-5
19-6
19-8
19-9
19-10
19-12

Self Relative Timing in Observe MAB Mode
Serial Port Timing
IEEE 1149.1 Serial Port (the Basic CTI)
TAP Controller State Machine
JTAG Instruction Register Cell

DIGITAL CONFIDENTIAL

18-2
18-7
18-8
18-9
19-2

xxxvII

Contents

19-8
19-9

IEEE 1149.1 Logic Timing during IR-5can Sequence
IEEE 1149.1 Logic Timing during DR-5can Sequence

19-14
19-15

19-10

In_beell Boundary Scan Cell
out_beell Boundary Scan Cell

19-17
19-17

lo_beell Boundary Scan Cell

19-18
19-18
19-21
19-22
19-23

19-11
19-12
19-13
19-14

md_beell Boundary Scan Cell
Boundary Scan Register at TAG Store Interface

19-15
19-16
20-1
20-2

Cells for Internal Scan Registers
An ISR section turned Into LFSR
NDAL Pin Timing Relative to the NDAL CLOCKS
Generic Data RAM Timing Diagram

20-12

20-3

Generic Tag RAM Timing Diagram

20-14

20-4
20-5
20-6
20-7
20-8

XNP Specific Data RAM Timing Diagram
XNP Specific Tag RAM Timing Diagram
Relationship of Internal and NDAL Clock Cycles

20-18
20-20
20-22
20-23
20-24

2~9

System Reset Timing
Clock Generator Reset Timing

TABLES
1-1

1-3

1-2
1-3
1-4

Register Field 'tYpe Notation
Register Field Notation
Revision History
3D-bit Mapping of Program Addresses to 32-blt Hardware Addresses
General Purpose Register Usage

1-3
1-4
1-6
2-4
2-5

Processor Status Longword
General Register Addressing Modes
PC-Relative Addressing Modes
NVAX Instruction Set

2-5
2-10
2-11
2-12

PTE Protection Code Access Matrix

2-32
2-34
2-35
2-37

2-1
2-2
2-3
2-4
2-5
2-6
2-7
2-8
2-9
2-10
2-11
2-12
2-13
2-14
2-15
2-16
2-17
2-18
2-19

xxxvIII

Interrupt Priority Levels
Exception Classes
Arithmetic exceptions
Memory Management Exceptions
Memory Management Exception Fault Parameter
Instruction Emulation Trap Stack Frame
System Control Block Vector
System Control Block Layout
SID Field Descriptions
IPR Address Space Decoding
Processor Registers
1/0 Space Registers

2-37
2-38
2-39
2-42
2-42
2-46
2-50
2-52
2-61

DIGITAL CONFIDENTIAL

Contents

2-20
3-1
3-2
3-3

Revision History
NVAX CPU pinout
NDAL AC timing specs
NVAX DAL Bandwidth at 30ns

3-4

NVAX DAL Bandwidth at 42ns

3-5

NDAL Signals
NDAL clocks

3-6

3-7
3-8

3-9

3-10
3-11
3-12
3-13
3-14
3-15
3-16
3-17
3-18
3-19
3-20
3-21
3-22
3-23
3-24
3-25
4-1

5-1
6-1
6-2
6-3
6-4
6-5
6-6

6-7
7-1
7-2
7-3

7-4

7-5
7-6

7-7
7-8

Byte Enable for Quadword Reads and Writes
Byte Enable for Octaword Writes
Possible Byte Enables for NVAX-generated transactions
NDAL Length Field

2-62

3-2
3-6

3-15
3-15
3-16
3-18
3-30

3-30
3-32
3-33

NDAL Command Encodlngs and Definitions
NDAL Address Cycle Commands as used by the NVAX CPU
Commander P%ID_H Assignments

3-34
3-34
3-35 .

NDAL Parity Coverage
NDAL Command Usage by NVAX
NDAL Command Usage by NDAL nodes besides NVAX
RDR usage for ALL fill cycles
NVAX Backup Cache Invalidates and Wrltebacks
NVAX Read Timeout Values In Normal Mode

3-36

NVAX Read Timeout Values In Test Mode
NDAL Errors and NVAX CPU Error Responses
NDAL Errors and Error Responses by System Components
XMI2-NVAX Coherency requirements
Cross-reference of all names appearing In the NVAX chip Interface chapter
Revision History
Revision History
Revision History
EBOX Data Path Control Mlcroword Fields, Standard Format
EBOX Data Path Control Mlcroword Fields, Special Format
Ebox Mlcrosequencer Control Mlcroword Fields, Jump Format
Ebox Microsequencer Control Mlcroword Fields, Branch Format
Ibox CSU Mlcroword Fields
Ibox Instruction ROM Fields
Revision History
lbox Pipeline
VIC Attributes
VIBA bit fields
VIC Status Flags
VMAR Field Descriptions
VTAG Field Descriptions
VDATA Field Descriptions
ICSR Field Descriptions

DIGITAL CONFIDENTIAL

3-39

3-40
3-44
3-54
3-57
3-57
3-60
3-63
3-65

3-70
3-72
4-6

5-22
6-1
6-2
6-4
6-4
6-5

6-6
6-8

7-4

7-5
7-7
7-8

7-14
7-15
7-15
7-16

xxxix

Contents

7-9

Specifier Control Fields

7-20

7-10

Complex Specifier Control Fields

7-20

7-11

Specifier Data Fields

7-21

7-12

Instruction Context Summary

7-21

7-13

Ebox Assist Summary

7-25

7-14

IBU stop and start summary

7-29

7-15

Instruction Queue Entry Format

7-30

7-16

I%OPERAND_BUS_H Definition

7-34

7-17

I%OPERAND_BUS_H Definition

7-34

7-18

Source Queue Entries Written for Non-field Access Type Operands

7-35

7-19

Source queue Entries Written for VR or VM Access Type Operands

7-35

7-20

Destination Queue Entries Written for Non-field Access Type Operands

7-37

7-21

Destination Queue Entries Written for VM Access Type Operands

7-38

7-22

Source Queue Entries Retired

7-39

7-23

Mlcroword Fields

7-40

7-24

Microcode Page Allocation

7-41

7-25

S1 Pipe Latch

7-43

7-26

Next Address Generation Fields

7-45

7-27

S2 Pipe Latch

7-46

7-28

CSU Registers

7-46

7-29

S3 Pipe Latch

7-48

7-30

Branch Prediction Logic

7-57

7-31

BPCR Field Descriptions

7-60

7-32

BPCR <8:6>

7-61

7-33

Reserved Addressing Mode Faults

7-66

7-34

Cross-reference of all names appearing In the Ibox chapter

7-67

7-35

Ibox Scan Register Fields

7-69

7-36

Revision History

7-71

8-1

Data Path Control Mlcroword Fields

8-4

8-2

GPR Write Length

8-13

ALU Operations

8-18

Shifter Operations

8-22

8-3
8-4
8-5
8-6
8-7
8-8
8-9
8-10
8-11
8-12
8-13
8-14
8-15

Condition Code Alteration Maps Specified By Microcode

8-28

Condition Code Alteration Maps Used By The Fbox

8-28

Setting and Clearing State Flags

8-30

MPU Calculation

8-32

Branch Condition Evaluation

8-34

Ebox Sourced Microbranch Conditions

8-40

Field Queue Branch

8-48

Detection of Ibox Incurred Faults and Errors

8-51

Ebox Mbox Requests

8-60

Ebox Memory Request Information Busses

8-62

Ebox Memory Request Information Truth Table

8-62

DIGITAL CONFIDENTIAL

Contents

8-16
8-17
8-18
8-19
8-20
8-21
8-22
8-23
8-24
8-25
8-26
8-27

Ebox Response to M%MME_FAULT_H and MOfoHARD_ERR_H
Ebox Mlcrotrap Requests
Fbox Fault Codes
Ebox Pipeline Stall and Flush Cases
Ebox Miscellaneous Operations
PCSCR Field Descriptions
ECR Field Descriptions
S3 Stall Timeout Values In Normal Mode
S3 Stall Timeout Values In Test Mode
Derivation of NVAX TImeout Values
Ebox Observe Scan Signals
PSt Restrictions Summary

8-65
8-71
8-72
8-73
8-77
8-81
8-83
8-85
8-86
8-87
8-87
8-96
8-87

8-28
8-29

Signal Name Cross-Reference
Revision History

9-1
9-2
9-3

Example: Writing an Entry In the Patchable Control Store
Contents of MlB Scan Chain, When Loading Patchable Control Store
Jump Format Control Field Definitions

9-4

9-8

Branch Format Control Field Definitions
Jump Format Control Field Decodes
Branch Format Control Field Decodes
Branch Address Formation
Current Address Selection

9-9
9-10
9-10
9-11

9-9
9-10
9-11
9-12
9-13
9-14
9-15
9-16

Mlcrotest Bus Sources
Mlcrotrap Request TIming
Mlcrotraps
Abort Effects In the Mlcrosequencer
Mlcroaddresses for Last Cycle Interrupts or exceptions
Instruction Queue Entry Format Field Definitions
Control Store Address Formation
Instruction Queue Operation

9-12
9-15
9-15
9-18
9-18
9-20
9-20
9-21

9-17
9-18
9-19

9-22
9-23
9-24
9-26
9-26

10-1

Instruction Context Format Field Definitions
Mlcrostack Pointer Example
Stall TIming In the Mlcrosequencer
Parallel Port Output Format Field Definitions
Contents of MlB Scan Chain, In Observe Mode
Schematic Signal Names, In Alphabetical Order
Behavioral Model Signal Names, In Alphabetical Order
Revision History
Interrupt Vector Offset Registers

10-2
10-3
10-4
10-5

Interrupt sca Vector Offset
Internal Interrupt Requests
Software Interrupts
References to Interval TImer Processor Registers

9-5

9-6
9-7

9-20
9-21
9-22
9-23
9-24

DIGITAL CONFIDENTIAL

8-89
9-4
9-5

9-9
9-9

9-30
9-31
9-33
10-3
10-3
10-4
1~5
1~

xII

Contents

Relative Interrupt Priority

10-7

Summary of Interrupts

10-10

10-8

INTSYS Field Descriptions

10-9

Cross-reference of all names appearing In the Interrupt chapter

10-12
10-15

10-10

Revision History

10-17

11-1

Fbox Internal Execute Cycles
List of the Fbox Total Execute Cycles

11-3
11-3

11-3

Fbox Floating Point and Integer Instructions

11-4

Total Fbox execute cycles for Divide operation

11-13
11-16

11-5

CSA Inputs

11-21

11-6

QM Cell Control Signals

11-25

10-6
10-7

11-2

11-7

Divider Output Stages

11-27

11-8

Stage 1 Fraction Register Operations

11-31

11-9

Exponent Adder Operations

11-36

11-10

Exponent Adder Carry-in Operations

11-37

11-11

Stage 3 Fraction Datapath Operations

11-69

11-12

Possible Values For Sum Bits cAO:B1>

11-71

11-13

Bit Injection Within Adder

11-72

11-14
11-15

Exponent Datapath Operation Summary

11-74
11-75

11-16

Exponent Output Selection
Stage 3 Sign Datapath Operatlons/slgn_dp_oper

11-76
11-78

11-19

Categories of Datapath Operations
Fraction Datapath Operations

11-20

Fraction Datapath Operation Summary

11-17
11-18

11-77
11-84
11-85

11-21

Exponent Datapath Operation Summary

11-89

11-22

Revision History

11-99

12-1

Reference Definitions
Byte Mask Logic for Aligned References

12-23

Mbox IPRs

12-37

MMAPEN Field Descriptions
PAMODE Field Descriptions

12-40
12-40

12-2
12-3
12-4
12-5
12-6

xiii

LSB Carry-ln Values

12-37

MMESTS Field Descriptions

12-41

12-7
12-8

TBSTS Field Descriptions

12-42

PCSTS Field Descriptions

12-43

12-9
12-10

PCCTL Field Descriptions
PCTAG Field Descriptions

12-44
12-45

12-11

PCDAP Field Descriptions

12-46

12-12

Probe Status Encodlngs

12-51

12-13

TB_TAG_FILL Definition

12-52

12-14
12-15

MTBTAG Field Descriptions
TB_PTE_FILL Definition

12-52
12-53

12-16

MTBPTE Field Descriptions

12-54

DIGITAL CONFIDENTIAL

Contents

12-17

Byte Mask Logic for Aligned and Unaligned References

12-57

12-18

PcachelPRs

12-76

12-19

MMESTS Field Descriptions

12-95

12-20

LOCK Encodlngs

12-96

12-21

FAULT Encodlngs

12-96

12-22

MMESTS State Update

12-97

12-23

18STS Field Descriptions

12-106

12-24

SRC Encodings

12-106

12-25

PCSTS Field Descriptions

12-107

12-26

Mbox Error Handling Matrix

12-112

12-27

Mbox Performance Monitor Modes

12-126

12-28

Cross-reference of all names appearing in the Mbox chapter

12-129

13-1

Backup Cache Size and RAMs Used

13-4

13-2

Tag and Index Interpretation based on cache size

13-4

13-3

Backup Cache RAM Speeds and NVAX Cycle Time

13-5

13-4

Cache pin drive times In the XNP environment

13-6

13-5

Cache pin timing symbol definitions

13-6

NVAX Backup Cache Interface Pins

13-10

13-7

Usage of P%TS_INDEX_H<20:5> based on cache size

13-11

13-8

Usage of P%TS_TAG_H<20:17> based on cache size

13-11

13-9

Usage of P%DR_INDEX_H<20:5> based on cache size

13-12

13-10

Cbox Queues and Major Latches

13-19

13-11

Mbox-Cbox Commands

13-25

13-12

Mbox to Cbox Command Matrix

13-26

13-13

tREAD_LATCH Fields

13-27

13-14

DREAD_LATCH Fields

13-27

13-15

WRITE_QUEUE Fields

13-28

13-16

Cbox to Mbox interface signals

13-30

13-17

Cbox to Mbox Command Matrix

13-31

13-18

Cbox to Mbox commands and resulting Mbox actions

13-31

13-19

CM_OUT_LATCH Fields

13-32

13-20

Fields of FILL_DATA_PIPE1 and FILL_DATA_PIPE2

13-34

13-21

Cbox Action Upon Receiving M%A8ORT_CBOX_IRD_H

13-35

13-22

NDAL_IN_QUEUE Fields

13-43

13-23

BIU commands sent to Cbox proper

13-43

13-24

NON_WRITEBACK_QUEUE Fields

13-44

13-25

WRITEBACK_QUEUE Fields

13-44

13-26

NVAX Tlmeout Values In Normal Mode

13-48

13-27

NVAX Tlmeout Values In Test Mode

13-48

13-28

Derivation of NVAX Tlmeout Values

13-49

13-29

FILL_CAM Fields
Cbox Response to Coherence Transactions to FILL_CAM Entries

13-53

13-30
13-31

tPR Address Space Decoding

13-57

DIGITAL CONFIDENTIAL

13-54

xliii

Contents

13-32

Cbox Processor Registers

13-33

CCTL Field Descriptions

13-58
13-61

13-34

TAG_SPEED

13-62

13-35

DATA_SPEED

13-62

13-36

SIZE

13-63

13-37

13-66

13-38

BCETSTS Field Descriptions
Interpretation of TS_ CMD

13-39

BCETAG Field Descriptions

13-40

TAG Interpretation

13-69
13-70

13-41

BCEDSTS Field Descriptions

13-42

Interpretation of DR_CMD

13-71
13-73

13-43

BCEDIDX Interpretation

13-74

13-44

CEFSTS Field Descriptions

13-76

13-45

NESTS Field Descriptions

13-81

13-46

NEOCMD Field Descriptions

13-47

BCTAG Field Descriptions

13-84
13-87

13-48

Tag and Index interpretation for BCTAG IPR

13-88

13-49

Cbox Task Priority Under Normal Conditions.

13-50

Cbox Task Priority When DWR_CONFLICT Bits are Set In the WRITE_QUEUE.

13-91
13-91

13-51

Cbox Task Priority When IWR_CONFLICT Bits are Set In the WRITE_QUEUE.

13-92

13-52

Cbox Task Priority When a DREAD_LOCK Is In progress until the WRITE_UNLOCK
Is done.

13-92

13-54

Order of quaclwords read from the Bcache
NVAX Backup Cache Invalidates and Wrltebacks

13-96
13-99

13-55

Backup cache behavior while It Is ON

13-102

13-56

Backup cache behavior during ETM

13-105

13-57

Backup cache state changes during ETM

13-106

13-58

Backup Cache ECC Errors and NVAX CPU Error Responses

13-53

13-60

13-111
Probability of reading data with an uncorrectable error after writing It with Inverted
checkblts
13-113
Backup Cache ECC Error handling during ETM
13-114

13-61
13-62

Cbox Parallel Port Connections
Interpretation of BC_TS_CMD<2:0>

13-63

FILL_CAM scan chain

13-116

13-64
13-65

Cbox Performance Monitoring Control
Cbox Performance Monitoring Control

13-118
13-118

13-66

CBOX Interface signals

13-120

13-67

Cross-reference of all names appearing In the CBOX chapter

13-125

13-68

Revision History

13-128

13-59

xliv

13-68

13-115
13-115

14-1

Vector Instruction Set

14-1

14-2
15-1

Revision History

14-4

Error Summary By Notification Entry Point

15-2

Console Halt Codes

15-2
15-19

DIGITAL CONFIDENTIAL

Contents

15-3

CPU State Initialized on Console Halt

15-20

15-4

Machine Check Stack Frame Fields

15-23

15-5

Machine Check Codes

15-24

15-6

Revision History

15-90

16-1

Revision History

16-7

17-1

NVAX CPU Clock Sections

17-3

17-2

Skews and RlselFall Times

17-3

Revision History

17-7
17-16

18-1

Performance Monitoring Facility Box Selection

18-3

18-2

Ibox Event Selection

18-4

18-3

Ebox Event Selection

18-4

Mbox Event Selection

18-5

Cbox PMCTRO Event Selection

18-6

18-6
18-7

Cbox PMCTR1 Event Selection

18-6

Revision History

18-12
19-3
19-4

19-1

NVAX CPU's Test Pins

19-2

Parallel Port Operating Modes

19-3

Serial to Parallel Conversion of Scan Data

19-4

Instruction Register

19-5
19-11

19-5

Boundary Scan Register Organization

19-19

19-6

Revision History

19-25

20-1

Maximum Ratings

20-1

20-2
20-3

Power DiSSipation Across Voltage and Cycle Time

20-2

NVAX Pin Driver Impedance
Maximum Pin Capacitance

20-3
20-4
20-4

20-6

NVAX Pin Levels
NVAX Pin Characteristics

20-7

Pin Loading for AC Tests

20-4
20-5

20-5

20-8

NDAL AC timing specs

20-7
20-10

20-9

Generic Data RAM Timing Specification

20-13

20-10

Generic Tag RAM Timing SpeCification
OMEGA-Speclflc Data RAM Timing Specification

20-15
20-16

20-12
20-13

OMEGA Specific Tag RAM Timing Specification
XNP SpecHlc Data RAM Timing Specification

20-17
20-19

20-11

20-14

XNP Specific Tag RAM Timing Specification

20-21

20-15

Interrupt, Test, and Boundary Scan Pin AC timing specs

20-16

Revision History

20-25
20-26

A-1

Revision History

A-19

DIGITAL CONFIDENTIAL

xlv

Chapter 1
Introduction

The NVAX CPU is a high-performance, single-chip implementation of the VAX architecture. It
is partitioned into multiple sections which cooperate to execute the VAX base instruction group.
The CPU chip includes the first levels of the memory subsystem hierarchy in an on-chip virtual
instruction cache and an on-chip physical instruction and data cache, as well as the controller
for a large second-level cache implemented in static RAMs on the CPU module.

1.1

Scope and Organization of this Specification
This specification describes the operation of the NVAX CPU chip. It contains a description of the
interface to the chip, an overview of the operation of the instruction pipeline, and extensive detail
about the functional operation of each section of the chip. In addition, the specification contains
discussions of error handling, chip initialization, and testability features.

1.2 Related Documents
The following documents are related to or were used in the preparation of this document:
•
•

DEC Standard 032 VAX Architecture Standard.
NVAX CPU Chip Design Methodology.

1.3 Terminology and Conventions
1.3.1

Numbering

All numbers are decimal unless otherwise indicated. Where there is ambiguity, numbers other
than decimal are indicated with the name of the base following the number in parentheses, e.g.,
FF (hex).

1.3.2

UNPREDICTABLE and UNDEFINED

RESULTS specified as UNPREDICTABLE may vary from moment to moment, implementation
to implementation, and instruction to instruction within implementations. Software can never
depend on results specified as UNPREDICTABLE.

DIGITAL CONFIDENTIAL

Introduction 1-1

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

OPERATIONS specified as UNDEFINED may vary from moment to moment, implementation to
implementation, and instruction to instruction within implementations. The operation may vary
in effect from nothing, to stopping system operation. UNDEFINED operations must not cause
the processor to bang.,· i.e., reach a state from which there is no transition to a normal state in
which the machine executes instructions.
Note the distinction between result and operation. Non-privileged software can not invoke
UNDEFINED operations.

1.3.3

Ranges and Extents

Ranges are specified by a pair of numbers separated by a " .. " and are inclusive, e.g., a range of
integers 0 ..4 includes the integers 0, 1, 2, 3, and 4.
Extents are specified by a pair of numbers in angle brackets separated by a colon and are inclusive,
e.g., bits <7:3> specify an extent of bits including bits 7, 6, 5, 4, and 3.

1.3.4

Must be Zero (MBZ)

Fields specified as Must Be Zero (MBZ) must never be filled by software with a non-zero value.
If the processor encounters a non-zero value in a field specified as MBZ, a Reserved Operand
exception occurs.

1.3.5 Should be Zero (SBZ)
Fields specified as Should Be Zero (SBZ) should be filled by software with a zero value. These
fields may be used at some future time. Non-zero values in SBZ fields produce UNPREDICTABLE
results.

1.3.6 Reg ister Format Notation
This spec:ification contains a number of figures that show the format of various registers, followed
by a description of each field. In general, the fields on the register are labeled with either a name
or a mnemonic. The description of each field includes the name or mnemonic, the bit extent,
and the type. An example of a register is shown in Figure 1-1. Table 1-1 is an example of the
description of the fields in this register.

1-2

Introduction

DIGITAL CONFIDENTIAL

NVAX CPU Chip Funetional Specification, Revision 1.0, February 1991

Figure 1-1:

31 30 29 28127 26 25 24123 22 21 20119 l8 l7 l61l5 l4 l3 12111 lO 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 0 0 0 0 0 0 01
FAULT_CMD
1 x x x xlIEI 0 0 0 0 0 0 0 01
1 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1

TRAP
INTERRUPT

1
1

---+

BUS_ERROR

Table 1-1:

----+

Name

Extent Type

BUS_ERROR

WC,O

The BUS_ERROR bit is set when a bus error is detected.

INTERRUPr

WC,O

The INTERRUPT bit is set when an error that is reported as an
interrupt is detected.

TRAP

WC,O

The TRAP bit is set when an error that is reported as a trap is detected.

RW,O

The IE bit enables error reporting interrupts. When IE is 0, interrupts
are disabled. When IE is a 1, interrupts are enabled.

FAULT_CMD

23:16

The FAULT_CMD field latches the command that was in progress when
an error is detected.

Description

The ''Type'' column in the field description includes both the actual type of the field, and an
optional initialized value, separated from the type by a comma. The type denotes the functional
operation of the field, and may be one of the values shown in Table 1-2. If present, the initialized
value indicates that the field is initialized by hardware or microcode to the specified value at
powerup. If the initialized value is not present, the field is not initialized at powerup.
Table 1-2: Register Field Type Notation
Notation

Description

A read-write bit or field. The value may be read and written by software, microcode,
or hardware.

A read-only bit or field. The value may be read by software, microcode, or hardware.
It is written by hardware; software or microcode writes are ignored.

A write-only bit or field. The value may be written by software or microcode. It is read
by hardware and reads by software or microcode return an UNPREDICTABLE result.

A write-only bit or field. The value may be written by software or microcode. It is read
by hardware and reads by soaware or microcode return a O.

A write-one-to-clear bit. The value may be read by software or microcode. Software or
microcode writes of a 1 cause the bit to be cleared by hardware. Software or microcode
writes of a 0 do not modify the state of the bit.

A read-to-clear field. The value is written by hardware and remains unchanged until
read. The value may be read by software or microcode, at which point, hardware may
write a new value into the field.

DIGITAL CONFIDENTIAL

Introduction 1-3

NVAX CPU Chip Functional Specification, Revision l~O, February 1991

In addition to named fields in registers, other bits of the register may be labeled with one of the
three symbols listed in Table 1-3. These symbols denote the type of the unnamed fields in the

Notation

Description

A "0" in a bit position denotes a register bit that is read as a 0 and ignored on write.

A "1" in a bit position denotes a register bit that is read as a 1 and ignored on write.

An "X' in a bit position denotes a register bit that does not exist in hardware. The
value is UNPREDICTABLE when read, and ignored on write.

1-4

Introduction

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

1.3.7 Timing Diagram Notation
This specification contains a number of timing diagrams that show the timing of various signals,
including NDAL signals. The notation used in these timing diagrams is shown in Figure 1-2.
Figure 1-2: Timing Diagram Notation
HIGH
LOW
INTERMEDIATE
VALID HIGH OR LOW
CHANGING

xxxxxxxxx
E!GH TO LOW
HIGH TO VALID

,SS\
,SSS
'SSm
,

$ $ ,

LOW TO HIGH

101

LOW TO VALID

1111
10M
I I I»

LOW TO INTERMEDIATE

t 2 2 ;

-...,j>...>..,)-INVALID TO INTERMEDIATE

XXX»)--

--««
--«(<XX

DIGITAL CONFIDENTIAL

Introduction 1-5

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

1.4 Revision History

Table 1-4: Revision History
Who

When

Mike Uhler

06-Mar-1989

Release for external review.

Mike Uhler

15-Dec-1989

Update for second-pass release.

1-6

Introduction

Description of change

DIGITAL CONFIDENTIAL

Chapter 2
Architectural Summary

2.1

Overview
This chapter provides a summary of the VAX. architectural features of the NVAX CPU Chip. It is
not intended as a complete reference but rather to give an overview of the user-visible features.
For a complete description of the architecture, consult the VAX Architecture Standard (DEC
Standard 032).

2.2

Visible State
The visible state of the processor consists of memory, both virtual and physical, the general
registers, the processor status longword (PSL), and the privileged internal processor registers
(IPRs).

2.2.1

Virtual Address Space

The virtual address space is four gigabytes (2**32), separated into three accessable regions (PO,
Pl, and SO) and one reserved page, as shown in Figure 2-1.

DIGITAL CONFIDENTIAL

Architectural Summary 2-1

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 2-1:
00000000

Virtual Address Space Layout

+-------------------------+1
1

length of PO Region in
pages (POLR)

11 Region
PO
----------------1
1
1
3FFFFFFF

PO Region growth direction

40000000

+-------------------------+
1
1

Pl Region growth direction

1I Pl
----------------1I
Region
7FFFFFFF

80000000

+-------------------------+
1
I
1

length of Pl Region in
pages (2**21-P1LR)
length of System Region
in pages (SLR)

1I Region
System ---------------1
I
1

1
1
1

I
I
1

,
ITIT!'DIT,

I
V

I
1

====~OO

IT::::::

System Region growth
direction

+-------------------------+
I Reserveci
1

Page

+-------------------------~

NOTE'

NVAX CPU chips at revision 1 implement the .original VAX memory management
architecture in which any reference to a virtual address above BFFFFFFF (hex) causes
a length violation. NVAX CPU chips at revision 2 or later implement the extended SO
space addressing described above.

2.2.2

Physical Address Space

The NVAX CPU naturally generates 32..bit physical addresses. This corresponds to a four gigabyte
physical address space as shown in Figure 2-2. Memory space occupies the :first seven-eighths
(3.5GB) of the physical address space. 110 space occupies the last one-eighth (512MB) of the
physical address space and can be distinguished from memory space by the fact that bits <31:29>
of the physical address are all ones.

2-2 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-2: 32-blt Physical Address Space Layout
00000000

+-------------------------+
I
I
I
I
I
I

I
I
I
I

Memory

Space

DFFFFFFF
EOOOOOOO
FFFFFFFF

I
I
I
I
I 3.5 GB

I
I
I
I
I

+-------------------------+
I/O
I 512 MB
Space

+-------------------------+

In addition to the natural 32-bit physical address, the CPU may be configured to generate 30-bit
physical addresses. In this mode, only 512MB of memory space can be referenced, as shown in
Figure 2---3.
Figure 2-3:
00000000

1FFFFFFF
20000000

30-blt Physical Address Space Layout

+-------------------------+
I
Memory
I 512 MB
I

Space

I
-+
I
I
I
I
I

+I
I
I
I
I
+I
I
I
I
I

Inaccessable
Region

+DFFFFFFF
EOOOOOOO
FFFFFFFF

+-------------------------+
I
I

I
I

-+ 3.0 GB
I
I
I
I
I
-+
I
I

+-------------------------+
I/O
I 512 MB
Space

+-------------------------+

The translation from 30-bit addresses to 32-bit addresses is accomplished by sign-extending
PA<29> to PA<31:30>. In this mode, the programmer sees a 1GB address space, split evenly
between memory and liD space, which is mapped to the actual 32-bit physical address space as
shown in Table 2-1. Unless explicitly stated otherwise, addresses that are given in the remainder

DIGITAL CONFIDENTIAL

Architectural Summary

2-3

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

of this specification are the full 32-bit addresses (which, of course, may have been generated from
a 30-bit program address via the mapping shown).
Table 2-1:

30-blt Mapping of Program Addresses to 32-blt Hardware Addresses

Program Address

Hardware Addr.ess

OOOOOOOO •. 1FFFFFFF

OOOOOOOO .. lFFFFFFF

20000000..3F'F'F'F'F'F'F'

EOOOOOOO.• FFFFFFFF

2.2.2.1

Physical Address Control Registers

During powerup, microcode configures the CPU to generate 30-bit physical addresses. Console
firmware may then reconfigure the CPU and optional vector unit to generate either 30-bit or
32-bit physical addresses by writing to the MODE bit in the PAMODE register. The PAMODE
register is shown in Figure 2-4.
Figure 2-4:

IPR E7 (hex), PAMODE

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 0

1 :PAMODE

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+~-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1

MODE --+

The PAMODE register also determines how PrEs are to be interpreted. In 30-bit mode, PrEs
are interpreted in 21-bit PFN format. In 32-bit mode, PrEs are interpreted in 25-bit PFN format
(although the two upper bits of the PFN field are ignored). The different PTE formats are
described in Section 2.6.4.
The PAMODE register is described in more detail in Chapter 12.

2.2.3

Registers

There are 16 32-bit General Purpose Registers (GPRs). The format is shown in Figure 2-5, and
the use of each GPR is shown in Table 2-2.

2-4 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 2-5: General Purpose Registers
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

I :Rn
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Table 2-2: General Purpose Register Usage

GPR

Use

Synonym

RO-RII

General Purpose

RI2

Argument Pointer

RI3

Frame Pointer

R14

Stack Pointer

R15

Program Counter

The Processor Status Longword (PSL) is a 32-bit register which contains processor state. The
PSL format is shown in Figure 2-6, and the fields of the PSL are shown in Table 2-3.
Figure 2-6:

Processor Status Longword Fields

31 30 29 28127 26 25 24123 22 21 20119 16 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--~-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

I I I IMBIFPI I CUR I PRV IMBI
ICMITPIVMIZ ID IISI MOD I MOD IZ I

IPL

MBZ

I I I I I I I I I
IDVIFUIIVI TI NI ZI VI CI :PSL

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Table 2-3:

Processor Status Longword

Name

Bit(s)

Description

Compatability Model

31
30

VIrtual Machine Model

FPD

First Part Done

Interrupt Stack

CUR_MOD

Trace Pending

25:24

Current Mode

PRV_MOD

23:22

Previous Mode

IPL

Interrupt Priority Level

20:16
7
6
5

Decimal Overfiow Trap Enable

Floating Underfiow Fault Enable
Integer Overfiow Trap Enable
Trace Trap Enable

1MBZ in CUlTent implementation

DIGITAL CONFIDENTIAL

Architectural Summary 2-5

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-3 (ConL):

Processor Status Longword

Name

Bit(s)

Description

Negative Condition Code

Zero Condition Code

Overfiow Condition Code

Carry Condition Code

Data Types

2.3

The l\TVAX CPU supports nine data types: byte, word, longword, quadword, character string,
variable length hit field, F_floating, D_floating, and G_floating. These are summarized in
Figure 2-7.
Figure 2-7:

Data Types

07 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+

Data Type: Byte
Length:
8 bits
Use:
Signed or unsigned integer
15 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I :A
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Data Type: Word
Length:
16 bits
Use:
Signed or unsigned integer
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I

I :A

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Data Type: Longword
Length:
32 bits
Use:
Signed or unsigned integer

Figure 2-7 Cont'd on next page

2-6 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 2-7 (Cont.):

Data Types

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

I :A

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

I :A+4

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Data Type: Quadword
Length:
64 bits
Use:
Signed integer
07 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+

:A
+--+--+--+--+--+--+--+--+
:A+l
+--+--+--+--+--+--+--~-+

+--~--+--+--+--+--+--+--+

:.A+len;r:.h - 1
Da~a

~y?e:

~n;~t.:

Use:

Ch~~acte~

S~=ing

0-64K by:.es
:Syce s~=ing

i///!///////I///////////I

1 :A

+--+--+--+--+--+--+--+--~--+--+--+--+--+--+--+--+--+--+--+--~--+--~-+--+--+--+--+--+--+--+--+--+

Data Type: Variable length bit field
Length:
0-32 bits
Use:
Bit string
15 14 13 12/11 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
lsi
exponent
fraction:A
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

fraction

:A+2

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
31 30 29 28127 26 25 24123 22 21 20/19 18 17 16

Data Type: F_floating
Length:
32 bits
Use:
Floating point
l5 14 13 1211l 10 09 08107 06 OS 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
lsi
exponent
I
fraetion
I :A
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-~+

fraction

1 :A+2

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

fraction

:A+4

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

fraction

1 :A+6

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
63 62 61 60159 58 57 56155 54 53 52151 50 49 48

Data Type: D_floating
Length:
64 bits
Use:
Floating point

Figure 2-7 Cont'd on next page

DIGITAL CONFIDENTIAL

Architectural Summary

2-7

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 2-7 (Cont.):

Data Types

15 14 13 ~21~1 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 sl
exponent
I fraetion
1 :A
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
fraction
1 :A+2
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
fraction
I :A+4
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
fraction
1 :A+6
+--+-----+-----+--+--+--+--+--+--+--+--+--+--+--+
63 62 61 60159 58 57 56155 54 53 52151 SO 49 4B

Data Type: G_floating
64 bits
Use:
Floating point

I.ength:

2.4 Instruction Formats and Addressing Modes
VAX instructions consist of a one- or two-byte opcode, followed by zero to six operand specifiers.

2.4.1

Opcode Formats

.An opcode may be either one or two contiguous bytes. The two-byte format begins with an FD

(hex) byte and is followed by a second opcode byte. The one-byte format is indicated by an opcode
byte whose value is anything other than FD (hex). The one- or two-byte opcode format is shown
in Figure 2-8.
Figure 2-8:

Opcode Formats
07 06 05 04103 02 01 00

One-byte opcocie:

+--+--+--+--+--+--+--+--+
1
opeocie
1 :A
+--+--+--+--+--+--+--+--+

Two-byte opcocie:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
opeocie
FD
I :A
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

15 14 13 12111 10 09 08107 06 05 04103 02 01 00

2.4.2

Addressing Modes

An operand specifier starts with a specifier byte and may be followed by a specifier extension.
Bits <3:0> of the specifier byte contain a GPR number and bits <7:4> of the specifier byte indicate
the addressing mode of the specifier. If the register number in the specifier byte does not contain
15, the addressing mode is a general register addressing mode. H the register number in the
specifier byte does contain 15, the addressing mode is a PC-relative addressing mode. The

2-8

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

different addressing modes are shown graphically in Figure 2-9. General register addressing
modes are listed in Table 2-4 and PC-relative addressing modes are listed in Table 2-5.
Figure 2-9:

Addressing Modes

General register
addressing mode:

07 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+
mode
1 register 1
+--+--+--+--+--+--+--+--+

PC-relative
addressing mode:

07 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+
mode
1 1 1 1 11
+--+--+--+--+--+--+--+--+

DIGITAL CONFIDENTIAL

Architectural Summary 2-9

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-4:

General Register Addressing Modes
Access

Mode

Name

Assembler

rmwav

IDdeDlble?

0-3

literal

S"#literal

yffff

index

i[Rx]

yyyyy

yyyfy

(Rn)

yyyyy

y
\IX

autodecrement

-eRn)

yyyyy

autoincrement

(Rn);.

yyyyy

\IX

autoincrement deferred

@(Rn)+

yyyyy

\IX

byte displacement

B"d(Rn)

yyyyy

byte displacement deferred

@B"d(Rn)

yyyyy

vvord displacement

W"d(Rn)

yyyyy

word
deferred

@W"'d(Rn)

yyyyy

lo~ord displaceIDent

L"d(Rn)

yyyyy

lo~ord

@L"'d(Rn)

yyyyy

displacement

deferred
.Access Types
r = read
m modify
w = write
a = address
v variable bit field

Syntax
i = any indexable address mode

=displacement

Rn =general register, n =0 to 15
Rx = general register, n = 0 to 14
Results
y = yes, always valid address mode
f reserved addressing mode fault
:r: logically impossible
p program counter acidressiDg
u = unpredictable
ud = unpredictable for clestination of CALLG, CALLS, JMP and JSB
uq = unpredictable for quad, D/G_lloating and field if po8+8ize > 32
u:r: = unpredictable if index register = base register

=
=
=

2-10

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-5:

PC-Relative Addressing Modes

Mode

Name

Assembler

rmwav

Indezable?

immediate

IA#constant

yuuyud

absolute

O#address

byte relative

BAaddress

byte relative deferred

@BAaddress

yyyyy
yyyyy
yyyyy
yyyyy

A
C

word relative

WAaddress

word relative deferred

@WAaddress

longword relative

LAaddress

longword relative defelTed

@LAaddress

yyyyy
yyyyy
yyyyy

y
y

y
y
y
y

For notation, refer to the key in Table 2-4

2.4.3

Branch Displacements

Branch instructions contain a one- or two-byte signed'branch displacement after the final specifier
(if any). The branch displacement is shown in Figure 2-10.
Figure 2-10:

Branch Displacements

Signed. byte
displacement:

07 06 05 04 10.3 02 01 00
+--+--+--+--+--+--+--+--+
displacement
+--+--+--+--+--+--+--+--+

Signed. word
displacement:

15 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
displacem&pt
I
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2.5 Instruction Set
The NVAX CPU supports the VAX Base Instruction Group as defined in DEC Standard 032.
These instructions are listed in Table 2-6.

DIGITAL CONFIDENTIAL

Architectural Summary 2-11

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6:
Opcode

NVAX Instruction Set
IDstructiOD

Exceptions

Integer, Arithmetic and Logical Instructions

ADAWI add.rw, sum.mw

iov

ADDB2 add.rb, sum.mb
ADDL2 add.rI, sum.ml

ADDW2 add.rw, sum.mw

*
*
*

iov

*
*
*

ADDB3 add1.rb, add2.rb, sum.wb

ADDLS addi.rI, add2.rI, sum.wI
ADDW3 add1.rw, add2.rw, sum.ww

*
*
*

iov

*
*
*

iov

ADWC add.rI, sum.m1

iov

ASHL cnt.rb, src.rI, dst. wI

*
*

iov

ASHQ cnt.rb, src.rq, dst.wq

*
*

iov

8A
OA

BIOB2 mask.rb, dst.mb
BICW2 mask-rw, dst.mw

*
*
*

0
0

*
*
*

8B
OB

BICB3 mask.rb, src.rb, dst. wb
BICW3 mask-rw, srC.TW, dst.ww

*
*
*

BISB2 mask.rb, dst.m.b

BISL2 mask.rI, dst.ml
BISW2 mask.rw, dst.mw

*
*
*

BISB3 mask.rb, src.rb, dst.wb
BISLS mask.rI, src.rI, dst.wI

BISW3 mask.rw, src.rw, dst. ww

*
*
*

BITB mask.rb, src.rb
BITL mask.rI, src.rl

BITW mask.rw, src.TW

*
*
*

BICL2 mask.rI, dst.m1

BICL3 mask.rI, src.rI, dst. wI

2-12 Architectural Summary

iov
iov

iov

0
0

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructioD

EltceptiODS

Integer, Arithmetic and LogicallDstructioDS

CLRB dst.wb

CLRL{::F} dst.wI

CLRQ{=D::G} dst.wq

CLRWdst.ww

CMPB src1.rb, src2.rb

CMPL srel.rl, src2.rI

CMPW sre1.rw, sre2.rw

*
*
*

CVTBL sre.rb, dst.wI

CVTBW sre.rb, dst.ww
CVTLB sre.rl, dst.wb

CVTLW src.rl, dst.ww

CVTWB sre.rw, dst.wb

CVTWL Srt.rw, dst.wI

DECB dif.mb

DECL dif.m1

DECW dif.mw

DIVB2 divr.rb, quo.mb

DIVL2 elivr.rl, quo.ml

DIVW2 divr.rw, quo.mw

DIVB3 divr.rb, divcLrb, quo.wb

DIVL3 divr.rl, divd.rl, quo.wI

II<

iov

II<

iov

II<

iov

II<

*
*
*

II<

iov

II<

iov

II<

iov

*
*
*

II<

iov, idvz

II<

iov, idvz

II<

iov, idvz

*
*
*

II<

iov, idvz

II<

iov, idvz
iov, idvz

*
*
*
*
*
*

DIVW3 divr.rw, divd.rw, quo.ww

*
*
*

EDIV divr.rI, divcLrq, quo.wl, rem.wI

II<

EMUL mulr.rl, muld.rl, add.rl, prod.wq

INCB sum.mb

II<

INCLsum.m1

*
*

II<

*
*

DIGITAL CONFIDENTIAL

iov
iov

Architectural Summary 2-13

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstractiOD

ExceptioDS

iov

*
*

iov

*
*

iov

Integer, Arithmetic and Logical InstructiOD&
B6

INCWsum.mw

MOOMB src.rb, dst.wb

MOOML src.rI, dst.wl

MOOMW src.rw, dst. ww

*
*

*
*
*

M'NEGB src.rb, dst.wb

MNEGL src.rI, dst.wI

MNEGW src.rw, dst. ww

*
*
*

MOVB sre.rb, dst. wb

MOVL sre.rI, dst.wl

MOVQ sre.rq, dst.wq

MOv\v srC.rw, dst.ww

*
*

MOVZBW sre.rb, dst.wb

MOVZBL sre.rb, dst.wl

MOVZWL sre.rw, dst.wI

*
*
*

MULB2 mulr.rb, prod.mb

MULL2 mulr.rl, prod.m1

MULW2 mulr.rw, prod.mw

*
*
*

MULB3 mulr.rb, muld.rb, prod.wb

*
*

*
*
*

*
*
*
*
*

0
0

iov

0
0
0
0
0
0
0

MULL3 mulr.rI, muld.rI, prod.wI

MULW3 mulr.rw, muld.rw, prod.ww

*
*
*

PUSHL src.rI, {-(SP).wI}

ROTL cnt.rb, src.rl, dst.wl

SBWO sub.rI, dif.m1

iov

SUBB2 sub.rb, dif.m.b

iov

2-14

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0. February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructiOD.

Exceptions

*
*

iov

*
*
*

*
*
*
*

Integer, Arithmetic and LogicallDstructioDS
C2

SUBL2 sub.rI, di£m1

A2.

SUBW2 sub.rw, dif.mw

SUBB3 sub.rb, min.rb, dif.wb

SUBL3 sub.rI, min.rI, dif.wI

SUBW3 sub.rw, min.rw, dif.ww

TSTB sre.rb

TSTL sre.rl

TSTW srC.rw

XORB2 mask.rb, dst.mb

XORL2 mask.rI, dst.m1

XORW2 mask.rw, dst.mw

XORB3 mask.rb, src.rb, cist.wb

XORL3 mask.rI, src.rI, dst.wl

XORW3 mask.rw, src.rw, dst. ww

iov
iov
iov
iov

0
0

Address IDstructioDS
9E

MOVAB src.ab, cist. wI

MOVAL{=F} arc.al, dst.wI

7E
3E

MOVAQ{=D::G} src.aq, dst. wI

PUSHAB src.ab, {-(SP).wl}

PUSHALt=F} ere.al, {-(SP).wI}

PUSHAQ{=D=G} arc.aq, {-(SP).wI}

PUSHAW src.aw, {-(SP).wl)

MOVAW src.aw, dst.wI

0
0
0

Variable-LeDgth Bit Field IDstructioDS
EC

CMPV pos.rI, size.rb, base.vb, {field.rv}, sre.rl

rav

CMPZV pos.rI, size.rb, base.vb, {field.rv}, src.rI

rav

DIGITAL CONFIDENTIAL

Architectural Summary 2-15

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructiOD

Exceptions

Variable-Length Bit Field IDstructions

EXTV pos.rl, size.rb, base.vb, ffield.rv}, dst.wl

rsv

EXTZV pos.rl, size.rb, base.vb, {field.rv}, dst.wl

rsv

INSV src.rl, pos.rl, size.rb, base. vb, {field.wv}

FFC startpos.rl, size.rb, base. vb , {field.rv} ,
findpos.wl
FFS startpos.rl, size.rb, base.vb, {field.rv} ,
findpos.wl

rsv
0

rsv

*
*
*

*
*

Control InstructiODS

ACBB limit.rb, add.rb, index.mb, displ.bw

ACBL limit.rl, add.rl, index.mI, clispl.bw

ACBW limit.rw, add.rw, index.mw, disp1.bw

AOBLEQ limit.rl, index.ml, disp1.bb

AOBLSS limit.rl, index.mI, displ.bb

BCC{=BGEQU} disp1.bb

BCS{=BLSSU} displ.bb

BEQL{=BEQLU} displ.bb

BGEQ clisp1.bb

BGTR displ.bb

iov
iov
iov
iov
iov

BGTRU disp1.bb

BLEQ displ.bb

BLEQU d,ispLbb

BLSS displ.bb

BNEQI=BNEQU} displ.bb

BVC displ.bb

BVS dispLbb

BBC pos.rl, base.vb, clisp1.bb, {field.rv}

rsv

BBS pos.rl, base.vb, displ.bb, {neld.rv}

rsv

2-16

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0. February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set
N

IDstruction

E%ceptiODS

Control InstructioDS

BBCC pos.rI, base.vb, displ.bb, ffield.mv}

rsv

BBCS pos.rI, base.vb, dispI.bb, ffield.mv}

rsv

BBSC pos.rI, base.vb, displ.bb, ffield.mv}

rsv

BBSS pos.rI, base.vb, dispI.bb, ffield.mv}

rsv

BBCCI pos.rI, base.vb, displ.bb, ffieId.mv}

rsv

BBSSI pos.rI, base.vb, displ.bb, {field.mv}

rsv

E9
ES

BLBC src.rI, disp1.bb
BLBS src.r1, disp1.bb

BRB disp1.bb

BRW displ.bw

BSBB disp1.bb, {-(SP).wl}

BSBW disp1.bw, {-(SP).wl}

CASEB
selector.rb,
displ.bw-list

base.rb,

limit.rb,

CASEL
selector.rI,
displ.bw-list

base.rI,

limit.rI,

lie

CASEW selector.rw,
displ.bw-list

base.rw,

limit.rw,

lie

JMP dst.ab

JSB dst.ab, {-(SP).wl}

RSB {(SP)+.rl}

SOBGEQ index.ml, disp1.bb

lie

iov

SOBGTR index.ml, displ.bb

*
*

lie

iov

DIGITAL CONFIDENTIAL

Architectural Summary 2-17

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructiOD

Exceptions

Procedure Call1DstructiODS

CALLG arglist.ab, dst.ab, {-(SP).w*)

rev

CALLS numarg.rl, dst.ab, {-(SP).w*}

rev

RET {(SP)+.r*)

rev

*
*

rev
rsv

Miscellaneous IDstructions
B9

BICPSW mask.rw

BISPSW mask.rw

*
*

BPI' (·<KSP). w*}

HALT f·<KSP).w*}

INDEX subscript.rl, low.r!, bigh.rl, size.rl,
indexin.rl, indexout.wI

MOVPSL dst.wI

NOP

POPR mask.rw, {(SP)+.r*}

PUSHR mask.rw, {-(SP). w*}

XFC {unspecified operands}

PrY

*
*

*
*
*

sub

Queue IDstructiODS
5C

INSQHI entry.ab, header.aq

5D
OE

INSQTI entry.ab, header.aq

INSQUE entry.ab, pred.ab

5E
5F
OF

REMQHI header.aq, addr. wI

REMQTI header.aq, addr. wI

REMQUE entry.ab, addr.wl

*
*

*
*
*

2-18

Architectural Summary

rsv
rsv

rsv
rev

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructiOD

hceptioDS

Operating System Support IDstructiODS
BD

OHME param.rw, {...(ySP).w*}

OHM!{ param.rw, {-(ySP).w*}

OHMS param.rw, {-(ySP).w*}

OHMU param.rw, {-(ySP).w*}

LDPOTX fPOB.r*, -<KSP).w*}

MFPR procreg.rl, dst. wI

rsy, prv

*
*

rsy, prv

MTPR src.rl, procreg.rI

*
*

rsy, prv

PROBER mode.rb, len.rw, base.ab

PROBEW mode.rb, Ien.rw, base.ab

*
*

OD
02

REI {(SP)+.r*}

oj<

SVPCTX {(SP)+.r*, POB.w*}

rsy
prv

Character StriDg IDstractioDB

OMPCS len.rw, srcladdr.ab, src2addr.ab

OMP05
srcllen.rw,
:fill.rb,src21en.rw, src2addr.ab

LOOO char.rb, len.rw, addr.ab

MOVOS Ien.rw,
{R0-5.wl}

dstaddr.ab,

MOV05 srclen.rw, srcaddr.ab, fill.rb, dstlen.rw,
dstaddr.ab,{R0-5.wl}

SOANO len.rw, addr.ab, tbladdr.ab, mask.rb

DIGITAL CONFIDENTIAL

srcaddr.ab,

srcladdr.ab,

Architectural Summary 2-19

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructiOD

ExceptioDS

Character StriDg InstructiODS

SKPC ehar.rb, len.rw, addr.ab

SPANC len.rw, addr.ab, tbladdr.ab, mask.rb

*
*
*

0
0

rav, fov, fuv

0
0

rav, fov, fuv

*
*
*

rsv, fov,fuv

rav, fov, fuv

rsv, fov, fuv

*
*
*

rav

*
*
*
*
*
*
*
*
*
*
*
*
*
*

rav, iov

rav, fov

*
*
*

rav, iov

rsv

*
*
*

rsv
rsv, iov

rav, iov

rsv,fov,fuv

rsv, iov

Floating Point IDstructiODS

ADDD2 add.rd, sum.md

ADDF2 add.rf, sum.mf

40FD

ADDG2 add.rg t sum.mg

ADDD3 addl.rd, add2.rd t sum.wd

4lFD

ADDF3 add1.ri', add.2.ri't sum.wf
ADDG3 addl.rg, add2.rg, sum. wg

CMPD srcl.rd, src2.rd

51
51FD

CMPF srel.n, sre2.rf
CMPG srel.rg, src2.rg

CVTBD sre.rb, dst.wd

33FD

CVTGF sre.rg, dst.wf

*
*
*
*
*
*
*
*
*
*
*
*
*
*

4A.FD

CVTGL arc.rg, dst.wl

4C
4CFD
68
76

CVTBF sre.rb, dst.wf
CVTBG sre.rb, dst.wg
CVTDB sre.rd, dst.wb
CVTDF sre.rd, dst.wf

CVTDL arc.rd, dst.wl

69
48

CVTDW src.rd, dst.ww
CVTFB src.n, dst. wb

CVTFD sre.n, dst.wd

99FD

CVTFG src.n, dst. wg

CVTFL src.n, dst. wI

CVTFW sre.n, dst.ww

48FD

CVTGB sre.rg, dst.wb

2-20 Architectural Summary

rav, fov, fuv

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstructiOIl

*
*
*
*
*
*
*
*
*
*

*
*
*

ExCeptioDS

rsv, iov

Floating Point IDstructiODB

49FD

CVTGW src.rg, dst.ww

CVTLD sre.rI, dst.wd

CVTLF src.rI, dst.wf

4EFD

CVTLG sre.rI, dst.wg

CVTWD src.rw, dst.wd

CVTWF src.rw, dst. wf

4DFD

CVTWG src.rw, dst.wg

CVTRDL sre.rd, dst.wI

CVTRFL sre.rf, dst. wI

4BFD

CVTRGL sre.rg, dst.wI

DIVD2 divr.rd, quo.md

DIVF2 divr.rf, quo.mf

46FD

DIVG2 divr.rg, quo.mg

DIVD3 divr.rd, divd.rd, quo.wd

DIVF3 divr.rf, divd.rf, quo.wf

47FD

DIVG3 divr.rg, divd.rg, quo.wg

MNEGD arc.rd., dst.wd

MNEGF src.rf, dst. wf

52FD

MNEGG sre.rg, dst.wg

MOVD src.rd., dst.wd

*
*
*

rsv, iov

*
*
*

rsv, fov, fuv, fdvz

*
*
*

rsv, fov, fuv, fdvz

*
*
*
*
*

*
*
*
*
*
*

rsv

*
*
*

MOVF src.rf, dst.wf

50FD

MOVG src.rg, dst.wg

lie

MULD2 mulr.rd, prod.md

lie

MULF2 .mulr.rf, prod.mf

44FD

MULG2 mulr.rg, prod.mg

lie

MULD3 mulr.rd, muld.rd, prod.wd

lie

MULF3 mulr.rf, muld.rf, prod.wf

45FD

MULG3 mulr.rg, muld.rg, prod.wg

DIGITAL CONFIDENTIAL

rsv

rsv
0

rsv,fov, fuv

rsv, fov, fuv

rsv,fov,fuv

rsv, fov, fuv

*
*

rsv, fov, fuv

lie

rsv, fov, fuv

Architectural Summary 2-21

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Exceptions

*
*
*

rsv,fov,fuv

rsv, fov, fuv

*
*
*

rsv, fov, fuv

*
*
*

rsv

sumlen.rw,

rsv, dov

ADDP6 addllen.rw, add1addr.ab, add21en.rw,

rsv,dov

IDstructiOD

Floating Point IDstructioDS
62

SUBD2 sub.rd, dif.md

SUBF2 sub.rf, dif.mf

42FD

SUBG2 sub.rg, dif.mg

SUBD3 sub.rd, min.rd, dif.wd

SUBF3 sub.rf, min.rf, dif.wf

43FD

SUBG3 sub.rg, min.rg, dif.wg

TSTD sre.rd

TSTF sre.rf

53FD

TSTGsrc.rg

Microcode-Assisted Emulated IDstructiODS
20

ADDP4 addlen.rw,

addaddr.ab,

sumaddr.ab
21

add2addr.ab, suaUen.rw, suznaddr.ab
F8

ASHP cnt.rb, srclen.rw, srcaddr.ab, round.rb,
dstlen.rw, dstaddr.ab

CMPP3 len.rw, srcladdr.ab, src2addr.ab

*
*

CMPP4 srellen.rw, srcladdr.ab, src21en.rw,
src2addr.ab

CRC tbl.ab, inierc.rI, strlen.rw, stream.ab

CVTLP src.rI, dstlen.rw, dstaddr.ab

*
*

rsv,dov

CVTPL srcien.TW, srcaddr.ab, dst.wI

*
*

rsv, iov

CVTPS

srelen.rw,
dstaddr.ab

srcaddr.ab,

dstlen.rw,

rsv, dov

CVTSP

srclen.rw,
dstaddr.ab

srcaddr.ab,

dstlen.rw,

rsv,dov

2-22 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

IDstrDctiOD

kceptions

Microcode-Assisted Emulated Instructions

CVTPl' srclen.rw, srcaddr.ab,
dstlen.rw, dstaddr.ab

tbladdr.ab,

rsv, dov

CVTTP srclen.rw, srcaddr.ab,
dstlen.rw, dstaddr.ab

tbladdr.ab,

rsv, dov

DIVP divrlen.rw, divraddr.ab, divdlen.rw,
divdaddr.ab, quolen.rw, quoaddr.ab

rsv, dov, ddvz

EDITPC srclen.rw, srcaddr.ab,

pattern.ab,

rsv, dov

srclen.rw,

dstaddr.ab
39

:MA.TCHC objlen.rw,
srcaddr.ab

:MO'V"P len.rw, srcaddr.ab, dstaddr.ab

MOVTC
srclen.rw,
srcaddr.ab,
tbladdr.ab, dstlen.rw, dstaddr.ab

fill.rb,

MOVTUC srclen.rw, srcaddr.ab,
tbladdr.ab, dstlen.rw, dstaddr.ab

esc.rb,

MULP mulrlen.rw, mulraddr.ab, muldlen.rw,
muldaddr.ab, prodlen.rw, prodaddr.ab

rsv, dov

SUBP4 sublen.rw,
difaddr.ab

subaddr.ab,

diflen.rw,

rsv, dov

SUBPG sublen.rw, subaddr.ab,
mjnaddr ab diflen]=WI difaddr ab

minlen.rw,

rsv, dov

DIGITAL CONFIDENTIAL

objaddr.ab,

Architectural Summary 2-23

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-6 (Cont.):

NVAX Instruction Set

The notation used for operand specifiers is <DBme>.<access type><data type>. Implied operands (those locations that are
referenced by the instruction but not specified by an operand) are denoted by curly braces n.

Access Type

a address operand
b branch displacement
m = modi1ied operand (both read and written)
r = read only operand
v if not "Rn", same as a, otherwise R[n+l]'R[n]
w write only operand

=
=

Data Type

b byte
d = D_fioating
f = F_floating
g G_fioating
1 = longword
q = quadword
v = neld (used only in implied operands)
w word
multiple longwords (used only in implied operands)

=
'" =

Condition Codes Modification

'" = conditionally set/cleared

- =not affected
0= cleared
1 = set

EzceptiODS

=
=

rsv reserved operand fault
iov = integer overflow trap
idvz integer divide by zero trap
fov = fioating overflow fault
fuv = floating under:fiow fault
fdvz floating divide by zero fault
dov = decimal over1low trap
ddvz decimal divide by zero trap
sub = subscript range trap
prv privileged instruction fault
vec = vector unit disabled fault

=
=
=

2-24

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

2.6 Memory Management
The NVAX CPU Chip supports a four gigabyte (2**32) virtual address space, divided into two
sections, system space and process space. Process space is further subdivided into the PO region
and the PI region.

2.6.1

Memory Management Control Registers

Memory management is controlled by three processor registers: Memory Management Enable
(MAPEN), Translation Buffer Invalidate Single (TBIS), and Translation Buffer Invalidate All
(TBlA).
Bit <0> of the MAPEN register enables memory management if written with a 1 and disables
memory management if written with a O. The MAPEN register is shown in Figure 2-11.
Figure 2-11:

IPR 38 (hex), MAPEN

The TBIS register controls translation buffer invalidation. Writing a virtual address into TBIS
invalidates any entry which maps that virtual address. The TBIS format is shown in Figure 2-12.

Figure 2-12:

IPR 3A (hex), TBIS

The TBIA register also controls translation buffer invalidation. Writing a zero into TBIA
invalidates the entire translation buffer. The TBIA format is shown in Figure 2-13.

DIGITAL CONFIDENTIAL

Architectural Summary

2-25

NVAX CPU Chip Functional Specification, Revision 1.lt August 1991

Figure 2-13:

IPR 39 (hex), TBIA

2.6.2

System Space Address Translation

A virtual address with bit <31> = 1 is an address in the system virtual address space.
System virtual address space is mapped by the System Page Table (SPT), which is defined by
the System Base Register (SBR) and the System Length Register (SLR). The SBR contains the
page-aligned physical address of the the System Page Table. The SLR contains the size of the
SPT in longwords, that is, the number of Page Table Entries. The Page Table Entry addressed
by the System Base Register maps the :first page of system virtual address space, that is, virtual
byte address 80000000 (hex). These registers are shown in Figure 2-14.
With a 22-bit SLR width, 222 - 1 pages in system space may be addressed. As a result, the last
page of system space (beginning at virtual address FFFFFEOO (hex» is not addressable. As a
result, this page is reserved and a reference to any address in that page will result in a length
violation.
NOTE

NVAX CPU chips at revision 1 implement the original VAX memory management
architecture in which any reference to a virtual address above BFFFFFFF (hex) causes
a length violation. NVAX CPU chips at revision 2 or later implement the extended SO
space addressing described above.
NOTE

When the CPU is configured to generate SO-bit physical addresses, SBR<SI:S0> are
ignored.

2-26

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-14:

IPR OC (hex), SBR and IPR OD (hex), SLR

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Physical Page Address of SPT
I 0 0 0 0 0 0 0 0 01 :SBR
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I 0 0 0 0 0 0 0 0 0 01
Length of SPT in Longwords
1 :SLR
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The system space translation algorithm is shown graphically in Figure 2-15.

DIGITAL CONFIDENTIAL

Architectural Summary 2-27

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-15: System Space Translation Algorithm
3 3
1 0

9 8

+-+---------------------+-------+
111 virtual page number I byte I
+-+---------------------+-------+
I
1\
\

system-space
virtual address:

3
1

I
I
212
413

extract VPN,
check length,
and add

I \
1 \
1
\
211 0 \

\
\
\

+------+---------------------+---+
\
1 physical address of SPT base 1 \
+--------------------------------+
I
1 sign-extend PA<29> to PA<31:30>1
I

SBR:

I
01

1
1

yields

\
I
1
1

1 if in 30-bit mode
13
11

+--------------------------------+
physical address of SPTE
+--------------------------------+

I
I

I
1

fetch

3
:2 2
1
1 3 2 0 1

+------+-------------------------+
page frame number
+------+-------------------------+
1 check access in current I

SPTE:

1
I
I
I
1
1
1

I
I mode,
I sign-extend PTE<:20> to 1
1 I?TE<22:21> if in 30-bit 1
I mode
1
13
11

physical address:

2.6.3

merge

1
1

I /
91/8

+-------------------------+-------+
1
page frame number
1 byte I
+-------------------------+-------+

Process Space Address Translation

A virtual address with hit <31> = 0 is an address in the process virtual address space. Process
space is divided into two equal sized, separately mapped regions. Ifvirtual address bit <30> = 0,
the address is in region PO. If virtual address bit <30> = 1, the address is in region PI.
2.6.3.1

PO Region Address Translation

The PO region of the address space is mapped by the PO Page Table (POPT), which is defined by
the PO Base Register (POBR) and the PO Length Register (POLR). The POBR contains the system
page-aligned virtual address of the PO Page Table. The POLR contains the size of the POPT in
longwords, that is, the number of Page Table Entries. The Page Table Entry addressed by the PO
Base Register maps the first page of the PO region of the virtual address space, that is, virtual
byte address O. The PO base and length registers are shown in Figure 2-16.

2-28

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

The PO space translation algorithm is shown graphically in Figure 2-17.
Figure 2-16: IPR 08 (hex), POBR and IPR 09 (hex), POLR
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 01
System Virtual Page Address of POPT
I 0 0 0 0 0 0 0 0 01 : POBR
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I 0 0 0 0 0 0 0 0 0 01
Length of POPT in Longwords
1 :POLR
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2-17:

PO Space Translation Algorithm
332
109

9 8

+---+-------------------+-------+
I 0 I virtual page number I byte I
+---+-------------------+-------+

process-space
virtual address:

I
I
I
212
312

3
1

extract VPN,
check length,
and add

1\
I \
I \
1

\
\
\

211 0 \

+-------+-------------------+---+ \
virtual address of POPT base
\
+-------------------------------+ I

POBR:

yields

13 3 2
11 0 9

virtual address
of POPTE:

9 8

1
01

I
I
I
I

I
I
I
I
I
I
I
I

+---+---------------------------+
I
Ivirtual pagQ number I byte
+---+---------------------------+
fetch using system-space translation
algorithm, including length check,
but without access check
3

2 2

3 2

+------+-------------------------+
I
I
page frame number
1
+------+-------------------------+
check access in current

POPTE:

I mode,
I
I sign-extend PTE<20> to 1
I PTE<22:21> if in 30-bit 1
I mode
1
I
merge
1
/
13
1 /
11
91/8

physical address:

2.6.3.2

I
I
I
I
I
I
I

I
/

0 /

+-------------------------+-------+
I
page frame number
1 byte I
+-------------------------+-------+

P1 Region Address Translation

The PI region of the address space is mapped by the PI Page Table (PIPT), which is defined by the
PI Base Register (PIBR) and the PI Length Register (PILR). Because PI space grows towards
smaller addresses, and because a consistent hardware interpretation of the base and length
registers is desirable, PIBR and PILR describe the portion of PI space that is NOT accessible.
DIGITAL CONFIDENTIAL

Architectural Summary 2-29

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Note that PILR contains the number of nonexistent PTEs. PIBR contains the page-aligned
virtual address of what would be the PTE for the first page of PI, that is, virtual byte address
40000000 (hex). The address in PIBR is not necessarily an address in system space,but all the
addresses of PTEs must be in system space.
The PI space translation algorithm is shown graphically in Figure 2-19.
Figure 2-18:

IPR OA (hex), P1BR and IPR OB (hex), P1 LR

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I

Virtual Page Address of P1PT

I 0

: P1BR

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I 0 0 0 0 0 0 0 0 0 01
(2 ** 21) - Length of P1PT in Longwords
I :P1LR
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figure 2-19:

P1 Space Translation Algorithm
332
109

9 8

+---+-------------------+-------+

process-space
virtual address:

I 0 Ivirtua1 page number I

byte I

+---+-------------------+-------+
I
I
I
212
312

3
1

extract VPN,
check length,
and add

1\
I \
I \
I
\
211 0 \

\
\
\
\
\

+-------+-------------------+---+ \
I virtual address of P1PT base

P1BR:

\
\

+-------------------------------+

I
I
I

I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

I
I
I

yields

13 3 2
11 0 9

9 8

I
01

+---+---------------------------+

virtual address
of P1PTE:

I virtual page nwnber I byte

+---+---------------------------+
fetch using system-space translation
algorithm, including length check,
but without access check
3

2 2

3 2

+------+-------------------------+
P1PTE:

page frame number

+------+-------------------------+

I
I check access in current
I
I mode,
I
I sign-extend PTE<20> to
I
I PTE<22:21> if in 30-bit
I
I
I mode
I
merge
/
13
I /
11
91/8

physical address:

/
/
0 /

+-------------------------+-------+
I
page frame number
I byte I

+-------------------------+-------+

2-30

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0t February 1991

2.6.4 Page Table Entry
If the CPU is configured to generate 30-bit physical addresses, it interprets PTEs in the 21-bit
PFN format shown in Figure 2-20. Conversely, if the CPU is configured to generate 32-bit
physical addresses, it interprets PTEs in the 25-bit PFN format shown in Figure 2-21. Note that
bits <24:23> of the 25-bitPFN format are ignored by the NVAX CPU chip, which implements only
32-bit physical addresses. The PTE formats shown below are described both in DEC Standard
032, and in Chapter l2.
Figure 2-20:

PTE Format (21-bH PFN)

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
.--+--+--+--+--+--+--+--~--+--+--+--+--+--+--+--+--+--.--+--+--+--+--+--+--+--+--+--+--+--+--+--+

PROT

1 M1 Z \ OWN 1 SIS I

Page Frame NUltIber

, :PTE

+--*--+--+--+--+--+--+--+--+--+--+--+--+--+--+--.--+--+--+--+--+--+--+--~-+--+--+--+--+--+--+--+

Figure 2-21 :

PTE Format (25-blt PFN)

31 30 29 26i27 26 25 24[23 22 21 20119 18 1~ 16[15 l ' 13 12\11 10 09 0610' 06 C! 0'103 02 0: 00
------------~--------~--+--------~--+--+_----~--~-----~--~--+--T--~--·-----------~-----------~--+
:?O':'

I Yo i SiS IS:

---------~--------~--------~-----~-------+-----------~-----------------------------~--~---------

DIGITAL CONFIDENTIAL

Architectural Summary 2-31

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-7:

PTE Protection Code Access Matrix

Code

C1Ift"eIlt Mode

Decimal Binary

Mnemonic

0
1

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

3
4

5
6

7
8
9

10
11
12
13
14
15

no access
unpredictable

SR.A~

RW
RW
RW
R
RW
RW
RW

URSW

URKW

RW
RW
RW

ERKW
ER
SW
SREW

UREW

Comment

RW
RW
R
R
RW
RW
R
R
RW
RW

reserved

all access

RW
R

R
R

RW
R

R
R

Access Modes

K = Kernel
E = Executive
S = Supervisor
U=User
Access 'l'ypes

R=Read
W= Write
- = No access

2.6.5 Translation Buffer
In order to save actual memory references when repeatedly referencing pages, the NVAX CPU
Chip uses a translation buffer to remember successful virtual address translations and page
status. The translation buffer contains 96 fully associative entries. Both system and process
references share these entries.
Translation buffer entries are replaced using a not-last-used (NLU) algorithm.. This algorithm
guarantees that the replacement pointer is not pointing at the last translation buffer entry to be
used. This is accomplished by rotating the replacement pointer to the next sequential translation
buffer entry if it is pointing to an entry that has just been accessed. Both D-stream and I-stream
references can cause the NLU to cycle. When the translation buffer does not contain a reference's
virtual address and page status, the machine updates the translation buffer by replacing the
entry that is selected by the replacement pointer.
2-32

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

2.7 . Exceptions and Interrupts
At certain times during the operation of a system, events within the system require the execution
of software routines outside the explicit How of control of instruction execution. An exception is
an event that is relevant primarily to the currently executing process and normally invokes a
software routine in the context of the CUtTent process. .An interrupt is an event which is usually
due to some activity outside the current process and invokes a software routine outside the context
of the current process.
Exceptions and interrupts are reported by constructing a frame on the stack and then dispatching
to the service routine through an event-specific vector in the System Control Block (8CB). The
minimum stack frame for any interrupt or exception is a PCIPSL pair as shown in Figure 2-22.
Figure 2-22: Minimum Exception Stack Frame
3: 30

:8\27 26 25

:~:23

22 21 20/19 18 :- :6,:5

13 ::,:: 10

08107 06 05 04103 02 01 00

------~--------------------~--------------------------------------------------------------+--~--.
\

: (SP)

------~-----~-----~-----------~--.--~--~--------------------------+--+--~----.--+--~--~--~-----+

------------------------------+--~--------------------+-----~--------------~--+--~-----~--------.

This minimum stack frame is used for all interrupts. Certain exceptions expand the stack frame
by pushing additional parameters on the stack above the PCIP~L pair as shown in Figure 2-23.
Figure 2-23: General Exception Stack Frame
31 30

28127 26 25 24123 22 21 20119 18 17 16/15 14 13 l2111 10

08/07 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Parameter n
I : (SP)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Parameter 1
I
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\
PC
I
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/

PSI.

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

What parameters, if any, are pushed on the stack above the PCIPSL pair is a function of the
specific exception being reported.

2.7.1

Interrupts

DEC Standard 032 defines 31 interrupt priority levels, a subset of which is implemented by
the NVAX CPU. When an interrupt request is generated, the hardware compares the request
with the current IPL of the CPU. If the new request is of higher priority an internal request is
generated. At the completion of the current instruction (or at selected points during the execution
of interruptible instructions), a microcode interrupt handler is invoked to process the request.
With hardware assistance, the microcode handler determines the highest priority interrupt,

DIGITAL CONFIDENTIAL

Architectural Summary 2-33

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

updates the IPL, pushes a PCIPSL pair on the stack, and dispatches to a macrocode interrupt
handler through the appropriate location in the SCB.
Of the 31 interrupt priority levels defined by DEC Standard 032, the NVAX CPU makes use of
24 of them, as shown in Table 2-8.
Table 2-8:

Interrupt Priority Levels

lPL (hex)

IPL (decimal)

Interrupt Condition

IF
IE
ID

BALT_L asserted (non maskable)

PWRFL_L asserted

B_ERR_L asserted (or internal hard elTOt' detected)

Unused

Performance
microcode)

S_ERR_L asserted (or internal soft error detected)

18-19
17
16
15
14
10-13

24-25

Unused

m(LL<3> asserted
m(LL<2> or I!\'"T_TlM_L asserted <mQ..L<2> takes priority)
mQ..L<l> asserted
mQ..L<o> asserted

16-19

Unused

01-15

SofWrare interrupt asserted

01-OF

monitoring intelTUpt

(internally

handled

Interrupts are discussed in more detail in Chapter 10.
2.7.1.1

Interrupt Control Registers

The interrupt system is controlled by three processor registers: the Interrupt Priority Level
Register (IPL), the Software Interrupt Request Register (SIRR), and the Software Interrupt
Summary Register (SISR).
A new interrupt priority level may be loaded into PSL<20:16> by writing the new value to
IPL<4:0>. The IPL register is shown in Figure ~24.

2-34

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-24:

IPR 12 (hex), IPL

A software interrupt may be requested by writing the desired level to 8IRR<3:0>. The 81RR
register is shown in Figure 2-25.
Figure 2-25:

IPR 14 (hex), SIRR

The 818R register records pending software interrupt requests at levels 01 through OF (hex). The
818R register is shown in Figure 2-26.
Figure 2-26:

IPR 15 (hex), SISR

2.7.2 Exceptions
The VAX architecture recognizes six classes of exceptions. Table 2-9 lists instances of exceptions
in each class.
Table 2-9:

Exception Classes

Exception Class

Instances

Arithmetic trapslfaults

Integer over1low trap
Integer divide-by-zero trap
Subscript range trap
Floating overfiow fault
Floating divide-by-zero fault
Floating underfiow fault

DIGITAL CONFIDENTIAL

Architectural Summary 2-35

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Table 2-9 (Cont.):

Exception Classes

Exception Class

Instances

Memory management exceptions

Access control violation fault
Translation not valid fault
M::O 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

Kemel-stack-not-valid abort
IntelTUpt-stack-not-valid halt
Console error halt
Machine check abort

A trap is an exception that occurs 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 and that leaves the registers and memory
in a consistent state such 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 such 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 which are unique to the NVAX CPU, or
where DEC Standard 032 is not clear about the implementation.
2.7.2.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 2-27. Table 2-10 lists the exceptions reported by
this mechanism.

2-36

Architectural Summary

DIGITAL CONFIDENTlAL

NVAX CPU Chip Functional Specification, Revision 1.2, December 1991

Figure 2-27: Arithmetic Exception Stack Frame
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 OS 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Type Code

1 : (SP)

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
PC

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
PSL

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Table 2-10:

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

2.7.2.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 2-11. All three exceptions
push the same frame on the stack, as shown in Figure 2-28. The top longword of the stack frame
contains a fault parameter whose bits are described in Table 2-12.
Table 2-11: Memory Management Exceptions
SCB Vector

Exception

20 (hex)

Access control violation

24 (hex)

Translation not valid

30 (hex)

Modify fault

DIGITAL CONFIDENTIAL

Architectural Summary 2-37

NVAX CPU Chip Functional Specification, Revision 1.2, December 1991

Figure 2-28: Memory Management Exception Stack Frame
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 01 MI PI LI : (SP)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1
Some Virtual Address in the Faulting Page
1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
PSL
1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Table 2-12: Memory Management Exception Fault Parameter
Bit

Mnemonic

Meaning

Length violation

L
p

Modify or write intent

2.7.2.3

PTE reference

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>=O at the beginning of the instruction, the exception is reported through 8CB vector
C8 (hex) as a trap with the stack frame shown in Figure 2-29. The longwords in the stack frame
are described in Table 2-13.

2-38 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 2-29:

Instruction Emulation Trap Stack Frame

31 30 29 28127 26 25 24123 22 21 20119 18 l7 l61l5 14 13 l211l lO 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Opcocie

1 : (SP)

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Old PC
1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Specifier n
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Specifier f2
.--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Specifier .3
.--+--+--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Specifier .4
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Specifier f 5
---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--~--+--+

Specifier +6
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-_._----+--+--+--+--+--+--+--+--+--+--+--+--+--+
SpeCifier f.' 7
---+--+--~--+--~--~--~-+--~-----~--+--+--+--+--+-----+-----+--+--.--T--~--+--~--~--+--+--+--+--+
Speci!ier .8

PC
---.--T-----------~--~--~--+--~--+--+-----~--~--------~-----~----~--+--~--~--+--~--+--T--+-----~
---+--~--~--+--+--~--+--~--+--~--~--~--.--~--~--~--------------~--~--+--~--------~-~--~--+------

Table 2-13:

Instruction Emulation Trap Stack Frame

Location

Use

Opcode

Zero-extended opcode of the emulated instruction

Old PC

PC of the opcode of the emulated instru.ction

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 don't have 8 specifiers, the remaining specifier longwords
contain UNPREDICTABLE values

New PC

PC of the instruction following the emulated instruction

PSL

PSL saved at the time of the trap

If PSL<FPD>=l 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 2-30. In this case, PC is that of the
opcode of the emulated instruction.

DIGITAL CONFIDENTIAL

Architectural Summary 2-39

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 2-30:

Suspended emulation Fault Stack Frame

31 30 29 28127 26 25 24123 22 21 20119 16 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

I : (SP)

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

PSL

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2.7.2.4

Vector Unit Disabled Fault

Vlhen the NVAX CPU attempts to issue a vector instruction to the optional vector processor, it
may discover that the vector unit is disabled. In this case, a vector unit disabled fault is initiated
through 8CB vector 68 (hex). There are no parameters for this exception (besides the usual
PCIPSL pair), and the reason for the exception must be determined by reading the appropriate
vector unit registers.
2.7.2.5

Machine Check exceptions

A machine check exception is reported through 8CB vector 04 (hex) when the ~TVAX 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 2-31. Machine checks are discussed at length in
Chapter 15.
Figure 2-31 :

Generic Machine Check Stack Frame

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

B~e

Count of Parameters, Excluding This Longword

I : (SP)

+-_._-.--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

PC
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

PSL

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2.7.2.6

Console Halts

In certain microcode Hows, 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 P8L, halt code,
and validity ftag are saved in IPR 43 (SAVP8L). The format of SAVPC and 8AVPSL are shown
in Figure 2-32.

2-40

Architectural SUi. imary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-32:

IPR 2A (hex), SAVPC and IPR 28 (hex), SAVPSL

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1

Saved PC

1 :SAVPC

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I

PSL<31 : 16>

Halt Code

PSL<7 : 0>

1 : SAVPSL

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1
MAPEN<O> --+ 1
Invalid SAVPSL if 1 --+

Console halts are discusssed in detail in Chapter 15.

2.8 System Control Block
The System Control Block (SCB) is a page containing the vectors for servicing interrupts and
exceptions. The SCB is pointed to by the System Control Block Base Register (SCBB), whose
format is shown in Figure 2-33. For best performance, SCBB should contain a page-aligned
address. Microcode forces a longword-aligned SCBB by clearing bits <1:0> of the new value
before loading the register.
NOTE

When the CPU is configured to generate 30-bit physical addresses, SCBB<31:30> are
ignored.
Figure 2-33:

IPR 11 (hex), SCaB

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Physical Page Address of SCB

SBZ

1 0

01 :SCBB

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2.8.1

System Control Block Vectors

An SCB vector is an aligned longword in the SCB through which the NVAX microcode dispatches
interrupts and exceptions. Each SCB vector has the format shown in Figure 2-34. The fields of
the vector are described in Table 2-14.

DIGITAL CONFIDENTIAL

Architectural Summary 2-41

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-34: System Control Block Vector
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

longword address of service routine

Icode I

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Table 2-14: System Control Block Vector
Bits

Contents

31:2

VutuaJ. address of the service routine for the interrupt or exception. The routine must be
longword aligned, as the microcode forces the lower two bits of the address to 00

1:0

Code, interpreted as follows:

2.8.2

Value

Meaning

The event is to be serviced on the kernel stack unless the CPU is already on the
interrupt stack, in which case the event is serviced on the interrupt stack

The event is to be serviced on the interrupt stack. If the event is an exception, the
IPL is raised to IF (hex)

Unimplemented, results in a console error halt

System Control Block Layout

The System Control Block layout is shown in Table 2-15.
Table 2-15: System Control Block Layout
Vector

Name

Type

Param

Notes

00
04

passive release

interrupt

IPL is raised to request IPL

machine check

abort

parameters
reflect
machine state; must be serviced
on interrupt stack

kernel stack not valid

abort

must be serviced on interrupt
stack

OC
10

power fail

interrupt

IPL is raised to IE (hex)

reserved/privileged
instruction

fault

14
18

customer reserved instruction

fault

XFC instruction

reserved operand

fault/abort

not always recoverable

reserved addressing mode

fault

access control violation/vector
alignment fault

fault

2-42 Architectural Summary

parameters are virtual address,
status code

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Table 2-15 (ConI.): System Control Block Layout

vector

Name

Type

Param

Notes

translation not valid

fault

parameters are virtual address,
status code

trace pending

fault

breakpoint instruction

fault

unused

arithmetic trap'fault

38-3C

unused

compatibility mode
VAXes

other

trap'fault

parameter is type code

CHMK

trap

parameter is
operand word

sign-extended

CHME

trap

parameter is
operand word

sign-extended

CHMS

trap

parameter is
operand word

sign-extended

CHMU

trap

parameter is
operand word

sign-extended

unused

soft error notification

interrupt

IPL is 1A (hex)

Performance
counter overflow

unused

hard error notification

monitoring

Internal interrupt at IPL IB
(hex).
This vector supplies
the physical base address of
the block of performance
monitoring counts in memory.
See Chapter 18 for details.

interrupt

IPL is ID (hex)

fault

vectorinstrucQons
IPL is 16 (hex)

unused

vector unit disabled

6C-7C

unused

interprocessor interrupt

interrupt

software level 1

interrupt

o
o

software level 2

interrupt

ordinarily used for AST delivery

software level 3

interrupt

ordinarily used
scheduling

90-BC

softwareleveb4-15

interrupt

CO
C4

interval timer

interrupt

for

process

IPL is 16 (hex)

unused

DIGITAL CONFIDENTIAL

Architectural Summary

2-43

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Table 2-15 (Cont.):

System Control Block Layout

Vector

Name

Type

Param

Notes

emulation start

fault

same
mode
exception,
FPD=O; parameters are opcode,
PC, specifiers

emulation continue

fault

same mode exception, FPD=l; no
parameters

DO-F4

unused

console receiver

interrupt

IPL is 15 (hex)

console transmitter

interrupt

IPL is 15 (hex)

interrupt

Device interrupt vectors

100-FFFC device vectors

2.9

CPU Identification
Software may quickly determine on which CPU it is executing in a multi-processor system by
reading the CPUID processor register. The format of this register is shown in Figure 2-35.
Figure 2-35:

IPR OE (hex), CPUID

The CPUID processor register is implemented internally as an 8-bit read-write register. The
source of the CPU ID information is system-specific, and it is the responsibility of the console
firmware at powerup to determine the CPU ID from the system-specific source, and write the
CPU ID register to the correct value.

2.10

System Identification

The System Identification Register (SID) is a read-only register which includes the the system
(actually the CPU) type, and the microcode revision number. The format of the SID register is
shown in Figure 2-36.

2-44

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-36:

IPR 3E (hex), SID

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1
CPU Type
1 0 0 0 0 0 0 0 0 0 OIPatch RevisionlNSI
Microcode Revision I :SID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

DIGITAL CONFIDENTIAL

Architectural Summary 2-45

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Table 2-16:

SID Field Descriptions

Name

Extent Type

Microcode Revision

7:0

This field contains the microcode (chip) revision number.
This number is incremented for each pass of the chip.

RO,O

If this bit is a zero, there is either no microcode patch
loaded, or the patch is a standard patch. If this bit
is a one, a non-standard microcode patch is loaded.. A
non-standard patch is one which goes beyond the formally
released patches, such as a patch used for performance
analysis. This bit is cleared on chip reset.

Patch Revision

13:9

RO,O

If this field is zero, no microcode patch is loaded. If this
field is non-zero, a microcode patch is loaded and this field
indicates the patch number. This field is cleared on chip
reset.

CPU Type

31:24

This field contains 19 (declmal), indicating that this is an
NVAXCPU.

Description

NOTE

The patch revision and non-standard patch fields (SID<13:8» were added in pass 2 of
the NVAX chip.

2.11

Process Structure

A process is a single thread of execution. The context of the current process is contained in the
Process Control Block (PCB). The PCB is pointed to by the Process Control Block Base register
(PCBB), which is shown in Figure 2-37. The format of the process control block is shown in
Figure 2-38. Microcode forces a longword-aligned PCBB by clearing bits <1:0> of the new value
before loading the register.
NOTE

When the CPU is configured to generate 30-bit physical addresses, PCBB<31:30> are
ignored.

2-46 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-37:

IPR 10 (hex), PCBB

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 OS 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Physical Longword Address of the PCB
1 0 01 :PCBB
+--+--+--~+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

DIGITAL CONFIDENTIAL

Architectural Summary 2-47

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Figure 2-38:

Process Control Block

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

KSP

:PCB

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

ESP

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

SSP

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

USP

+12

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
RO
I +16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+20

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
R2
I +24
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+28

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+32

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+36

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+40

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+44

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+48

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+52

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

R10

+56

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Rll
I +60
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I

AP(Rl2)

+64

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I

FP (Rl3)

+68

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+72

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

PSL

+76

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
POBR
I +80
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I 0
0 0 0 0 I ASTLVL I 0 0 I
POLR
I
+84
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

P1BR

+88

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

IPME 0

PlLR

+92

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

2-48

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Hevision 1.0, February 1991

2.12 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.
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 2-39.

Figure 2-39:

IPR Address Space Decoding

31 30 29 2612i 26 25 24123 22 21 20119 l8 17 16115 14 13 12111 10 09 0810i 06 05 0'103 02 01 00
------~--~-----+--~--~--~-----.--+--+--~--~--~--~--~--------------+-----~--~--~-----------+-----~

Bcache Tag !PR Address
31 30 29 2812i 26 25 24123 22 21 20119 18 l7 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

SBZ

Bcacbe Tag Index

1 11 01 01 xl

SBZ

+--+--+--~--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Bcache Deallocate IPR Address
31 30 29 28127 26 25 24123 22 21 20119 18 1i 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1

SBZ

1 11 0 1 11 xl

Bcache Tag Deallocate Index

SBZ

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Pcache Tag IPR Address
31 30 29 28127 26 2S 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
SBZ

1 11 11 0 I

SBZ

Pcacbe Tag Index

SBZ

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Pcache Set Select (O-left, 1-rigbt) -+
Pcache Data Parity IPR Address
31 30 29 28127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
SBZ
1 11 11 11
SBZ
I Pcacbe Tag Index I
SBZ
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I
Pcache Set Select (o-left, 1-right) -+

DIGITAL CONFIDENTIAL

1
Subblock select +

Architectural Summary 2-49

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

The numeric range for each of the four groups is shown in Table 2-17.
Table 2-17:

IPR Address Space Decoding

IPR Group

Mnemonic2

IPR
Address
Range (hez:)

Contents

OOOOOOOO..OOOOOOFFl

Normal

256 individual IPRs.

64k Bcache tag IPRs, each separated by 20(bex)
from the previous one.

Bcache Tag

BCTAG

01000000..011FFFEO

Bcache Deallocate

BCFLUSH

01400000..015FFFEOI

64k Bcache tag deallocate IPRs, each separated
by 20(bex) from the previous one.

Pcache Tag

PCTAG

01800000..01801FE01

256 Pcache tag IPRs, 128 for each Pcache set,
each separated by 20(bex) from the previous
one.

Pcache Data Parity

PCDAP

01COOOOO .. 01C01FFS 1 1024 Pcache data parity IPRs, 512 for each
Pcache set, each separated by 8(bex) from the
previous one.

1 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 non-zero. Although non-contiguous address ranges are shown for these groups, the entire
IPR address space maps into one of the these groups. H these fields are non-zero, the operation of the CPU is Ul\TDEFINED.

2The mnemonic is for the first lPR in the block

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 o. Similarly, the IPR address
for the first subblock of Pcache data parity is 01COOOOO (hex), and the IPR address for the second
subblock of Pcache data parity is 01COOOO8 (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. 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 110 space references and passed to the system environment via a read or write
command on the NDAL.
Each of the 256 possible IPRs in the normal group are of longword length, so a lKB block of 110
space is required to convert each possible IPR to a unique 110 space longword. This block starts
at address E1000000 (hex). Conversion of an IPR address to an 110 space address in this block

2-50

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

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
[0 ADDRESS = E1000000

+ (IPR NUMBER * 4)

The actual hardware implementation of this is different in that the IPR number is shifted left by
2 bits, and bits <31:30,24> are set. There is no multiply or add 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 1KB block is never referenced as a result of
an MTPRlMFPR to or from these IPRs. However, note that a programmer can indeed reference
these locations via an explicit I/O space reference with, e.g., MOVL. References to this block of 110
space locations with instructions other than MTPR/MFPR may result in UNDEFINED behavior.
The processor registers implemented by the NVAX CPU are are shown in Table 2-18.
NOTE

Many of the processor registers listed in Table 2-18 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.

DIGITAL CONFIDENTIAL

Architectural Summary 2-51

NVAX CPU Chip Functional Specification, Revision 1.1, August 1991

Table 2-18:

Processor Registers
Number

Mnemonic (Dec) (Hex) Type Imp!

Cat

Kernel Stack Pointer

KSP

Executive Stack Pointer

ESP

Supervisor Stack Pointer

SSP

User Stack Pointer

USP

Interrupt Stack Pointer

ISP

NVAX

1-1

RW
RW

NVAX
NVAX
NVAX
NVAX

1-1

1I0Adcb

1-1
1-1

Reserved

El00001·

Reserved

El00001~

Reserved

El00001C

1-1

PO Base Register

POBR

NVAX

1-2

PO Length Register

POLR

1-2

PI Base Register

PIBR

PI Length Register

PILR

System Base Register

SBR

System Length Register

SLR

CPU Identification1

CPUID

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX

Reserved

1-2
1-2
1-2
1-2
2-1
3

El00003(

Process Control Block Base

PCBB

System Control Block Base
Interrupt Priority Levell
ASTLevel l

SCBB

IPL

ASTLVL

Soft.ware Interru.pt Request Register

SmR

Soft.ware Interru.pt Summary Registerl

SISR

Reserved

El000058

Reserved

El00005C

2-7

El000060

3-7

El000064

3-7

El000068

2-3

El00006C

2-3

El000070

2-3

El000074

2-3

El000078

2-3

El00007C

2-3

El000080

Interval Counter ControllStatus l ,2

ICCS

Next Interval Count

NICR

Interval Count

ICR

Time of Year Register

TODR

Console Storage Receiver Status

CSRS

Console Storage Receiver Data

CSRD

Console Storage 'Transmitter Status

CSTS

Console Storage 'Transmitter Data

CSTD

Console Receiver Contro1lStatus

RXCS

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX

NVAX
System
System
System
System
System
System
System
System

1-1
1-1
1-1
1-1
1-1
1-1

1 Initialized on reset
2Subset or full implementation depending on ECR control hit

2-52

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU .Chip Functional Specification, Revision 1.0, February 1991

Table 2-18 (Cont.):

Processor Registers
Number
VOAddress

Mnemonic (])ec) (Bm:) Type Impl

Console Receiver Data Buffer

RXDB

System 2-3

E1000084

Console Transmitter Control/Status

TXCS

System 2-3

E1000088

Console Transmitter Data Buffer

TXDB

System 2-3

E100008C

Cat

Reserved

E1000090

Reserved

E1000094

Reserved

E100009C

Reserved

E10000AO

Reserved

E10000A4

R
R

Machine Check Error Register

MCESR

Console Saved PC

SAVPC

Console Saved PSL

SAVPSL

NVAX

:NVAX
NVAX

2-1

Reserved

E10000BO

Reserved

E10000B4

Reserved

E10000B8

Reserved

E10000BC

Reserved

E10000CO

Reserved

E10000C4

Reserved

E10000C8

Reserved

E10000CC

Reserved

E10000DO

Reserved

E10000D4

Reserved

E10000D8

IORESET

System 2-3

MAPEN

Translation Buffer Invalidate All

TBIA

Translation Buffer Invalidate Single

TBIS

NVAX
NVAX
NVAX

I/O System Reset Register
Memory Management Enable

2-1

E10000DC

1-2
1-1
1-1

E10000EC

E10000FO

PME

System Identification

Translation Buffer Check

TBCHK

Reserved
. Reserved
Performance Monitor Enable

NVAX
NVAX
NVAX

2-1
2-1
1-1

llnitialized on reset

DIGITAL CONFIDENTIAL

Architectural Summary 2-53

NVAX CPU Chip Functional Specification, R.evision 1.0, F.ebruary 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemomc (Dec) (Hex) Type Impl

IPL 14 Interrupt ACKs
IPL 15 Interrupt ACKs
IPL 16 Interrupt ACKs
IPL 17 Interrupt ACKs
Clear Write Buffers

IAKl4
IAKl5

1AK16

IAKl7
CWB

Reserved

67
68
69
70
71
72
73

45
46
47
48
49

Reserved

4D
4E
4F
50
51
52
53

Reserved

77
78
79
80
81
82
83

Reserved

55
56
57
58
59
5A
5B
5C
5D
5E
5F

Reserved
Reserved
Reserved
Reserved

Reserved
Reserved
Reserved
Reserved
Reserved

Reserved

89
90
91
92
93

Reserved

Reserved
Reserved
Reserved

I10Addre

System 2-3
System 2-3

System 2-3

System 2-3
System 2-3

E1000100
E1000104
E1000108
E100010C
E1000110
E1000114
E1000118
E100011C
E1000120
E1000124
E1000128
E100012C
E1000130
E1000134
E1000138
E100013C
E1000140
E1000144
E1000148
E100014C
E1000150
E1000154
E1000158
E100015C
E1000160
E1000164
E1000168
ElOOO16C
E1000170
E1000174
ElOOO178
E1OOO17C

40
41
42

Reserved

Cat

3
3
8

3
3
3
3
3
3
8

3
3
3
3
3
3
3
3
3
8

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

2-54 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (He:s:) Type Impl

Cat

IlOAddress

Reserved

E1000180

Reserved

E1000184

Reserved

E1000188

Reserved

E100018C

Reserved for VM

100

E1000190

Reserved for VM

101

E1000194

Reserved for VM

102

E1000198

Reserved

103

E100019C

Reserved

104

E1000lAO

Reserved

105

E1000lA4

Reserved

106

E1000lA8

Reserved

107

E1000lAC

Reserved

108

E10001BO

Reserved

109

E10001B4

Reserved

110

E10001B8

Reserved

111

E10001BC

Reserved

112

E10001CO

Reserved

113

E10001C4

Reserved

114

E10001C8

Reserved

115

E10001CC

Reserved

116

E10001DO

Reserved

117

E10001D4

Reserved

118

E10001D8

Reserved

119

E10001DC

Reserved for Ebox

120

2-6

E 1000lEO

Reserved for Ebox

121

2-6

E10001E4

Interrupt System Status Registe~

INTSYS

122

Performance Monitoring Facility Count

PMFCNT.

123

Patchable Control Store Control Registers

PCSeR

124

Ebox Control Register

ECR

125

Mbox TB Tag FillS

MTBTAG.

126

Mbox TB PTE FillS

MTBPI'E

127

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX

2-1
2-1
2-1
2-1
2-1
2-1

sTesta.bility and diagnostic use only; not for software use in normal operation

DIGITAL CONFIDENTIAL

Architectural Summary 2-55

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (Hex) Type Impl

Cat

110 Addrel

Reserved for Vectors

128

E1000230

Reserved for Vectors

129

E1000230

Reserved for Vectors

130

E1000230

Reserved for Vectors

131

E1000230

Reserved for Vectors

132

E1000230

Reserved for Vectors

133

E1000230

Reserved for Vectors

134

E1000230

Reserved for Vectors

135

E1000230

Reserved for Vectors

136

E1000230

Reserved for Vectors

137

E1000230

Reserved for Vectors

138

E1000230

Reserved for Vectors

139

E1000230

Reserved for Vectors

140

E1000230

Reserved for Vectors

141

E1000234

Reserved for Vectors

142

E1000238

143

E100023C

Vector Processor Status Register

Reserved for Vectors
VPSR

144

Vector

E1000240

Vector Arithmetic Exception Register

VAER

145

Vector

E1000244

Vector Memory Activity Register

VMAC

146

Vector

E1000248

Vector Trans. Buffer Invalidate All

VTBIA

Vector

147

E100024C

Reserved for Vectors

148

E1000250

Reserved for Vectors

149

E1000254

Reserved for Vectors

150

E1000258

Reserved for Vectors

151

E100025C

Reserved for Vectors

152

E1000260

Reserved for Vectors

153

E1000264

Reserved for Vectors

154

E1000268

Reserved for Vectors

155

E100026C

Reserved for Vectors

156

E1000270

Reserved for Vectors

157

E1000274

Reserved for Vectors

158

E1000278

Reserved for Vectors

159

E100027C

2-56

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (Hes:) Type Impl

Cat

Obox Control Register

CCTL

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
:t\"VAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX

2-5

Reserved for Obox

160

161

A1
A2

Bcache Data ECC

BCDECC

162

Bcache Error Tag Status

BCETSTS

163

Bcache Error Tag Index

BCETIDX

164

Bcache Error Tag

BCETAG

165

Bcache Error Data Status

BCEDSTS 166

Bcache Error Data Index

BCEDIDX 167

Bcache Error ECC

BCEDECC 168

Reserved for Cbox

169

Reserved for Obox

170

Fill Error Address

CEFADR

171

Fill Error Status

OEFSTS

172

173

174

175

176

177

178

Reserved for Obox
NDAL Error Status

:r-..~STS

Reserved for Cbox
NDAL Error Output Address

NEOADR

Reserved for Cbox
NDAL EITOr Output Command

NEOCMD

179

NEDATHI 180

181

NEDATLO 182

188

184

Reserved for Obox

185

Reserved for Cbox

186

Reserved for Cbox
NDAL EITOr Data High
Reserved for Obox
NDAL Error Data Low
Reserved for Obox
NDAL Error Input Command

NEIOMD

Reserved for Cbox

187

Reserved for Cbox

188

Reserved for Cbox

189

Reserved for Cbox

190

Reserved for Obox

191

DIGITAL CONFIDENTIAL

RW
R
R
R
R
R

110 Address

2-6
2-5
2-5
2-5
2-5
2-5
2-5
2-5
2-6
2-6
2-5
2-5
2-6
2-5
2-6
2-5
2-6
2-5
2-6
2-5
2-6
2-5
2-6
2-5
2-6
2-6
2-6
2-6
2-6
2-6
2-6

Architectural Summary '2-57

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (Be:&:) Type

Impl

Cat

I10Addrt

Reserved

192

El000300

Reserved

193

El000304

Reserved

194

El000308

Reserved

195

El00030C

Reserved

196

El000310

Reserved

197

El000314

Reserved

198

El000318

Reserved

199

El000310

Reserved

200

E1000320

Reserved

201

E1000324

Reserved

202

El000328

Reserved

203

E100032C

Reserved

204

El000330

Reserved

205

El000334

Reserved

206

E1000338

E100033C

Reserved
VIC :Memory Address Register
VIC Tag Register
VIC Data Register
Ibox Control and Status Register
Ibox Branch Prediction Control RegisterB

VMAR
VTAG
VDATA
ICSR
BPCR

Reserved for !box

207

208

209

210

211

212

213

RW
RW
RW
RW
RW

Ibox Backup pQ4

BPC

214

Ibox Backup PC with RLOG Unwind'

BPCUNW

215

Reserved for !box

216

Reserved for !box

217

Reserved for !box

218

Reserved for !box

219

Reserved for !box

220

Reserved for !box

221

Reserved for Ibox

222

Reserved for Ibox

223

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX

2-5
2-5
2-5
2-5
2-5
2-6
2-5
2-5
2-6
2-6
2-6
2-6
2-6
2-6
2-6
2-6

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

"Chip test use only; not for software use

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0t February 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (Hex) Type Impl

Cat

Mhox PO Base Registe~

MPOBR

2-5

Mbox System Length RegisterS

MSLR

229

Mbox Memory Management Enable!

MMAPEN

230

E4
E5
E6

Mbox Physical Address Mode

PAMODE

231

l\Ibox M:ME Address

MMEADR

232

l\fbox M:ME PTE Address

MMEPTE

233

Mbox M:ME Status

MMESTS

234

235

236

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
!\"VAX

1'4\TAX.

2-5

NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX.
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX
NVAX

2-6

224

Mhox PO Length Registe~

MPOLR

225

Mhox P1 Base RegisterS

MP1BR

226

Mhox P1 Length Registers

MP1LR

227

Mhox System Base Registe~

MSBR

228

RW
RW

Reserved for l\fbox
~fbox TB Parity Address

TBADR

l\fbox TB Parity Status

TBSTS

23i

Reserved for Mbox

238

Reserved for Mhox

239

Reserved for Mhox

240

241

242
244

F2
F3
F4

Reserved for Mbox
Mbox Pcache Parity Address

PCADR

Reserved for Mbox
Mhox Pcache Status

243
PCSTS

Reserved for Mhox

245

Reserved for Mbox

246

Reserved for Mbox

247

Mhox Pcache Control

PCCTL

248

Reserved for Mbox

249

Reserved for Mhox

250

Reserved for Mhox

251

Reserved for Mbox

252

Reserved for Mbo%.

253

Reserved for Mhox

254

Reserved for Mhox

255

R
RW

110 Address

2-5
2-5
2-5
2-5
2-5
2-5
2-5
2-5
2-5
2-5
2·6

2-6
2-6
2-6
2·5
2-6
2-5
2-6
2-6
2-6
2-5
2-6
2-6
2-6
2-6
2-6
2-6
2-6

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

DIGITAL CONFIDENTIAL

Architectural Summary 2-59

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 2-18 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (Hex) Type

Unimplemented

100-

Impl

Cat

I10Addn

OOFFFFFF
See Table 2-17

01000000-

F'F'F'F'F'F'F'F
Type:
R = Read-only register
RW = Read-write register
W = Write-only register
Impl(emented):

=
=

l\'"VAX Implemented in the NVAX CPU chip
System Implemented in the system environment
Vec'tor =Implemented in the optional vector unit or its NDAL interface
Cat(eg-ory), class-subclass, where:
class is one of:

1 Implemented as per DEC standard 032
2 l'.I\iAX-spec:i:1ic implementation which 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 NV.AX CPU chip

2-60 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional SpecificatiOllt Revision 1.0, February 1991

2.13 1/0 space Addresses
.As noted above, processor registers that are not implemented on the NVAX CPU chip are
converted to I/O space reads or writes. Most of these IPRs are optional and may be implemented
or not, as dictated by the needs of the system environment. The I/O space registers that must be
implemented by the system environment are shown in Table 2-19.

Table 2-19:

1/0 Space Registers

I/O
Space
Address
(Hex)

Type

Definition

E0040000

Powerup boot ROM address from which the first instruction is fetched.

EI000100

Interrupt acknowledge for an IPL 14 (hex) interrupt requested via the
IRQ..L<O> pin.

E1000104

Interrupt acknowledge for an IPL 15 (hex) interrupt requested via the
mQ..L<l> pin.

E1000108

Interrupt acknowledge for an IPL 16 (hex) interrupt requested via the
mQ..L<2> pin.

E100010C

Interrupt acknowledge for an IPL 17 (hex) interrupt requested via the
IRQ..L<3> pin.

E1000110

Location which invokes a write buffer flush in the system environment.
When this location is read, the CPU is waiting for confirmation that the
ftush has completed. The returned data is ignored.

DIGITAL CONFIDENTIAL

Architectural Summary 2-61

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

2.14

Revision History

Table 2-20:

Revision History

Who

When

Description of change

Mike Uhler

06-Mar-1989

Release for extemal review.

Mike Uhler

15-Dec-1989

Update for second-pass release.

Mike Uhler

2O-Jul-1990

Update to reflect implementation.

Mike Uhler

04-Dec-1990

Update after pass 1 PG.

2-62

Architectural Summary

DIGITAL CONFIDENTIAL

Chapter 3
NVAX Chip Interface

3.1

Introduction
The NVAX chip communicates through five interfaces: the NDAL (NVAX data-address lines), the
backup cache interface, the interrupt lines, the clocking interface, and the test interface.
This chapter begins by listing all the NVAX pins and giving a brief description of each. The rest of
the chapter describes the NDAL protocol in detail. The other interfaces are described as follows:
the backup cache interfaces in Chapter 13, the intelTUpt lines in Chapter 10, the test interface
in Chapter 19, and the clocking interface in Chapter 17.
The NDAL is a 64-bit pended bidirectional bus which is used by the NVAX CPU to communicate
with the system environment. The NDAL cycle time is three times longer than· the NVAX CPU
cycle time. The NVAX CPU cycle time is targeted to 14ns, making the NDAL cycle time 42
ns. Binned CPU parts may run at 10ns, resulting in an NDAL cycle time of 30ns. The NDAL
supports up to four (4) nodes with a maximum of one (1) NVAX CPU. In this spec, these four
nodes are referred to as CPU (NVAX), IOl_NODE, I02_NODE, and the memory interface.
The NVAX CPU contains a writethrough primary cache and a writeback backup cache. The NDAL
is designed to support the writeback cache and cache coherency in a multiprocessor system.
NOTE

IMPORTANT INFORMATION REGARDING THE NVAX CHIP INTERFACE IS ALSO
CONTAINED IN Chapter 10 (The Interrupt Section), Chapter 13 (The Cbox), Chapter 17
(Chip Clocking), AND Chapter 19 (Testability Micro-Architecture). THE READER
MUST CONSULT THOSE CHAPTERS IN ORDER TO OBTAIN COMPLETE INFORMATION.

3.2

NVAX CPU pinout
The NVAX CPU chip contains the pins listed in Table 3-1. Following the table, each pin is
described in more detail.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-1

NVAX CPU Chip Functional Specifi.~tion, Revision 1.0, February 1991

Table 3-1:

NVAX CPU pinout

1101

Type2

Function

Number Total

0
0
0

SS,lDlR
SS,lDlR

NVAX Request
NVAXHold

SS,lDlR
SS,lDlR
SS,lDlR
T,4D4R

NVAX Suppress
NVAXGrant
Writeback Only
Data/Address Lines

T,4D4R
T,4D4R

Command

NDAL SIGNALS (80 total)s
P%CPU_REQ..L
PO/OCPU_BOLD_L
Po/oCPU_SUPPRESS_L
PO/OCPU_GRANT_L

PO/OCPU_WB_ONLY_L

P%NDAL_B<63:O>

10
10
10
10
10

Po/oC:MD_B<8:0>
P%ID_H<2:O>
P%PARITY_B<2:O>
Po/cACK_L

1
2

1
1
1

3
4

4
3
3

73
76
79
80

OD,4D4R

N ode Identification Lines
NDALParity
Acknowledge

SS,lD1R
SS,lDlR
SS,lD1R
SS,lDlR

Oscillator, High Asserted
Oscillator, Low Asserted
Test ClocklTimeout Clock
Test Clock

1
1
1
1

81
82
83

SS,lDlR
SS,lD4R
SS,lD4R
SS,lD4R

Test Clock Control
NDAL PHIl2, Driven
NDAL PHI23, Driven
NDAL PHI34, Driven

1
1
1

85
86
87

NDAL PHI41, Driven
NDAL PHI12, Received
NDAL PHI23, Received
NDAL PHI34, Received

1
1

89
90
91
92

T~4D4R

CLOCKS (15 total)"
Po/c;OSC_H
P%OSC_L
P%OSC_TCl_H
Po/oOSC_TC2_B
P%OSC_TEST_H
P%PBl12_0UT_H
P%PHI23_0UT_H
P%PID34_0UT_B
p%pm41_0UT_B

I
I
I
I
I
0

0
0

P%PBl12_IN_H
Po/oPHI23_IN_B
P%PBl34_IN_B
p%pm41_IN_B

SS,lD4R
SS,lD4R

I
I

SS,lD4R
SS,lD4R

P%ASYNC_RESET_L
P%SYS_RESET_L

I
0

SS,1D4R
SS,lDlR
SS,lD3R

NDAL PHI4l, Received

1
1

Reset Input to NVAX
Reset Output to System

1
1

93
94
95

INTERRUPT AND ERROR SIGNALS (10 total)1
P%MACBINE_CHECK_B

SS,lD1R

Machine Check

Po/cIR(LL<3:O>
P%H_ERR_L
P%S_ERR_L

OD,3DlR

100

OD,3DlR
OD,3D1R
SS,1DlR

Interrupt Request Lines
Hard (unrecoverable) Error
Soft (recoverable) Error

I
I
I

Interval Timer Request

1
1
1

101
102
103

I
I

SS,ID1R
SS,lDlR

Power Fail
Halt

1
1

105

P%INT_TIM_L
P%PWRFL_L
P%HALT_L

3-2

NVAX Chip Interface

104

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Running
Pin

110

Type

Function

Number Total

SS,lD6R

Tag Store Index Lines

121

SS,lD6R

Tag Store Output Enable

122

SS,lD6R

Tag Store Write Enable

123

T,7D7R

Tag Store Tag

138

T,7D7R

Tag Store ECC

144

T,7D7R

Tag Store Owned Bit

145

T,7D7R

Tag Store Valid Bit

146

BACKUP CACHE SIGNALS (133 total)·
P%TS_INDEX_B<20:5>
P%TS_OE_L
P%TS_WE_L
P%TS_TAG_B<31:17>
P%TS_ECC_B<5:0>
P%TS_OWNED_H
P%TS_VALID_H
P%DR_INDEX_B<20:3>
P%DR_OE_L
P%DR_WE_L
P%DR_DATA_B<63:0>
P%DR_ECC_B<7:0>

0
0
0
10
10
10
10
0
0
0
10
10

SS,lD18R

Data RAM Index Lines

164

SS,1D18R

Data RAM Output Enable

165

SS,lD18R

Data RAM Write Enable

166

T,19D19R

Data RAM Data Lines

230

T,19D19R

Data RAM ECC

238

TEST SIGNALS (23 total) '1
P%TEST_DATA_H

SS,lD1R

Test data input for microcode
use.

239

P%TEST_STROBE_B

SS,lDIR

Test strobe for microcode use.

240

P%DISABLE_OUT_L

SS,ID1R

Disable NVAX Outputs

241

P%TEMP_H

SS,lD1R

NVAX Temperature Output

242

P%TMS_H

SS,lDIR

JTAG Test Mode Select

1
1

243

P%TCK_H

SS,lD1R

JTAG Test Clock

244

P%TDI_H

SS,lDIR

JTAG Serial Test Data Input

245

P%TDO_B

SS,lD2R

JTAG Serial Test Data Output

24S

P%PP_CMD_B<2:O>

SS,lD1R

Parallel Test Port Command

249

P%PP_DATA_B<ll:O>

T,2D2R

Parallel Test Port Data

261

1 Indicates whether the pin is an NVAX. CPU Input, Output, or Input/Output pin.

2Single Source is denoted by SS, Tristate by T, Open Drain by OD; #D indicates the maximum number of drivers and #R
indicates the maximum. number of receivers expected on the board.
sThese pins are discussed in detail in this chapter.
'These pins are discussed in detail in Chapter 17
6These pins are discussed in detail in Chapter 10
6These pins are discussed in detail in Chapter 13
7These pins are discussed in detail in Chapter 19

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-3

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.2.1

NDAL Signals and Timing

The functionality of the NDAL pins is described in detail in Section 3.3. The timing of the pins
is shown in Figure 3-1, and the AC specs are given in Table 3-2.
NOTE

The timing of the NDAL signals is given relative to the NDAL clocks which are received
by NVAX: P%PHI12_IN_H, P9DPHI23_IN_H, P%PHIS4_IN_H, and P%PHI41_IN_
H. NVAX drivers were designed to meet this timing, taking the NDAL clock skew into
account. (NDAL clock skew is covered in Chapter 17.) NVAX expects to receive signals
which have been designed taking the clock skew into account; NVAX receivers account
for no clock skew.

3-4 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-1:

NDAL Pin nmlng Relative to the NDAL CLOCKS
,----I-----Nl~

P4
P%PHI12_ IN_H
P%PHI23_IN_H
P%PHI34 _ IN_ H
P%PHI41_IN_H

P%ID 8<2:0>
P%PARITY 8<2 :0>
P%NDAI. 8<63:0>
P%CMD_H<3:0>

_------~I
1

------~~~

---I

1------------

»»»>--

AJt ciriven by NVAX CPU:

Driven from PtPHI12 IN 8 r.ia:i.ng edge
Ra~ea.~~ with P~PHIil_lN~H rising edge
;

;

>OOOOOOOOOOOOOO
La~ch c~oses

>--

>) >

:
I
with P%PHI41_IN_H ri~ing ed9-

As receive~ by NVAX CPU

E----

i
_____________J~-------------~~____________
~

~«««{«««««(

~--------------~I1

/.,.______....;.i______~\.

P-%ID H<2:0>
P-%PARITY 8<2:0>
P-%NDAL 8<63:0>
P%CMD_ ik3 : 0>

D ALe Y C L

(~atch

open ~U%'ing phi23)

I
1----_________________

______ I

~--------------~\~.\~\~,~,~,~,~\~,\
i?II?II?I?I?II?I?li??III??li
~ ?~~led low by ~\TAX CP~ ~ ?~~led h.gh ~h%'ough boara pullup resistor
h-;AX ~~~. ~ow w/?~P£:23 IN E r~sin;; ~~ release. w~th P~PEI23 IN H f.~~ing

- -:

:- -

As required by NVAX CPU
La~ch c~ose.

with P%PH!3' IN H rising edge

(~tch open during phi12)-

1----1
PtCPU HOLD L
PtCPU-SUPPRESS L
PtCPU:REQ_L
-

~~~~~~--------A.a d%'i ven by NVAX CPU
I
_______ I_D_r_i_V_en_With POPHI12_lN_H riaiAg ~_e______________________

PtCPU WB ONLY L
PtcPU:c:Rim_L-

As requi%'e~ by NVAX

CPU
Latch c~oses with PtPHI41 IN 8 rising edge
(~atch open c1uring pb.i23) -

--- ---I

DIGITAL CONFIDENTIAL

- - - - - - \1 - - - - - -

NVAX Chip Interface 3-5

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-2:

NDAL AC timing specs

Input Pin

Hold Time

Po/cNDAL_B<63:O>
P%CMD_H<3:0>
P%ID_B<2:O>
Po/tPARITY_B<2:O>

P%CPU_WB_ONLY_L
P%CPU_GRANT_L

Output Pin

Drive Time

Tristate Time

P'iC!'.~.AL_H<63:O>

Po/cCMD_B<3:0>

P%ID_H<2:O>
P%P.ARITY_H<2:O>
P%PBI23_IN_H R + 1 phase Gow
transition), PC-IDPBl23_IN_H F + 3
phases(high transition)3
PO/CCPU_HOLD_L
Po/cCPU_SUPPRESS_L
Po/tCPU_REQ...L
lR means the rising edge of the dock is used; F meaDS the falling edge of the clock is used..
2The 2ns hold time requirement on the NDAL is as follows: the data does not have to be actively driven for this amount
of time if the driver ensures that the values will be capacitively held on the bus for 2m past the phi4 risiDg edge.
8P%ACE_L is pulled up through a resistor in the system; the same must be done on the test load board.

3.2.1.1

pOkCPU_REQ_L

NVAX asserts P9"DCPU_REQ..L to request the NDAL for the following cycle. P%CPU_REQ..L
is a unidirectional signal from NVAX to the arbiter.

3-6

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specificationt Revision 1.0t February 1991

3.2.1.2

P%CPU_HOLD_L

The NVAX CPU asserts P%CPU_HOLD_L in order to drive the NDAL on consecutive cycles.
3.2.1.3

pOkCPU_SUPPRESS_L

NVAX asserts P%CPU_SUPPRESS_L in order to suppress new NDAL transactions. While
P%CPU_SUPPRESS_L is asserted, only fills and writebacks are allowed to proceed from nonCPU nodes.
.
3.2.1.4

P%CPU_GRANT_L

P%CPU_GRANT_L is asserted to notify NVAX that it must drive the NDAL during the following
cycle.
3.2.1.5

pO/oCPU_WB_ONLY_L

'When the system asserts P%CPU_WB_ONLY_L, NVAX only issues 'WDISOW':N or NOPcommands.
3.2.1.6

pO/oNDAL_H<63:0>

!\'VAX uses P%NDAL_H<63:0> to transfer address and data information to and from the system.
3.2.1.7

pO/oCMD_H<3:0>

The Po/oCMD_H<3:O> lines contain the NDAL command during any given cycle. NVAX drives
and receives these lines.
3.2.1.8

P%ID_H<2:0>

NVAX drives and receives P%ID_H<2:O>, which contain the node identification number for every
cycle. These lines identify which node is driving the NDAL or which node is to receive the NDAL,
depending upon the current command.
3.2.1.9

pOkPARITY_H<2:0>

NVAX drives and receives P%PARITY_H<2:0>, which contains parity computed over P%NDAL_
H<63:0>, P%CMD_H<3:O> and P%ID_H<2:O> during every NDAL cycle.
3.2.1.10

P%ACK_L

NVAX asserts P%ACK_L when it has received a fill data cycle. NVAX receives P%ACK_L as an
acknowledgement that its outgoing cycle was successfully received. It also receives Po/oACK_L
for cycles which it did not drive on the NDAL, as a way of detecting inconsistent parity errors.
An inconsistent parity error is where NVAX detects a parity error on the NDAL and also notices
that P%ACK_L was asserted for that cycle.
P%ACK_L is an open drain signal which is pulled high (deasserted) by an external resistor on
the board.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-7

NVAX CPU Chip Functional Specification, Revi~OD 1.0, February 1991

3.2.2

Clocking signals

The NVAX CPU chip generates four two-phase clocks which are distributed to the system. These
clocks are also distributed back to itself, which minimizes skew between NVAX and the other
chips on the NDAL. Each NDAL cycle is three CPU cycles long.
The clocking signals are described in detail in Chapter 17.
3.2.2.1

P%OSC_H, POIoOSC_L

P%OSC_H and P%OSC_L are complementary oscillator inputs to NVAX. They are used to generate on-chip clocks and system clocks. When P9DOSC_TEST_H is deasserted, P%OSC_H and
P%OSC_L are used to generate NVAX clocks.
3.2.2.2

P%OSC_TC1_H, POIoOSC_TC2_H

P%OSC_TCl_H and P%OSC_TC2_H are oscillator inputs to l\TVAX for use during testing only.
'When Po/oOSC_TEST_H is asserted, P%OSC_TCl_H and P%OSC_TC.2_H are used to generate
NVJV( clocks.
P%OSC_TCl_H and Po/oOSC_TC2_H are 90 degrees out of phase with each other, and are XOR'd
internally to produce an internal clock \vhich runs at twice the speed. This allows ~-VA..~ to run
at full speed while the input clocks are running at half speed.
P%OSC_TCl_H is also used as an input to the Ebox base timeout counter as an alternate clock
for the timeout counter. Normally, the base counter is run from the internal NVAX clock; if the
system designer wants to lengthen the timeout values used by NVAX, the base counter may be
configured to run from Po/DOSC_TCl_H instead. Po/oOSC_TCl_H is synchronized to the internal
NVAX clocks in order to be used for this purpose.
3.2.2.3

P%OSC_TEST_H

P%OSC_TEST_H is a control pin which determines which oscillator inputs are used by the clock
generators. When Po/oOSC_TEST_H is deasserted, Po/DOSC_H and Po/DOSC_L are used; when
P%OSC_TEST_H is asserted, lHrDOSC_TCl_H and P%OSC_TC2_H are used.
3.2.2.4

P%PHI12_0UT_H, POIoPHI23_0UT_H, POIoPHI34_0UT_H, POkPHI41_0UT_H

These two-phase overlapping clocks are driven from the NVAX chip to all nodes on the NDAL,
including back to NVAX itself.
3.2.2.5

P%PHI12_IN_H, POIoPHI23_IN_H, POkPHI34_IN_H, P%PHI41_IN_H

These NVAX pins are used to receive the NDAL clocks, which are driven from P%PHII2_0UT_
H, P%PHI23_0UT_H, lHrcPHI34_0UT_H, and P%Pffi41_0UT_H.
3.2.2.6

P%ASYNC_RESET_L

P%ASYNC_BESET_L is an asynchronous input to NVAX which is used to generate an internal
reset signal as well as P%SYS_RESET_L.

3-8

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specificatiollt Revision 1.0, February 1991

3.2.2.7

P%SYS_RESET_L

NVAX drives P%SYS_RESET_L to notify all NDAL receivers to reset. It is deasserted synchronously with the NDAL clocks.

3.2.3

Interrupt and Error Signals

The interrupt and elTor signals are described in detail in Chapter 10.
3.2.3.1

pO/oMACHINE_CHECK_H

The assertion of P%MACHINE_CHECK_H indicates that the CPU is in a machine cheek sequence. This signal may be wired to an LED on the board. (The pin is not able to drive the LED
directly.) It will flicker during a normal machine check. If the CPU never comes out of machine
check, the LED will stay lit and indicates to Field Service that the board needs to be replaced.
3.2.3.2

pOkIRQ_l<3:0>

The P%m~L<3:0> lines provide a general-purpose interrupt request facility to interrupt the
~'VAX CPU. These four external interrupt request lines cOlTespond to interrupt requests at IPLs
17,16,15, and 14 (hex). P%m~L<3> corresponds to IPL 17, P%IR~L<2> cOlTesponds to IPL
16, p%m~L<l> cOlTesponds to IPL 15, and p%m(LL<O> cOlTesponds to IPL 14. These lines
are level-sensitive, NOT edge sensitive. Once a node asserts its interrupt line, it should keep it
asserted until N'VAX services the request.
p%m~L<3:0> are asynchronous inputs to NVAX and are not expected to operate with any fixed

relationship to the NDAL timing.
3.2.3.3

p%H_ERR_l

P%H_ERR_L is used to notify NVAX of an error condition in the system which has cOITUpted
machine state. These elTors usually cannot be colTected by any retry mechanism.
If at all possible, NDAL errors should be reported using the transaction level error reporting
mechanisms (not asserting P%ACK_L or using the Read Data Error command). If this is not
possible, P%H_ERR_L or Po/oS_ERR_L may be used. When P%H_EBR_L is asserted, NVAX
will take a Hard Error InteITu.pt at IPL 1D (hex).

P%H_ERR_L is an asynchronous input to NVAX and is not expected to operate with any fixed
relationship to the NDAL timing.
3.2.3.4

p%S_ERR_l

The assertion of P%S_ERR_L indicates that an error which did not affect instruction execution has been detected in the system environment. For example, if an NDAL node uses the
BADWDATA because of an uncorrectable error in its cache, it would also assert P%S_ERR_L to
notify NVAX of the event. When it recognizes the assertion of P%S_ERR_L, NVAX takes a Soft
ElTor Interrupt at IPL 1A (hex).

P%S_ERR_L is an asynchronous input to NVAX and is not expected to operate with any fixed
relationship to the NDAL timing.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-9

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.2.3.5

POkINT_TIM_L

The assertion of P%INT_TIM_L indicates that the interval timer period has expired.
P%INT_TIM_L is an asynchronous input to NVAX and is not expected to operate with any fixed
relationship to the NDAL timing.
3.2.3.6

P%PWRFL_L

The assertion of P%PWRFL_L informs the CPU of an impending power failure.
P%PWRFL_L is an asynchronous input to NVAX and is not expected to operate with any fixed
relationship to the NDAL timing.
3.2.3.7

P%HAl.T_L

The assertion of ProHALT_L causes the CPU to enter the console at IPL IF (hex) at the next
macroinstruction boundary.
P%HALT_L is an asynchronous input to NVAX and is not expected to operate with any fixed
relationship to the NDAL timing.

3.2.4

Cache interface signals

These pins are described in detail in Chapter 13. The timing of the pins is shown in Figure 3-2.
NOTE

The timing of the Bcache interface signals is given relative to the INTERNAL hTVAX
clocks.
3.2.4.1

pOkTS_INDEX_H<20:S>

P%TS_INDEX_H<20:5> drive the address lines of the backup cache tag RAMs, thus indexing
into one row of the tag store.
3.2.4.2

POkTS_OE_L

This pin is connected to the output enable pins of the backup cache tag store RAMs. When NVAX
asserts P%TS_OE_L, the RAMs are enabled to drive P%TS_TAG_H<31:17>, P%TS_VALID_H,
P%TS_OWNED_H, and P%TS_ECC_H<5:0>.

3.2A.3

pOkTS_WE_L

This pin is connected to the write enable pins of the backup cache tag store RAMs. When
NVAX asserts P%TS_WE_L, the RAMs are enabled to write the information on P%TS_TAG_
H<31:17>, P%TS_VALID_H, P%TS_OWNED_H, and P%TS_ECC_H<5:0>, which NVAX drives
when P%TS_WE_L is asserted.

3-10

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-2:

Bcache Pin TIming Relative to INTERNAL NVAX Clocks (14ns system)
eye L E , - - - - I - - - - o N N V A:X eye L E : - - - -

- - - - I - - - - N N V A:X

~---------IE
8.0n~
~ri"'" by.WAX at

________.

~SSSsssss,ssssssss,sS'

""~ or ph_:i_3_ _ _ _ _ __

i77777777177777777i777

____i ..

IE
S.On.
~i
As c1riven by NVAX :

S.On.~

rted at ""~ of ph~'. ""Ujrted at

'SSSSSSSS'SSSSSSSSSSS\

P%'.rS_WE_L

e.Ons~

As c:lrivan by NVAX :

As.ertec:1 at beginn:i.ng of phi3,

?%'1'S ECC 5<5:0>
P%'1'S-TAG-5<31:17>

---I

1717171777777777777171

?t'.rS_WE_L

P%TS EC= 5<5:0>
P%TS-TAG-5<31:17>
?%'1'S-O~ E
P%TS:V;''':'ZD:S

""gimlinq of phi.

---.

.E
S . Ons
~
cieasaertec:1 at beg:i.nnUlg of phil

~««««««««««({ w:~~e dA~a

As c:lriven by NVAX
1):ivan at :be¢nn:i.ng of phH;

xxxxxxxXxxxxxx

P%TS-o~"fD 3

As requirec:1 by WAX

VUi· 1. 5"" bafon phi2;

E
8. 5ns
~
: 1. 5n~
'.r:iat&-ced. a.~ :be~nnin; of phi'

I
II

»)~
iE-

.
I
.,
i»»»»»»»»)i»}»»)i)}»»»

rea~ aa~a

P%'.rS:VALID:B

~:istata ~t l>eg:i.n%'l.l.ng of phi4
u10w WAX to ""_i_ve
_ _ _ _ _ __

~---------IE

S.Ons

Dri~ by ~ at tba ~g1rmi1>g Ior phi3 . _ _ _ _ _ _ _ _ _ _ __

\SSSSSSSS'SSSSSSSS'ss'

il7111177111111111illl
IE
S.Ona
~I
I

Ie
S.Ona
~i
As c:lrivan by NVAX :

____ioertad ""gimli i " . . . T
at

ted

ZSSSSSSSSZSSSSSSSS{SS\'

P%OR_WE_L

S.Ons

As c:lriven by NVAX
Assertec:1 at beginning of ph:i3,

- I :! :!---:
P%OR ECC B<7:0>
P%OR:OA'.ri_B<63:0>
P%OR Ece 5<7: 0>

P%OR:o~i_B<63:0>

at ~gimIin<;: of phi'

~777727'1~!!11777'f7

I:
!:
!

daaaaertec:1 at beginning of phil

X>OOOOOOOOOOOOO

As c1riven by NVAX

orivi at be~ing of phi i

read data

wrl.te dita::::J}})
-~S-.-S-n~: 1.Sn;::;j
IE:ristatec:1~at be~ of

P:u'

»»»»> >})}}})}»»»»»}>}»}».

As required by W A X : :
VaJ.id at beginning of ph:i2
: :

---- 1----i

i
:---

: : :

'.rristate at beginning of phi4
to aJ.l.ow WAX to dr:f.ve

i---- ----1---- ---- ---- ----

NOTE: Al.l. c:lrive times are shown as simul.atec:1 in the XNP boarc:1 environment with typical. (14na) WAX
parts; drive times in other environments and nth non-typical. WAX parts will differ. ~e diagram
assumes a 14-ns WAX cycl.e.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-11

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.2.4.4

P%TS_TAG_H<31 :17>

P%TS_TAG_H<31:17> car.ry the tag which is written to and read from the backup cache tag
store. Each of these pads is built with an internal resistor so that if the tag bit is not used in a
particular system, the pin value as seen by the Cbox is O. For example, a machine which runs
only in SO-bit mode does not need to connect P%TS_TAG_H<31:29> to the backup cache.
3.2.4.5

POkTS_ECC_H<5:0>

P%TS_ECC_H<5:0 > carry the error correcting code which is written to and read from the backup
cache tag store.
3.2.4.6

pOkTS_OWNED_H

P%TS_OWNED_H carries the OWNED bit which is written to and read from the backup cache
tag store.
3.2.4.7

pOkTS_VAlID_H

P'ibTS_VALID_H carries the VALID bit which is written to and read from the backup cache tag
store.
3.2.4.8

P"oDR_INDEX_H<20:3>

P%DR_INDEX_H<20:3> drive the address lines of the backup cache data RAMs, thus indexing
into one row (one quadword) of the cache.
3.2.4.9

P"oDR_OE_L

This pin is connected to the output enable pins of the backup cache data RAMs. When NVAX
asserts P%DR_OE_L, the RAMs are enabled to drive Po/oDR_DATA_H<63:0> and P%DR_ECC_
H<7:0>.
3.2.4.10

P%DR_WE_l

This pin is connected to the write enable pins of the backup cache data RAMs. When NVAX asserts
P%DR_WE_L, the RAMs are enabled to write the information on P%DR_DATA_H<63:0> and
P%DR_ECC_H<7:0>, which NVAX drives when P9DDR_WE_L is asserted.
3.2.4.11

P%DR_DATA_H<63:0>

P%DR_DATA_H<63:O> carry the cache data which is written to and read from the backup cache.
3.2.4.12

POkDR_ECC_H<7:0>

P%DR_ECC_H<7:0 > carry the error correcting code which is written to and read from the
backup cache data RAMs.

3-12

NVAX Chip Interface

DIGITAL. CONFIDENTIAL.

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.2.5

Test Pins

These pins are covered in more detail in Chapter 19.
3.2.5.1

P%TEST_DATA_H

TEST_DATA_H.is an asynchronous input pin which may be used by microcode. It is pulled high
internally so that if it is not used, it does not have to be connected on the board.
3.2.5.2

P% TEST_STROBE_H

TEST_STROBE_H is an asynchronous input pin which may be used by microcode. It is pulled
high internally so that if it is not used, it does not have to be connected on the board.
3.2.5.3

pO/oDISABLE_OUT_L

When P%DISABLE_OUT_L is asserted, NVAX does not drive any of its Input/Output or Output
pins, including the NDAL clock outputs CP%Pln12_0UT_H, P%PHI23_0UT_H, P%Pffi34_
OUT_H and P%PHI41_0UT_H).
This functionality is used only during test.
3.2.5.4

P% TEMP_H

P%TEMP_H is an output pin to be used in test to determine when the NVAX CPU chip is at
thermal equilibrium. The voltage on this pin will vary between VDD_I and VSS_I, depending on
chip temperature, but the temperature to voltage transfer function will not be specified.

As the chip heats up the voltage on the pin will fall, and once the chip is at thermal equilibrium
the voltage will remain at some value below VDD_I. This voltage will be monitored by the tester,
and testing will commence only when the voltage stops changing, indicating that the chip is at
thermal equilibrium.
3.2.5.5

P%TMS_H

P%TMS_H is the JTAG test mode select input. It is pulled high by an on-chip resistor when it
is not being driven externally.
3.2.5.6

POkTCK_H

P%TCK_H is the JTAG test clock. It is pulled low by an on-chip resistor when it is not being
driven externally.
3.2.5.7

P%TDI_H

P%TDI_H is the JTAG serial test data input. It is pulled high by an on-chip resistor when it is
not being driven externally.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-13

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.2.5.8

pOkTDO_H

P%TDO_H is the JTAG serial test data output.
3.2.5.9

pOkPP_CMD_H<2:0>

p%pp_CMD_H<2:0> provides the NVAX parallel port a command indicating the current function
of the parallel port.
3.2.5.10

POkPP_DATA_H<11:D>

P%PP_DATA_H<II:O> are output pins for reading test data from NVAX.

3-14

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specifi.catiollt Revision 1.0, February 1991

3.3

The NDAL
The NDAL is a 64-bit limited length, pended, synchronous bus with centralized arbitration.
Several transactions can be in progress at a given time, allowing highly efficient use of bus
bandwidth. Arbitration and data transfers occur simultaneously. The bus uses multiplexed data
and address lines. The NDAL supports quadword, octaword and hexaword reads and writes to
memory and 110 space.
The NDAL supports up to four (4) nodes with a maximum of one (1) NVAX CPU. In this spec, these
four nodes are referred to as CPU (NVAX), IOl_NODE, 102_NODE, and the memory interface.
Thirty nanoseconds is the minimum NDAL cycle time being considered for a binned CPU.
Operating at 30ns, the NDAL has a raw bandwidth of 267 Mbytes/second. At 42ns, the NDAL
has a raw bandwidth of 190 Mbytes/second. The usable bandwidth, which depends on transaction
length, is shown in Table 3-3 and Table 3-4:.
Table 3-3:

NVAX DAL Bandwidth at 30ns

Operation

Bandwidth

Quadword Read

133.0 Mbytes/sec

Octa.word Read

178.0 Mbytes/sec

Hexaword Read

213.0 Mbytes/sec

Quadword Write

133.0 :Mbytes/sec

Oet.a.word Write

178.0 Mbytes/sec

Hexaword Write

213.0 Mbytes/sec

Table 3-4:

NVAX DAL Bandwidth at 42ns

Operation

Bandwidth

Quadword Read

95.0 Mbyteslsec

Oet.a.word Read

127.0 Mbyteslsec

Hexaword Read

152.0 Mbytes/sec

Quadword Write

95.0 Mbyteslsec

Octaword Write

127.0 Mbyteslsec

Hexaword Write

152.0 Mbyteslsec

Table 3-5 details each NDAL signal. Where All is indicated for Drivers and Receivers, all four
possible NDAL nodes drive or receive the signal.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-15

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-5:
SigDa!

NDAL Signals
Type!

Drivers

Receivers

Function

Arbitration sigDals

P'ltCPU_REQ..L

NVAX

Arbiter

NVAX requests the bus.

IOl_RE<LL

IOl_NODE

Arbiter

IOl_NODE requests the bus.

I02_RE<LL

I02_NODE

Arbiter

I02_NODE requests the bus.

Po/tCPU_HOLD_L

NVAX

Arbiter

Extends Po/t>CPU_GBANT_L.

IOl_HOLD_L

10l_NODE

Arbiter

Extends IOl_GRANT.

I02_HOLD_L

102_NODE

Arbiter

Extends I02_GRANT.

Po/tCPU_GRANT_L

Arbiter

NVAX

Grants NVAX the bus.

IOl_GRANT_L

Arbiter

10 I_NODE

Grants IOI_NODE the bus.

I02_GRMTT_L

Arbiter

I02_NODE

Grants I02_NODE the bus.

PO/OCPU_SUPPRESS_L

NVAX

Arbiter

Suppresses all but writebacks and fills.

PO/OCPU_WB_O~'"LY_L

Arbiter

NVAX

Limits NVAX to doing only Disown Writes
or NOPs.

10l_SLTPPRESS_L

IOl_NODE

Arbiter

Suppresses all but writebacks and fills.

101_WB_01'l'"LY_L

Arbiter

IOl_NODE

IOl_NODE may only do Disown Writes
and :fills.

I02_SUPPRES8_L

I02_NODE

Arbiter

Suppresses all but writebacks and fills.

102_WB_ONLY_L

Arbiter

I02_NODE

I02_NODE may only do Disown Writes
and :fills.

Data, address, and com.mand sigDals

All

Multiplexed data and address lines.

Po/oCMD_H<3:0>

T
T

All

Command being performed this cycle.

P%ID_B<2:O>

All

Commander identification for the transaction.

P'loPARITY_B<2:O>

All

P%NDAL_B<63:O>

Parity for P%NDAL_H, P%CMD_H, and

KID_H.
OD

All

Po/oSYS_RESET_L

NVAX

All but NVAX Resets all nodes.

Pln12_H

NVAX

All

PHI12 clock for all bus residents.

Pm23_H

NVAX

All

Pln23 clock for all bus residents.

PHI34_H

NVAX

All

pm34 clock for all bus residents.

PHI4l_H

NVAX

All

pm4l clock for all bus residents.

Po/oACK_L

NDAL acknowledgement of receipt.

Clock sigDals

1Indicates whether the pin is Bingle 80urce (B8), '.1ristate (T), or Open Drain (OD)

3-16

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.1

Terms

In order to clearly describe the transactions which occur on the NDAL, the following terms are
used:
•
•

•

•
•

•

•
•
•

Node - A node is a hardware device that connects to the NDAL. The largest NDAL system
configuration will support 4 nodes.
Transfer - A transfer is the smallest quantum of work that occurs on the NDAL. Typical
examples of transfers are the address cycle of a read, the address cycle of a write, and each
data cycle of a write.
Transaction - A transaction is composed of one or more transfers. Transaction is the name
given to the logical task being performed (e.g., read); in the case of the read specifically, the
transaction consists of a command transfer followed some time later by a return data transfer.
See Commander, Responder, Transmitter, and Receiver below.
Commander - The commander is the node that initiated the transaction in progress. In
any write transaction, the commander is the node that requested the write; for reads, the
commander is the one who requested the data. The distinction of being the commander in a
transaction holds for the duration of the transaction in spite of the fact that in some cases it
might appear that the commander changes. A case in point is where the commander initiates
a read transaction. It is the responder (data source) that initiates the return data transfer,
but the node that requested the data is still the commander.
Responder - The responder is the complement to the commander in a transaction.
Transmitter - The transmitter during an !'.c~AL cycle is the node that is driving the information on the NDAL. Using the read transaction as an example, the commander is the
transmitter .during the command transfer; during the return data transfer the commander is
the receiver.
Receiver - The receiver receives the data being moved during a transfer.
Naturally Aligned - Refers to a data quantity whose address could be specified as an offset,
from the beginning of memory, of an integral number of data elements of the same size. The
lower address bits of a piece of naturally aligned data are zero.
ETM - Error Transition Mode. The backup cache enters Error Transition Mode when an error
occurs. While in ETM, the state of the backup cache is preserved as much as possible. It
continues to service requests to blocks which it owns, since those contain the only valid copy
of data in the system. ETM is described completely in Chapter 13.
Address cycle - The cycle during which the address of the transaction is transmitted on the
NDAL. This is the first cycle of a read or write.
Data cycle - A cycle during which the NDAL transfers data. These include data cycles of a
write and fill data cycles.
Read Data Return - This is the command used during a cycle in which a responder is returning
read data to a commander. These cycles are also referred to as fills.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-17

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.2

NDAL Clocking

The NDAL is a four-phase bus. NVAX drives four two-phase overlapping clocks to the other chips
on the NDAL as well as back to itself, as shown in Table ~.
Table 3-6:

NDAL clocks

NVAX output pin

NDAL clock

NVAX input pin

P%PBl12_0UT_H
P%PBl23_0UT_H
P%PBl34_0UT_H
Po/oPID41_0UT_H

PHI12_H
PHI23_H
PHI34_B

P%PBIl2_IN_H
P%PBI23_IN_H
P9'tPm34_IN_H
P%Pm:41_IN_H

PHI41_H

See Chapter 17 for more details.

3.3.3

NDAL Arbitration

The NDAL protocol can architecturally support up to 4 nodes, which consist of one NVAX CPU
and three interfaces to memory or 110. This spec assumes one interface to memory and two
interfaces to 110. The 110 interfaces are referred to as I01_NODE and I02_NODE. The non-CPU
nodes mayor may not contain caches.

use

At a given time, any or all of the nodes may desire the
of the ~-nAL. Arbitration cycles occur
in parallel with data transfer cycles using a set of lines dedicated specifically for arbitration.
Figure 3-3 shows the connection of the arbitration signals on the fully-configured NDAL. This
arbitration scheme assumes that the arbiter is built into the memory interface. If the arbiter
were built as a separate chip, the memory interface would nee,d its own request, hold, grant,
suppress, and wb_only lines. When the arbiter is built into the memory interface, the memory
interface can withhold grant if its input queues are filling up.

3-18

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specificati~n, Revision 1.0, February 1991

Figure 3-3:

NDAL Arbitration Block Diagram

.---------. CPU REO L

1
1
1 NVAX
1
1
1
1
1
1

---------

1----=---=---------------->1
1 CPU HOLD L
1
I----~----=--------------->I

1 CPU_GRANT_L
1
1<-------------------------1
1 CPU SUPPRESS L
1
1----=--------=----------->1
1 CPU WB ONLY L
1
I<---~--~----=-------------I

,---------,

1 Arbiter
1

1 Memory

1Inter!acQI
1

.---------. I01_P~Q_L

!Cl_P.~~D_~

:~:_G?~.!::_:.

1<-------------------------1

1------------------------->1

I:Ol_N:iD~

1------------------------->1
1

:O:_S::?P?~SS_:.

I------------------------->i

1
1

:<-------------------------i
,---------,

. ---------. :c: ?~'~ l
:
:----=---=---------------->1
1
1 102 HOLD L
1
1:02 NODE !----=----=--------------->I
1

I02_GRANT_L

1<-------------------------1
1 102 SUPPR!:SS l
1

1
1
1

1----=--------=----------->1
1 I02_WB_ONLY_L
1
1<-------------------------1

,---------,

The following sections describe the NDAL arbitration signals.
3.3.3.1
3.3.3.1.1

NDAL Arbitration Signals
P%CPU_REQ_L

NVAX asserts P%CPU_REQ..,L to request the NDAL for the following cycle. PrDCPU_REQ..,L
is a unidirectional signal from NVAX to the arbiter.
3.3.3.1.2

I01_REQ_L

IOl_NODE, an interface node, asserts IOI_REQ..L when it wants to drive the NDAL. IOl_REQ..L
is a unidirectional signal from IOI_NODE to the arbiter.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-19

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.3.1.3

I02_REQ_L

I02_NODE, an interface node, asserts I02_RE~L when it wants to drive the NDAL. I02_RE'LL
is a unidirectional signal from I02_NODE to the arbiter.
3.3.3.1.4

pO/oCPU_HOLD_L

The NVAX CPU asserts Po/£PU_HOLD_L in order to gain access to the NDAL for consecutive
cycles. The NVAX CPU only asserts Po/oCPU_HOLD_L when PlfoCPU_GBANT_L is asserted;
it never asserts P%CPU_HOLD_L unless Po/oCPU_GBANT_L is asserted. Assertion of
P%CPU_HOLD_L guarantees that NVAX may retain ownership of the NDAL in the next cycle,
independent of the value of any other outstanding requests. The arbiter must grant the bus to
the CPU if the CPU asserts Po/£PU_HOLD_L.
P%CPU_HOLD_L is used for multicycle transfers, allowing NVAX to acquire consecutive cycles.
NVAX asserts P%CPU_HOLD_L for hexaword Disown Write transactions, in order to transfer
the four quadwords of data consecutively and directly after the address cycle; and for quadword
Write or Disown Write transactions, in order to transfer the one quadword of data directly after
the address cycle. NVAX never asserts P%CPU_HOLD_L for more than four contiguous cycles.
3.3.3.1.5

I01_HOLD_L

IOl_HOLD_L is analogous to Po/cCPU_HOLD_L. It performs HOLD functionality for
IOl_NODE.
IOl_NODE may not assert IOl_HOLD_L unless IOI_GRANT_L is asserted during the current
~"DAL cycle. Assertion ofIOI_HOLD_L guarantees that IOI_NODE may retain ownership of the

NDAL in the next cycle, independent of the value of any other outstanding requests. The arbiter
must grant the bus to IOl_NODE if it asserts IOl_HOLD_L.
IOl_HOLD_L signal is used for multicycle transfers, allowing IOI_NODE to acquire consecutive
cycles. In a hexaword write transaction, for instance, IOl_NODE asserts IOI_HOLD_L in order
to transfer the four quadwords of data consecutively. IOI_HOLD_L may also be used to transfer
Fill data in consecutive cycles. 101_HOLD_L may be asserted for a maximum of four contiguous
cycles.
3.3.3.1.6

I02_HOLD_L

I02_HOLD_L is analogous to 101_HOLD_L. It performs HOLD functionality for I02_NODE.
3.3.3.1.7

POIoCPU_SUPPRESS_L

NVAX asserts Po/£PU_SUPPRESS_L in order to suppress new NDAL transactions which NVAX
treats as cache coherency requests. It does this when its two-entry cache coherency queue (the
NDAL_IN_QUEUE) is in danger of overflowing.
During the cycle when Po/£PU_SUPPRESS_L is asserted, NVAX will accept a new transaction.
NVAX requires transactions in the following cycle to be suppressed.

3-20 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

While Pt;OCPU_SUPPRESS_L is asserted, only fills and writebacks are allowed to proceed
from non-CPU nodes. The CPU may continue to put all transactions onto the bus (as long
as Po/oCPU_WB_ONLY_L is not asserted). Because the NDAL_IN_QUEUE is full and takes the
highest priority within the Cbox, NVAX is mostly working on cache coherency transactions while
P%CPU_SUPPRESS_L is asserted, which may cause NVAX to issue WDISOWNs on the NDAL.
However, NVAX may and does issue any type of transaction while P%CPU_SUPPRESS_L is
asserted.
3.3.3.1.8

I01_SUPPRESS_L

IOl_NODE can suppress new transactions on the NDAL by asserting IOl_SUPPRESS_L. Fills
and writebacks will proceed as usual.
3.3.3.1.9

I02_SUPPRESS_L

I02_NODE can suppress new transactions on the NDAL by asserting I02_SUPPRESS_L. Fills
and writebacks will proceed as usual.
3.3.3.1.10

P%CPU_GRANT_L

Pt7cCPU_GR.A-"'TT_L is asserted to notify ~-v..4J( that it must drive the !\'T!>AL during the following
cycle. Vthen P7cCPU_GRANT_L is asserted, ~"VAX must drive the bus with a valid command
and correct parity. If NVAX did not request the NDAL, it drives the bus with a NOP. It only
drives a non-NOP command if it actually requested the NDAL in the previous cycle.
IfNVAX asserts P%CPU_HOLD_L, P%CPU_GRANT_L must be asserted in the next cycle.
3.3.3.1.11

I01_GRANT_L

The arbiter asserts IOl_GRANT_L when IOl_NODE is permitted to drive the bus. When
IOl_GRANT_L is asserted, IOl_NODE must drive the bus with a valid command and correct
parity. If IOl_HOLD_L is asserted, IOl_GRANT_L must be asserted in the next cycle.
3.3.3.1.12

I02_GRANT_L

I02_GRANT_L is analogous to IOl_GRANT_L. It grants the bus to I02_NODE.
3.3.3.1.13

p%CPU_WB_ONLY_L

When Po/oCPU_WB_ONLY_L is asserted, NV.AX will only issue Write Disown or NOPcommands,
including Write Disowns due to Write Unlocks when the cache is off or in ETM. Otherwise, NVAX
will not issue any new requests. During the cycle in which P%CPU_WB_ONLY_L is asserted,
the system must be prepared to accept one more non-writeback. command from the CPU. Starting
with the cycle following the assertion of P9"oCPU_WB_ONLY_L, NVAX will only issue writeback.
commands.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-21

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.3.1~14

I01_WB_ONLY_L

101_WB_ONLY_L is driven by the arbiter and received by 101_NODE. When 101_WB_ONLY_L
is asserted, 101_NODE only arbs for the bus in order to return. fills or disown writes. It does not
initiate any new transactions.
3.3.3.1.15

I02_WB_ONLY_L

102_WB_ONLY_L is driven by the arbiter and received by I02_NODE. When 102_WB_ONLY_L
is asserted, 102_NODE only arbs for the bus in order to return. fills or disown writes. It does not
initiate any new transactions.
3.3.3.2

NDAL Arbitration Timing

The timing for NDAL arbitration is shown in Figure 3-4. There are several critical spots to note
in the diagram. The arbiter receives the request lines by the end of PI. It must drive the grant
lines to \"alid values by the end ofP3. It has two phases to calculate arbitration and to drive the
grant lines across the board.
In the fastest system (IOns ~"VAX), the arbiter has 15ns after receiving the request lines to
arbitrate and to drive the grant lines. Board simulations for one system show that driving the
grant lines will take about half that time.
From the time a bus driver receives its grant line, it has three phases to drive P%NDAL_H<63:0>,
P%CMD_H<3:0>, P%ID_H<2:0>, and Po/cPARITY_H<2:0> to valid levels.
From the time the NDAL is valid on its pins, the receiver has four phases to compute parity and
to assert P%ACK_L.

3-22 NVAX Chip Interface

DIGITAL CONFIDENTIAL

c
i5

i;!r
o

--" D A L

8m
~

NDAL H

CPUflO_L

;;:

C Y C L &:

---I--N
I_P4__
o

\\\\\\\\\\

-arbiter-

s
~
w

»>--

z
j
r
»

it0"
OlllllUl1

grlmt held because of CPU HOLD_ L

bun not granted to 10 NODEl

-arbiter-

NULL cycle hot ACKod

/...

_ _ _ _ _ _--1

\\\\\\\\\\\\\\\\\\\\\~

11WIW
write address oyole ACKed

-------- \

---',------~--,

bus granted

\\.-_ _ _ __

\___

toc::J

=
a

~
~

g
~

ia
~

_n~,-

:::I

\.\\\.\.\.\.\.\.'\\

CiI

..g

bus granted to CPU

!I.

PHIU

s
~

U)---{JUTUH « « H « «
drive write data

filllllttt

AC~L

o
:r

2----

Lp:

\.'-'-\.\.\.\.\.\..'-.

IOI_GRANT_L

. . -l . ~)~.-.-.-I

L p2

\\\'\ill\\\'
1l7lll7l11
CPU holds bus 1:0 drive w.rUe data

IOI_REO_L

PHI34

~.---r Pl~:t C'I

drive write addr.eulJ

\\\\\\\\\\\
CPU request to do write

CPU_GRANT_L

C Y G J.~:

-< <<<<« (S UUUUJJ---------u}---{UU JUJU U<ilill

CPU_HOLD_L

PHI23

D A L

-~-.I-~-

null data oyole

PHIl2

1--- - - - - - - - - - - - -

---I------I----i--- - - - - - - - - -

J
~

cc
cc
~

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.3.3

NDAL Suppress and Its nmlng

When any node asserts its suppress line, no transactions other than writebacks or fills must be
driven onto the bus, starting in the following cycle. For example, when Po/cCPU_SUPPRESS_L
is asserted, the arbiter can accomplish this in the following way: if P9"cCPU_SUPPRESS_L is
asserted during cycle 0, the arbiter does not grant the bus to any node, with the possible exception
of the CPU, in cycle O. At the same time it asserts 101_'WB_ONLY and 102_WB_ONLY. In cycle
1, the arbiter continues to perform bus arbitration as it normally would, but now IOI_NODE and
I02_NODE recognize the assertion of their respective W'B_ONLY lines, and they do not request
the bus except for fills and writebacks.
From this, it may be seen that the assertion of Po/oCPU_SUPPRESS_L causes the arbiter
to assert 101_WB_ONLY_L and 102_'WB_ONLY_L; the assertion of 101_SUPPRESS_L causes
the arbiter to assert Po/oCPU_WB_ONLY_L and 102_WB_ONLY_L; and the assertion of
I02_SUPPRESS_L causes the arbiter to assert Po/cCPU_WB_ONLY_L and 101_WB_ONLY_L.
The timing for suppression of the bus is shown in Figure 3-5. In this example, the CPU suppresses
the bus by asserting P%CPU_SUPPRESS_L, which is valid at the end of PI in NDAL cycle O.
The arbiter immediately asserts 101_,\\'B_01\TLY_L and 102_,\\'B_ONLY_L, which are valid by
the end of P3 in the same cycle. This notifies IOI_NODE and 102_NODE that they should not
arbitrate for the bus for new transactions, only for writebacks and fills. (If the 10 chip cannot
suppress its request line quickly enough, it may drive NOPs onto the !\"D.A.L if it gets GRAl\"T,
instead of '\vithdrawing its request in the first cycle.) Accordingly, in ~'"D.AL CYCLE 1 as shown
in the diagram, IOI_RE~L is deasserted by IOI_NODE, since it has a read or.a write request
to do. I02_RE'LL remains asserted because 102_NODE has a fill to do.
During the cycle in which Po/oCPU_SUPPRESS...L is asserted, the arbiter does not grant to any
node with the exception of the CPU. Since it is the one suppressing the bus it should be allowed
to continue issuing transactions on the bus.
If a node had its HOLD line asserted and it had been granted the bus in the cycle before, it
WOULD get grant under suppress. The rules for HOLD override the rules for SUPPRESS.
In NDAL CYCLE 1, the bus is granted to 102_NODE which has arb'd to do its fill. The:fill is
driven in NDAL cycle 2.
3.3.3.4

NDAL Arbitration Rules

The rules of arbitration are as follows:
1. Any node may assert its request line during any cycle.
2. A node's grant line must be asserted before that node drives the NDAL.
3. An NDAL driver may only assert its HOLD_L line if it has been granted the bus for the
current cycle.
4. If a node has been granted the bus, and it asserts HOLD, it is guaranteed to be granted the
bus in the following cycle.
5. HOLD may only be used in two cases: (a) to hold the bus for the data cycles of a write; (b) to
send consecutive :fill cycles.

3-24

NVAX Chip Interface

DIGITAL CONFIDENTIAL

c
i5

....~

-N D A L

o
o
z

:!!

c
m

~
l>
r-

<UillUIUllmU{~---

NDAL_H

--I--N
I

C Y C L E

CPU_SUPPRIlSS_L

._p_l__ I_~

U~(

s lO_NODEl drives read address

D A L

C Y C I. Po

---1N
__

____ I_ . _~~_I_~_4

CPU drives rend ndd~ess

~_I~

2---

:read data return driven by IO_NODE2:

z
c

~ill\\\\'

IIlllTTl171

C
'U
"V

\\\\\\\,\\

11UIUll7
NB ONLY deaaserted
after SUpfRESS dea.serted

arbiter asserts 101 NB ONLY L due to suppress
- -

I02_WB_ONLY_L

C YC L E

U )-{UllUllIIHllllU--- -=:7»-

UUH UUH (UU

s CPU suppresses bus due to full input queue

IOl_WB_ONLY_L

D A L

J1
ca

\\\\\\\\\\

U7lllTlll

arbiter as.erts I02_WB_ONLY_L due to suppress

I...
i:r

ca
IOl_RIlQ_L

I02_REQ_L

""'\\\\\\

CPU_RIlQ_L

""",,"ill'

request for fill

fill request remn.i.llIJ

request for read

IUUflju/

nflll~""

,·d

0
0

Et.

111101171

: request withdrawn after grant

171111/111

IOl_GRANT_L

0
."tt

I01_WD_ONLY_L

read/write request

bus not re-granted due to suppress

Et.

bus not granted due to suppraso;

CPU GRANT L

o
:r

PHI12

""''''''

bus grnnl:ed in cycle after suppress

J
f

011111171

bus granted to CPU under CPU_SUJ?PltESS

!i.
I

, ' -_ _ __

S
~

j:>

PHI23

_ _---II

PHI34

_______,

~U1

PHIU

UUUlZll7

\\\\\\\\\~.

I02_GRAN'r_L

r-----

r---

----,

- - - - - - - - - - - - ---1------1

, _ __

/
--,

·--I·-·------j·--+

/
-I - - - - -

j....

i....

NVAX CPU Chip Functional Specification, Hevision 1.0, February 1991

6. HOLD must be used to retain the bus for the data cycles of a write, as the data cycles must
be contiguous with the write address cycle.
7. HOLD must not be used to retain the bus for new transactions, as arbitration fairness would
not be maintained.
8. If a node requests the bus and is granted the bus, it must drive the NDAL during the granted
cycle with a valid command. NOP is a valid command. NVAX takes this a step further and
drives NOP if it is granted the bus when it did not request it.
9. Any node which issues a read must be able to accept the corresponding fills as they cannot
be suppressed or slowed.
10. If a node's WB_ONLY line is asserted, it may only drive the NDAL with NOP, RDE, RORn,
WDISOWN, WDATA, or BADWDATA.
11. If a node asserts its SUPPRESS line, the arbiter must not grant the bus to any node
except that one in the next cycle. At the same time the arbiter must assert the appropriate
'WB_ONLY lines. In the following cycle, the arbiter must grant the bus normally.
12. The rules for HOLD override the rules for SUPPRESS.
13. The bus must be actively driven during every cycle.
Specifics on arbitration algorithms may be found in the system specs for each ~~.AX system.

3-26 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.4

NDAl Information Transfer

3.3.4.1

p % NDAL_H<63:0>

The use of this field is multiplexed between address and data information. On data cycles the
lines represent 64 bits of read or write data; on address cycles the lines represent address, byte
enable, and length information.
There are four types of data cycles: Write Data, Bad Write Data, Read Data Return, and
Read Data Error. During write data cycles the commander drives its Commander ID on
P%ID_H<2:O> and drives data on P%NDAL_H<63:0>. The full 64 bits of data are written
during hexaword writes. For octaword and quadword length writes, the data bytes which are
written correspond to the byte enable hits which were asserted during the address cycle which
initiated the transaction. During Read Data Return and Read Data Error cycles the responder
drives the original commander ID.
The ~'"DAL address cycle is used by a commander to initiate an NDAL transaction. On address
cycles the address is driv.en in the lo\ver longword of the bus, and the byte enable and transaction
length are in the upper longword, as shown in Figure 3-6.
Figure 3-6:

Address Cycle Format

---~--~--~--~--~--~-----------~-----------~--~--~-----~--~--~--~--~--~--~--~-----~--~-----~--~--~
: :";i::

~-----~--~-----------------------------~--~--~--------------------~--~--------~--------~-----~--~

3: 30 29 2812i 26 25 24::3 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

space

aaaress

---+--+--~--~--~--~--~--------~--~--+--+--+--+--~-----+--~--~--+--+--+-----~--~--~--~--+--+--+--+

,-- Mem -

000 •• 110

I/O - III

Each field shown in the diagram is described in the sections which follow.
3.3.4.1.1

Address Field

The address space supported by the NDAL is divided into memory space and 110 space.
The lower 32 bits of the address cycle P%NDAL_H<31:0> define the address of an NDAL read
or write transaction. The NDAL supports a 4 Gigabyte (2**32 byte) address space. The most
significant hits of this address (corresponding to lines P%NDAL_H<31:29» select 512 Mb 110
space (P%NDAL_H<31:29> = 111) or 3.5 Gb memory space <P%NDAL_H<31:29> =000 .. 110).
Figure 3-7 illustrates the division of the address space into memory space and 110 space.
The division of the NDAL address space in the 110 region is further defined to accommodate the
need for NDAL node and 110 node address space. More information about the division of 110
space may be found in Chapter 2.

DIGITAL CONFIDENTIAL

NVAX Chip Interface

3-27

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-7:
00000000

Physical Address Space Layout

+-------------------------+
-+I

+I
I

I
-+

+I
I

Memory

Space

I :;.5 Gigabytes

I
-+

I
I
-+

::0

i
I

::.2 Me:;~::'":es

Address bits <31:0> are all significant bits in an address to 1/0 space. Although the length field
on the ~"DAL is always quadword for I/O space reads and writes, the actual amount of data
read or written may be less than a quadword. The byte enable is used to read or write the
requested bytes only. If the byte enable indicates a I-byte read or write, every bit of the address
is significant. The lower bits of the address are provided so that the I/O adapters do not have to
deduce the address from the byte enable.
The number of significant bits in an address to MEMORY depends on the transaction type and
length as shown in Figure 3-8.

3-28

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-8:

NDAL Memory Address Interpretation

A, i- 4 3 2 1 0
+-+-+-+-+-+

Read quadword, octaword, hexaword

Islsldldldl
+-+-+-+-+-+

Write quadword

Islsldldldl
+-+-+-+-+-+

Write oct.aword

Islalaldldl
+-+-+-+-+-+

Write hexaword

Idlalaldldl
+-+-+-+-+-+

s - significant
d - don't care

It can be seen from the figure that bits A<4:3> are significant address bits or don't care, depending
on the function being requested.
All reads have significant bits down to the quadword. Although fills may be returned in any order,
there is a performance advantage if memory returns the requested quadword first. The NDAL
prot.ocol identifies each quadword using one of the four Read Data Return commands, so that
quadwords can be placed in correct locations regardless of the order in which they are returned.
Quadword, octaword and hexaword writes are always naturally aligned and driven on the NDAL
in order from the lowest-addressed quadword to the highest.

3.3.4.1.2

Byte Enable Field

The Byte Enable field is located in P%NDAL_H<55:40> during the address cycle. It is used to
supply byte-level enable information for quadword-Iength DREADs, !READs, DREADs, WRITEs,
and "TDISDWNs and octaword-Iength WRITEs and WDISOWNs. Of these transactions, NVAX
generates only quadword IREADs and DREADs to I/O space, quadword WRITEs to I/O space,
and quadword WRITEs and WDISOWNs to memory space.
If the byte enable is a "ltt, the byte is to be read or written. If it is a "0", the byte is not read or
written.
NOTE

During quadword-Iength transactions the high portion of the byte enable field, located
in P%NDAL_H<55:48>, is ignored. Commanders may drive any data pattern they
wish in this field as long as it has correct parity. Responders must not depend on a
certain defined pattern (such as all zeros).

During hexaword-Iength transactions the entire byte enable field is ignored. During
hexaword transactions, commanders are permitted to drive any data pattern they wish
in this field as long as it has correct parity. Responders must not depend on a certain
defined pattern (such as all zeros).
During oetaword-Iength transactions, the byte enable located in PfDNDAL_H<47:4D>
always corresponds to the low-order quadword of the oetaword. The byte enable
located in P%NDAL_H<55:48> always corresponds to the high-order quadword of the
oetaword.
The correspondence between bits in the enable and bytes of the data is shown in Table 3-7 and
Table 3-8.
DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-29

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-7:

Byte Enable for Quadword Reads and WrHes

Address cycle

Data cycle

Byte Enable

Data Byte

Po/oNDAL_H<47>

P%NDAL_H<63:56>

P%NDAL_H<46>
Po/oNDAL_H<45>

P%NDAL_H<55:48>
P%NDAL_B<47:40>

P%NDAL_H<44>

P%NDAL_B<39:32>

Po/oNDAL_H<43>

P%NDAL_H<31:24>

P%NDAL_B<42>

Po/cNDAL_H<23:16>

P%NDAL_H<41>

P%NDAL_H<15:08>
Po/oNDAL_H<07:00>

. Po/oNDAL_H<40>

Table~:

Byte Enable for Octaword Writes

Address cycle

First data cycle

Second data cycle

B~-te Enable Bit

Quadword 0 Data Byte

Quadword 1 Data Byte

Po/c..''"DAL_B<4i>

Po/~"DAL_H<63:56>

P%~'"DAL_B<46>

Po/oNDAL_H<55:4B>

P%~"DAL_H<45>
P%~"DAL_H<44>

P%NDAL_H<47:40>
P%NDAL_H<39:32>

P%~"DAL_H<43>

P%NDAL_H<31:24>

P%~'"DAL_B<42>

Po/oNDAL_H<23:16>

P%NDAL_H<41>

P%NDAL_B<15:08>

P%NDAL_H<40>

P%NDAL_H<07:00>

P%NDAL_H<55>

P%NDAL_B<63:56>

P%NDAL_H<D4>

P%NDAL_B<55:48>

Po/oNDAL_B<03>
P%NDAL_B<52>

P%NDAL_B<4'1:40>

Po/oNDAL_H<51>

P%NDAL_B<31:24>

P%NDAL_B<50>

P%NDAL_B<23:l6>

P%NDAL_B<39:32>

P%NDAL_B<49>

P%NDAL_B<15:08>

Po/oNDAL_B<48>

KNDAL_B<O'1:OO>

3-30 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-9 illustrates possible bit pattem.s in the byte enable for transactions which NVAX
generates. Only transactions in which the byte enable is valid are listed.
NVAX will generate every possible byte enable for every possible address for quadword WRITEs
and WDISOWNs to memory space, as shown by the table. lREADs to 110 space will always
request a full quadword of data by asserting all the byte enable bits.
DREADs and WRITEs to I/O space are issued using the quadword length NDAL encoding, but
the requests are for only a byte, word, or longword at a time, as indicated by the byte enable
given in the command cycle of a transaction. References that are unaligned across a naturally
aligned quadword are decomposed into two separate requests for the bytes in each quadword;
where this is the case, Table 3-9 shows the byte enable values for both references generated. In
the cases where a second request is generated, the address is incremented by 8, which addresses
the next quadword in 110 space, but address bits <2:0> are OOO(BIN).
'When the NVAX CPU does an I/O space read for an interrupt acknowledge (IAK. read), it always
generates a longword-aligned word-length read request. In other words, the byte enable which
l\."l'\JAX uses for an IAK read is either 0000 0011 (binary) or 0011 0000 (binary).
Table 3-9 reflects what NDAL requests the l\TVAX CPU will generate, depending on the software
written. Software must take care only to generate requests which make sense in the system
environment. Specifically, unaligned requests are forbidden by DEC Standard 032.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-31

NVAX CPU Chip Functional Specification, Revision l~O, February 1991

Table 3-9:

Possible Byte Enables for NVAX-generated transactions
Byte Enabled:O>

NDAL

Software

Transaction

Addr<2:O> :Beq.#

QW
WRITE,
WDISOWN
(memory space)

any
adcir

1st

QW !READ (lIO
space)

000

1st

QWDREAD,

000

QWWRITE

NDALI

NDAL

Software

Addr<2:O> Byte Beq.

Word Beq.

LW:Beq.

QWBeq.

unrestricted

same as
SW

11111111

1st

000

2nd

100

1st

001

0000 0001

OOOOOOll

0000 1111

00001111
11110000

(lIO space)

001

010

011

100

101

110

111

3-32

NVAX Chip Interface

0000 0010

00000110

00011110

2nd

101

1110 0000

3rd

000

00000001

1st

010

0000 0100

00001100

00111100

2nd

110

11000000

3rd

000

00000011

1st

011

0000 1000

00011000

01111000

2nd

111

10000000

3rd

000

0000 o ill

1st

100

2nd

000

1st

101

2nd

000

3rd

001

1st

110

2nd

000

3rd

010

1st

111

2nd

000

3rd

011

00010000

0011 0000

1111 0000

11110000
0000 llll

00100000

01100000

11100000

0000 0001

00000001
00011110

0100 0000

1100 0000

UOOOOOO

0000 0011

00000011
00111100

1000 0000

0000 0001

0000 0111

0000 0111
01l110oo

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.4.1.2.1

110 space writes

When the NVAX CPU issues an 110 space write, it always replicates the data identically on the
high longword and the low longword of the NDAL, although the byte enable indicates that the
data is only valid in one longword or the other. A system device may take advantage of this fact
to avoid rotating the data.
3.3.4.1.3

Length Field

The length field is used to indicate the amount of data to be read or written for the current
transaction. Table 3-10 shows how the length values correspond to transaction lengths.
Table 3-10:

NDAL Length Field

hexaword

unused

quadword

ocr.aword (not used by NVAX CPU)

3.3.4.2

pO/oCMD_H<3:0>

The P%CMD_H<3:0> lines specify the current ·bus transaction during any given cycle. The
interpretation of the four bits is shown in Table 3-11.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-33

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-11 :

NDAl Command Encodlngs and Definitions

Levels

Abbrev.

Bus 'IraDsactioD

Type

Function

0000
0001

NOP

No Operation

Nop

No Operation

Reserved

0010

WRITE

Write

Addr

Write to memory with byte enable if
quadword or octaword

0011

WDISOWN

Write Disown

Addr

Write memory; cache disowns block
and returns ownership to memory

0100

!READ
DREAD

Instruction Stream Read

Addr

Instruction-stream read

Data Stream Read

Addr

Data-stream read (without ownership)

OREAD

D-Stream Read Ownership

Addr

Data-stream read claiming ownership
for the cache

0101
0110
0111
1000
1001

RDE

Read Data ElTor

Data

Used instead of Read Data Return in
the case of an error.

1010

'WDATA

Write Data Cycle

Data

Write data is being ttansfen-ed

1011

BADWDATA

Bad Write Data

Data

Write data with errors is being
transfened

1100

RDRO

Read DataO Return (fill)

Data

Read data is returning colTesponding
to QW 0 of a hexaword.

1101

RDR1

Read Datal Return (fill)

Data

Reserved
Reserved

Read data is returning corresponding
to QW 1 ofa hexaword.

1110

RDR2

Read Data2 Return (fill)

Data

Read data is returning colTesponding
to QW 2 of a hexaword.

1111

RDRS

Read Data3 Return (fill)

Data

Read data is returning corresponding
to QW 3 of a hexaword.

The NVAX CPU does not implement all transaction lengths with all commands. The commands
and lengths which it uses are in the table which follows. If NVAX implements the command in
memory space, MEM is indicated in the table; if it implements the command in 110 space, 110 is
indicated in the table.
Table 3-12:

NDAL Address Cycle Commands as used by the NVAX CPU

COMMAND

QUADWORD

!READ

00
110

DREAD

OCTAWORD

REXAWORD
~M
~M

OREAD

WRITE
WDISOWN

1 NVAX uses these transactions only when the backup cache is disabled or in Error Transition Mode.

3-34 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

When the cache is off, the NVAX CPU issues OREAD commands of hexaword length,
and cOlTesponding Disown Write commands of quadword length. These correspond to the
CPU-internal commands of Read Lock and Write Unlock. The lock/ownership granularity in
memory must not be less than a hexaword. Otherwise, when the CPU did a hexaword OREAD
followed by a quadword Disown Write, the other three quadwords would be in limbo. The CPU
would assume that it didn't own them, and memory would believe that they were still owned by
the cache.
3.3.4.3

pOklD_H<2:0>

During the address cycle and return data cycles, P%ID_H<2:O> contain the commander's ID. This
ID is used to identify the source of the request on the address cycle and to associate returning
data with the commander who issued the request on return data cycles.
The commander ID codes available for use by a node are shown in Table 3-13. P%ID_H<2:1>
indicate which node originated the transaction, and P%ID_H<O> indicates which of two
outstanding reads per node.
Table 3-13:

Commander pOkID_H Assignments

Node Name
!\'\.:-\.x

OOX

memory interface

Olx

10 I_NODE
I02_NODE

lOX
llX

During write command and data cycles, P%ID_H<2:0> is driven with the ID of the commander.
P%ID_H<2:1> is driven with the bits identifying the commander, and P%ID_H<O> may be driven
with any value. P%ID_H<O> is not necessarily driven with the same value during the command
cycle of a write and the corresponding data cycles of that write.
Each commander node on the NDAL may have two read transactions outstanding.
The memory interface is not a commander node, but it has been assigned a commander ID which
may be used in some NVAX. systems. For example, in the nlI2 system, the memory interface
refiects XMI2 read and write commands into the NDAL for cache coherency reasons. These reads
and writes are not taken up by any node on the NDAL except to enforce cache coherency. The
memory interface uses its own ID when driving these reads and writes onto the NDAL. If a write
is refiected onto the NDAL merely to enforce cache coherency, the WDATA cycles may be omitted.
3.3.4.4

P%PARITY_H<2:D>

P%PARITY_H<2> is computed over P%CMD_H<3:O> and P%ID_H<2:O>. Even parity is used,
where the" exclusive OR" of all bits including the parity bit is a "0". (All bits, including the parity
bit, have an even number of "1"'s.)
P%PARITY_H<2>
is
inverted,
forcing
an
NDAL
parity
CCTL<FORCE_NDAL_PERR> is set. This is described in Chapter 13.

DIGITAL CONFIDENTIAL

error,

when

NVAX Chip Interface 3-35

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

P%PARITY_H is computed over the high longword of the NDAL, P%NDAL_H<63:32>. Odd
parity is used, where the "exclusive OR" of all bits including the parity bit is a "Itt. (All bits,
including the parity bit, have an odd number of "I "'s.)
P%PARITY_H<O> is computed over the low longword of the NDAL, P%NDAL..-H<31:0>. Even
parity is used.
Using a combination of odd and even parity means that neither all "l"'s nor all "O"'s is a legal
bus pattern.
If a device requests the bus and is granted it, but chooses not to use it during a given
cycle, it is responsible for driving the NOP command on P%CMD_H<3:0>. It must drive
P%NDAL_H<63:0>, P%ID_H<2:0>, and P%PARITY_H<2:0> with correct parity.
If NVAX did not request the bus, and it is granted the NDAL anyway, it will drive the NDAL
with a NOP.
When the bus is idle, the arbiter ensures that the NDAL is driven with correct parity. To do this,
the arbiter may take advantage of the fact that ~"\~~ will drive the l\t~AL with NOP if it is
unexpectedly gTanted the bus.
The l\"'VAX BIU checks the ~L>AL for correct parity in every cycle, regardless of the contents
of the bus. It does not distinguish between errors on the command lines or the data lines; it
computes the three parity bits, and if any fail, it responds to the error according to Table 3-21.
Table 3-14:

NDAl Parity Coverage

Parity bit

protected data

parity type

P%PARITY_B<2> Po/oCMD_H<8:O>J»%ID_H<2:0> even parity
P%PARITY_B<l> Po/cNDAL_H<63:32>
odd parity
even parity

3.3.4.5

PO/OACK_L

P%ACK_L is an open drain signal which is pulled high (deasserted) by an external resistor on
the board. The resistor is able to pull the node high during the time allotted without assistance
from any other P%ACK_L driver. Thus, an P%ACK_L driver only has to pull the signal low at
the appropriate time.
The receiver for a particular NDAL cycle is responsible for pulling P%ACK_L low (asserted) if it
receives the cycle without parity errors. If another receiver detects a parity error on the cycle, it
reports it by asserting P%H_EBR_L or PfoS_ERR_L.
If Po/oACK_L is asserted in response to an NDAL cycle, it indicates that the receiving node has
accepted an address cycle or a data cycle. Po/oACK_L being asserted for a read address cycle
indicates that the responder will return a read response cycle at a later time. If it is asserted
for a write address cycle, the transfer of the write address is assumed successful. If a cycle is
accompanied by a NOP command, the cycle mayor may not be acknowledged by the assertion of
P%ACK_L; NOP's do not have to be acknowledged but they may be.
P%ACK_L is always asserted by the NDAL receiver unless there was a parity error on the bus.
It is NOT used for flow control.

3-36 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

P%ACK_L is also not asserted when there is no node on the NDAL which recognizes the
address space addressed, i.e., transactions to non-existent memory and I/O space will not receive
P%ACK_L assertion.
See Table 3-21 for NVAX response when P%ACK_L is not asserted.
The timing of ACK_L relative to the data or address cycle is shown in Figure 3-9. For a given
transfer, ACK_L is asserted one cycle later. In cycle 0 a read is driven, so ACK_L is asserted in
cycle 1. In cycle 4 a NOP is driven, and in cycle 5 ACK_L is not asserted because NOP's do not
have to be acknowledged.
Figure 3-9:

ImA!.

pO/oACK_l Timing

cycle i 0 I 1 I :2 I 3 I 4 I 5 I 6 I i I
i-----I-----I-----I-----!-----l-----j-----I-----I
I

I ?ea::"

I
v~=:'-:I

I ~=K

rica": I Read: !,cF

I
I
I
I ~=K I ACK I ~=:.

;
I
: ~·==:'-:i v;::'a-:I

i cycle I cy:le: cyc:'e I c~·:::'e'
I 0
I :.
i :
i
~
I
I

DIGITAL CONFIDENTIAL

,-I ..-

I
I
!
I A=? I

.. -.

__
, _.:, __ --=
.... c
-~-,I

€

NVAX Chip Interface 3-37

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.5

NDAL Transactions

The following sections describe the entire set of NDAL transactions.
Table 3-15 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
ETM, NVAX issues Disown Writes of both hexaword and quadword length. When the cache is
off, NVAX issues only quadword Disown Writes. NVAX issues quadword Disown Writes only as
the result of an interlock operation.
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.

3-38

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0t February 1991

Table 3-15:

NDAL Command Usage by NVAX

Address

Space
N/A
N/A

Memory
Memory
Memory
Memory
Memory
:Memory
l\iemory
:Memory
Memory
:Memory
l\iemory
I\lemory

110
110
110
110
110
110
110
110
110
110
110
110

Used
Command

NVAX

by
Leugth

LeDgth

Nop
Reserved

yes
no

WRITE

yes
yes
yes
yes
yes
no
yes
yes
no
no
no
no

yes
yes
no
no
no

no
no
no
no
no

no
yes
yes
yes
yes

yes
no
yes
yes
no
no
yes
no
no
no
no
no

yes
no
yes
yes
no

no
no
no
no
no

WDISOWN

!READ
DREAD
OREAD

RDE
'WDATA
BAD,\VDATA
RDRO
RDRI
RDR2
RDR3

WRITE
WDISOWN

!READ

DREAD
OREAD

RDE
WDATA
BADWDATA
RDRO
RDRl
RDR2
RDRa

DIGITAL CONFIDENTIAL

NVAX Chip Interface

3-39

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-16 shows the usage of NDAL commands by NDAL devices other than NVAX. The
ownership commands (OREAD and WDISOWN) are not defined at all in I/O space. Although
nodes may use OREAD and WDISOWN of lengths other than hexaword, they must be aware
of the memory coherency problems connected with using lengths other than hexaword for these
operations. Memory defines ownership along hexaword boundaries.
Table 3-16:
Address
Space

NDAL Command Usage by NDAL nodes besides NVAX

COlDDUUld

Used
by NDAL
nodes

Leugth

Length

N/A

Nop

yes

N/A

Reserved

:Memory

WRITE

yes

.:.uemory
"

WDISOWN

yes

1:Iemory

!READ

yes

~lemory

DREAD

yes

~lemory

OREAD

yes

~lemory

RDE

yes

XvIemory

WDATA

yes

Memory

BADWDATA

yes

XvIemory

RDRO

yes

Memory

RDRl

yes

Memory

RDR2

yes

Memory

RDR3

yes

I/O

WRITE

yes

I/O

WDISOWN

I/O

!READ

yes

I/O

DREAD
OREAD

yes

I/O

RDE

yes

I/O

WDATA

yes

I/O

BADWDATA

yes

I/O

RDRO

yes

I/O

RDRl

yes

I/O

RDR2

yes

I/O

RDR3

yes

I/O

3-40 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.5.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 interfaces in the system, and the one which recognizes the address
latches that address and command. This device is the responder. The responder uses Read Data
Return or Read Data Error cycles to return the data. Reads and fills are described in the sections
which follow.

3.3.5.1.1

Dstream Read Requests (DREAD)

An NDAL commander uses the DREAD command to request Data Stream data from a responder,
either memory or an 110 device.
3.3.5.1.2

Istream Read Requests (IREAD)

The IREAD command is used to request Instruction-Stream data from a responder, either memory
or an I/O device.
The separate I-stream read command is used in implementing halt protection for the CPU. 'When
a system device which asserts P~oHALT_L recognizes an I-stream read in halt-protected space,
it prevents PlioHALT_L from being asserted to the CPU. In the meantime, DREADs outside of
halt-protected space may occur. Vlhen an IREAD outside of halt-protected space happens, the
system device resumes asserting P%HALT_L to the CPU.
When NVAX issues the IREAD command in 110 space, it expects a full quadword of data in
return. The responding device may decode the IREAD command instead of the byte enable field
to detect the need to return a full quadword of data.
In addition, the separate IREAD command may be helpful in analysis during system debug or
for performance analysis.
3.3.5.1.3

Ownership Read Requests (OREAD)

A node uses the OREAD command to gain ownership of a hexaword block of memory. Whereas
previous systems implemented an Interlock read as well, the NDAL defines only the Ownership
read. Interlocks can be accomplished using OREADs.
OREADs are only defined for memory space; they are not used in 110 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. Memory clears the owned bit when a
Disown Write of any length is received to the same block.
It

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-41

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.5.1.4

How memory handles reads to Owned blocks

If the ownership bit is already set in memory when the DREAD arrives, data is not returned
immediately to the commander. Once the node which owns the data Disown Writes the block, the
Ownership bit is set in memory and the data is returned to the commander. The fact that the
ownership bit was set at the beginning of the reference is transparent to the commander on the
NDAL. Once an OREAD is issued on the NDAL, the data must be returned to the commander
without requiring any retry sequence.
The analogous statement is true for an IREAD or a DREAD: If the ownership bit is already
set in memory when the IREAD or DREAD arrives, data is not returned immediately to the
commander. Once the node which owns the data Disown Writes the block, the the data is returned
to the commander. The fact that the ownership bit was set at the beginning of the reference is
transparent to the commander on the NDAL. Once an lREAD or DREAD is issued on the NDAL,
the data must be returned to the commander without requiring any retry sequence.
In certain error-handling situations, l'.TVAX itself may issue a read to a block which it already
o·wns. In this case the memory controller should handle the read as it normally would: wait until
!\'"'V-U completes the WDISO"'N, then return the read data to NVAX and set the ownership hit
if the read was an DREAD.
3.3.5.1.5

Read cycle description and timing

A read command cycle consists of a commander driving an address cycle on P%NDAL_H<63:0>,
as sho'\vn in Section 3.3.4. The commander drives Po/cCMD_H<3:0> with DREAD, IREAD, or
OREAD. It drives its own identification code on P%ID_H<2:0>, and it drives correct parity on
P%PARlTY_H<2:0>.

The timing for a read cycle is shown in Figure 3-10. In this example, N'VAX is doing a read. In
Cycle 0, NVAX asserts P%CPU_REQ..L to request the NDAL. It is granted the bus immediately,
as shown by the assertion of Po/oCPU_GRANT_L in cycle O. (This example assumes that no
other device was requesting the NDAL during this cycle.)
The assertion ofPo/oCPU_GRANT_L in phase 3 of cycle 0 means that NVAX is obligated to drive
the NDAL in phase 1 of Cycle 1. It drives the read address out at that time. In this example, it
deasserts its request line at the same time as it has no other requests to make. (It is not obligated
to deassert request if it does have other requests to make.)
The device receiving the read recognizes it in phase 3 of cycle 1, and computes parity across the
data it received. In this example, it recognizes no parity error, and asserts Po/GACK_L so that
it is valid in phase 3 of cycle 2. The CPU receives P%ACK_L and knows that the read address
.
cycle completed successfully.
If there had been a parity error and Po/GAC~L had not been asserted, NVAX would have
responded with an error condition as described in Section 3.3.10.3.

3-42 NVAX Chip Interface

DIGITAL CONFIDENTIAL

c
Ci

__ I ____

2----

____

NDAL_H

~n(M(M(~(~(T(r«r.(M(M(~(~(~(T«r(M(~------T)~)~«««««««««

CPU_REO_L

\S\\\\\\\)
reque.t to do read

null data cycle

);

~------I--" D A L C Y C L 1:
I~~_~I ~~
~I_~_I~

C Y C L E

CiJ

1
..
0

o ---I--~" D A L

CYCL1:

::!!

DAL

(Q
C

»>----

»~«««««««««

drive re8d

8ddress

null data cycle

~
:u
r

11alllll1

m
a.
ct

CPU_HOLD_L

3
:;

""SID\\

CPU_GRANT_L

arbiter

{{fllllU71
bus granted to read driver

n
~

·0

null data cycle not ACKed

PHI12

PHI2l

_ _--'I

PRI34

_ _ _ _ _ _-II-------u--

loom

\\\\\ill\\\\\\"\\ill"""

AC~_L

read address cycle ACKed

g
Et.

, _ _ _ _ __

/----~'__

Et.

PRUI

1--- - - - - - - - - -

---I---I------I---i--- - - -

!i.

S
....

0
:r

ii"
5"

"
i-

CC
CC

....
....

NVAX CPU Chip Functional Specification, Revision 1.0t February 1991

3.3.5.1.6

Read Data Return cycles (RORO, RDR1, RDR2, ROR3)

The Read Data Return command is used in response to any read request, whether !READ,
DREAD, or OREAD. Multiple cycles are necessary to transfer all of 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.
For a hexaword read, the four fill quadwords may be returned in any order. The NDAL Read
Data Return command identifies the location of each quadword within the natural boundary as
it is returned so that it can be placed in the correct location regardless of the return order. The
data which is returned is naturally aligned within each quadword.
In I/O space, only one cycle's worth of data is returned. The actual amount of valid data
returned depends upon the byte enable which was issued with the read request, as described
in Section 3.3.4.1.2. The Read Data Return command corresponding to the requested 110 space
address is used in returning the data.
Read Data Return cycles do not have to occur in adjacent cycles. The requested quadword should
be returned as soon as possible, for performance reasons, even if the remaining quadwords are
not yet available. The remaining quadwords may be sent as they become available.
Because the ~L>AL 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.
Table 3-17 shows the correspondence between address hits <4:3> and the RDR command used in
returning data at that address. (Bits <4:3> indicate the alignment of a quadword of data within
a hexaword.) The RDR command must correspond to the address of the data being returned for
transactions of all lengths, whether quadword, octaword or hexaword. The correct RDR command
must be used for both memory space and 110 space.
Table 3-17:

RDR usage for ALL fill cycles

Address
bits <4:3>

COD1Dl8.Dd used for fill cycle

RDRO

RDRl

RDR2

RDRS

3.3.5.1.7

Read data error cycles (RDE)

RDE is used to notify a commander of a problem with read data which is being returned. For
example, the memory interface may use this command when it encounters an uncorrectable read
error.

3-44 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification. Revision 1.0. February 1991

Once a Read Data Error cycle is sent for a particular read, no further read responses may be
sent for that transaction. The following sequence illustrates the series of events during a return
data of hexaword length containing an uncorrectable read error. In this example, HOLD is used
to return the data in consecutive cycles.
Figure 3-11:

RDE example

I resplHOLD IHOLD I
I
IRDROIRDRllRDE I
I

Arb

CMD_H
NDAI.._H

!D_F.

Idataldatal
I
Icmdr Icmdrl cmdrl

ACK_L

3.3.5.1.8

IACR lACK IACR

Read data cycle description and timing

During a read data cycle, Po/tC:MD_H<3:0> is driven to the value representing RDRO~ RDR1,
RDR2, RDR3, or RDE. P%NDAL_H<63:0> is driven with the quadword of read data being
returned. P%ID_H<2:0> is driven with the ID which was issued \vith the original read request.
Correct parity is driven on P%PARITY_H<2:0>.
The timing for a Read Data Return cycle is shown in Figure 3-12. In this example, IOI_NODE
has fill data to return. In cycle 0, I01_RE'LL is asserted to request the bus, and IOl_GR.4...:."""T....L
is asserted in response. Since I01_G~"T_L was asserted in cycle 0, IOl_NODE is obligated to
drive the NDAL in cycle 1. It does so and returns the fill data. The original requestor of the data
receives the data at the beginning of phase 3 of cycle 1, and since it detects no parity errors, it
asserts Po/aACK_L so that it is valid in phi3 of cycle 2, as shown.
3.3.5.1.9

Read Transaction Examples

3.3.5.1.9.1

Quadword Read and Fill

A quadword read consists of a command transfer followed by a return data transfer as shown
below:

DIGITAL CONFIDENTIAL

NVAX Chip Interface

3-45

-N D A L

I PI

e
:r

-0
5'

---I---N
I
o

D A L

C Y C L E

- --- ---

_____ 1_ _ ~)3 -----1

PI)

--1----

D A L

_ ~_I

C Y C L E

2,-=-1 !

(;
~

NDAL_H

-<"("'(T«7"'l("('Y("r.«"(,",,(T«7"'l("'("T(,.,«.--~---r»n>-< « «( «(
null data cycle

IOl_IUlO_L

,\\"'\\\\

CYCLE

::II

request to return read data

« « « «( (

rend <lat_" rel:urn

» >-< « « «( « « « « «(

)

n--

null data cycle

lllllllZ7/

arbiter
AC~L

null data cycle not ACKed
I

PHI12

PHI23

PHI34

PHUI

bus qranted to read reftpoll<ier

_ _ _ _ _...,,1

--~,_

,--------

/
\

§
r>

-~---~-

--,'-_ _ _ _ __

1--- - - -

, _ __

:;:

::!l

E:t.

()

f
S;
i.
J

rI.

at""

____ ~---'____ _ _ _ _ /

- - - - - - - - - - - - - - - ----1----1 _---1-----1--- - - - - - 0

11777711l

read data return ACKed

1-----"

/1------'"'"\\

_ _---J1

\\\\\\\\S\\\\\\\\\\\\\\\\\\\

(")

1l1ll11l11

c
r>

~
\\\\S\\\\\

IOl_GRANT_L

(")

;

IOl_HOLD_L

f
~

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-13:
0
Arb
eMIl_H
NDAI.._H

ID_B
ACK_I.

Quadword Read and Fill
1

I emar I
I
I read I
I
I addr I
I
Icmd:1
I
I
I ACKI
I
I

I resp I

IRDR21

I
I
I

I data I
I
Ic:::mdrl
I
I ACKI

The two transfers are the read command and the Read Data Return. The CPU commander
arbitrates for the NDAL in cycle 0, and wins. In cycle 1 it drives the command and address of
the read, and its own ID (for use later to identify the returning data). In cycle 2 the receiver for
tha t cycle asserts P%ACK_L if no parity error was detected on the bus.
Sometime later (call it cycle 4) the return data transfer begins with the responder arbitrating for
the l\IL>AL. Having won it, in cycle 5 it drives the command, the data, and the commander's ID.
The status of the returning data is specified in the read response code: either Read Data Return
or Read Data Error. In this example, the quadword requested '\vas to quad\vord 2 of a hexaword,
so the RDR2 command is used in returning the data.
The commander monitors the NDAL and checks for an ID match during Read Data Return cycles.
An ID match indicates that the read data is meant for that commander. In cycle 6, the commander
asserts P%ACK_L if it detected no parity error during the previous ~'"DAL cycle.

3.3.5.1.9.2

Multiple Quadword Reads

The only type of multiple quadword read which is used by NVAX is the hexaword read. Octaword
reads are also supported by the NDAL protocol but are not issued by the NVAX CPU. These
read transactions move multiple quadwords of data from the responder to the commander. The
command transfer of the transaction is shown below.
Figure 3-14:
o
Arb
eMIl H
NDAL_H
IDB

ACK_I.

Read command on the NDAL
1

I emar I
I
I
I read I
I
laddrl
I
I cmdr I
I
I ACKI

The following sequence illustrates the response to a hexaword read. In this example, quadword
1 of the hexaword was the requested quadword, so Read Data. Return 1 is the command
accompanying the first data to return. The requested quadword is returned first for performance
reasons, although that is not required by NVAX or the NDAL.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 347

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-15:

Read data retum without using HOLD

o
Arb

CMD_H
NDAl.._E

Irespl
Irespl
Irespl
Irespl
I
IRDRlI
IRDRO I
IRDR31
IRDR21
Idata I
Idata I
Idata I
Idatal

ID-:H

Iemar I

ACK_L

Icmdr I

lACK I

lemarl

lACK I

lemarl

lACK I

lACK

The transfer above moves four quadwords of data. The command field of the NDAL in cycle 1,
3, 5, and 7 says Read Data Return with the P%ID_H field identifying the intended receiver (the
transaction commander). Each cycle provides a new quadword of read data and the P%ID_H
remains unchanged.
The example shows no transactions interleaved with the Read Data Return cycles, but it is
entirely possible for non-related transfers to be taking place in the cycles between the fill cycles
for one read.
Read data may be returned in continuous cycles, if desired. through the use of the hold arbitration
signals (see example below). The transmitter asserts its hold line in the first cycle to ensure that
it maintains use of the NDAL long enough to complete the transfer. The hold lines are the highest
priority arbitration lines and thus guarantee access. An interface is constrained to a maximum
of four consecutive cycles in which it can assert its hold line.
Figure 3-16:

Read data return using HOLD

o
eM!) H

3-48

Iresplholdlhcldlholdl
I
I
IRDR2 IRDR3 IRDRO IRDRl I

ND;,L_H

Idataldataldatalda~al

ID_H

I cmdr Icmdr I cmdr Icmdr I

ACK_l

lACK lACK lACK lACK

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.5.2
3.3.5.2.1

Writes
Normal Write Transactions (WRITE)

These transactions are used to move a pattern of bytes from an NDAL commander to one of
the responders. The byte enable functionality is only used for quadword and octaword length
transactions. In any hexaword write, all bytes are written regardless of the byte enable values.
Parity must be correct for all bytes sent from any node, as NVAX checks parity across the entire
NDAL during every cycle.
If NVAX sees a write on the NDAL, it treats it as an invalidate request. A block invalidate is
done if it is valid in the cache. A writeback is done if the block is owned.
3.3.5.2.2

Disown Write Transactions (WDISOWN)

The Disown "Trite transaction is the complement to the Ownership Read. After NVAX successfully
gains ownership of a block in memory, it must relinquish ownership when another node wants
ownership of the block or when the Bcache needs to do a deallocate. h'T\TAX accomplishes this by
performing a Disown Write to the memory ,vith the latest copy of the data. The memory, which
has been monitoring the bus traffic, notices that the transaction requested is a Disown Write.
This condition allows it to clear the ownership bit in memory and to write the data as requested.
I\'"V:<\X uses the Disown "Trite command ofhexaword length to perform writebacks from the backup
cache. "W"hen the cache is off, it uses quad'\vord Diso'WIl '\\;'rites to achieve the effect of a Write
Unlock.
3.3.5.2.3

Write Data and Bad Write Data (WDATA,BADWDATA)

The Write Data command is used during the data cycles ofa write if the data is good. If the data
has been corrupted in some way, for instance, there were uncorrectable errors in a cache which
was storing the data, the command used is Bad Write Data.
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,
P%S_ERR_L may be asserted when the Bad Write Data command is used, to notify NVAX of
the error.
3.3.5.2.4

Write transaction description and timing

In a Write transaction, a commander gains the NDAL and sends an address cycle. In this
cycle, P%CMD_H<3:0> is driven to the value for WRITE. P%NDAL_H<63:0> is driven with the
address, the transaction length, and byte enable. P%ID_H<2:1> is driven with the commander's
identification code, and P%ID_H<O> is driven with any value.
The commander immediately follows this cycle with one to four consecutive cycles of write data,
depending on the length specified. In these cycles, P%CMD_H<3:0> is driven with either the
WDATA command or the BADWDATA command. P%NDAL_H<63:O> is driven with the write
data. P%ID_H<2:1> is driven with the commander's identification code, and P%ID_H<O> must
be driven, but may be driven with any value, as long as the parity is correct.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-49

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

All interfaces on the NDAL decode the address, and the one that recognizes the address becomes
the responder and asserts P9CACK_L. The responder accepts the command, address, and data
and performs the requested write.
For quadword and octaword length transactions to memory space, the byte enable field that
accompanies each command and address is completely unrestricted. Each bit in the IS-bit byte
enable field corresponds to a byte of data in the associated quadword or octaword. If the bit is
0, that byte must not be written; if the bit is 1, that byte must be written. For hexaword write
transactions, the responder ignores the byte enable and writes all 32 bytes.
For I/O space transactions, the byte enable is used as indicated in Section 3.3.4.1.2.
The timing for a quadword write on the NDAL is shown in Figure 3-17. In cycle 0, NVAX
requests the bus for the write by asserting P%CPU_RE<LL. In this example, no higher priority
request is pending, so NVAX is granted the bus right away, in cycle O. NVAX then drives the
write command and address in cycle 1, and asserts P%CPU_HOLD_L at the same time in order
to retain the bus. In cycle 2 the write data is driven.
Assuming there are no parity errors, Po/oACK_L is asserted by the receiver in cycle 2. This is in
response to the address cycle of cycle 1. In cycle 3, which is not shown, P%ACK_L is asserted
for the data cycle, cycle 2.
3.3.5.2.5
3.3.5.2.5.1

Write Transaction Examples
Quadword Writes

Quadword writes move some number of bytes from the commander to the responder as specified
by the byte enable field. The commander arbitrates as usual and upon winning the NDAL, drives
the appropriate write command, the intended address, the data byte enable, and its own ID and
asserts its hold line to signal that it will need the next cycle also. In cycle two, it identifies the
cycle as a Write Data Cycle and provides the write data. If an NDAL parity error is detected on
cycle 1 or 2, it is signaled in cycle 2 or 3 by withholding the assertion of P%ACK_L.
The cycle timing for a quadword write is shown in Figure 3-18.

3-50 NVAX Chip Interface

DIGITAL CONFIDENTIAL

s
ilr

-N D A L

0
Z

"11

---I--N
I

C Y C LEO

NDAL_H

~ « « « « « «(<< (<<

CPU_IUlQ_L

\\\\\\\\\\

null dat.a cycle

:!1

D A L

I_~

C Y C. L ..~

-.--------1--__~~__ ~_I

N D A L

__ I _

C Y C L E

_I~

>---< « «( «( «(lillBl_____J.I>----< « « (« « « « « («
dri.ve wdle ,,<.I.tr:r·no

» >--

drive write dat.a

alllalll

z
....

g
~

request. to do writ.e

:s.

tr
\\\\\\\\\\

CPU_HOLDJ.

1111111111

\.\.\.'\.y\'\.'\.'\.'\.

CPU_GRANT_L

gron\; halel by orbit.er

bus 9rant.ed to writ.e driver

/lI1llZll7

3
Sea

e
fd~

t!!j

AC~L

PHI12

PHI23

PJlI34

_ _ _ _ _ _.JI

PHI41

\\\\\\\\'\.\\\\\\lli\\\'~\

null data cycle not ACKed

\
---Jr----~-

writ.e address cycle ACKed

'\ ___ m _ /

,'"-__

r~~

i
l

--,

g
tt-

,'-_ _ _ __

allOW

- - - - - - - - - - - - ---I--------I---··-----·--I----i---- - - - - - - - - - - - -

rI.

....

j:>

t!!j

-0
CD

;.
fa

t....

j
....
....
CO

C&)

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 3-18:

Quadword wrHe on the NDAL

o
Arb
CMD_P.
NDAl._H

ID H
ACK_L

3.3.5.2.5.2

123

I emcir IHOLD I
I
I
Iw:1tlwaatl
I
ladcirldatal
I
I emcir I emcir I
I

lACK lACK

Multiple Quadword Writes

The only multiple-data-cycle write issued by the NVAX CPU is the Hexaword Disown Write.
Hexaword writes are similar to quadword writes except for the amount of data moved. The byte
enable must be ignored in hexaword write transactions and all the bytes of the hexaword must
be written.
The first cycle of a hexaword write is identified with the length desired; successive cycles are
identified as write data cycles. The hold line remains asserted, maintaining use of the NDAL for
the commander.
The four auad'~ords of data "ithin the hexaword must be issued in order from lowest address to
highest address. The order then is quad,vord 0, quadword 1, quadword 2, quadword 3. (Address
bits <4:3> determine the position of a quadword within a hexaword.) Unlike fill data cycl.es, the
same command, 'W'DAT..A\., is issued for every write data cycle, so the order in which the data is
issued is essential so that it is written to the correct address in memory.
.
A hexaword write is shown in Figure 3-19.
Figure 3-19:

Hexaword write on the NDAL

o
Arb

om H
NDAL_H

ID_H
AC:K_L

lemcirlholdlholdlholdlholdl
I
I
Iwrt Iwdattwdatlwdattwdatl
I
ladciridatOIdatlldat21aat31
I
lemcirl
I
I
I
I
I

lACK lACK lACK lACK lACK

NOTE
The write data must always immediately follow the write address cycle with no NULL
cycles in between.
The NDAL protocol also allows for octaword writes. The NVAX CPU does not use these, but they
may be used by other nodes.
The two quadwords of data within the octaword must be issued in order from lowest address to
highest address. The order then is quadword 0, quadword 1. (Address hit <3> determines the
position of a quadword within an octaword.)

3-52

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

.An octaword write is shown in Figure 3-20.

Figure 3-20:

Octaword write on the NDAL

ID_E
ACK_L

CMD_H
NDAl.._H

3.3.5.3

I emar Iholdlholdl
I
I
Iwri~lwda~lwdatl
I
laddrldatOldatll
I
lemdrl
I
I

Arb

lACK lACK lACK

NOPs

For implementation reasons, occasionally NVAX will arbitrate for the NDAL and, if the bus is
granted, it \vill drive a NOP. This only happens when ~\TAX has just driven out two back-to-back
transactions. This happens rarely, and since 1\TVAX has the lowest priority of the NDAL nodes,
it is not a performance problem.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-53

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.6 Cache Coherency
Ownership Reads and Disown Writes on the NDAL are intended to support writeback caches by
attaching an owner status to each block in physical memory. A block in memory is defined as
a hexaword, or 32 bytes. A node which owns a block may write it repeatedly without accessing
memory. Only one node owns a given block. Ownership is passed from memory to a non-memory
node through an Ownership Read command. Ownership is passed from non-memory nodes to
memory through a Disown Write command.
The ownership bits in the caches and in memory indicate that a cache owns the block. The
ownership bit in the writeback cache is set when the cache owns the block and is clear when the
cache does not own the block. The ownership bit in memory is set when some cache owns the
block and clear when memory owns the block.
Shared read-only access to a block is permitted only when memory owns it. Otherwise the block
can only be read by the node which owns the block.
1\'VAX nodes with writeback caches can gain ownership and retain it for a very long time. ~\TAX
monitors the bus continuously for memory space read-type and write commands to memory space
by other nodes. ~nen l\TVAX detects a request for a block that it owns, it will perform the disown
write to memory, allowing the original command to complete successfully.

Table 3-18 shows what action is performed in the backup cache based upon the state of the block
in the cache when a particular command is received.
Table 3-18:

NVAX Backup Cache Invalidates and Wrltebacks

~'1>AL Command

Invalid block

Valid & Unowned

Valid & Owned
Writeback,

IREAD,DREAD

set Bcache to

valid-unowned state
OREAD

Invalidate

Writeback, Invalidate

WRITE

Invalidate

Writeback, Invalidate

WDISOWN

Some devices other than NVAX will access memory directly over the NDAL. As these commands
go to memory, NVAX recognizes the command and performs the appropriate cache coherency
action. NVAX does not acknowledge the commands as the memory interface is the receiver for
the transaction. NVAX distinguishes cycles driven by devices other than itself by decoding the
value driven on P%ID_H<2:0> for the cycle, and recognizes those as cache coherency transactions.
In some systems, such as the XMI2 system, there is a system bus to which multiple NVAX CPUs
are interfaced. In these systems, memory commands which occur on the system bus must be
driven into the NDAL so that NVAX can respond to them as necessary with cache coherency
actions.
For example, if an OREAD happens on the XMI2, an OREAD must be driven onto the NDAL
to trigger NVAX to write back the block if it owns it. However, there is no node on the NDAL
which becomes a responder to a memory access transaction which is driven FROM the memory
interface. The result is that P<ftACK_L is not asserted to acknowledge such a transaction. This
is not an error condition.

3-54 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

For more detail on the specific cache coherency requirements in the XMI2 system, refer to
Section 3.4.1.

3.3.7

Interrupts

The P%ffiQ..L<3:0> lines provide a general-purpose interrupt request facility to inteITUpt the
NVAX CPU. These lines are level-sensitive, NOT edge sensitive. Once a node asserts its interrupt
line, it should keep it asserted until NVAX services the request.
When NVAX receives an interrupt, it issues a read on the NDAL to one of four specified 110 space
addresses. There is one address specified for each Interrupt Priority Level. This mechanism
replaces the specific command, Read Interrupt Vector, which was used in previous systems.
Read cycles to these specified I/O space addresses are monitored by all nodes which have an
interrupt outstanding. The node which responds :first with a Read Data Return transaction will
deasserl its interrupt request.
Interrupting nodes on the ~'1)AL do not have to deassert and reissue their interrupts after one
node is serviced. The remaining nodes monitoring the bus see the return vector cycle and maintain
their interrupt requests in anticipation of another ~"V_4Jr 110 space read for an Interrupt Vector.
If the common interrupt line remains asserted, NVAX will initiate another such cycle to be fielded
by another first responder.
Chapter 10 describes interrupts in detail.

3.3.8

Clear Write Buffer

Clear Write Buffer is used to force all writes in the processor to be delivered to memory. In
previous systems, an explicit Clear Write Buffer command on the pin bus was used. The NDAL
uses an 110 space address which may be read or written to indicate that write buffers should be
cleared.
The I/O space read is used when the CPU wishes an acknowledgement of the request. The CPU
waits for the "read data to return. before continuing operation. The actual read data which is
returned is meaningless except to allow the CPU to proceed. The 110 space read does not complete
until all previous writes are complete. This mechanism may be used during a process context
switch to force any errors associated with previous writes to happen in the context of the current
process before the process context switch actually occurs.
II

The device which responds with read data to the Clear Write Buffer is system dependent. In
theory it would be memory, since memory responding would indicate that all buffers before
memory had been cleared.
The I/O space write which serves as Clear Write Buffer is used when the process mode changes
but the process is not being switched. Here the purpose is to :flush the writes as fast as possible
when the mode changes, and to flush them ahead of any subsequent reads. Because the mode is
changed often, it would be a performance hit to use the CWB read and to have to wait for the
read data to return. Therefore the Clear Write Buffer is done as a write.
When the Cbox receives the clear write buffer command from the Mbox, it flushes its write queue.
The writes are delivered to the backup cache, since it is writeback, rather than directly to memory.
The I/O space clear write buffer command, whether a read or a write, is then issued on the NDAL.

DIGITAL CONFIDENTIAL

NVAX Chip Interface

3-55

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.9

VAX architecturally-defined interlocks

A VAX interlocked instruction causes the generation of a Read-Lock and a Write-Unlock 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 when the Cbox receives the read
lock from the Mbox, the command is never seen on the NDAL as it is serviced directly on the
cache. Writeback of the block is prevented until the write unlock is issued from the Ebox.
3.3.9.1

Ownership and Interlock transactions

If !\TVAX has a read lock in progress and P%CPU_WB_ONLY_L is asserted, the CBOX issues
the write unlock regardless of the assertion ofP%CPU_WB_ONLY_L. Otherwise, deadlock might
occur ifP%CPU_WB~ONLY_L were asserted and a device in the system was waiting for NVAX
to do a Write Unlock before deassertingP%CPU_W'B_ONLY_L. For example, memory would not
return Read Lock data to an 110 device if the ownership bit 'were set.
The ~\~ CPU does not support interlocks to 110 space. If the Cbox receives an interlock to I/O
space, it converts it to a normal read on the l\rnAL.

3-56 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.10

Errors

The NDAL supports the detection of all single-bit and some multiple-bit transmission related elTor
conditions on the P%NDAL_H, Po/oCMD_H, P%ID_H, and P%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 elTors.
3.3.1 0.1

Transaction Timeout

Each NDAL node must implement a timeout counter for each read which it may have outstanding.
The NVAX Cbox implements two timeout counters, one for each possible outstanding read. If a
read request times out, it is aborted by the Cbox. Any missing Read Data Return cycles will
eventually cause that read to timeout in the Cbox. See Table 3-21 for details on how timeout is
handled.
The ~'VAX BIU starts its read timeout counter when it receives P%ACK_L assertion for the read.
The counter is an 8-bit counter '\vhich, in normal operation, is clocked with a signal from the Ebox,
EO/CTIMEOUT_ENABLE_H. The base counter in the Ebox is 16 bits wide. This implementation results
in the timeout values shown in Table 3-19.
Table 3-19:

NVAX Read TImeout Values In Normal Mode

l'\\TAX chip speed

Timeout Granularity

Read timeout

l().ns~-VAX

655 microseconds

16i milliseconds

12-ns NVAX

786 microseconds

200 milliseconds

14-ns:t-.TVAX

917 microseconds

234 milliseconds

A test mode for the NVAX read timeout counters is provided, and is described in detail in
Chapter 13. In test mode, the read timeout counters are run directly from the internal NVAX
clock, rather than from E%TIMEOVT_ENABLE_H. The test mode timeout values are shown in
Table 3-20.
Table 3-20:

NVAX Read Timeout Values In Test Mode

NVAX chip speed

Timeout Granularity

Read timeout

10-ns NVAX

10 nanoseconds

2.5 microseconds

12-ns NVAX

12 nanoseconds

3.0 microseconds

14-ns NVAX

14 nanoseconds

3.5 microseconds

The occurrence of transaction timeout is not normal and is expected to happen only when the
system is broken.
More information on timeout may be found in Chapter 13.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-57

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.10.2

Non-exlstent memory and 110

An address which is not implemented in memory on a particular system is known as non-existent
memory. An 110 address of a device which is not present on a particular system is known as

non-existent I/O.
Devices on the NDAL must acknowledge any transactions to address space which they recognize
by asserting P%ACK_L (except when there is a parity error). An address which is not recognized
by any NDAL device is not acknowledged.
If Po/oACK_L is not asserted in response to an NVAX request, the Cbox records the error by
saving state in its error registers. (This error case is covered in Table 3-21). Software can read
the error registers in the other NDAL nodes and find that the absence of P%ACK_L was not
due to a parity error on the NDAL. From that information it can deduce that the problem was
non-existent memory or 110.
If an interface between the NDAL and another bus recognizes a read to some address and ACK's
it, then finds that the address is not implemented on the other bus, the interface must use RDE
to terminate the READ on the :r-..TDAL. It must not simply let the read time out, as this method
of terminating the transaction takes much longer.
If an ~~AL device ACK.'s a write, then determines that it was to non-existent memory or I/O
space, it should notify the CPU appropriately. One possibility is to assert P%H_ERR_L.

3.3.10.3

Error Handling

This section describes the required behavior of NDAL commanders and responders in reaction to
error conditions.
In general, NDAL errors are handled as follows:
•
•

•

3-58

Null cycles have correct parity but are not acknowledged. The absence ofP%ACK_L assertion
for these cycles is not an error condition.
Any NDAL receiver detecting bad parity in any field on a non-NULL cycle must ignore the
cycle. P%ACK_L must not be asserted and no action should be taken in response to the NDAL
command. The receiver may log the error. The device which drove the NDAL cycle must log
the error (the absence of lHfDACK_L assertion) and notify NVAX in some way, depending on
the exact situation.
If an NDAL responder returns Read Data Error for one quadword of return data, it must not
send any further quadwords of data for that requeSt. If any further fills are received, the
Cbox treats them as unexpected fills as described in Table 3-21.
On an ownership read, the memory should set the ownership bit as soon as it starts sending
data back to the requestor. The NVAX backup cache does not set its ownership bit until it
receives all the data for the block, so if any fill data is lost, the block will appear not to be
owned by any element in the system. This simplifies error handling ifNVAX did the OREAD
because of a write, and the write data has already been written into the cache when the error
occurs. No other device can get access to the block while the error is being handled.

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

•

An NDAL memory node may not clear its ownership hit unless all write data cycles associated
with the Disown Write transaction are properly received. H write data is sent with the
BADWDATA command, it is considered to be properly received.

The NVAX BIU does not retry failed commands on the NDAL.
If the Cbox recognizes that data has been lost, it asserts C%CBOX_H_ERR_B to the Ebox. (In some
cases, the data may be recoverable by software.) When C%cBOx..H_ERR_B is asserted, the Cbox
always puts the Bcache into Error Transition Mode.
The Cbox asserts C%CBOx..S_ERR_H when it recognizes a soft error. A soft elTor does not
necessarily interfere with code running on the machine. In some cases, the Cbox enters ETM
upon recognizing a soft elTor.
Table 3-21 shows the response of the NVAX CPU for every eITor situation.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-59

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-21:

NDAl Errors and NVAX CPU Error Responses

General Problem

Specific situation and action taken by NVAX CPU

NVAX
detects
parity en-or on any
NDALcycle

P1foACK_L asserted
(inconsistent parity
error)

P%ACK_L
not asserted (parity
error)

Cbox asserts OICBO~sJB.R_H, puts backup cache into Error
Transition Mode. An invalidate or writeback request may
have been missed.
Cbox asserts OIiCBO~s..EBR..H, puts backup cache into Error
Transition Mode. An invalidate or writeback request may
have been missed. 1

Po/cACK_L

not
asserted
for
:NVAX-originated
command

IREAD, DREAD (to

Cbox aborts the read in the Cbox and the MOOr, asserts

memory or 110)

CC'ACBGX..S_ERRJ.

OREAD

Cbox aborts the read in the Cbox and the Mbox, enters
ElTor Transition ~Mode~ and asserts ~Ox...S_ERR_EL If the
OREAD was done because of a write miss, the write will
now be done straight to memory since the cache is in ET~1.

WRITE
WDISOWN,

address
cycle or data cycle
(to memory or lIO)

Read
timeout
or Read Data Error
before
requested
quadword
is
received

Cbox asserts ~BOXJI_ElUt_E. enters Error Transition :Mode.
Data which should have been written to memory has been
lost. If the elTor was on the data cycle and, in the sysum
implementation. memory marks the data bad. software
may choose to ignore the hard e!TOr response since the en-or
will. be detected whenfrl'the data is read. ~"VAX continues
to send the \VDATA cycles even if the address cycle or one
of the WDATA cycles is NAICd.

IREAD,

Cbox aborts the read in the Cbox and the ~!box, asserts

DREAD (memory or
lIO space)

CIliCBGX..SJm,R..H.

OREAD

Cbox aborts the read in the Cbox and the Mbox, asserts
The Cbox
does not set the ownership bit in the cache. If memory has
set its ownership bit, there is no record of ownership for
the block in the system; however, soft;ware can analyze and
clean up the problem by reading the. Cbox error registers.
If the OREAD was done because of a write miss, the write
will now be done straight to memory since the cache is in

CIliCBGX..SJRlUl, enters Error Transition Mode.

ETM.
lin some systems, such as the NVAX XMI-2 system, commands may be sent on the NDAL purely to notify NVAX of an
invalidate request; these commands are not acknowledged.
2The Cbox aborts the read in the Cbox by clearing valid bit in the FILL_CAM; it aborts the read in the Mbox by asserting
OACBox..BAB.D_EU...a with the I_CF or D_CF command.

3-60

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-21 (Cont.):

NDAL Errors and NVAX CPU Error Responses

General Problem

Specific situation and action taken by NVAX CPU

Read
timeout
or Read Data Error
after
requested
quadword
successfully
received

Read
timeout
or RDE on OREAD
with
pending
writeback request

DIGITAL CONFIDENTIAL

mEAD,DREAD

Cbox aborts the read in the Cbox and the Mbox, asserts
c.cBO%..S_EltR.R, does not validate cache entry.

OREAD
for a read-modify or
a read-lock

Cbox aborts the read in the Cbox and the Mbox, asserts
The block
is not validated or marked owned in the backup cache.
Depending on system implementation, the ownership bit
may be set in memory.
If the OREAD was for a
read-modify, software can analyze and correct the potential
inconsistency in ownership information by reading the
Cbox error registers. If the OREAD was for a read-lock,
the write-unlock will follow to memory (as a quadword
disown write) after the Cbox handles the error. If the
memory subsystem has set its ownership bit, this write
unlock preserves consistency in ownership in the memory
subsyste~ if not, the write unlock location appears to
be owned by memory and will be handled as an error by
memory.

OREAD for a write

Cbox aborts the read in the Cbox, asserts CC-~BOx...H..EBR.B:,
enters Error Transition }Ylode. The write was pretiously
done into the cache when the requested quadword. returned,
since the Cbox merges the write data with the fill data.
Since the read did not complete, the ownership bit is not set
in the cache even though the new write data is in the cache.
Software can recover the write data ifit is non-shared data.
The backup cache must be flushed of owned data using the
deallocate register, then put into force hit mode. The data
can then be read and written to memory. If the data is
shared, writes to memory may have been done out of order
by the Cbox, and system integrity is in question.

c.cBO%..S_EltR.R, enters Error Transition Mode.

A pending writeback request is entered in the Fn..J..,_CAM
when a writeback request arrives for an outstanding
OREAD. If the OREAD does not complete successfully for
any reason, the writeback request is aborted. The Cbox has
not received the entire block, so it does not claim ownership
for the block. Therefore, it does not write back the block as
was requested.

NVAX Chip Interface

3-61

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-21 (Cont.):

NDAL Errors and NVAX CPU Error Responses

General Problem

Specific SituatiOD and action taken by NVAX CPU

Unexpected
fill
or unexpected RDE
received

If there is no corresponding FILL_CAM entry for a
returning fill or RDE, the Cbox ignores the fill data.
CfIiCBOX..H...EB.R..B is asserted. The data is not placed in the
Bcache and not sent to the Mhox. 3 CEFSTS is loaded and
locked; the UNEXPECTED_FILL bit is set since the £l1 or
RDE was unexpected.

SIt is possible to create a scenario where an unexpected fill is received and is recognized by the Cbex because there is an

entry in the FILL_CAM which apparently corresponds to the:6ll. For example, suppose the Cbox starts READ A READ
A times out, so the Cbox aborts it and the con-esponding FILL_CAM entry is cleared. Now the Cbex starts READ B using
the same ID as the aborted READ A Now, if memory returns read data for A, it apparently cOlTesponds to the fill cam
entry for READ B. The data is accepted and NVAX is unknowingly operating with incorrect data. This behavior may
cascade into READ C, READ D, etc., if the Cbox always has a new read outstanding by the time some unexpected data
arrives. Eventually, however, the :fill cam entry will be empty when read data is returned, and the Cbox will recognize
the error. Before the Cbox recognizes the condition. ~\:A..X may have been behavmg very strangely, as it bas probably
been operating 'with either wrong Dstream. or ~'l"OI!g !stream data.

3-62

NVAX Chip Interface

DIGITAL CONFIDENTIAl.

NVAX CPU Chip Functional Specification. Revision 1.0. February 1991

Each system which uses the NVAX CPU chip will develop its own error strategy. In general,
enough information should be logged so that software can understand the problem. Table 3-22
addresses system errors which the system designer should take into account.
Table 3-22:

NDAL Errors and Error Responses by System Components

General Problem

Specific situation and considerations to be made

NDAL parity error
and
Po/oACK_L
asserted

Node has cache

Assert P%S_ERR_L and disable the cache. The node may
have missed an invalidate.

Node has no cache

Assert P%S_ERR_L.

NDAL parity error
and Po/oACK_L not
asserted

The lack of assertion of P%ACK_L is sufficient to notify
the transmitter of the cycle; that transmitter is responsible
for notifying the CPU of the error. If the transmitter lost a
write, it should assert P%H_ERR_L.
write

The memory interlace should not assert Po/oH_ERR_L
because it cannot tell who sent the write. It should log
the parity error. The transmitter which sent the write
asserts P%H_ERR_L or takes other actions to initiate
error recovery.

WDATA
for
Disown Write

The memory should not clear its OBIT; this way, reads from
other CPUs will fail until software corrects the problem.

Any

WDATA

'WDISO'WN
to memory location
which memory owns

3.3.10.4

Response is system dependent. :Memory should probably
perform the write and log the error.

Error Recovery

In most cases an NDAL commander is permitted to reissue a failing transaction in order to
recover from transient bus errors. Should the recovery fail (recovery may involve one or more
reattempts of the failed transaction), then the commander logs a hard error. Implementation
of error recovery is a system-dependent decision. This section contains guidelines on when a
transaction may be retried.
•
•
•
•
•

All transactions which do not receive P%ACK_L assertion for the address cycle may be
retried.
Any failing NDAL Write transaction may be retried.
Any failing Read to memory space may be retried.
Any failing 110 space Write transaction may be retried.
It is unsafe to retry any 110 space Read transaction receiving a response timeout since some
110 devices may have read side effects.

The NVAX CPU will not implement retry on any NDAL transactions.

DIGITAL CONFIDENTIAL

NVAX Chip Interface

3-63

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.3.11

NDAL Initialization

When the NVAX CPU chip enters the reset state, the BID does the following:
•
•
•
•

Tristates P%NDAL_H<63:O>, P90CMD_H<3:0>, P%ID_H<2:0>, and P%P.ARI'lY_H<2:O>.
This occurs when internal reset is asserted, and is not qualified with any clock..
Releases P%ACK_L. This occurs when internal reset is asserted, and is not qualified with
any clock.
Deasserts P%CPU_REQ..L, P%cPU_HOLD_L, and Po/oCPU_SUPPBESS_L. This occurs
when internal reset is asserted, and is not qualified with any clock.
P%CPU_GRANT_L and P%CPU_WB_ONLY_L are sampled during reset.

While NVAX is asserting P%SYS_RESET_L, the NDAL clocks are nmning. P%SYS_RESET_L
is deasserted relative to l\T!)AL P:En12.
During reset, some l\TDAL node must drive the NDAL so that it is driven with a NOP and good
parity by the time P~SYS_BESET_L is deasserted. NVAX receives the NDAL during reset. The
NDAL must be drh.-en to valid levels with good parity by the time reset is deasserted, to prevent
1\'"'\'AX from detecting a parity error. The following is an example of how to drive the ~-nAL with
a NOp, \vhile putting valid parity on the bus:
•
•
•
•
•
•

Drive P%CMD_H<3:0> low (this is the NOP command).
Drive P%NDAL_H<63:0> low.
Drive P'icID_H<2:0> low.
Drive P%P.ARI'lY_H<2> low.
Drive P%P.ARI'lY_H<l> high.
Drive P%P.ARI'lY_H<O> low.

The NVAX CPU does not assert P%CPU_REQ..L until at least 4 NDAL cycles after
P%SYS_RESET_L is deasserted.
P%CPU_GRANT_L should be deasserted during system reset. NVAX will not drive the NDAL
if granted during reset.

3-64

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.4 The XMI·2 NVAX System
A block diagram of the XMI-2 system is shown in Figure 3-21. Everything in the picture except
memory,1I0, other CPUs, and the XMI-2 is contained on one module.
The XMI-2 system is being developed by MSB and is a follow-on to the Mariah XMI-2 system.
Figure 3-21:

NVAX XMI-2 System Block Diagram
1 BCache 1 ECC
I Tag
I Valid
I RAMs
I Owned

1ROM 1 I EEPROM I I SRAM I
,---, ,------, ,----,
I
1
I

,-------,

I IOPort I
,------,
I

I TOY I
'---'
I

,-------+------+-+------+------,
I ROMBus
I

:S6!~~z

-------------

1 1~·= I
I X!-::2
I

1,;;'.):
!

~::-

----->

lOs::

I
,---

5"+~1

l~;;':'

XM!-2

i\
II

11 XClkl

100

Ii }::'ao:1
1
i

:?.=. "\T:'=:

1<------l------------------>::r:l':.,SS:::I<--/-->1 :.a-::2 !<--->I:

S?.z :,,~

I " 1m;...!. I
la:b:!'':.e:1

:~:lS

,-------,

I C:::::ne: I
I
I

,------,

, _____________ ,

II
I I
II
II I!
i I

i I
II
II
1 !.~_!.:I?~!
i<-----> i I
,----------,
1I

S ~:=

-------I Cache I
":~

....

E:::}:,

I Da':.a
I R»!s

---------II
I
I/O
1<-----> I I
,----------,
II
---------II
IOther CPOs 1<----->1 I
\/

,-------,

,----------,

3.4.1

Cache coherency in the XMI2 system

Commands on the XMI2 must be forwarded to the CPU in order to maintain cache coherency.
Table 3-23 shows the XMI2 commands and the corresponding command which must be forwarded
on the NDAL to NVAX. The actions which Nvax takes as a result of the NDAL commands are
shown in Section 3.3.6.
Table 3-23:

XMI2-NVAX Coherency requirements

XMI2 Command

ResuJ:tiDg NDAL Command

Read

Dstream read

Interlock Read,Ownership Read

Ownership Read

Unlock Write, Write Masked

Write1

Disown Write,Tag Bad Data

none

1WDATA cycles for the write may be omitted since the write is driven onto the NDAL for cache coherency reasons only.

DIGITAL CONFIDENTIAL

NVAX Chip Interface

3-65

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Unlock Writes must be forwarded to the NDAL for the following case. Assume an 110 device does
a Read Lock, Write Unlock to memory location A. Assume that the CPU wants to do a normal
read to location A, and that it does not have A in its cache. Assume the following timing on the
XMI:
Figure 3-22:
t1~

XMI2 Unlock Write example

I/O device

CPU

I
I

Interlock Read A

I
I

Read A

Unlock Write A

"\;"

If the CPU reads A between the Read Lock and the Write Unlock the data the CPU caches should
be invalidated after the write unlock. Otherwise, the CPU has stale data in its cache. This is
because normal reads get data from XMI2 memory even if the location is interlocked. When
'\rntes are fOI"\\"arded from the XMI2 to the NDAL, only the write address cycle must be driven.
The write data cycles may be omitted.

3-66 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.5 The Lowend NVAX System • OMEGA
A block diagram of the lowend system, called Omega, is shown in Figure 3-23. The lowend system
is being developed in Maynard, in ESB, the Entry Systems Business Group (formerly MVB).
Figure 3-23:

NVAX Lowend System Block Diagram

1 Bc

1 ECC

1 Tag

,Valid

1 RAMs

,Owned

1 O-bit
1 memory

\_--------,

\_------,

1 NMC
I memory
I :-s:
I

\_--

lw;':'

==''0

1::"nt~::fac~ I

(64+=~1)

-----> I

:?-= Y::"=:

I<--------------·------------>i& l~~~

S?J: :iD

la:bit.. :
I

;

i<-->!~MI

I
i

\_--------,

I
I

\_--'

,------------,
;..±"

1
18
I 6.; :'a-:.a
i 6 ~:::
1

._-_ ...
3:'ock

I:C;'

I (l;"v·,i;A-::?:bus Adapte=)

I
I!~;''!'-=;''':

Im;...:..-=~.ft:

linte:!ace

inte==ace

\_---------------------,

;':t:-~ ••
_:;-

ICacne
,Data

iRams

ICP-bus

~----->I

I
I

ICP-bus

\_------,

I
CQBle

Qbus

1<--------->

I
I
\-------,
•

\-----> I sse

\_------,I

The Lowend System implements an ownership hit in memory which is used to indicate that
the NVAX CPU owns the block in its backup cache. This bit is covered by ECC. If an I/O
interface issues a read or a write to a location which is owned by the NVAX backup cache, the
memory interface holds the request until the writeback completes. It then completes the original
transaction. The same applies to ownership transactions which may arrive from the NCA for an
owned block of memory.
The NCA uses the NDAL ownership transactions in order to perform interlocked transactions.
One key problem in the Lowend System is the latency of a Qbus transaction. Once a device
successfully issues a transaction on the Qbus, a timeout counter starts which will time out after
8 microseconds. This timing is difficult to meet in an NVAX system because of the writeback
cache.
The analysis of the problem may be found in the specs for the Omega system.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-67

NVAX CPU Chip Functional Speci:.6cation, Revision 1.0, February 1991

3.6

Resolved Issues

1. Issue: Should we implement Force Bad Parity on the NDAL for testing purposes, or can

we get away without it? Solution: We are implementing a way to force bad parity on the
command field of the ndal.
2. Issue: The arbitration signals are not parity protected. Solution: This is not a problem
because they are acknowledged by grant. The commander can always detect a problem by
observing grant. If a request line is broken, the CPU will eventually timeout.
3. Issue: Should the Cbox do retry on parity errors? Solution: No. The XMI has never seen
a parity elTOr and it is a much longer bus with big connectors which we don't have. Retry
would add unnecessary complexity.
4. Issue from Supnik: Allow space for extended addressing by moving byte enable over. Solution:
Byte enable moved over.
5. Issue: Should parity be even or odd or a combination of both? Solution: Use even parity
across the command, even parity across the lower longword of the hTDAL, and odd parity
across the upper longword of the l\'T!>AL. The combination helps for package reasons - all pins
can't drive the same way at once. (Steve Thierauf)
6. Issue: Should the ~'"D. -\L
. cycle time equal 2 or 3 CPU cycles? Solution: It will be much easier
to design to 3 cycles so we'll do this in the interest of the schedule. 3 cycles may cost us 3%
performance but it is worth it for ease of design.
7. Issue: Should NVAX drive the lower three bits of address for I/O space transactions? Solution:
Yes. It is in the critical path of I/O devices to deduce the address from the byte enable.
8. Issue: If an Unlock Write transaction is directed to a location not currently locked, should
the responder perform the write operation? Solution: This is a system-dependent issue.
Recommendation added to the ElTOrs section.
9. Issue: Should we have an acknowledged I/O space write? This would preserve write ordering
between memory writes and I/O space writes. Solution: Historically this problem has not
been addressed so our solving it is no value added. Software can be written which avoids the
problem.
10. Issue: Do the lowend systems need byte parity? Solution: If a system is built without a
backup cache, the performance is going to be poor so doing the read-modify-write for masked
writes to memory is OK. The Lowend System will need to do read-modify-writes when the
cache is in EtTor Transition Mode, but this is very rare. As long as there is time to compute
longword parity it seems sufficient. Adding byte parity would increase the number of pins on
the CPU and on all NDAL interfaces by 6.
11. Issue: There was not enough time for the arbiter if HOLD was a single open-drain signal.
Solution: Have three hold signals, one for each commander, each of which is point-to-point.
12. Is parity enable necessary? If not, we get rid of a pin. Solution: Parity enable is not necessary.
Every planned NVAX system is able to generate parity on every ndal cycle.
13. An additional command is under consideration. It would be called Disown Without Writeback
(DISWOWB). It would be driven from the CPU to the memory interface after the CPU received
a hexaword write to an owned block. DISWOWB indicates that the backup cache has given
up ownership and invalidated the block, but is returning no data to memory. If a hexaword
write is done in the system, memory has no use for the old data so it would be a waste of

3-68

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

time for the CPU to return it. Solution: This command does not appear to be useful enough
to warrant the complexity.
14. Can the CPU chip remove the internal resistors on the NDAL? If we do, some chip in the
system would have to pull the bus to valid levels during reset. Resolution: Yes, NVAX has
removed the internal resistors. Another component in every NVAX system will pull the NDAL
to valid levels during reset.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-69

· NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.7 NVAX Chip Interface Signal Name Cross-Reference
All NVAX signal names and pin names referenced in this chapter have appeared in bold and reflect
the actual name appearing in the NVAX schematic set. For each signal and pin appearing in this
chapter, the table below lists the corresponding name which exists in the behavioral model.
Table 3-24: Cross-reference of all names appearing In the NVAX chip Interface chapter
Schematic Name

Behavioral Model Name
OICBOXJI_EIlR-.B
C9iCBOx.,.S..EBll-B
OIiCBOx.,.BARD_ElUt..B
~'l'lMEO'VT_ENABLE_H

P%ACK_L

Po/aASYNC_RESET_L

P%ASYNC_RESET_L

P%CMD_H<3:0>

Po/cCPU_GRAl'.'T_L

PO/CCPU_GR.A1\'T_L

P%CPU_HOLD_L

Po/cCPU_REQ..L

Po/cCPU_SUPPRESS_L

p%CPU_S'UPPBESS_L

Po/£PU_WB_ONLY_L

PO/CCPU_WB_ONLY_L

P%DISABLE_OUT_L

P%DR_DATA_B<63:0>

Po/oDR_DATA.,H<63:0>

Po/oDR_ECC_H<7:O>

Po/oDR_ECC_B<7:O>

P%DR_INDEX_H<20:3>

Po/oDR_INDEX....B<20:3>

P%DR_OE_L

P%DR_WE_L

Po/oDR_WE_L

P%HALT_L

Po/dlALT_L

P%H_ERR_L

Po/dI_EBR_L

P%ID_B<2:O>

Po/dD_B<2:O>

Po/oINT_TIM_L

P%INT_TIM_L

p%m~L<3:O>

Po/dR~L<3:0>

Po/oMACBlNE_CHECK_H

P%NDAL_B<6S:O>

Po/oNDAL_B<63:O>

Po/"oSC_B

Po/tOSC_H

Po/oOSC_L

Po/oOSC_TCl_H

Po/oOSC_TC2_H

Po/tOSC_TC2_H

Po/oOSC_TEST_B

Po/oOSC_TEST_H

3-70 NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-24 (Cont.): Cross-reference of all names appearing In the NVAX chip Interface chapter
Schematic Name

Behavioral Model Name

P%PARI'IY_B<2:O>
P%PBl12_IN_H

Po/DPARI'IY_B<2:O>
P%PBl12_IN_H

P%PBI12_0UT_H

Po/DPBI23_IN_B

Po/DPBI23_IN_H

P%PBI23_0UT_H

Po/DPBl23_0UT_B

Po/DPIDS4_IN_B

P%PID34_IN_H

P%PIDS4_0UT_H

P%PID34_0UT_H

P%PID41_IN_B

P%PID41_IN_H

P%PID41_0UT_H
Po/cpp_CMD_H<2:0>

P%PP_CMD_H<2:0>

P%PP_DATA_H<ll:O>

P%PID41_0UT_H

P%PWRFL_L

P%SYS_RESET_L

P%S_ERR_L

Po/cTCK_H
P%TDI_H

P%TDO_H

P%TEMP_B

P%TEST_DATA_H

P%TEST_STROBE_H

P%TMS_H

P%TS_ECC_B<5:O>

P%TS_ECC_H<5:O>

P%TS_INDEX_H<20:5>

P%TS_INDEX_B<20:5>

P%TS_OE_L

P%TS_OWNED_H

P%TS_TAG_B<31:1'1>

P%TS_VALID_B

P%TS_VALID_H

P%TS_WE_L

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-71

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

3.8

Revision History

Table 3-25:

Revision History

Who

When

Description of change

Rebecca Stamm

20-Feb-1991

Update after NVAX first pass. Clarmed ACK timing. Added signal
name cross-reference. Added NDAL timing AC spec. Corrected Byte
Enable table. Updated Bcache pin timing. J5T1MEOt1CENABLEJI clocks
the Cbox timeout counter, not l5"l'Dr1EOVT_BABEJI. Added P% prefix to
all pin names.

Rebecca Stamm

7-Nov-1990

PP_DATA are output only.
Correction:
power-up.

Clarify NACK'd write handling.
NVAX DOES receive the NDAL I/O signals during

Rebecca Stamm

4-Jul-1990

Update initialization description. Assert Herr on unexpected :6.11.
Update ndal pin timing. :NVAX may drive NOPs under 'WB_O:NLY.
Po/dD_H<O> not driven with same value during command and data
cycles of a write. Close force_bad-parity issue.

Rebecca Stamm

17-May-1990

Take out vector pins, add two new test pins~ update description of
unexpected :fill handling by setting CEFSTSctJl"~ECTED_FILL>.

Rebecca Stamm

20-Feb-1990

Add unexpected RDE handling.
Clarmed byte enables and
octaword-length transactions. Corrected running total for ~\:~~
pins. Add detailed timeout description. Added timeout functionality
to P%OSC_TCl_H.

Rebecca Stamm

3-Feb-1990

External release. Updates from internal review. Address<2:0> is sent
out as zeros for the second half of an unaligned 110 space reference.
NVAX does not implement internal resistors to pull the NDAL to
valid levels during reset; a system device must drive the bus during
reset.

Rebecca Stamm

3O-Jan-1990

Reorganized chapter. Clarified byte enable section. NVAX issues
identical data on both halves of the bus during I/O space writes.
Released for internal review.

Rebecca Stamm

01-Dec-1989

Revision 1.0 release. Clarified byte enable table. Added error
handling for unexpected fills. Added error handling for requested
writebacks whose OREADs do not complete.

Rebecca Stamm

06-Mar-1989

Release for external review.

3-72

NVAX Chip Interface

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 3-25 (Cont.):

Revision History

Who

When

Description of change

Rebecca Stamm

24-0ct-1989

Several NVAX pins were added, deleted, or changed in either
name or functionality. The terminology byte mask is changed
to byte enable. 101_WB_ONLY, 102_WB_ONLY, lOI_SUPPRESS,
and I02_SUPPRESS were added, and NDAL arbitration was
changed, giving the arbiter responsibility for asserted the appropriate
WE_ONLY lines when a SUPPRESS line is asserted. Addition
of BADWDATA command. New command encodings. Elimination
of Read Lock and Write Unlock commands on the NDAL. Add
better explanation of Clear Write Buffer. Update error section.
Remove PARITY_ENABLE_L pin. Removed Qbus latency problem
description. Assigned an ID to the memory interface. Read data
may be returned in any order: :r-.,'rVAX does not require the requested
quadword first, although it is a performance advantage to return the
requested qw first.

DIGITAL CONFIDENTIAL

NVAX Chip Interface 3-73

Chapter 4
Chip Overview

4.1

NVAX CPU Chip Box and Section Overview
The ~'TVAX. CPU Chip is a single-chip CMOS-4 macropipelined implementation of the base instruction group, and the optional vector instruction group of the VAX architecture. Included in
the chip are:
•
•
•
•
•
•
•
•

CPU: Instruction fetch and decode, microsequencer, and execution unit
Control Store: 1600, 61-bit microwords
Primary Cache: 8 KB, 2-way set associative, physically-addressed, write through, mixed
instruction and data stream
Instruction Cache: 2 KB, direct-mapped., virtually addressed, instruction stream only
Translation Buffer: 96 entries, fully associative
Floating Point: 4 stage, pipelined, integrated fioating point unit with selective stage 4
bypass
Backup Cache Interface: Support for four cache sizes (2MB, 512KB, 256KB, 128KB), two
tag RAM speeds and three data RAM speeds.
NDAL Interface: Memory subsystem interface. Supports an ownership coherence protocol
on the Backup Cache

The NVAX chip is designed in CMOS-4 with a typical cycle time of 14 DB, and with the option of
running chips at a slower or faster cycle time. The chip can be incorporated into many different
system environments, ranging from the desktop to the midrange, and from single processor to
multiprocessor systems.
The NVAX is a macropipelined design: it pipelines macroinstruction decode and operand fetch
with macroinstruction execution. Pipeline efficiency is increased by queuing up instruction information and operand values for later use by the execution unit. Thus, when the macropipeline is
nlDning smoothly, the Ibox (instruction parser/operand fetcher) is running several macroinstructions ahead of the Ebox (execution unit). Outstanding writes to registers or memory locations are
kept in a scoreboard to ensure that data is not read before it has been written. See Chapter 5
for a more in-depth discussion of the macropipeline.

DIGITAL CONFIDENTIAL

Chip Overview 4-1

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

This chapter gives an overview of the different sections, or "boxes", that comprise the NVAX
CPU. For more information on any of the boxes, please see the appropriate chapters within this
specification. Figure 4-1 is a block diagram of the boxes, and the major buses that run between
them.
Figure 4-1:

NVAX CPU Block Diagram

IBOX

E%IBOX IA BUS •
E%50 nTI1=IE' A
E%DO::RETIRE'.J-I

USEO

~~~~l~HL----:~~~
FBOX

EBOX

-----------------TAGI
DATA
RAMS

;

CBOX

;

NDAL _ _ _ _ _ _ __

4.1.1

The Ibox

The Ibox decodes VAX instructions and parses operand specifiers. Instruction control, such as
the control store dispatch address, is then placed in the instruction queue for later use by the
Microsequencer and Ebox. The Ibox processes the operand specifiers at a rate of one specifier per
cycle and, as necessary, initiates specifier memory read operations. All the information needed
to access the specifiers is queued in the source queue and destination queue in the Ebox.
The Ibox prefetches instruction stream data into the prefetch queue (PFQ), which can hold 16
bytes. The Ibox has a dedicated instruction-stream-only cache, called the virtual instruction cache
(VIC). The VIC is a 2 KE, direct-mapped cache, with a block and fill size of 32 bytes.

4-2 Chip Overview

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

The Ibox has both read and write ports to the GPR and MD portions of the Ebox register file
which are used to process the operand specifiers. The Ibox maintains a scoreboard to ensure that
reads and writes to the register file are always performed in synchronization with the Ebox. The
Ibox stops processing instructions and operands upon issuing certain complex instructions (for
example, CALL, RET, and character string instructions). This is done to maintain read/write
ordering when the Ebox will be altering large amounts of VAX state.
Since the Ibox is often parsing several macroinstructions ahead of the Ebox, the correct value
for the PSL condition codes is not known at the time the Ibox executes a conditional branch
instruction. Rather than emptying the pipe, the Ibox predicts which direction the branch will
take, and passes this information on to the Ebox via the branch queue. The Ebox later signals
if there was a misprediction, and the hardware backs out of the path. The branch prediction
algorithm utilizes a 512-entry RAM, which caches four bits of branch history per entry.

4.1.2

The Ebox and Microsequencer

The Ebox and Microsequencer work together to perform the actual "work" of the VAX instructions.
Together they implement a four stage micropipelined unit, which has the ability to stall and to
microtrap. The Ebox and Microsequencer dequeue instruction and operand information provided
by the Ibox via the instruction queue, the source queue, and the destination queue. For literal type
operands, the source queue contains the actual operand value. In the case of register, memory,
and immediate type operands, the source queue holds a pointer to the data in the Ebox register
file. The contents of memory operands are provided by the Mbox based on earlier requests from
the Ibox. GPR results are written directly back to the register :file. Memory results are sent to
the Mbox, where the data will be matched with the appropriate specifier address previously sent
by the Ibox. At times, the Ebox initiates its own memory reads and writes using E%V~BUS_L
and E%WBUS_H.
The Microsequencer determines the next microword to be fetched from. the control store. It
then provides this cycle-by-cycle control to the Ebox. The Microsequencer allows for eight-way
microbranches, and for microsubroutines to a depth of six.
The Ebox contains a five-port register file, which holds the VAX GPRs, six Memory Data Registers
(MDs), six microcode working registers, and ten miscellaneous CPU state registers. It also contains an ALU, a shifter, and the VAX PSL. The Ebox uses the RMUX, controlled by the retire
queue, to order the completion of Ebox and Fbox instructions. As the Ebox and the Fbox are
distinct hardware resources, there is some amount of execution overlap allowed between the two
units.
The Ebox implements specialized hardware features in order to speed the execution of certain
VAX instructions: the population counter (CALLx, PUSHR, POPR), and the mask processing unit
(CALLx, RET, FFx, PUSHR, POPR). The Ebox also has logic to gather hardware and software
interrupt requests, and to notify the Microsequencer of pending interrupts.

4.1.3

The Fbox

The Fbox implements a four stage pipelined execution unit with selective stage 4 bypass for the
floating point and integer multiply instructions. Operands are supplied by the Ebox up to 64
bits per cycle on Eo/cABUS_B and ~BBUS_H. Results are returned to the Ebox 32 bits per cycle on
F%FBOX_RESULT_H. The Ebox is responsible for storing the Fbox result in memory or the GPRs.

DIGITAL CONFIDENTIAL

Chip Overview 4-3

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

4.1.4 The Mbox
The Mbox receives read requests from the Ibox (both instruction stream and data stream) and
from the Ebox (data stream only). It receives write/store requests from the Ebox. Also, the Cbox
sends the Mbox fill data and invalidates for the Pcache. The Mbox arbitrates between these
requesters, and queues requests which cannot currently be handled. Once a request is started,
the Mbox performs address translation and cache lookup in two cycles, assuming there are no
misses or other delays. The two-cycle Mbox operation is pipelined.
The Mbox uses the translation buffer (96 fully associative entries) to map virtual to physical
addresses. In the case of a TB miss, the memory management hardware in the Mbox will read
the page table entry and fill the TB. The Mbox is also responsible for all access checks, TNV
checks, M-bit checks, and quadword unaligned data processing.
The Mbox houses the Primary Cache (Pcache). The Pcache is 8KB, 2-way set associative and
writethrough, with a block and fill size of 32 bytes. The Pcache state is maintained as a subset
of the Backup Cache.
The Mbox ensures that Ibox specifier reads are ordered correctly with respect to Ebox specifier
stores. This memory "scoreboarding" is accomplished by using the PA queue. a small list of
physical addresses which have a pending Ebox store.

4.1.5

The Cbox

The Cbox is the controller for the second level cache (the Backup Cache, or Bcache). Both the
tags and data for the Bcache are stored in off-chip RAMs. The size and access time of the Bcache
RAMs can be configured as needed by different system environments. The Bcache sizes supported
are 2 ME, 512 KB, 256 KB, and 128 KB. In addition, a system with no Bcache RAMs is supported,
although significant performance degradation occurs without a Bcache. The Bcache is a direct
mapped writeback cache with block and fill sizes of 32 bytes. The Cbox packs sequential writes
to the same quadword in order to mjnimize Bcache write accesses. Multiple write commands are
held in the eight-entry WRITE_QUEUE.
The Cbox is also the interface to the NDAL, which is the NVAX connection to the memory subsystem. The NDAL_IN_QUEUE loads fill data and writeback requests from the NDAL to the CPU.
The NON_WRITEBACK_QUEUE and WRITEBACK_QUEUE hold read requests and writeback
data to be sent to the memory subsystem over the NDAL.

4.1.6

Major Internal Buses

This is a list of the major interbox buses:
•

B%S6_DATA,..B:

This bidirectional bus between the Cbox and MBox is used to transfer write data to the backup
cache, to to transfer:fill data to the primary cache.
•

C%cBOX-,ADDR_B:

This bus is used to transfer the physical address of a Pcache invalidate from the Cbox to the
MBOx.
•

Eo/oABUS_H, E%BBUS_H:

These two 32-bit buses contain the A- and B-port operands for the Ebox, and are also used
to transfer operand data to the Fbox.

4-4

Chip Overview

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

•

E%mOx..~BUS_L:

This bus is used by the Ibox to read the Ebox Register File in order to perform an operand
access. An example is to read a register's contents for a register deferred type specifier.
•

E%IXLRETIRE_H, E%D~RETIRE_BMODE_H, E~RETIRE_RN'_H:

This collection of related buses transfers information from the Ebox to the Ibox when a destination queue entry is retired.
•

E%SQ..BETIRE_H,

WfcSQ..RETIRE_MD_H,

£C1c8~RETIRE_RMODE_H,

E%SQ..RETIBE_RN'l_H,

Eo/cS~RETlRE_BN2_H:

This collection of related buses transfers information from the Ebox to the Ibox when a source
queue entry is retired.
•

E%VA....BUS_L:

This bus transfers an address from the Ebox to the MBOx.
•

E%WBUS_H:

This 32-bit bus transfers write data from the RMUX to the register file and the Mbox.
•

E_USQI1cMIB_H:

This bus carries Control Store data from the Mierosequencer to the Ebox.
•

E_BUS%UTEST_L:

This 3-bit bus transfers mierobranch conditions from the Ebox: to the mierosequencer.
•

Fo/oFBOX_RESULT_H:

This bus is used to transfer results from the Fbox to the Ebox.
•

I%mOX-.ADDR_H:

This bus transmits the virtual address of an Ibox memory reference to the Mbox. The address
may be for instruction prefeteh or an operand access.
•

I%IQ...BUS_H:

This bus carries instruction information from the Ibox to the Instruction Queue in the
Mierosequencer.
•

I%mOX_IW_BUS_H:

This bus is used by the Ibox to write the Ebox Register File for autoincrementldecrement type
specifiers and to deliver immediate operands to the Register File.
•

I%OPERAND_BUS_H:

This bus transfers information from the Ibox to the source and destination queues in the
Ebox.
•

Mo/cMD_BUS_H:

The bus returns right-justified memory read data from the Mbox to either the Ibox (64 bits)
or the Ebox (32 bits).
•

M%S6_PA....H:

This bus transfers the address for a backup cache reference from the MBox to the Cbox.
•

NDAL:
The NDAL are bidirectional off-cbip multiplexed address and data lines used by the Cbox to
communicate with the memory subsystem. The NDAL carries :6.11 data and writeback requests
to the CPU, and writeback data and read requests from the CPU to memory.

DIGITAL CONFIDENTIAL

Chip Overview 4-5

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

4.2

Revision History

Table 4-1:

Revision History

Who

When

DesmdpuoDofCbaage

Debra Bernstein

06-Mar-1989

Release for extemal review.

Mike Uhler

18-Dec-1989

Update for second-pass release.

Mike Uhler

04-Dec-1990

Update after pass 1 PG.

4-6 Chip OVerview

DIGITAL CONFIDENTIAL

Chapter 5
Macroinstruction and Microinstruction Pipelines

5.1

Introduction
This chapter discusses the architecture of the !\'"'\:U CPU macroinstruction and microinstruction
pipeline. It includes a section of general pipeline fundamentals to set the stage for the specific
NVAX CPU implementation of the pipeline. This is followed by an overview of the NVAX CPU
pipeline, an examination of macroinstIUction execution, and a discussion of stall and exception
handling from the viewpoint of the Ebox.

5.2

Pipeline Fundamentals
This section discusses the fundamentals of instruction pipelining in a general manner that is
independent of the NVAX CPU implementation. It is intended as a primer for those readers who
do not understand the concept and implications of instruction pipelining. Readers familiar with
this material are encouraged to skip (or at most skim) this section.

5.2.1

The Concept of a Pipeline

The execution of a VAX macroinstruction involves a sequence of steps which are carried out
in order to complete the macroinstruction operation. Among these steps are: instruction fetch,

instruction decode, specifier evaluation and operand fetch, instruction execution, and result store.
On the simplest machines, these steps are carried out sequentially, with no overlap of the steps,
as shown in Figure 5-1.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-1

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 5-1:

Non-Plpellned Instruction Execution

Instruction 1
Instruction 2
Instruction 3

In this diagram, "SO", "S2", ..., "S6" denote particular steps in the execution of an instruction.
For this simple scheme, all of the steps for one instruction are performed, and the instruction is
completed, before any of the steps for the next instruction are started.
In more complex machines, one or more steps of the execution process are carried out in parallel
with other steps. For example, consider Figure 5-2.
Figure 5-2:

Partlally.Plpelined Instruction execution

--------------->
---------------------+----------------------------------- T~

Instruction 1
Instruction :2
Instruction 3

.
.
15015lI5215315'155ISf,

~--------------------+
150:5:1521531541551561

+--------------------+
+--------------------+
15015l1521531541S51561
+--------------------+

In this example, step 86 of each instruction is overlapped in time (or executed in parallel) with
step SO of the next instruction. In doing so, the number of instructions executed per unit time
(instruction throughput) goes up because an instruction appears to take less time to complete.
In the most complex machines, most (or all) of the steps are executed in parallel as indicated in
Figure 5-3.

5-2

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Speemcation, Revision 1.0, February 1991

Figure 5-3:

Fully.Plpelined Instruction execution

--------------->
+--------------------+
1501511521531541551561
+--------------------+
+--------------------+
1501511521531541551561
+--------------------+
+--------------------+
1501511521531541551561
+--------------------+
+--------------------+
1501511521531541551561
+--------------------+
+--------------------+
:501511521531S41551S61
+--------------------+

--------------- !ime
Instruction 1

Instruction 2

Instruction 3

Instruction 4

Instruction 5

In this example every step of instruction execution is performed in parallel with every other
step. This means that a ne\v instruction is started as soon as step 80 is completed for the
previous instruction. If each step, 80 ..86, took the same amount of time, the apparent instruction
throughput would be seven times greater than that of Figure 5-1 above, even though each
instruction takes the same amount of time to execute in both cases.
Figures 5-2 and 5-3 are examples of the concept of instruction pipelining, in which one or
more steps necessary to ex.ecute an instruction are performed in parallel with steps for other
instructions.

5.2.2

Pipeline Flow

A real-world form of a pipeline is an automobile assembly line. At each station of the assembly
line (called segments of the pipeline in our case), a task is performed on the partially completed
automobile and the result is passed on to the next station. At the end of the assembly line, the
automobile is complete.
In an instruction pipeline, as in an assembly line, each segment is responsible for performing a
task and passing the completed result to the next segment. The exact task to be performed in
each pipeline segment is a function of the degree of pipelining implemented and the complexity
of the instruction set.
One attribute of an automobile assembly line is equally important to an instruction pipeline:
smooth and continuous flow. An automobile assembly line works well because the tasks to be
performed at each station take about the same amount of time. This keeps the line moving at a
constant pace, with no starts and stops which would redu.ce the number of completed automobiles
per unit time.

An analogous situation exists in an instruction pipeline. In order to achieve real efficiency in
an instruction pipeline, information must flow smoothly and continuously from the start of the
pipeline to the end. If a pipeline segment somewhere in the middle is not able to supply results
to the next segment of the pipeline, the entire pipeline after the offending segment must stop, or
stall, until the segment can supply a result.
In the general case, a pipeline stall results when a pipeline segment can not supply a result to
the next segment, or when it can not accept a new result from a previous segment.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

This is a fundamental problem with most instruction pipelines because they occasionally (or not
so occasionally) stall. Stalls result in decreased instruction throughput because the smooth flow
of the pipeline is broken.
A typical example of a pipeline stall involves memory reads. A simple three-segment pipeline
might fetch operands in segment 1, use the operands to compute results in segment 2, and make
memory references or store results in segment 3, as shown in Figure 5-4.
Figure 5-4:

Simple Three-Segment Pipeline

+-----------+
+-----------+ +-----------+
1 Operand
1-> I Computation 1->1 Memory
I

Access

Read

+-----------+ +-----------+ +-----------+
Figure 5-5 illustrates what happens when the pipeline control wants to use the result of the
memory read as an operand.
Figure 5-5:

Information Flow Against the Pipeline

~-----------1
1

O!=,&=r.d

~----------+

+-----------Meme=-..!
i ----+

,-> I Computation 1->1
1 1

.iL~::eS5!

aead

+------------ +-----------+ +-----------+ I
--------------------------------------+
I
+-----------+
+-----------+ +-----------+
Operand
1->ICcmputationl->1 Result
~---->I

Access

Stor&

+-----------+ +-----------+ +-----------+
In this case, the operand access segment of 12 can not supply an operand to the computation
segment because the memory read done by II has not yet completed. As a result, the pipeline
must stall until the memory read has completed. This is shown in Figure 5-6.

5-4

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Figure 5-6: Stalls Introduced by Backward Pipeline Flow
I1

+-----------+ +-----------+ +-----------+
1 Operand 1->IComputat1onl->1 Memory
1----+
1 Access 1 1
1 1 Read
1
1
+-----------+ +-----------+ +-----------+
1
+-------------------------------------+
1
+-----------+ +-----------+ +-----------+
+---->1
Stall
1->1
Stall
1->1
Stall
1
1
1
1 1
1 1
1
+-----------+ +-----------+ +-----------+
1
1
+-----------+ +-----------+ +-----------+
+------------------->1
Stall
1->1
Stall
1->1
Stall
1
1
1 1
1 1
+-----------+ +-----------+ +-----------+
1
1
+-----------+ +-----------+ +-----------+
+---------------------------------->1 Operand 1->IComputat1onl->1 Result
1
1 Access 1 1
1 1 Store
I
+-----------+ +-----------+ +-----------+

In this diagram, the memory read data from 11 is not available until the read request passes
through segment 3 of the pipeline. But the operand access segment for 12 wants the data
immediately. The result is that the operand access segment of 12 has to stall twice waiting for
the memory read data to become available. This, in turn, stalls the rest of the pipeline segments
after the operand access segment.
This situation is an excellent example of an age-old problem with instruction pipelining. The
natural and desired direction of information :fiow in a pipeline is from left to right in the above
diagrams. In this case, information must flow from the output of the memory read segment into
the operand access segment. This requires a right-to-Ieft movement of information from a later
pipeline segment to an earlier one. In general, any information transfer which goes against the
normal flow of the pipeline has the potential for causing pipeline stalls.

5.2.3

Stalls and Exceptions in an Instruction Pipeline

Even the best pipeline design must be prepared to deal with stalls and exceptions created in the
pipeline. As mentioned above, a stall is a condition in which a pipeline segment can not accept
a new result from a previous segment, or can not send a result to a new segment. An exception
occurs when a pipeline segment detects an abnormal condition which must stop, and then drain
the pipeline. Examples of exceptions are: memory management faults, reserved operand faults,
and arithmetic overflows. One of the inherent costs of a pipelined implementation is the extra
logic necessary to deal with stalls and exceptions.
There are two primary considerations concerning stalls: what action to take when one occurs,
and how to minimize them in the first place. The design of most instruction pipelines assumes
that the pipeline will not stall, and handles the stall condition as a special case, rather than
the other way around. This means that each segment of the pipeline performs its function and
produces a result each cycle. If a stall occurs just before the end of the cycle, the segment must
block global state updates and repeat the same operation during the next cycle. The design of
the pipeline control must take this into account and be prepared to handle the condition.
A common stall condition occurs when each pipeline segment has the same average speed, but
different peak speeds. For example, a pipeline segment whose task is to perform both memory
references and register result stores may take longer to perform memory references than result
stores. This can cause earlier segments of the pipeline to stall because the segment can not
take new inputs as fast if it is doing a memory reference rather than a result store. A common

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-5

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

technique to minimize this problem is to place buffers between pipeline segments, as shown in
Figure 5-7.
Figure 5-7:

Buffers Between Pipeline Segments

+-----------+
+------+ +-----------+ +------+ +-----------+
I Operand 1-> IBu£fer 1-> IComputation 1-> IBu££er 1->1 Memory
I

Aeees s

Read

+-----------+ +------+ +-----------+ +------+ +-----------+
By placing a buffer of sufficient depth between each segment of the pipeline, segments of differing
peak speeds can avoid stalls caused if the next segment is unable to accept a new result. Instead,
the result goes into the inter-segment buffer and the next segment removes it from the buffer
when it needs it. Unfortunately, adding such buffers means that additional logic must also be
added to handle the buffer fullIbuffer empty conditions.
The performance advantage of an instruction pipeline comes from the parallelism built into the
pipeline. If the parallelism is defeated by, for example, a stall, the advantage starts to drop. One
problem associated with pipelines is that they can provide '1umpy" performance. That is, two
similar programs may experience radically different performance if one causes many more stalls
(which defeat the parallelism of the pipeline) than the other.
Pipeline exceptions are different from stalls in that exceptions cause the pipeline to empty
or drain. Usually, everything that entered the pipeline before the point of error is allowed
to complete. Everything that entered the pipeline after the point of error is prevented from
completing. This can add considerable complexity to the pipeline control.
A larger problem occurs when the designer wants exceptions to be recoverable. Consider an
exception caused by a memory management fault. On the VAX., this condition can occur because
of a TB miss. The correct response to this fault is to read a PrE from memory, refill the TB, and
restart the request that caused the fault. This can add considerable complexity to the design.

5.3

NVAX CPU Pipeline Overview
The remainder of this chapter discusses the NVAX CPU pipeline, which is shown as a block
diagram in Figure 5-8. This is a high-level view of the CPU and abstracts many of the details.
For a more detailed view of the pipeline, users are encouraged to refer to the individual box
chapters in this specification.
The pipeline is divided into seven segments denoted as "SO" through "S6". In Figure 5-8, the
components of each section of the CPU are shown in the segment of the pipeline in which they
operate.
The NVAX CPU is fully pipelined and, as such, is most similar to the abstract example
shown in Figure 5-3. In addition to the overall macroinstruction pipeline, in which multiple
macroinstructions are processed in the various segments of the pipeline, most of the sections
also micropipeline operations. That is, if more than one operation is required to process a
macroinstruction, the multiple operations are also pipelined within a section.

5-6 Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

c
i5

fa
C

CiJ

"11

5
m

~
><

;;
r

'''0

'ILlr 0 ...._ ....... 00

IlAMII

1.5"

MYoMD_OUB_"
I
I
I

ft.

~
ct
NDAL

::J
::J

B:
0"

It.

CM OUT
UHC"

D-

"T"
Mil

;

a:
~

MjOX

S
n

:
:

---~.-~~~
I'X
oUt,,,:

!I.

t""

'~"7

.;-,

I3"

jlf(~

1;-....,..;:~

'~j
-,,....,.,.

to-'

t8
to-'

NVAX CPU Chip Functional Speci:&cation, Revision 1.0, February 1991

5.3.1

Normal Macroinstruction Execution

Execution of macroinstructions in the NVAX pipeline is decomposed into many smaller steps
which are the distributed responsibility of the various sections of the chip. Because the NVAX
CPU implements a macroinstruction pipeline, each section is relatively autonomous, with queues
inserted between the sections to normalize the processing rates of each section.

5.3.1.1

The Ibox

The Ibox is responsible for fetching instruction stream data for the next instruction, decomposing
the data into opcode and specifiers, and evaluating the specifiers with the goal of prefetcbing
operands to support Ebox execution of the instruction.
The Ibox is distributed across segments SO through S3 of the pipeline, with most of the work
being done in 81. In 80, instruction stream data is fetched from the virtual instruction cache
(VI C) using the address contained in the virtual instruction buffer address register MBA). The
data is written into the prefetch q1l:eue (PFQ) and VIBA is incremented to the next location.
In segment S1, the PFQ is read and the burst unit uses internal state and the contents of
the IROM to select the next instruction stream component-either an opcode or specifier. This
decoding processing is known as bursting. Some instruction components take multiple cycles to
burst. For example, FD opcodes require two burst cycles: one for the FD byte, and one for the
second opcode byte. Similarly, indexed specifiers require at least two burst cycles: one for the
index byte, and one or more for the base specifier.
"When an opcode is decoded, the information is passed to the issue unit, which consults the mOM
for the initial Ebox control store address of the routine which will process the instruction. The
issue unit sends the address and other instruction-related information to the instruction queue
where it is held until the Ebox reaches the instruction.
"When a specifier is decoded, the information is passed to the source and destination queue
allocation logic and, potentially, to the complex specifier pipeline. The source and destination
queue allocation logic allocates the appropriate number of entries for the specifier in the source
and destination queues in the Ebox. These queues contain pointers to operands and results, and
are discussed in more detail below.
If the specifier is not a short literal or register specifier, which are collectively known as
simple specifiers, it is considered to be a complex specifier and is processed by the small
microcode-controlled complex specifier unit (CSU), which is distributed in segments 81 (control
store access), S2 (operand access, including register file read), and S3 (ALU operation, Mbox
request, GPR write) of the pipeline. The esu pipeline computes all specifier memory addresses,
and makes the appropriate request to the Mbox for the specifier type. To avoid reading or writing
a GPR which is interlocked by a pending Ebox reference, the CSU pipeline includes a register
scoreboard which detects data dependencies. The esu pipeline also provides additional help to
the Ebox by supplying operand information that is not an explicit part of the instruction stream.
For example, the PC is supplied as an implicit operand for instructions that require it (such as
BSBB).
The branch prediction unit (BPU) watches each opcode that is decoded looking for conditional
and unconditional branches. For unconditional branches, the BPU calculates the target PC and
redirects PC and VIBA to the new path. For conditional branches, the BPU predicts whether
the instruction will branch or not based on previous history. If the prediction indicates that the
branch will be taken, PC and VIBA are redirected to the new path. The BPU writes the conditional
5-8 Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

branch prediction flag into the branch queue in the Ebox, to be used by the Ebox in the execution
of the instruction. The BPU maintains enough state to restore the correct instruction PC if the
prediction turns out to be incorrect.
5.3.1.2

The Microsequencer

The microsequencer operates in segment 82 of the pipeline and is responsible for supplying to
the Ebox the next microinstruction to execute. If a macroinstruction requires the execution of
more than one microinstruction, the microsequencer supplies each microinstruction in sequence
based on directives included in the previous microinstruction.
At macroinstruction boundaries, the microsequencer removes the next entry from the instruction
queue, which includes the initial microinstruction address for the macroinstruction. If the
instruction queue is empty, the microsequencer supplies the address of a special no-op
microinstruction.
The microsequencer is also responsible for evaluating all exception requests, and for providing
a pipeline £lush control signal to the Ebox. For certain exceptions and interrupts, the
microsequencer injects the address of a special microinstruction handler that is used to respond
to the event.
5.3.1.3

The Ebox

The Ebox is responsible for executing all of the non-floating point instructions, for delivery of
operands to and receipt of results from the Fbox, and for handling non-instruction events such
as interrupts and exceptions. The Ebox is distributed through segments 83 (operand access,
including register file read), S4 (ALU and shifter operation, Rmux request), and 85 (Rmux
completion, register write, completion of Mbox request) of the pipeline.
For the most part, instruction operands are prefetched by the Ibox, and addressed indirectly
through the source queue. The source queue contains the operand itselffor short literal specifiers,
and a pointer to an entry in the register file for other operand types.
An entry in the field queue is made when a field-type specifier entry is made into the source queue.
The field queue provides microbranch conditions that allow the Ebox microcode to determine if
a field-type specifier addresses either a GPR or memory. A microbranch on a valid field queue
entry retires the entry from the queue.

The register file is divided into four parts: the GPRs, memory data (MD) registers, working
registers, and CPU state registers. For register-mode speci::6.ers, the source queue points to the
appropriate GPR in the register file. For other non-short literal speci::6.er modes, the source queue
points to an MD register. The MD register is either written directly by the Ibox, or by the Mbox
as the result of a memory read generated by the Ibox.
The 83 segment of the Ebox pipeline is responsible for selecting the appropriate operands for the
Ebox and Fbox execution of instructions. Operands are selected onto E%ABUS_B and E%BBUS_B
for use in both the Ebox and Fbox. In most instances, these operands come from the register file,
although there are other data path sources of non-instruction operands (such as the P8L).
Ebox computation is done by the ALU and the shifter in the S4 segment of the pipeline on
operands supplied by the 83 segment. Control for these units is supplied by the microinstruction
which was originally supplied to the 83 segment by the microsequencer, and then subsequently
moved forward in the pipeline.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-9

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991·

The S4 segment also contains the RMUX, whose responsibility is to select results from either
the Ebox or Fbox and perform the appropriate register or memory operation. The RMUX inputs
come from the ALU, shifter, and P%FBO~RESULT_B at the end of the cycle. The RMUX actually
spans the S4/85 boundary such that its outputs are valid at the beginning of the 85 segment.
The RMUX is controlled by the retire queue, which specifies the source (either Ebox or Fbox) of
the result to be processed (or retired) next. Non-selected RMUX sources are delayed until the
retire queue indicates that they should be processed.
As the source queue points to instru.ction operands, so the destination queue points to the
destination for instruction results. If the result is to be stored in a GPR, the destination queue
contains a pointer to the appropriate GPR. If the result is to be stored in memory, the destination
queue indicates that a request is to be made to the Mbox, which contains the physical address of
the result in the PA queue (which is described below). This information is supplied as a control

input to the RMUX logic.
Once the RMUX selects the appropriate source of result information, it either requests Mbox
service, or sends the result onto E%WBUS_B to be written back to the register file or to other data.
path registers in the 85 segment of the pipeline. The interface between the Ebox and Mbox for
all memory requests is the EM_LATCH, which contains control information and may contain an
address, data, or both, depending on the type of request. In addition to operands and results that
are prefetched by the Ibox, the Ebox can also make explicit memory requests to the Mbox to read
or write data.
5.3.1.4

The Fbox

The Fbox is responsible for executing all of the :floating point instructions in the VAX base
instruction group, as well as the longword-Iength integer multiply instructions.
For each instruction that the Fbox is to execute, it receives from the microsequencer the opcode
and other instruction-related information. The Fbox receives operand data from the Ebox on
Eo/oABUS_B and E%BBUS_H.
Execution of instructions is performed in a dedicated Fbox pipeline that appears in segment S4
of Figure 5-8,. but is actually a minimum of three cycles in length. Certain instructions, such
as integer multiply, may require multiple passes through some segments of the Fbox pipeline.
Other instructions, such as divide, are not pipelined at all.
Fbox results and status are returned via P%FBO~BESULT_H to the RMUX in the Ebox for
retirement. When the instruction is next to retire, the RMUX hardware, as directed by the
destination queue, sends the results to either the GPRs for register destinations, or to the Mbox
for memory destinations.
5.3.1.5

The Mbox

The Mbox operates in the 85 and 86 segments of the pipeline, and is responsible for all memory
references initiated by the other sections of the chip. Mbox requests can come from the Ibox
(for VIC fills and for specifier references), the Ebox or Fbox via the RMUX and the EM_LATCH
(for instruction result stores and for explicit Ebox memory requests), from the Mbox itself (for
translation buffer fills and PrE reads), and from the Cbox (for invalidates and cache fills).

5-10

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

All virtual references are translated to a physical address by the translation buffer (TB), which
operates in the 85 segment of the pipeline. For instruction result references generated by the
Ibox, the translated address is stored in the physical address queue CPA queue). These addresses
are later matched with data from the Ebox or Fbox, when the result is calculated.
For memory references, the physical address from either the TB or the PA queue is used to
address the primary cache (Pcache) starting in the 85 segment of the pipeline and continuing
into the 86 segment. Read data is available in the middle of the 86 segment, right-justified and
returned to the requester on M%'MD_BUS_B by the end of the cycle. Writes are also completed by
the end of the cycle. Although the Pcache access spans the 85 and 86 segments of the pipeline,
a new access can be started each cycle in the absence of a TB or cache miss.
5.3.1.6

The Cbox

The Cbox is responsible for maintaining and accessing the backup cache (Bcache), and for control
of the off-chip bus (the NDAL). The Cbox receives input from the Mbox in the 86 segment of the
pipeline, and usually takes multiple cycles to complete a request. For this reason, the Cbox is
not shown in specific pipeline segments.
If a memory read misses in the Pcache, the request is sent to the Cbox for processin~. The
Cbox first looks for the data in the Bcache and fills the Pcache from the Bcache if the data is
present. If the data is not present in the Bcache, the Cbox requests a cache filIon the ~-nAL
from memory. When memory returns the data, it is written to both the Bcache and to the Pcache
(and potentially to the VIC). Although Pcache fills are done by making a request to the Mbox
pipeline, data is returned to the original requester as quickly as possible by driving data directly
onto Bo/cS6_DAT.A...B, and from there onto M%MD_BUS_B as soon as the bus is free.
Because the Pcache operates as a write-through cache, all memory writes are passed to the Cbox.
10 avoid multiple writes to the same Bcache block., the Cbox contains a write buffer in which
multiple writes to the same quadwords are packed together before the Bcache is actually written.
To maintain cache coherence with other system components, the Obex acquires ownership of any
data that is written to the cache.

5.3.2

Stalls in the Pipeline

Despite our best attempts at keeping the pipeline flowing smoothly, there are conditions which
cause segments of the pipeline to stall. Conceptually, each segment of the pipeline can be
considered as a black box which performs three steps every cycle:
1. The task appropriate to the pipeline segment is performed, using control and inputs from the
previous pipeline segment. The segment then updates local state (within the segment), but
not global state (outside of the segment).
2. Just before the end of the cycle, all segments send stall conditions to the appropriate state
sequencer for that segment, which evaluates the conditions and determines which, if any,
pipeline segments must stall.
3. If no stall conditions exist for a pipeline segment, the state sequencer allows it to pass results
to the next segment and accept results from the previous segment. This is accomplished by
updating global state.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-11

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

This sequence of steps maximizes throughput by allowing each pipeline segment to assume that
a stall will not occur (which should be the common case). If a stall does occur at the end of
the cycle, global state updates are blocked, and the stalled segment repeats the same task (with
potentially different inputs) in the next cycle (and the next, and the next) until the stall condition
is removed.
This description is over-simplified in some cases because some global state must be updated by a
segment before the stall condition is known. Also, some tasks must be performed by a segment
once and only once. These are treated specially on a case-by-case basis in each segment.
Within a particular section of the chip, a stall in one pipeline segment also causes stalls in all
upstream segments (those that occur earlier in the pipeline) of the pipeline. Unlike Rigel, stalls
in one segment of the pipeline do not cause stalls in downstream segments of the pipeline. For
example, a memory data stall in Rigel also caused a stall of the downstream ALU segment. In
NVAX., a memory data stall does not stall the ALU segment (a no-op is inserted into the S4
segment when S4 advances to S5).
There are a number of stall conditions in the chip which result in a pipeline stall. Each is
discussed briefly below and in much more detail in the appropriate chapter of this specification.
5.3.2.1

SO Stalls

Stalls that occur in the SO segment of the pipeline are as follows:

Ibox:
•

5.3.2.2

PFQ full: In normal operation, the VIC is accessed using the address in VIBA, the data is
sent to the prefetch queue, and VIBA is incremented. If the PFQ is full, the increment of
VIBA is blocked, and the data is re-referenced in the VIC until there is room for it in the
PFQ. At that point, prefetch resumes.
S1 Stalls

Stalls that occur in the Sl segment of the pipeline are as follows:

!box:
•

•

Insufficient PFQ data: The burst unit attempts to decode the next instruction component
each cycle. If there are insufficient PFQ bytes valid to decode the entire component, the burst
unit stalls until the required bytes are delivered from the VIC.
Source queue or destination queue full: During specifier decoding, the source and destination
queue allocation logic must allocate enough entries in each queue to satisfy the requirements
of the specifier being parsed. To guarantee that there will be sufficient resources available,
there must be at least 2 free source queue entries and 2 free destination queue entries to
complete the burst of the specifier. If there are insufficient free entries in either queue,the
burst unit stalls until free entries become available.
MD file full: When a complex specifier is decoded, the source queue allocation logic must
allocate enough memory data registers in the register file to satisfy the requirements of the
specifier being parsed. 'Ib guarantee that there will be sufficient resources available, there
must be at least 2 free memory data registers available to complete the burst of the specifier.
If there are insufficient free registers, the burst unit stalls until enough memory data registers
becomes available.

5-12 Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

•

5.3.2.3

Second conditional branch decoded: The branch prediction unit predicts the path that each
conditional branch will take and redirects the instruction stream based on that prediction. It
retains sufficient state to restore the alternate path if the prediction was wrong. If a second
conditional branch is decoded before the first is resolved by the Ebox, the branch prediction
unit has nowhere to store the state, so the burst unit stalls until the Ebox resolves the actual
direction of the first branch.
Instruction queue full: When a new opcode is decoded by the burst unit, the issue unit
attempts to add an entry for the instruction to the instruction queue. If there are no free
entries in the instruction queue, the burst unit stalls until a free entry becomes available,
which occurs when an instruction is retired through the RMtJX.
Complex specifier unit busy: If the burst unit decodes an instruction component that must
be processed by the CSU pipeline, it makes a request for service by the CSU through an 81
request latch. If this latch is still valid from a previous request for service (either due to a
multi-cycle :flow or a CSU stall), the burst unit stalls until the valid bit in the request latch
is cleared.
Immediate data length not available: The length of the specifier extension for immediate
specifiers is dependent on the data length of the specifier for that specific instruction. The
data length information comes from one of the Ibox instr-:.ction PLAs which is accessed based
on the opcode of the instruction. If the PLA access is not complete before an immediate
specifier is decoded (which would have to be the first specifier of the instruction), the burst
unit stalls for one cycle.

S2 Stalls

Stalls that occur in the 82 segment of the pipeline are as follows:
Ibox:
•

•

Outstanding Ebox or Fbox GPR write: In order to calculate certain specifier memory
addresses, the C8U must read the contents of a GPR from the register file. If there is a
pending Ebox or Fbox write to the register, the Ibox GPR scoreboard prevents the GPR read
by stalling the 82 segment of the C8U pipeline. The stall continues until the GPR write
completes.
Memory data not valid: For certain operations, the Ibox makes an Mbox request to return
data which is used to complete the operation (e.g., the read done for the indirect address of a
displacement deferred specifier). The Ibox MD register contains a valid bit which is cleared
when a request is made, and set when data returns in response to the request. If the Ibox
references the Ibox MD register when the valid bit is off, the 82 segment of the e8U pipeline
stalls until the data is returned by the Mbox.

Microsequeneer:
•

Instruction queue empty: The final microinstruction of a macroinstruction execution How
in the Ebox is indicated when a 8EQ.MUXILAST.CYCLE* microinstruction is decoded
by the microsequencer. In response to this event, the Ebox expects to receive the first
microinstruction of the next macroinstruction How based on the initial address in the
instruction queue. If the instruction queue is empty, the Microsequencer supplies the
instruction queue stall microinstruction in place of the next macroinstruction :flow. In effect,
this stalls the micro sequencer for one cycle.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-13

NVAX CPU Chip Functional Speci:fication, Revision 1.0t February 1991

5.3.2.4

S3 Stalls

Stalls that occur in the S3 segment of the pipeline are as follows:
Ibox:

•

Outstanding Ebox GPR read: In order to complete the processing for auto-increment,
auto-decrement, and auto-increment defelTed specifiers, the CSU must update the GPR with
the new value. If there is a pending Ebox read to the register through the source queue, the
Ibox scoreboard prevents the GPR write by stalling the S3 segment of the esu pipeline. The
stall continues until the Ebox reads the GPR.
Specifier queue full: For most complex specifiers, the esu makes a request for Mbox service
for the memory request required by the specifier. If there are no free entries in the specifier
queue, the S3 segment of the esu pipeline stalls until a free entry becomes available.
RLOG full: Auto-increment, auto-decrement, and auto-increment defelTed specifiers require
a free RLOG entry in which to log the change to the GPR. If there are no free RLOG entries
when such a specifier is decoded, the S3 segment of the esu pipeline stalls until a free entry
becomes available.

Ebox:

•

Memory read data not valid: In some instances, the Ebox may make an explicit read request
to the Mbox to return data in one of the 6 Ebox working registers in the register file. When
the request is made, the valid bit on the register is cleared. '\\1ten the data is written to the
register, the valid bit is set. If the Ebox references the working register when the valid bit is
clear, the S3 segment of the Ebox pipeline stalls until the entry becomes valid.
Field queue not valid: For each macroinstruction that includes a field-type specifier, the
microcode microbranches on the first entry in the field queue to determine whether the field
specifier addresses a GPR or memory. If the field queue is empty (indicating that the Ibox
has not yet parsed the field specifier), the result of the next address calculation repeats the
microbranch the next cycle. Although this is not a true stall, the effects are the same in that
a microinstruction is repeated until the field queue becomes valid.
Outstanding Fbox GPR write: Because the Fbox computation pipeline is multiple cycles long,
the Ebox may start to process subsequent instructions before the Fbox completes the first.
If the Fbox instruction result is destined for a GPR that is referenced by a subsequent Ebox
microword, the S3 segment of the Ebox pipeline stalls until the Fbox GPR write occurs.
Fbox instruction queue full: When an instruction is issued to the Fbox, an entry is added to
the Fbox instruction queue. If there are no free entries in the queue, the S3 segment of the
Ebox pipeline stalls until a free entry becomes available.

EboxlFbox:

•

Source queue empty: Most instruction operands are prefetched by the Ibox, which writes
a pointer to the operand value into the source queue. The Ebox then references up to two
operands per cycle indirectly through the source queue for delivery to the Ebox or Fbox. If
either of the source queue entries referenced is not valid, the S3 segment of the Ebox pipeline
stalls until the entry becomes valid.

5-14 Macroinstruction and MicrolnstNction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

•

5.3.2.5

Memory operand not valid: Memory operands are prefetched by the Ibox, and the data is
written by the either the Mbox or Ibox into the memory data registers in the register file. If
a referenced source queue entry points to a memory data register which is not valid, the S3
segment of the Ebox pipeline stalls until the entry becomes valid.

S4 Stalls

Stalls that occur in the S4 segment of the pipeline are as follows:
Ebox:

•

Branch queue empty: When a conditional or unconditional branch is decoded by the Ibox, an
entry is added to the branch queue. For conditional branch instructions, the entry indicates
the Ibox prediction of the branch direction. The branch queue is referenced by the Ebox to
verify that the branch displacement was valid, and to compare the actual branch direction
with the prediction. If the branch queue entry has not yet been made by the Ibox, the S4
segment of the Ebox pipeline stalls until the entry is made.
Fbox GPR operand scoreboard full: The Ebox implements a register scoreboard to prevent
the Ebox from reading a GPR to which there is an outstanding write by the Fbox. For each
Fbox instruction which will write a GPR result, the Ebox adds an entry to the Fbox GPR
scoreboard. If the scoreboard is full when the Ebox attempts to add an entry, the S4 segment
of the Ebox pipeline stalls until a free entry becomes available.

Fbox:

•

Fbox operand not valid: Instructions are issued to the Fbox when the opcode is removed
from the instruction queue by the microsequencer. Operands for the instruction may not
arrive until some time later. If the Fbox attempts to start the instruction execution when the
operands are not yet valid, the Fbox pipeline stalls until the operands become valid.

EboxlFbox:

•

Destination queue empty: Destination specifiers for instructions are processed by the Ibox,
which writes a pointer to the destination (either GPR or memory) into the destination queue.
The destination queue is referenced in two cases: when the Ebox or Fbox store instruction
results via the RMIJX, and when the Ebox tries to add the destination of Fbox instructions to
the Ebox GPR scoreboard. If the destination queue entry is not valid (as would be the case if
the Ibox has not completed processing the destination specifier), a stall occurs until the entry
becomes valid.
PA queue empty: For memory destination specifiers, the Ibox sends the virtual address of the
destination to the Mbox, which translates it and adds the physical address to the PA queue.
If the destination queue indicates that an instruction result is in memory, a store request is
made to the Mbox which supplies the data for the result. The Mbox matches the data with
the first address in the PA queue and performs the write. If the PA queue is not valid when
the Ebox or Fbox has a memory result ready, the RMUX stalls until the entry becomes valid.
As a result, the source of the RMUX input (Ebox or Fbox) also stalls.
EM_LATCH full: All implicit and explicit memory requests made by the Ebox or Fbox pass
through the EM_LATCH to the Mbox. If the Mbox is still processing the previous request
when a new request is made, the RMUX stalls until the previous request is completed. As a
result, the source of the RMUX input (Ebox or Fbox) also stalls.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-15

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

•

5.3.3

RMUX selected to other source: Macroinstructions must be completed in the order in which
they appear in the instruction stream. The Ebox retire queue determines whether the next
instruction to complete comes from the Ebox or the Fbox. If the next instruction should come
from one source and the other makes an RMUX request, the other source stalls until the
retire queue indicates that the next instruction should come from that source.

Exception Handling

A pipeline exception occurs when a segment of the pipeline detects an event which requires that
the normal flow of the pipeline be stopped in favor of another flow. There are two fundamental
types of pipeline exceptions: those that resume the original pipeline flow once the exception is
corrected, and those that require the intervention of the operating system. A TB miss on a
memory reference is an example of the :first type, and an access control violation is an example
of the second type. M=O faults are handled specially, as described below.
Restartable exceptions are handled entirely within the confines of the section that detected the
event. Other exceptions must be reported to the Ebox for processing. Because the NVAX CPU is
macropipelined, exceptions can be detected by sections of the pipeline long before the instruction
which caused the exception is actually executed by the Ebox or Fbox. However, the reporting of
the exception is deferred until the instruction is executed by the Ebox or Fbox. At that point, an
Ebox handler is invoked to process the event.
Because the Ebox and Fbox are micropipelined, the point at which an exception handler is
invoked must be carefully controlled. For example, three macroinstructions may be in execution in
segments S3, 84, and S5 of the Ebox pipeline. If an exception is reported for the macroinstruction
in the 83 segment, the t"\vo macroinstructions that are in the 84 and 85 segments must be allowed
to complete before the exception handler is invoked.

To accomplish this, the S41S5 boundary in the Ebox is defined to be the commit point for a
microinstruction. Architectural state is not modified before the 85 segment of the pipeline, unless
there is some mechanism for restoring the original state if an exception is detected (the Ibox RLOG
is an example of such a mechanism). Exception reporting is deferred until the microinstruction
to which the event belongs attempts to cross the S4!S5 boundary. At that point, the exception
is reported and an exception handler is invoked. By deferring exception reporting to this point,
the previous microinstruction (which may belong to the previous macroinstruction) is allowed to
complete.
Most exceptions are reported by requesting a microtrap from the Microsequencer. When the
Microsequencer receives a microtrap request, it causes the Eboxto break all its stalls, aborts
the Ebox pipeline (by asserting E_USQ%PEJ\BORT_L), and injects the address of a handler for
the event into the control store address latch. This starts an Ebox microcode routine which will
process the exception as appropriate. Certain other kinds of exceptions are reported by simply
injecting the appropriate handler address into the control store at the appropriate point.
The VAX architecture categorizes exceptions into two types: faults and traps. For both types, the
microcode handler for the exception causes the Ibox to back out all GPR modifications that are
in the RLOG, and retrieves the PC from. the PC queue. For faults, the PC returned is the PC of
the opcode of the instruction which caused the exception. For traps, the PC returned is the PC
of the opcode of the next instruction to execute. The microcode then constructs the appropriate
exception frame on the stack, and dispatches to the operating system through the appropriate
8CB vector.

5-16

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Hevision 1.0, February 1991

There are a number of exceptions detected by the NVAX CPU pipeline, each of which is discussed
briefly below, and in much more detail in the appropriate chapter of this specification.
5.3.3.1

Interrupts

The CPU services interrupt requests from various sources between macroinstructions, and at
selected points within the string instructions. Interrupt requests are received by the interrupt
section and compared with the current IPL in the PSL. If the interrupt request is for an IPL
that is higher than the current value in the PSL, a request is posted to the microsequencer. At
the next macroinstruction boundary, the microsequencer substitutes the address of the microcode
interrupt service routine for the instruction execution flow.
The microcode handler then determines if there is actually an interrupt pending. If there is, it
is dispatched to the operating system through the appropriate SCB vector.
5.3.3.2

Integer Arithmetic exceptions

There are three integer arithmetic exceptions detected by the CPU, all of which are categorized
as traps by the VAX architecture. This is significant because the event is not reported until after
the commit point of the instruction, which allows that instruction to complete.
Integer Overflow Trap
An integer overflow is detected by the RMUX at the end of the S4 segment of the Ebox
pipeline. If PSL<lV> is set and overflow traps are enabled by the microcode, the event is
reported in segment 85 of the pipeline via a microtrap request.
Integer Divide-By-Zero Trap
An integer divide-by-zero is detected by the Ebox microcode routine for the instruction. It
is reported by explicitly retiring the instruction and then jumping directly to the microcode
handler for the event.
Subscript Range Trap
A subscript range trap is detected by the Ebox microcode routine for the INDEX instruction.
It is reported by explicitly retiring the instruction and then jumping directly to the microcode
handler for the event.

5.3.3.3

Floating Point Arithmetic exceptions

All floating point arithmetic exceptions are detected by the Fbox pipeline during the execution of
the instruction. The event is reported by the RMUX when it selects the Fbox as the source of the
next instruction to process. At that point, a microtrap is requested.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-17

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

5.3.3.4

Memory Management Exceptions

Memory management exceptions are detected by the Mbox when it processes a virtual read or
write. This section covers actual memory management exceptions such as access control violation,
translation not valid, and M=O faults. Translation buffer misses are discussed separately in the
next section. Because the reporting of memory management exceptions is specific to the operation
that caused the exception, each case is discussed separately.

•

I·Stream Faults
While the Ibox is decoding instructions, it may access a page which is not accessible due
to a memory management exception. This may occur on the opcode, a specifier or specifier
extension, or on a branch displacement. Should this occur, the Ibox sets a global :MME
fault flag and stops. Memory management exceptions detected on intermediate operations
during specifier evaluation (such as a read for the indirect address of a displacement deferred
specifier) are converted by the Ibox into source or destination faults, as described below.
If the Ebox reaches the instruction which caused the exception (which may not happen due to,
for example, interrupt, exception, or branch), it will reference one of the queues, which does
not have a valid entry because the Ibox stopped when the error was detected. The particular
queue depends on the instruction component on which the error was detected. If the Ibox
global MME flag is set when an empty queue entry is referenced, the error is reported in one
of four ways.
If the Ibox global ~WE flag is set when the microsequencer references an invalid instruction
queue entry, it inserts the instruction queue stall into the pipeline and the Ebox qualifies it
with the fault flag. "When this flag reaches the 54 segment of the pipeline and is selected by
the RMUX, a microtrap is requested.
If the Ibox global MME flag is set when the Ebox references an invalid source queue entry,
a fault flag is injected into either the Ebox or Fbox pipelines, depending on the type of
instruction. To avoid a deadlock, S3 stalls do not prevent forward prgress of the flag in
the pipeline. "When the flag reaches the S4 segment of the pipeline and is selected by the
RMux, a microtrap is requested.
If the Ibox global :M:ME flag is set when the Ebox microcode microbranches on an invalid field
queue entry, a fault flag is injected into the Ebox ·pipeline. When the flag reaches the S4
segment of the pipeline and is selected by the RMUX, a microtrap is requested.
If the Ibox global :MME :flag is set when the Ebox references an invalid branch queue entry,
and the RMUX selects the Ebox, a microtrap is requested.
If the Ibox global MME :flag is set when the RMUX references an invalid destination queue
entry for a store request, a microtrap is requested.

•

Source Operand Faults
If the Mbox detects a memory management exception during the translation for a source
specifier, it qualifies the data returned to the MD file with a fault flag which is written into
the MD file. When this entry is referenced by the Ebox, a fault flag is injected into the
pipeline. To avoid a deadlock, S3 stalls do not prevent forward prgress of the flag in the
pipeline. When the flag reaches the S4 segment of the pipeline and is selected by the RMUX,
a microtrap is requested.

5-18

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

•

Destination Address Faults
If the Mbox detects a memory management exception during the translation for a destination
specifier, it sets a fault flag in the PA queue entry for the address. When this entry is
referenced by the RM'UX, a microtrap is requested,.

•

Faults on Explicit Ebox Memory Requests
Explicit Ebox reads and writes are, by definition, performed in the context of the instruction
which the Ebox is currently executing. If the Mbox detects a memory management exception
that was the result of an explicit Ehox read or write, it requests an immediate microtrap to
the memory management fault handler.

•

M=O faults
M=O faults occur when the Mbox finds the M-hit clear in the PTE which is used to translate
write-type references. The event is reported to the Ebox in one of the three ways described
above: ,"ia the MD :file or PA queue fault :flags, or via an immediate microtrap for explicit
Ebox writes.
Unlike other memory management exceptions, which are dispatched to the operating system,
M=O faults are completely processed by the Ebox microcode handler. For normal instructions,
the handler causes the !box to back out all GPR modifications that are in the RLOG and
retrieves the PC from the PC queue. For string instructions, any RLOG entries that belong
to the string instructions are not processed, and PSL<FPD> is set. Using the PTE address
supplied by the Mbox, the Ebox microcode reads the PTE, sets the M-bit, and writes the
PTE back to memory. The instruction stream is then restarted at the interrupted instruction
(which may result in special FPD handling, as described below).

5.3.3.5

Translation Buffer Miss

Translation buffer misses are handled by the Mbox transparently to the rest of the CPU. When
a reference misses in the translation buffer, the Mbox aborts the current reference and invokes
the services of the memory management exception sequencer in the Mbox, which fetches the
appropriate PTE from memory and loads it into the translation buffer. The original reference is
then restarted.
5.3.3.6

Reserved Addressing Mode Faults

Reserved addressing mode faults are detected by the !box for certain illegal combinations of
specifier addressing modes and registers. When one of these combinations is detected, the Ibox
sets a global addressing mode fault flag that indicates that the condition was detected and stops.
If the Ibox global addressing mode fault flag is set when the Ebox references an invalid source
queue entry, a fault flag is injected into either the Ebox or Fbox pipelines, depending on the type
of instruction. To avoid a deadlock, 83 stalls do not prevent forward prgress of the -flag in the
pipeline. The fault flag is carried along the Ebox or Fbox pipeline and passed to the RMUX,
which reports the event by requesting a microtrap when that source is selected.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-19

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

If the Ibox global addressing mode fault flag is set when the Ebox microcode microbranches on
an invalid field queue entry, a fault flag is injected into the Ebox pipeline. When the flag reaches
the 54 segment of the pipeline and is selected by the RMUX, a microtrap is requested.
Similarly, if the Ibox global addressing mode fault flag is set when the RMUX, in response to
a request by the Ebox or Fbox, references an invalid destination queue entry, a microtrap is
requested.
5.3.3.7

Reserved Operand Faults

Reserved operand faults for floating point operands are detected by the Fbox, and reported in the
same manner as the floating point arithmetic exceptions described above.
Other reserved operand faults are detected by Ebox microcode as part of macroinstruction
execution flows and are reported by jumping directly to the fault handler.
5.3.3.8

Exceptions Occurring as the Consequence of an Instruction

Opcode-specific exceptions such as reserved instruction faults, breakpoint faults, etc., are
dispatched directly to handlers by placing the address of the handler in the instruction PLA.
for each instruction.
Other instruction-related faults, such as privileged instruction faults, are detected in execution
Hows by the Ebox microcode and are reported by jumping directly to the fault handler.
For testability, the Fbox may be disabled. If this is the case, integer multiply instructions
are executed by the Ebox microcode and floating point instructions are converted into reserved
instruction faults for emulation by software. When the first Ebox microinstruction of an Fbox
operand flow for a floating point macroinstruction reaches the S4 segment of the pipeline, a
microtrap is requested. The handler for this microtrap then jumps directly to the reserved
instruction fault handler.
5.3.3.9

Trace Fault

Trace faults are detected by the microsequencer with some help from the Ebox. The
microsequencer maintains a duplicate copy of PSL<TP>, which it updates as required to track
the state of the PSL copy as it would exist when the instruction is executed by the Ebox. At
the end of a macroinstruction, the microsequencer logically ORs its local copy of the TP bit with
PSL<TP>. If either is set, the microsequencer substitutes the address of the microcode trace fault
handler for the address of the next macroinstruction.
5.3.3.10

Conditional Branch Mispredict

When the Ibox decodes a conditional branch, it predicts the path that the branch will take and
places its prediction into the branch queue. When the Ebox reaches the instruction, it evaluates
the actual path that the branch took and compares it in the 85 segment of the Ebox pipeline with
the Ibox prediction. If the two are different, the Ibox is notified that the branch was mispredicted
and a microtrap request is made to abort the Ebox and Fbox pipelines. The Ibox flushes itself,
backs out any GPR modifications that are in the RLOG, and redirects the instruction stream to
the alternate path. The Ebox microcode handler for this event cleans up certain machine state
and waits for the first instruction from the alternate path.

5-20

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

5.3.3.11

First Part Done Handling

During the execution of one of the 8 string instructions that are implemented by the CPU, an
exception or an interrupt may be detected. In that event, the Ebox microcode saves all state
necessary to resume the instruction in the GPRs, backs up PC to point to the opcode of the string
instruction, sets PSL<FPD> in the saved PSL, and dispatches to the handler for the interrupt or
exception.
When the interrupt or exception is resolved, the software handler terminates with an REI back to
the instruction. When the Ibox decodes an instruction with PSL<FPD> set, it stops parsing the
instruction immediately after the opcode. In particular, it does not parse the specifiers. When the
microsequencer finds PSL<FPD> set at a macroinstruction boundary, it substitutes the address
of a special FPD handler for the instruction execution fiow.
The FPD handler determines which instruction is being resumed from the opcode, unpacks the
state saved in the GPRs, clears PSL<FPD>, advances PC to the end of the string instruction (by
adding the opcode PC to the length of the instruction, which was part of the saved state), and
jumps back to the middle of the interrupted instruction.
5.3.3.12

Cache and Memory Hardware Errors

Cache and memory hardware errors are detected by the Mbox or Cbox, depending on the type
of error. If the error is recoverable (e.g., a Pcache tag parity error on a write simply disables
the Pcache), it is reported via a soft error interrupt request and is dispatched to the operating
system.
In some instances, write errors that are not recoverable by hardware are reported via a hard
error interrupt request, which results in the invocation of the operating system.
Read errors that are not recoverable by hardware· are reported via the assertion of a soft error
interrupt, and also in a manner that is similar to that used for memory management exceptions,
as described above. In fact, the MD file, PA queue, and the Ibox all contain a hardware error :Hag
in parallel with the memory management fault flag. With the exception ofTB parity errors, which
cause an immediate microtrap request, the event is reported to the Ebox in exactly the same way
as the equivalent memory management exception would be, but the microcode exception handler
is different. For example, an unrecoverable error on a specifier read would set the hardware error
flag in the MD file. When the :Hag is referenced, the error flag is injected into the pipeline. When
the fiag advances to the S4 segment and is selected by the RMUX., it causes a microtrap request
which invokes a hardware error handler rather than a memory management handler.
Note that certain other errors are reported in the same way. For example, if the memory
management sequencer in the Mbox receives an unrecoverable error trying to read a PTE
necessary to translate a destination specifier, it sets the hardware error fiag in the PA queue
for the entry corresponding to the specifier. This results in a microtrap to the hardware error
handler when the entry is referenced. PTE read errors for read references are also reported via
the original reference.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines 5-21

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

5.4

Revision History

Table 5-1:

Revision History

Who

When

Description of cbaDge

Mike Uhler

06-Mar-1989

Release for external review.

Mike Uhler

19-Dec-1989

Update for second-pass release.

Mike Uhler

02-Feb-1991

Update after pass 1 PG.

5-22 Macroinstruction and MicrolnstNction Pipelines

DIGITAL CONFIDENTIAL

Chapter 6
Microinstruction Formats

6.1

Ebox Microcode
The NVAX microword consists of 61 bits divided into two major sections. Bits <60:15> control
the Ebox Data Path and are encoded into two formats. Bits <14:0> control the Microsequencer
and are also encoded into two formats.

6.1.1

Data Path Control

The Data Path Control Microword specifies all the information needed to control the Ebox Data
Path. The two formats, Standard and Special, are selected by bit <60>, the FORMAT bit. In
addition, bit <45>, the LIT bit, selects the constant generation format of the microword, which
may be either an 8-hit constant or a 10-bit constant, depending on a decode in the MISe field.
Pictures of the microword formats are in Figure ~l and Figure 6-2. A brief description of each
field is given in Table ~l and Table ~2.
Figure 6-1:

Ebox Data Path Control, Standard Format

615 5 5 515 5 5 515 5 4 414 4 4 414 4 4 413 3 3 313 3 3 313 3 2 212 2 2 212 2 2 211 1 1 111
019 8 7 615 4 3 211 0 9 817 6 5 413 2 1 019 8 7 615 4 3 211 0 9 817 6 5 413 2 1 019 8 7 615

+-+---------+---------+-+-----+-+---------+---------+-+-+-+-----------+-----------+---------+
10 I
ALU
I
MRQ
IQI SHF 101
VAL
I
B
ILIWIVI
DST
1
A
I MIse
I
+-+---------+---------+-+-----+-+---------+---------+-+-+-+-----------+-----------+---------+
IllPOS 1
CONST
I MIse not equal CONST.10
+-+---+---------------+
III
CONST.10
I MISe equal CONST.10
+-+-------------------+
Table 6-1:

EBOX Data Path Control Microword FIelds, Standard Format

Bit Position

Microword Field

FOR~

59:55

ALU

DIGITAL CONFIDENTIAL

Microword
Fonnat

Description
Microword format-Standard or Special

Both

ALU function select

Microinstruction Formats 6-1

NVAX CPU Chip Functional Specification, Revision 1.0, February 1991

Table 6-1 (Cont.):

EBOX Data Path Control Mlcroword Fields, Standard Format

Bit Position

Microword Field

Microword
Format

Description

54:50

MRQ

Both

Mhox request select

Standard

Q register load control

48:46

SHF

Standard

Shifter function select

LIT

Both

ALU/shift.er B port control-register or literal