Digital PDFs

MISC-6840853C

October 1991

390 pages

Original

19MB

Document:	NVAX Plus CPU Chip Functional Specification
Order Number:	MISC-6840853C
Revision:
Pages:	390
Original Filename:

OCR Text

NVAX Plus CPU Chip
Functional Specification
The NVAX Plus CPU Chip is a high-performance, single-chip implementation of the VAX Architecture for use
in low-end and mid-range syst49ms.

~3v~sionlUpdate tnformatton:

This is Revision 0.3 of this specHication, the third external release

DIGITAL CONFIDENTIAL
This information shall not be disclO!I8d to persons other than DJGrTAL employees or generally distributed within
DIGITAL. Distribution is restricted tlo persons authorized and designated by the originating organization. This
document shall not be transmitted electronically, copied unless authorized by the. originating organization, or left
unattended. When not in use, this document shall be stored in a locked storage area. These restrictions are
snforced until this document is reclassHied by the originating organization.

Semiconductor Engineering Group
Digital Equipment Corporation, Hudson, Massachusetts

October 1991

The drawings and specifications 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 thls 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 <01991 by Digital Equipment Corporation
All Rights Reserved
Printed in U .SA

The following are trademarks of Digital Equipment Corporation:
DEC
DECnet
DEeUS
MicroVAX
MicroVMS
PDP

ULTRIX
ULTRIX-32
UNIBUS
VAX
VAXBI
VAXcluster

VAXstation
VMS

Idl ijgl i Itlal'l

Contents
CHAPTER 1

INTRODUCTION

1-1

1.1

SCOPE AND ORGANIZATION OF THIS SPECIFICATION

1-1

1.2

RELATED DOCUMENTS

1-1

1.3

TERMINOLOGY ANtI CONVENTIONS
1.3.1
Numberlrtg
1.3.2
UNPREDICTABLE and UNDEFINED
1.3.3
Ranges and Extents
1.3.4
Must be Zero (MBZ)
1.3.5
Should ble Zero (SBZ)
1.3.6
Register IFormat Notation
1.3.7
Timing Diagram Notation

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

1.4

REVISION HISTORY

1-6

ARCHITECTURAL S.UMMARY

2-1

2.1

OVERVIEW

'2_1

2.2

VISIBLE STATE
Virtual Acldress Space
Physical j~ddress Space
22.2.1
Physical Address Control Registers • 2-4
Registers
2..2.3

2-1
2-1
2-2

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 Dilsplacements

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

2.5

INSTRUCTION SET

2-11

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

2-25
2-25
2-26
2-27

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

2-32
2-32

CHAPTER 2

2..2.1
2..2.2

2.6

2.6.1
2.6.2
2.6.3

2.7

2.7.1

DIGITAL CONFIDENTIAL

2-4

2-30
2-31

III

Contents

2.7.2

2-34

2.8

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

2-40
2-40
2-41

2.9

CPU IDENTIFICATION

2-43

2.10

SYSTEM IDENTIFICATION

2-43

2.'1

PROCESS STRUCTURE

2-46

2.12

MAIL.BOX STRUCTURE
Mailbox Operation
2.12.1

2-48
2-50

2.13

PROCESSOR REGISTERS

2-52

2.14

REVISION HISTORY

2-63

EXTERNAL INTERFACE

3-1

3.1

OVERVIEW

3-1

3.2

SIGNALS
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6

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

CHAPTER 3

3.2.7
3.2.8
3.2.9
3.2.10
3..2.11

Exceptions
2.7.2.1
Arithmetic Exceptions • 2-35
Memory Management Exceptions • 2-36
2.7.2.2
2.7.2.3
Emulated instruction Exceptions • 2-37
2.7.2.4
Machine Check Exceptions • 2-39
2.7.2.5
Console Halts • 2-39

Clocks
DC_OK 'and Reset
Initialization and DiagnostiC Interface
Address Bus
Data Bus
External Cache Control
3.2.6.1
The TagAdr RAM • 3-8
3.2.6.2
The TagCtl RAM • 3-8
3.2.6.3
The Data RAM • 3-9
3.2.6.4
Backmaps • 3-1 0
3.2.6.5
External Cache Access • 3-1 0
3.2.6.5.1
HoldReq and HoldAck • 3-10
3.2.6.5.2
TagOk • 3-1'
External Cycle Control
Primary Cache. tnvalidate
Interrupts
Electrical L.evel Configuration
Testing

3-12
3-15
3-16
3-16
3-16

3.3

64-BIT MODE

3-16

3.4

TRANSACTIONS
3.4.1
Reset
3.4.2
Fast External Cache Read Hit
Fast External Cache Write Hit
3.4.3
Fast External Cache Byte/Word Write Hit
3.4.4
Transfer to SysClk for External tranactions
3.4.5

3-16
3-16
3-19
3-19
3-20
3-20

DIGITAL CONFIDENTIAL

Contents

3.4~6

3.4.7
3.4.8
3.4.9
~.4.'O
3.4~11

3.4.12
3.5

3.6

CHAPTER 4
4.1

4.2

CHAPTER 5
5.1
5.2

READ_BLOCK Transaction
Write Btc)ck
LDxL Tra:nnsaction
STxC Tnlnsactton
BARRIEF~ Transaction
FETCH Transaction
FETCHM Transaction

~21
~22

~23
~23
~24
~24
-~24

SUMMARY OF NVAX PLUS OPTIONS
System C:tock Dlvisors
3.5.1
3.5.2
Cache AI::cess
3.5.3
Flamingo 1/0 Address Mapping
3.5.4
Direct Mllpped Pcache
3.5.5
adr_h<3~t :32>
3.5.6
QW 1/0 VVRITESIMTPR MAILBOX
QW 1/0 F;rEADS
3.5.7
PV mode
3.5.8

~25

REVISION HISTORY

3-27

CHIP OVERVIEW

4-1

NVAX PLUS CPU CHIP BOX AND SECTION OVERVIEW
4.1.1
The Ibox
4.1.2
The Ebo)( and Microsequencer
4.1.3
The Fbo):
4.1.4
The Mbo:"
The Cbo)(
4.1.5
Major tnt,ernal Buses
4.1.6

4-1
4-2

REVISION HISTORY

~25
~25
~25

~25
~25

~26

3-26
3-26

4-3
4-3
4-4
4-4
4-4
4-5

MACROINSTRUCTION AND MICROINST~UCTION PIPELINES
INTRODUCTION
PIPELtNE FUNDAME~NTALS
The Conc:ept of a Pipeline
Pipeline IFtow
Stalls and Exceptions in an tnstructlon Pipeline

5.2.1
5.2.2
5.2.3
5.3

NVAX PLUS CPU PII:tELINE OVERVIEW
Normal Macroinstruction Execution
5.3.1.1
The Ibox • 5-6
5.3.1.2
The Microsequencer • 5-8
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-"

5.3.1

DIGITAL CONFIDENTiAL

Contents

5.3.2

5.3.3

Stalls in the Pipeline
5.3.2.1
SO Stalls • 5-12
5.3.2.2
S1 Stalls • 5-12
5.3.2.3
S2 Stalls • 5-13
5.3.2.4
S3 Stalls • 5-13
5.3.2.5
S4 Stalls • 5-14
Exception Handling
5.3.3.1
interrupts • 5-16
5.3.3.2
Integer Arithmetic Exceptions • 5-17
5.3.3.3
Floating Point Arithmetic Exceptions • 5-17
5.3.3.4
Memory Management Exceptions • 5-17
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 OT an
Instruction • 5-20
5.3.3.9
Trace Fault • 5-20
5.3.3.10
Conc:t.itional 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-15

REVISION HISTORY

5-22

CHAPTER 6· MICROINSTRUCTION FORMATS

&-1

5.4

6.1

EBOX MICROCODE
6.1.1
Data Path Control
6.1.2
Microsequencer Control

6-3

6.2

IBOX CSU MICROCODE

6-4

6.3

REVISION HISTORY

6-5

CHAPTER 7 THE IBOX

7-1
7-1

OVERVIEW
7.1.1
Introduction
7.1.2
Functional Overview

7-1
7-2

7.2

VIC CONTROL AND ERROR REGISTERS

7-4

7.3

VIC PERFORMANCE MONITORING HARDWARE

7-6

7.4

IBOX IPR TRANSACTIONS
7.4.1
IPR Reads
7.4.2
IPR Writes

7-7
7-7

7.5

BRANCH PREDICTION IPR REGISTER

7-8

7.S

TESTABILITY
Overview
7.6.1
Internal Scan Register and Data Reducer
7.6.2
7.6.3
Parallel Port
7.6.4
Architectural Features
Metal 3 Nodes
7.6.5
7.6.S
Issues

7.1

&-1
6-1

7-7

7-9

7-9
7-9

7-10
7-10

DIGfTAL CONFIDENTIAL

Contents

7.7

PERFORMANCE MONITORING HARDWARE
7.7.1
Signals

7-10
7-10

7.8

REVISION HISTORY

7-11

THE EBOX

8-1

8.1

CHAPTER OVERVIEW

8-1

8.2

INTRODUCTION

8-1

8.3

EBOX OVERVIEW
8.3.1
Microwol'd Fields
8.3,1.'
Microsequencer Control Fields • 8-6
8.3.2
The Register File
8.3.3
ALU and Shifter
8.3.3.'
Sources of ALU and Shifter Operands • 8-6
8.3.3.2
ALU Functions • 8-6
8.3.3.3
Shifter Functions • 8-6
8.3.3.4
Destinatiol"ls of ALU and Shifter Results • ~7
Ibox..Ebox Interface
8..3.4
8..3.5
Other Registers and States
8.3.5
Ebox Memory Access
CPU Control Functions
8.3.7
8..3.8
Ebox Pipeline
8.3.9
Pipeline Stalls
8.3.10
Microtraps, Exceptions, and Interrupts
EboxlPRs
8..3.1'
8.3. , 1. ,
IPR 124, Patchable Control Store Control Register • ~12
8.3.11.2
IPR 125, Ebox Control Register· ~13
8..3.12
Inltiallzatuon
8..3.13
Testability
8.3.13.'
Parallel Port Test Features • ~16
8.3.13.2
Observe Scan • ~17
8.3.13.3
E%WBUS<31:0> LFSR • ~17
8.3.14
Revision History

8-4
8-4

CHAPTER 8

8-6
8-6

8-7
8-8

8-9
8-9
8-9

8-10
8-1'
8-12
8-16
8-16

8-17

THE MICROSEQUENCER

9-,

9.'

OVERVIEW

9-1

9.2

FUNCTIONAL DESCRIPTION
9.2.1
Introductoon
9.2.2
Control Store
9.2.2.1
Patchable Control Store • 9-2
9.2.2.2
Microsequencer Control Field of Microcode • 9-2
9.2.2.3
MIB Latches • 9-4
Next Address Logic
9.2.3
9.2.3.1
CAL and CAL INPUT BUS • 9-5
9.2.3.1.1
Microtest Bus • 9-5
9.2.3.2
Microtrap Logic • 9-7
9.2.3.3
Last Cycle Logic • 9-7
9.2.3.4
Microstack • 9-8
9.2.4
Stall Logie

9-1

CHAPTER 9

DIG[TAL CONFIDENTIAL

9-2
9-2

9-5

9-8

vII

Contents

9.3

INITIALIZATION

9-8

9.4

MICROCODE RESTRICTIONS

9-8

9.5

TESTABILITY
9.5.1
Test Address
9.5.2
MIS Scan Chain

9-9
9-9
9-10

9.6

REVISION HISTORY

9-10

THE INTERRUPT SECTION

10-1

10.1

OVERVIEW

10-1

10..2

INTERRUPT SUMMARY
10..2.1
External Interrupts
10.2.1.1
HALT_H Interrupt Received by Edge-Sensitive Logic • 10-2
10.2.1.2
Extemal Interrupt Requests Received by Level-Sensitive
Logic • 10-2
10..2.2
Internal Interrupt Requests
10.2.3
Special Considerations tor Interval Tlmer Interrupts
10.2.4
Priority of Interrupt Requests

10-1
10-2

10.3

INTERRUPT SECTION STRUCTURE
1003.1
Synchronization Logic
1003.2
Interrupt State Register
10.3.3
Interrupt Generation Logic

10-5
10-5
10-6
10-7

10.4

EBOX MICROCODE INTERFACE

10-8

10.5

PROCESSOR REGISTER INTERFACE

10-10

10.6

INTERRUPT SECTION INTERFACES
10.6.1
Ebox Interface
10.6.1.1
Signats From Ebox • 10-11
10.6.1.2
Signals To Ebox • 10-11
10.6.2
Microsequencer tnterface
10.6.2.1
Signals trom Microsequencer • 10-11
10.6.2.2
Signals To Microsequencer • 10-11
10.6.3
Cbox Interface
10.6.3.1
Signals From Cbox • 10-11
10.6.4
Ibox Interface
10.6.4.1
Signals From Ibox • 10-12
10.6.5
Mbox Interface
10.6.5.1
Signals From Mbox • 10-12
10.6.6
Pin Interface
10.6.6.1
Input Pins • 10-'2

10-11
10-'1

CHAPTER 10

10.7

vIII

REVISION HISTORY

10-3
10-3
10-4

10-11

10-11
10-1'
10-12
10-12
10-12

DIGITAL CONFIDENTIAL

Contents

CHAPTER 11

THE FBOX

1'-1

1'.1

.OVERVIEW

11-1

11.2

INTRODUCTION

11-1

1'.3

FBOX FUNCTIONAL. OVERVIEW
Fbox Intlsrface
'1.3.1
11.3.2
D.lvider
11.3.3
Stage 1
11.3.4
Stage 2
11.3.5
Stage 3
11.3.6
Stage 4
11.3.7
Fbox Instruction Set
Revision History
'1.3.8

11-2

CHAPTER 12 THE MBOX

11-3

1'-4
1'-4
11-4
'1-4
'1-4
'1-4
'1-7
12-1

12.1

INTRODUCTION

12-1

12.2

MBOX STRUCTURE
12.2.1
~M_LATC::H
CBOX_Lj~TCH
12.2.2
12.2.3
TB
12.2.4
DMISS_L,ATCH and IMISS_LATCH
12.2.5
Peache

12-2
12-6
12-6
12-6
12-6
12-7

12.3

REFERENCE PROCESSING
REFERENCE DEFINmONS
12.3.1
12.3.2
Arbttraticm Algorithm

12-7
12-7
12-9

12.4

12-9
12-9

12.5

12.4.2
12.4.3

Generic Read-hit and Read-mlss/Cache_fIllSequences
12.4.1.1
Returning Read Data • 12-10
O-stream Read Processing
1/0 SpaCE~ Reads

12-10
12-'1

WRfTES
12.5.1

Writes to 1/0 Space

12-'1
12-12

12.6

IPR PROCESSING
12.6.1
MBOX IPlRs

12-13
12-13

12.7

INVALIOATES
12.7.1
ABORTING REFERENCES

12-21
12-22

12.8

CONOmONS FOR ABORTING REFERENCES

12-22

12.9

READ_LOCKlWRITE._UNLOCK

12-22

12.10

PCACHE REPLACEMENT ALGORITHM

12-23

12.11

PCACHE REDUNDANCY LOGIC

12-23

12.12

MEMORY MANAGEMENT
ACVITNV/M::O Fault Handling:
12.12.1

12-24
12-24

DIGrTAL CONFIDENTIAL

Contents

12.12.2

12-24

ACV detection:
12.122.1 TNV detection • 12-25
12.12.2.2 M-O detection: • 12-25
12.122.3 Recording ACVrTNVIM.O Faults • 12-26

MBOX ERROR HANDLING
Recording Mbox errors
12.13.1.1 TBSTS and TBADR • 12-27
12.13.1 .2 peSTS and PCADR • 12-27
Mbox Error Processing
12.13.2
12.132.1 Processing Cbox errors on Mbox-initiated read-like
sequences • 12-28
12.132.1" Cbox-detected ECC errors • 12-28
12.132.1.2 Cbox-detected hard errors on requested fill data • 12-28
12.132.1.3 Cbox-detected hard errors on nonarequested fill
data • 12-29
12.1 32.2 Mbox Error Processing Matrix • 12-29

12-27
12-27

MBOX INTERFACES
Signals trom Cbox
Signals to Cbox

12-32
12-32
12-32

12.15

INITIALIZATION
12.15.1
lnttialization by Microcode and Software
12.15.1.1 Pcache Initialization • 12-33
12.15.1.2 Memory Management Initialization • .12-34

12-33
12-33

12.16

MBOX TESTABILrrY FEATURES
tnternal Scan Register and Data Reducers
12.16.1
Nodes on Paranel Port
12.16.2
Architectural teatures
12.16.3
12.16.3.1 Translation Buffer Testability • 12-36
12.16.3.2 Pcache Testability • 12-37

12-34
12-34
12-35
12-36

12.17

MBOX PERFORMANCE MONITOR HARDWARE

12-37

12.18

REVISION HISTORY

12-38

CHAPTER 13

NVAX PLUS CBOX

13-1

13.1

FUNCTIONAL OVERVIEW

13-1

13.2

CBOX REGISTERS
BIU_ADDR
13.2.'
13.2.2
BIU_STAT
13.2.3
FllL_ADDR
13.2.4
BIU_CTl
13.2.5
DIAG_CTL
13.2.6
FIll_SYNDROME
13..2.7
BEDECC
13.2.8
BC_TAG
13.2.9
STxC_RESULT
13.2.10
SIO
SOE-IE
13.2.1'
13.2.12
QW_PACK

13-2
13-2
13-2
13-5
13-6
13-9
13-10
13-1'
13-"
13-12
13-12
13-13
13-13

12.13

12.13.1

12.14

12.14.1
12.14.2

12-28

DIGITAL CONFIDENTIAL

Contents

13.2.13
13.2.14
13.2.15
13.2.16
13.2.17
13.2.18
13.2.19

CLR_IO_PACK
CONSOL,E HALT/CHALT
Time-ot-Day Register (TO DR)
Programmable Interval Clock
Interval Clock Control Register
Interval Count Register
Next Interval Count Register

13-13
13-14
13-14
13-14
13-15
13-16
13-16

13.3

CACHE ORGANIZAT10N

13-16

13.4

CACHE_SPEED ANt) SYS_ CLK

13-17

13.5

DATAPATH

13-17

13.6

MBOX INTERFACE
13.6.1
The IREA,D _LATCH and the DREAD_LATCH
13.6.2
WRrrE_p,~CKER and WRITE_QUEUE
13.6.3
1/0 Space Writes
13.6.3.1
NON-MASKED FLAMINGO 1/0 Writes • 13-23
13.6.3.2
MASKED FLAM INGO 110 Writes • 13-23
13.6.4
MASKED FLAMINGO 1/0 READS
13.6.5
CM_OUT•.LATCH
13.6.6
FILL_DATA_PIPE' and FIL.L_DATA_PIPE2
13.6.7
IREAD Aborts

13-18
13-19
13-20
13-23

ARBITERIBUS CONTROL
Dispatch Controller
Fill Contrc)Uer
ARB PL.A INPUTS
ARB PLA OUTPUTS
IDLE
DISPATCt-1
13.7.6.1
PACK_WR fTE • 13-34
13.7.6.2
IPR_READ • 13-35
13.7.6.3
HIGH_LW_TEMP • 13-35
13.7.6.4
DREAD_LOCK • 13-35
13.7.6.5
WRITE • 13-35
13.7.6.6
BWR • 13-36
13.7.6.7
WRITE_ UNLOCK • 13-36
13.7.7
ORO
13.7.8
IRD
13.7.9
ROC
13.7.10
RON
13.7.11
FILL
13.7.12
SYS_RD
13.7.12.1 Read Errors • 13-40
13.7.13
WR_STALll.
WR_PROBE
13.7.14
13.7.15
WR_CMP

13-28
13-28
13-30
13-30
13-30
13-3'
13-31

13.7

13.7.'
13.7.2
13.7.3
13.7.4
13.7.5
13.7.6

13.7.16
13.7.17
13.7.18
13.7.19

DIGITAL CONFIDENTIAL

WR
BWR_STAJLL
BWR_PROBE
BWR_CMFI

13-24
13-24
13-25
13-27

13-37
13-37
13-37
13-39
13-39
13-40

13-41
13-41
13-41
13-42
13-43
13-43
13-43

Contents

13.7.20
13.7.21
13.7.22
13.7.23
13.7.24

13-44
13-44
13-45
13-45

BWR_MERGE
BWR
BWR_SYS_RD
BWR_SYS_MERGE
SYS_WR

13-46

13.8

CBOX ERROR HAND1.ING SUMMARY

13-46

13.9

INVA1.IDATES

13-48

13.10

REVISION HISTORY

13-48

ERROR HANDLING

14-1

14.1

TERMIN01.0GY

14-1

14.2

ERROR HAND1.ING INTRODUCTION ~ND SUMMARY

14-1

ERROR HAND1.ING AND RECOVERY
Error State Collection
Error Analysis
Error Recovery
14.3.3.1
Special Considerations ior Cache and Memory Errors • 14-6
14.3.3.'.1
Cache Coherence in Error Handling • 14-7
14.3.3.1.1.1 Cache Enable, Disable, and Flush Procedures • 14-7
14.3.3.1.1.1.1.Disabling the NVAX Plus Caches for Error Handling • 14-7
14.3.3.1.1.1.2 Enabling the NVAX Caches • 14-8
14.3.3.1.1.2 Extracting Data from the Bcache • 14-8
14.3.3.'.2
Cache and T8 Test Procedures • 14-8
Error Retry
14.3.4
14.3.4.1
General Multiple Error Handling Philosophy • 14-10

14-2
14-3
14-5
14-6

14.4

CONS01.E HA1.T AND HALT INTERRUPT

14-11

14.5

MACHINE CHECKS
14.5. ,
Machine Check Stack Frame
Events Reported Via Machine Check Exceptions
14.5.2
14.5.2.1
MCHK_UNKNOWN_MSTATUS • 14-18
14.5.2.2
MCHK_INT.ID_VALUE • 14-18
14.5.2.3
MCHK_CANT_GET_HERE • 14-19
14.5.2.4
MCHK_MOVC.5TATUS • 14-19
14.5.2.5
MCHK_ASYNC_ERROR • 14-19
14.5.2.5.'
T8 Parity Errors· 14-19
14.5.2.52
Ebox 53 Stall Timeout Error • 14-20
14.5.2.6
MCHK_5YNC_ERROR • 14-20
14.5.2.6.1
VIC Parity Errors • 14-2'
14.5.2.6.2
FILL Uncorrectable ECC Errors • 14-22
14.5.2.6.3
FILUBIU write error • 14-22
14.5.2.6.4
Lost Fill Error • 14-22
14.5.2.6.5
BIU_HERR • 14-23
14.5.2.6.6
Lost Fill Error • 14-23
14.5.2.6.7
PTE read errors • 14-24
14.5.2.6.7.1 PTe Read Errors in Interruptable Instructions • 14-24
14.5.2.6.7.2 Uncorrectable ECC FILL Errors and on PTE Reads • 14-25
14.5.2.6.7..3 CACK_HERR on PTE Read • 14-26
14.5.2.7 . Inconsistent Status in Machine Check Cause Analysis • 14-26

14-13
14-13
14-15

CHAPTER 14

14.3

14.3.'
14.3.2
14.3.3

xli

14-9

DIGITAL CONFIDENTIAL

a •

,F~

Contents

14.6

HARD ERROR INTERRUPTS
Events Reported Via Hard Error Interrupts
14.6.1.1
Uncorrectable Errors During Write or Write-Unlock
Processing • 14-28
14.6.1.2
System Environment Hard Error Interrupts • 14-28
14.6.1.3
Inconsistent Status in Hard Error Interrupt Cause
Analysis· 14-29

14-27
14-27

14.7

SOFi ERROR INTEtRRUPTS
.Events [Reported Via Soft Error Interrupts
14.7.'
14.7.1.1
VIC Parity Errors • 14-32
14.7.1.2
Pcache Parity Errors .. 14-33
14.7.1.3
FILL Uncorrectable ECC Errors on I-Stream or D-Stream
Reads • 1:4-33
14.7.1.3,.1
Multiple Errors Which interfere with Analysis of PTE Read
Error e 14-34

14-30
14-30

14.8

KERNEL STACK NC)T VALID EXCEPTION

14-35

14.9.

ERROR RECOVERY COOING EXAMPLES

14-36

14.10

REVISION HISTORY

14-36

CHIP INITIALIZA1'ION

15-1

15.'

OVERVIEW

15-1

15.2

HARDWARElMICRC)CODE INmALIZATION

15-1

15.3

CONSOLE INITIALr.ZATION

15-3

15.4

OTHER INITIALIZATION

15-3

15.5

REVISIQN HISTORY

15-4

PERFORMANCE MONITORING FACILITY

1 s.:-1

16.'

OVERVIEW

16-1

16.2

SOFlWARE INTERI=ACE TO THE PERFORMANCE MONITORING FACILITY
16.2.1
Memory Data Structure
Memory Data Structure Updates
16.2.2
16.2.3
Configuring the Performance Monitoring Facility
16.2.3.1
Ibox Event Selection e. , ~
, 6.2.3.2
Ebox Event Selection • , S-4
, 6.2.3.3
Mbox Event Selection e '6-5
, 6.2.3.4
Cbox Event Selection e ,6-6
16.2.4
EnabUn" and Disabling the Performance Monitoring Facility
. Reading and Ciearing the Performance Monitoring Facility Counts
16.2.5

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

14.6.1

CHAPTER 15

CHAPTER 16

16.3

16.4

16-7
16-7

HARDWARE AND MICROCODE IMPLEMENTATION OF THE PERFORMANCE
MONITORING FACII_ITY
16.3.1
Hardware Implementation
Microcode Interaction with the Hardware
16.3.2

16-8
16-9
16-10

REVISION HISTORY

16-12

DIGrTAL CONFIDENTIAL

xIII

Contents

CHAPTER 17

TESTABILITY MICRO-ARCHrTECTURE

17-1

17.1

CHAPTER OVERVIEW

17-1

17.2

THE TESTABILITY STRATEGY

17-1

17.3

TEST MICRO-ARCHITECTURE OVERVIEW

17-1

17.4

PARALLEL TEST PORT
Parallel Port Operation
17.4.1

17-3
17-4

17.S

TEST PADS

17-6

17.6

SYSTEM PORT

17-6

17.7

TRISTATE_L

17-7

17.8

CONT_L

17-7

17.9

REVISION HISTORY

17-8

AC/DC CHARACTERISTICS

18-1

18.'

INPUT CLOCKS

18-'

18.2

CPUCLKOUT_H

18-2

18.3

TEST CONFIGURATION

18-2

18.4

FAST CYCLES ON EXTERNAL CACHE
18.4.1
Fast Read Cycles
18.4.2
Fast Write Cycles
18.4.3
CEOE timing

18-2
18-3
18-3
18-4

18.S

EXTERNAL CYCLES

18-4

1S.6

TAGEQ

18-S

1S.7

TAGOK

18-6

18.8

TESTER CONSIDERATIONS
18.S.1
Asynchronous Inputs
1S.8.2
Signals 11med from Cpu Clock

18-6
18-6
18-7

1S.9

DC CHARACTERISTICS
Power Supply
1S.9.1
Input Clocks
18.9.2
18.9.3
Signal pins

18-7
18-7
18-8
18-9

1S.10

TIMING OVERVIEW

18-10

18.1'

SIGNALS

18-10

1S.12

REVISION HISTORY

18-1S

CHAPTER 18

xiv

DIGITAL CONFIDENTIAL

Contents

CHAPTER 19

NVAX PLUS PINOUT

19-1

19.1

OVERVIEW

19-1

19.2

NVAX PLUS PINOUT

19-2

19.3

NVAX PLUSlEV4 PINOUT DIFFERENCES

19-11

'9.4

REVISION HISTORY

19-12

FIGURES
1-1

1-3

1-2

TIming Diagram .Notation

1-5

2-1

Virtual Address Spltce Layout

2-2

32·btt Physical Address Space Layout

2-3

30-blt Physical Address Space Layout

2-3

2-4

PAMODE Register

2-4

2-5

General Purpose Rngisters

2-4

2-6

Processor Status Longword Fields

2-7

Data Types

2-5
2-6

2-8

Opcode Formats

2-8
2-9

2-9

Addressing Modes

2-10

Branch Displacemelilts

2-11

MAPEN Register

2-"
2-25

2-12

TBtS Register

2-25

2-13

TBIA Register

2-25

2-14

System Base and L.~ngth Registers

2-26

2-15

System Space Tram~lation Algorithm

2-27

2-16

PO Base and Length Registers

2-28

2-17

PO Space Translation Algorithm

2-28

2-18

P1 Base a~d Length Registers

2-29

2-19

P1 Space Translation Algorithm

2-20

PTE Format (21-blt F)FN)

2-29
2-30

2-21

PTE Format (25-blt F)FN)

2-30

2-22

Minimum Exception Stack Frame

2-32

2-23

General Exception Stack Frame

2-32

2-24

Interrupt Priority Level Register

2-33

2-25

Software Interrupt Request Registers

2-34

2-26

Software Interrupt Summary Register

2-34

2-27

Arithmetic Exception Stack Frame

2-36

2-28

Memory Managemerllt Exception Stack Frame

2-37

2-29

Instruction Emulation Trap Stack Frame

2-38

2-30

Suspended Emulation Fault Stack Frame

2-39

2-31
·2-32

Generic Machine Check Stack Frame

2-39

Console Saved PC and Saved PSl

2-40

DIGrTAL CONFIDENTIAL

Contents

5-3

Fully-PipeUned instruction Execution

2-40
2-¢1
2-43
2-44
2-45
2-46
2-47
2-48
2-49
2-50
2-50
2-52
4-2
5-2
5-2
5-3

5-4

Simple Three-Segment Pipeline

5-4

5-4
5-4

2-33
2-34
2-35
2-36
2-37
2-38
2-39
2-40
2-41
2-42
2-43
2-44
4-1
5-1
5-2

xvi

System Control Block Base Register
System Control Block Vector
CPU 10 Register
System Identification (SID)
System Type (SYS_TYPE)
Process Control Block Base Register
Process Control Block
L.MBPR Register
Mailbox Data Structure
Mailbox Pointer
MAIL.BOXReglster
IPR Address Space Decoding
NVAX Plus CPU Block Diagram
Non-Pipelined Instruction Execution
Parlially-Pipelined lnstructlon Execution

5-5

tnformation Flow Against the Pipeline

.5-6

StaUs Introduced by Backward Pipeline Flow

5-7

Butters Between Pipeline Segments

5-8

NVAX Plus CPU Pipeline

6-1
6-2

Ebox Data Path Control, Standard Format
Ebox Data Path Control, Speclal Format

5-5
5-7
6-1
6-2

6-3
6-4

Ebox Microsequencer Control, Jump Format

6-4

Ebox Microsequencer Control, Branch Format

6-4

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

Ibox CSU Format

6-5
7-2
7-4
7-5
7-5

8-3

Ebox Control Register, ECR

8-12
8-14

9-1
9-2

Microsequencer Block Diagram

9-3

Microcode Microsequencer Control Field Formats

9-4

9-3

Parallel Port Output Format

10-1
10-2
11-1
11-2
12-1

lnterrupt Section Block Diagram

9-9
10-5
10-9
'1-2
'1-3
12-3

Ibox Block Diagram
VMAR Register
VTAG Register
VDATA Register

7-6
7-8
8-3

ICSR Register
BPCR Register
Ebox Block Diagram

pes Control Register, PCSCR

INT.SYS Register Format
Fbox block diagram
Fbox Execute Cycle Diagram
Mbox Block Diagram

DIGITAL CONFIDENT'AL

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -_ _1_1. . . . . . . . . . . . . . . .
,1

Contents

12-2

Barrel Shifter Func1tlon

12-12

12-3

MPOBR Register

12-14

12-4

MPOLR Register

12-14

12-5

MP1 BR Register

12-14

12-6

MP1 LR Register

12-14

12-7

MSBR Register

12-14

12-8

MSLR Register

12-15

12-9

MMAPEN Register

12-15

12-10

PAMODE Register

12-15

12-11

MMEADR Register

12-16

12-12

MMEPTE Register

12-16

12-13

MMESTS Register

12-16

12-14

TBADR Register

12-17

12-15

TBSTS Register

12-17

12-16

PCADR Register

12-18

12-17

PCSTS Register

12-19

12-18

PCCTL Register

12-19

PCTAG Register

12-20

PCDAP Register

12-21

13-1

BIU_ADDR

13-2

BIU_STAT

13-2

FILL_ADDR

13-5

BIU_CTL

13-6

13-3
13-4
13-5
13-6
13-7
13-8
13-9
13-10

DIAG_CTL

13-9

FILL_SYNDROME

13-10

BEDECC

13-11

BC_TAG

13-12

STxC_RESULT
SIO

13-12

13-11

SOE-IE

13-13

13-12

Time of Day Regist4Jr, TODR

13-14

13-13

ICCS

13-14

ICR

13-15

NICR

13-16

Mbox Interface

13-18

13-17

13-26

13-18

B%S6_DATA bypasis timing
M%ABORT_ CBOX_~RD Timing

13-19

DISPATCH timing

13-29

13-20

13-38

13-21

stalLreq timing
wr_stall timing

13-42

14-1

Console Saved PC

14-11

14-2

Console Saved PSL.

14-3

Machine Check Staj=k Frame

14-11
14-13

DIGfTAL CONFIDENTIAL

13-12

13-27

xvII

Contents

14-4

Cause Parse Tree for Machine Check Exceptions

14-16

14-5

Hard Error Interrupt Stack Frame

14-27

14-6
14-7

Cause Parse Tree for Hard Error Interrupts

14-28

Soft Error Interrupt Stack Frame

14-30

14-8

Cause Parse Tree for Soft Error Interrupts

14-9

Kernel Stack Not Valid Stack Frame

14-3'
14-35

16-'
16-2

Performance Monitoring Data Structure Base Address

16-2

Per-CPU Performance Monitoring Data Structure

16-2

16-3

PME Processor Register

16-7

16-4

PMFCNT Processor Register

16-7

16-5

Performance Monitoring Hardware Block Diagram

16-9

17-'
17-2

Self Relative Timing In Observe M4B Mode

17-5

Internal Scan Register Operation Timing

17-5

1-1

1-3

1-2

1-3

TABLES

1-3

1-4

Revision History

1-6

2-'
2-2

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

2-4

General Purpose Register Usage

2-5

2-3

Processor Status Longword

2-5

2-4

General Register Addressing Modes

2-10

2-5

PC-Relative Addressing Modes

2-11

2-6

NVAX Instruction Set

2-12

2-7

PTE Protection Code Access Matrix

2-31

2-8

Interrupt Priority Levels

2-33

2-9

Exception Classes

2-34

2-10

Arithmetic Exceptions

2-36

2-1'
2-12

Memory Management Exceptions

2-36

Memory Management Exception Fault Parameter

2-37

2-13

Instruction Emulation Trap Stack Frame

2-38

2-14

System Control Block Vector

2-41

2-15

System Control Block Layout

2-41

2-16

SID Field Descriptions

2-45

2-17

LMBPR Description

2-48

2-18

Mailbox Data Structure Description

2-49

2-19

Mailbox Pointer Description

2-50

2-20

MAILBOX Register Description

2-21

IPR Address Space Decoding

2-5'
2-53

2-22
2-23

Processor Registers

2-54

Revision History

2-63

DIGITAL CONFIDENTIAL

Contents

3-1
3-2

NVAX_PlUS Signai:s

3-1

New_NVAX_PlUS Signals

3-3
3-4

EVAX Signals

3-3
3-3

System Clock Divisor

3-5

System Clock Delay

3-6

Tag Control Encodlngs

3-9

3-7

Cycle Types

3-5
3-5

EBOX Data Path CClntrol Microword Fields, Special Format

3-12
3-14
3-14
3-16
3-27
4-5
5-22
6-1
6-2

6-3

Ebox Microsequenc!er Control Microword Fields, Jump Format

6-4

3-8

Acknowledgment Types

3-9
3-10
3-1'
4-1
5-1
6-1
6-2

Read Data Acknowledgment Types
Reset State
Revision History
Revision History
Revision History
EBOX Data Path Control Microword Fields, Standard Format

6-4

Ebox Microsequenc:er Control Microword Fields, Branch Format

6-4

6-5

Ibox CSU Microword Fields

6-6

Revision History

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

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

VMAR Register
VTAG Register
VDATA Register
ICSR Register
BPCR Register,
BPCR <8:6>

7-7

Ibox Scan Chain Fields

7-8
8-1
8-2

Revision History
Data Path Control Microword Fields

B-4

PCSCR Field Descriptions

8-13
8-15
8-17

8-3
8-4

ECR Field Descrlptnons

9-,
9-2
9-3

Jump Format Contl'ol Field Definitions

Revision History
Branch Format Cor.trol Field Definitions

9-4

Current Address SEtlection
Microtest Bus Sources

9-5

Microaddresses for last Cycle Interrupts or Exceptions

9-6

Parallel Port Output Format Field Definitions

9-7

Contents of MIS Sc:an Chain

9-8

Revision History

10-'
10-2
10-3
10-4

Relative lnterrupt F'rlorlty
Summary of lnterrLlpts
INT.SYS Register Fields
Revision History

DIGITAl. CONFIDENTIAl.

9-4
9-4

9-5
9-6

9-7
9-9
9-10
9-10
10-4
10-7
10-10
10-12

xix

Contents

11-1

Fbox Internal Execute Cycles

11-3

11-2

List of the Fbox Total Execute Cycles

11-3

Fbox Floating Point and tnteger Instructions

1'-4
12-1

Revision History

1'-5
11-7

Reference Definitions

12-7

12-2

Mbox IPRs

12-13

12-3

MMAPEN Definition

12-15

12-4

PAMODE Definition

12-15

12-5

MMESTS Register Definition

12-16

12-6

FAULT Encodings

12-17

12-7

LOCK Encodings

12-17

12-8

TBSTS Description

12-18

'12-9

SRC Encodings

12-18

12-10

PCSTS Description

12-19

12-11

PCCTL Definition

12-20

12-12

Pcache Tag IPR Format

12-21

12-13

Pcache Data Parity IPR Format

12-21

12-14

Mbox Error Handling Matrix

12-29

12-15

Mbox Performance Monitor Modes

12-37

13-1

BIU STAT

13-3

13-2

BIU Control Register

13-6

13-3
13-4·

BC_SPD

13-8

BC_SIZE

13-9

13-5

Diagnostic Control Register

13-10

13-6

Fill Syndrome

13-11

13-7

BEDECC

13-11

13-8

Cbox Queues and Major Latches

13-17

13-9

Mbox-Cbox Commands

13-19

13-10

IREAD _LATCH Fields

13-20

13-11

DREAD_LATCH Fields

13-20

13-12

WRrTE_QUEUE Fields

13-21

13-13

CM_OUT_LATCH Fields

13-24

13-14

Cbox-Mbox Interface control signals

13-25

13-15

Cbox_Mbox commands and actions

13-25

13-16

Fields of FILL_DATA_PIPE1 and FILL_DATA_PIPE2

13-26

13-17

Cbox Action Upon Receiving M%ABORT_CBOX_IRD

13-18

NVAX Plus CBOX Error Handling

13-27
13-47

13-19

Revision History

13-48

14-1

Error Summary By Notification Entry Point

14-2

Console Halt Codes

14-11

14-3

CPU State lnltialized on Console Halt

14-12

14-4

Machine Check Stack Frame Fields

14-14

14-5

Machine Check Codes

14-15

DIGITAL CONFIDENTlAL

Contents

14-6
15-1
16-'
16-2
16-3
16-4
16-5
16-6
16-7
17-1
17-2
17-3

Revision History
Revision History
Performance Monltc'ring Facility Box Selection
Ibox Event Selection
Ebox Event Selection
Mbox Event Selectie.n
Cbox PMCTRO Event Selection
Cbox PMCTR, Event Selection
Revision History
NVAX Plus Test Pim;
Parallel Port OperaUng Modes .
Revision History

18-'
.18-2

Input Clock Timing
External Cycles

18-3
18-4
18-5
18-6
18-7
1S-1

tagEq
Asynchronous Signals on 8 Tester
CMOS DC Charactel'istlcs
NVAX_PLUS Signal~.
Revi~ion History
Revision History

DIGITAL CONFIDENTIAL

14-36
15-4
16-3
16-4
16-4
16-5
16-6
16-6
16-12
17-3
17-6
17-8
18-2
18-5
18-5
18-7
18-9
18-10
18-15
1S-12

xxi

-------------,------------------------------------------,

NVAX Plus CPU Chip Functional Specification, Revision O.3~ October 1991

Chapter 1

Introduction

The NVAX PLUS CPU is a high-performance, single-chip implementation of the V.AX architecture.
It is partitioned into multiple sections which cooperate to execute the VAX base inistruction 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.
The NVAX Plus chip is an NVAX core with an EVAX external interface. Microcode changes are
also required to support the EVAX interlocks and to input from serial ROM at startup. Most of
the CBOX-MBOX interface section is reused. The CBOX arbitration logic is redesigned to control
the EDAL interface. Cache fLlls and coherency transactions are controlled by EDAL system logic
with only a single CPU requelst active at a time.

1.1

Scope and Organization of this Specification
This specification describes the operation-of the NVAX PLUS chip. It contains an Architecturial
Summary, 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 the CBOX section of the chip.
The IBOX, EBOX, MBOX, FBOX, and Interrupt sections are taken from the NVAX CPU
Functional Specification. These sections retain the high level description of the section, the
description of the software visible IPRs, and specify the changes required by NVAX Plus to accommodate the EVAX interface and Vector option. Sections which aid in understanding the interface
between the NVAX Plus CBOX and N'VAX Core are also retained. For a detailed desription of
the IBOX, EBOX, MBOX, FBOX, and Interrupt sections refer to the NVAX CPU Chip Functional
Specification.
.
In addition, the specification contains discussions of error handling, cbip initialization, and testability features.

1.2

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

NVAX CPU Chip Functional Specification
EV3 and EV4 Specification
DEC Standard 032 VAX Architecture Standard.

DIGITAL CONFIDENTIAL

Introduction

1-1

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

•

153

NVAX CPU Chip Design Methodology.

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.
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 hang., 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.
UNDEFINED operations.

1.3.3

Non-privileged software can not invoke

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 CMBZ) must never oe 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-2

introduction

DIGfTAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

1.3.6

Reg ister Format Noultion

This specification 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.
Figure 1-1:
31 30

2BI:7 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 OBI07 06 05 04103 02 01 00

TRAP

---+

INTERRUPT -+

BUS_ERROR

Table 1-1:

----+

Name

Bit(s)

Type

BUS_ERROR

°1

WC,O

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

INTERRUPT

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.

R'W,

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

Description

The FAULT_CMD neld latches the command that was in progress when
an elTor is detected.

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:

Notation

Descriptioll

A read-WritE! bit or neld. The value may be read and written by software, microcode,
or hardware.

A read-only bit or neld. 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 hardwarEl and reads by software or microcode return an UNPREDICTABLE result.

DIGITAL CONFIDENTIAL

Introduction

1-3

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 1-2 (Cont.):

Notation

Description

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 a O.

A write-one-to-c1ear 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-c1ear 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.

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
register.
Table 1-3:

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 "r' 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 Plus CPU Chip Functional Specification, Revision 0.3, October 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
INVALID BUT NOT CHANGING

xxxxxxxxx

HIGH TO INVALID

\SS\
\SSS
S\S'XXX

INTERMEDIATE TO LOW

, ss,

HIGH TO LOW
HIGH TO VALID

HIGH TO INTERMEDIATE

, ss,

LOW TO VALID

IZZI
IIII

LOW TO INVALID

111m

LOW TO HIGH

, ? 2 ;

LOW TO INTERMEDIATE
VALID TO INTERMEDIATE

DIGITAL CONFIDENTIAL

I 2 Z ,

-..,j}'-oj}"">-xxx»>---««
--«(<XX

~ntroductlon

1-5

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

1.4

Revision History

Table 1-4:

Revision History

Who

When

Description of change

Mike'tThler

06-Mar-1989

Release for external review.

Mike'tThler

15-Dec-1989

Update for second.pass release.

Gil Wolrich

15-Nov-1990

NVAX PLUS release for external review.

1-6

Introduction

DIGITAL CONFIDENTlAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Chapter 2
Architectural Summary

2.1

Overview
This chapter provides a summary of the VAX architectural features of the N'VAX Plus 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 V.A.X Architecture Standard
(DEC. Standard 032).

2.2

Visible State
The visible state of the prOCt~ssor 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 Spac~e

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

DIGITAL CONFIDENTIAL

Architectural Summary

2-1

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-1:
00000000

Virtual Addre$s Space Layout

.-------------------------~
1
1
1

length of PC' Regior. ir,
pages (POLR)

1 Region
PO
----------------1
3FFFFFFF
40000000

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

PlRegion ----------------1

80000000

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

1
1

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

FFFFFDFF
FFFFFEOO
FFFFFFFF

Pl Regior. growth direction

iFFFFFFF

System
Region

PO Region growth direction

length o! Pl Region ir;
pages (2··2l-Pl~R)
lengt.h of System Region
in pages (S~R)
System Region growth
d1rectior.

~-------------------------~
1
Reserved
1

Pa9E-

.-------------------------~

2.2.2

Physical Address Space

The l\TVAX Plus 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 seveneighths (3.5GB) of the physical address space. 1/0 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 Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-2:
00000000

32-blt Physical Address Space Layout

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

...

Memory

Space

DFFFFFFF
EOOOOOOO

...-

--t

3.5 GB

+--------------------,-----+
I/O
51: MB
I

FFFFFFFF

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

30-blt Physical Address Space Layout

+-------------------_ . . _---+
Memory
Space

I 512 MB
I

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

20000000

lnaccessable
Region

I
I
I
-+ 3.0 GB
I
I
I
I

I
-+

DFF:FFFF
EOOOOOOO

FFFFFFFF

+-------------------------+
1/0
I 512 ME
Space

+-------------------------+
The translation from 30-bit addresses to 32-bit addresses is acc9mplished by sign-extending
PA<29> to PA<31:30>. In tIDB mode, the programmer sees a 1GB address space, split evenly

between memory and I/O spac~e, 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

ArchltecturalSummary

2-3

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 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 Address

OOOOOOOO .. lFFFFFFF

OOOOOOOO .. lF'F'F'F'F'F'F

20000000 .. 3FFFFFFF

EOOOOOOO •. FFFFFFFF

2.2.2.1

Physical Address Control Registers

Durin'g powerup, microcode configures the CPU to generate 30-bit physical addresses. Console
firmware may then reconfigure the CPU to generate either 30-bit or 32-bit physical addresses by
writing to the MODE bit in the P.AM:ODE and VP.AM:ODE registers, respectively. The P.AM:ODE
register is shown in Figure 2-4.
Figure 2-4:

PAMODE Register

31 30 2i 26127 26 25 241:3 :: 21 20119 16 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
i 0

(;

C·

I : PAMODE
I

MODE --'

The VPAMODE register is identical in format to the PAMODE register.
The PAMODE register also determines how PTEs are to be interpreted. In 30-bit mode, PTEs
are interpreted in 21-bit PFN format. In 32-bit mode, PTEs 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.

2.2.3

Reg isters

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.
Figure 2-5:

General Purpose Registers

31 3C 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

2-4

Architectural Summary

DIGITAL CONFIDENTIAL

'--------------,. . .----------______.._I..

--I

I. . . . . . . .~. .

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

-Tabte 2-2:

General Purpose Register Usage

GPR

Use

Synonym

RO-Rll

General Purpose

R12

Argument Pointer

R13

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
28127 "" __
26 • 25
18
17 16115 1~ 13 12111 10 09 08107 06 OS 04103
0: ...00
__ + 3G
__ 2e
__ _____
__ "' 2C12!
__ __ ::
__ 21
__ <i. 2011e
_ _ "" _ _
_ _ + __ + __ + __ ,,, __ + __ + __ + __ .... __ + __ + __ + __ ... __ + __
__ • __ ....02
__ . +-__
__ *
~

I IMBIF?I
! CUR ! PRV IMBI
ICM I T? IVM I Zit- I IS: MOD I MOD IZ I

Tabte 2-3:

I
IPl.

MBZ

Processor Status Longword

Name

Bit(s)

Description

Oompatability Mode

Trace Pending

V:lrtual Machine Mode 1

FPD

F.lrst Part Done

IS
GUR_MOD
PRY_MOD

IntelTUpt Stack

25;24

CUlTent Mode

23;22

Previous Mode

IPL
DV

20:16

IrltelTUpt Priority Level

Decimal Overflow !rap Enable

FU
IV
T
N

Floating Underflow Fault Enable

Integer Overflow !rap Enable

Trace Trap Enable

Negati~e Condition Code

Zero Condition Code

Overflow Condition Code

Carry Condition Code

IDVIFUIIVI TI NI ZI VI CI :PSl.

1 MBZ unless v.irtual machine option is implemented

DIGITAL CONFIDENTIAL

Architectural Summary

2-5

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Data Types

2.3

The NVAX Plus CPU supports nine data types: byte, word, longword, quad word, character
string, variable length bit field, F_fioating, D_fioating, and G_fioating. These are summarized in
Figure 2-7.
Figure 2-7:

Data Types

Oi 06 05 04103 0: 01 00
:A

Data Type: Byt~
Length:
6 bi~s
Use:
Signec 0: unsignec integer
15

23 :2,1: 1C 09 0810i 06 05 04103 02 01 00
I :A

Data Type: Worc
Length:
16 bits
Use:
Signec or unsignec integer
31 30 29

261:~

2£ 25 24123 22 21 20119 16 1i 16115 14 13 12111 10 09 0810i 06 05 04103 02 01 00
:A

Data Type: Longword
Leng~h:
32 bits
Use:
Signed or unsigned integer
31 30 29

2812~

26 25 24123 22 21 20119 18 l' 1£115 14 13 12111 10 09 08!Oi O£ 05 04103 02 01 00
I

I :A+4

Data Type: Quadword
Length:
64 bits
Use:
Signed integer

Figure 2-7 Cont'd. on next page

2-6

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CF'U Chip Functional Specification, Revision 0.3, October 1991

Figure 2-7 (Cont.):

Data Types

07 06 05 04103 02 01 00

+--+--.--+--+--+--+--+--+
1

·:A+1

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

:A+length-1
D8~~ Type: Charac~er String
. Length:
0-64K bytes
Use:
Byte string

P+S P+S-1

P P-1

1IIIIIIIIillllllllllllili
Type: Va=iable length bit field
Lengt.h:
(1-32 bi ts
Use:
Bit string

Dat~

lS l ' 13 12/11 10 09 08107 06 05 04103 02 01 00

:A
:A+2

fract.ion
31 30 29 28127 26 25 24123 22 21

2011~

18 17 16

Data Type: F_float.ing
Length:
32 bits
Use:
Floating point
15.14 13 12/11 10 09 08107 06 05 04103 02 01 00
i

fraction

exponent
traction

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

:A
:A+2

tract.ion

:A+4

fraction

:A+6

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

63 62 61 60159 58 57 56155 54 53 52/51 SO 49 48

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

Figure 2-7 Cont'd on next page

DIGITAL CONFIDENTIAL

Architectural Summary

2-7

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-7 (Cont.):
15

Data Types

13 121ll 10 09 08107 06 05 04103 02 01 OC

exponent

I s I

63 62 6:

6015~

I :fraction

I :J..

fraction

I :A+2

traction

I :A+4

fraction

I :A+6

58 57 56155 54 53 52151 50

Data Type: G floating
Length:
64 bits
Use:
Floai1ng point

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- bytQ

opc ode:

opcode

I :A

15 14 13 12111 10 09 08107 06 05 04103 02 01 00
.--+--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Two-byte ope ode:·

2.4.2

opcode

I :A

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. If 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 Plus CPU Chip -Functional Specification, Revision 0.3, October 1991

different addressing modesa:re 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:

0; 06 05 04103 02 01 00
+--+--+--+--.j.--+--+-----+

mode

I register

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

0; 06 05 04103 02 01 00

PC-relat.ive
addressing mode:

modw
: 1 1 1 11
+--+--+--+--..~--+--+--'1""---+-

DIGITAL CONFIDENTIAL

ArchltecturalSummary

2-9

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Tab~e 2-4:

General Register Addressing Modes
Access

Mode

Name

Assembler

rmwav

Indexable?

0-3

literal

S"#literal

y ffff

:x.

index

i[Rx]

yyyyy

y y y fy

(Rn)

yyyyy

auto decrement

-(Rn)

yyyyy

Y
u:x:

autoincrement

(Rn)+

yyyyy

u:x

autoincrement deferred

@(Rn)+

yyyyy

u:x:

byte displacement

B"d(Rn)

yyyyy

byte displacement deferred

@B"d(Rn)

yyyyy

Y
y

word displacement

W"d(Rn)

yyyyy

word displacement deferred

@W"dCRn)

yyyyy

longword displacement

L"d(Rn)

yyyyy

longword displacement deferred

@L"dCRn)

yyyyy

Y
y

Access Types

=
=
=
=
=

r read
m modify
w
write
a address
v variable bit field
Synta:r:

=
=
=
=

any indexable address mode
d displacement
Rn general register, n 0 to 15
R:x general register, n 0 to 14
i

=
=

Results

y yes, always valid address mode
f = reserved addressing mode fault
x = logically impossible
p = program counter addressing
u
unpredictable
ud = unpredictable for destination of CALLG, CALLS, JMP and JSB
uq unpredictable for quad, DIG_floating and field if pos+size > 32
u.x = unpredictable if index register • base register

=
=

2-1 0

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

Table 2-5:

PC-Relative Address:lng Modes
Access

Indexable?

Mode

Name

Assembler

rmwav

immediate

I "#constant

yuuyud

absolute

@#address

yyyyy

byte relative

B"address

yyyyy

byte relative deferred

@B"address

yyyyy

word relative

W"address

yyyyy

word relative deferred

@W"address

yyyyy

longword relative

L"address

yyyyy

longword relative deferrEld

@L"address

yyyyy

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

2.4.3

Branch Displacements

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

Branch Displacements
07 06 05 04103 02 01 00

Signed byte
displacement:

displa<:ement
+--+--+--+---)0--+--... --+--+
15 l' 13 12111 10 09 OBI07 06 05 04103 02 01 00

Signed word
displacement:

2.5

displacement

Instruction Set
The NVAX Plus CPU supports the VAX Base Instru.ction Group as defined in DEC Standard 032
plus the optional VAX vector in.structions and the virtual machine instructions. These instructions
are listed in Table 2-6.

DIGrTAL CONFIDENTIAL

Architectural Summary

2-11

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6:
Opcode

NVAX Instruction Set
Instruction

Exceptions

iov

Integer, Arithmetic and Logical Instructions

ADAWI add.rw, sum.mw

II<

ADDB2 add.rb, sum.mb

II<

iov

II<

iov

ADDL2 add.rl, sum.ml

II<

ADD'W2 add.rw, sum.mw

II<

iov

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

II<

II:

II<

iov

ADDL3 addl.rl, add2.rl, sum.wI

II<

iov

ADD"W3 add1.rw, add2.rw, sum. ww

II<

iov

ADWC add.rl, sum.ml

II<

II:

II<

iov

ASHL cnt.rb, ere.rl, dst.wl

II<

iov

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

II<

iov

BICB2 mask.rb, dst.mb

II<

BICL2 mask.rl, dst.ml

II<

BIC\\72 mask.rw, dst.mw

II<

BICB3 mask.rb, sre.rb, dat. wb

II<

BICL3 mask.rl, sre.rl, dst. wI

II<

BIC'W3 mask.rw, ere.rw, dst.ww

II<

BISB2 mask.rh, d~mb

II<

BISL2 mask.rl, dat.ml

II<

BISW2 mask.TW, dst.mw

II<

BISB3 mask.rh, ere.rb, dst.wb

II<

BISL3 mask.rl, ere.rl, dst.wl

II<

BISW3 mask.rw, ere.rw, dst. ww

II<

BITB mask.rb, sre.rb

II<

BITL mask.rl, sre.rl

II<

BIT\V mask.rw, ere.rw

II<

D3
B3

2-12

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):

NVAX tnstruction Set
N

CLRB dst.wb
CLRLI=F} dst.wl
CLRQI=D=G} dst. wq
CLRW dst.ww

CMPB srcl.rb, src2.rb
CMPL sre1.rl, src2.rl
CMPW sre1.TW, src2.rw

II<

CVTBL sre.rb, dst.wI
CVTBW sre.rb, dst.ww
CVTLB sre.rl, dst. wb
CVTLW sre.rl, dst~ww
CVTWB sre.TW, dst.wb
CVTWL src.TW, dst. wI

II<

iov

'"
'"

II<

iov

II<

iov

II<

iov

D7
B7

DECB dif.mb
DECL dif.m1
DEC'W dif.mw

II<

iov

II<

iov

86
C6
A6

DIVB2 divr.rb, quo.mb
DIVL2 divr.rl, quo.m1
DIVW2 divr.TW, qUO.II1W

II<

...

iov, idvz

...

II<

iov, idvz

II<

81:

II<

iov, idvz

87
C7
A7

DIVB3 divr.rb, divd.rh, quo.wb
DIVL3 divr.rl, divd.rl, quo. wI
DIVW3 divr.TW, divd.rw, quo.ww

II<

iov, idvz

'"
'"

...
...

iov, idvz
ioy, idvz

EDIV divr.rl, divd.rq, quo.wl, rem.wl

II<

...

iov, idvz

'7A

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

II<

96
D6

INCB sum.mb
INCL sum.m1

II<

...

ioy

II<

...

II<

iov

Opcode

Instruction

Ex:ceptioDS

Integer, Ari~etic and Logical Instructions

94
D4
7C

B4
91

Dl
Bl
98
99

F6
F7
33
32
97

DIGfTAL CONFIDENTIAL

II<
II<

II<

Architectural Summary

2-13

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

Z·

Exceptions

II<

iov

Integer, Arithmetic and Logical Instructions

INCW sum.mw

II<

MCOMB src.rb, dst.wb

II<

0
0

MOOML src.rl, dst.wl

II<

MOO~7 src.'I"\IV, dst.ww

II<

MNEGB src.rb, dst.wb

II<

iov

II<

10V

MNEGL src.rl, dst.wl

II<

.AE

1\1NEGVi7 srC.'I"\IV, dst. ww

II<

MOVB src.rb, dst. wb

II<

MOVL src.rl, dst.wl

II<

MOVQ src.rq, dst.wq

II<

MOVW src.rw, dst.ww

II<

MOVZBW src.rb, dst.wb

II<

MOVZBL src.rb, dst.wI

II<

MOVZWL src.rw, dst.wl

MULB2 mulr.rb, prod.mb

II<

iov

II<

MULL2 mulr.rI, prod.ml

II<

iov

MULViT2 mulr.rw, prod.mw

II<

iov

MULE3 mulr.rb, muld.rb, prod.wb

II<

...

II<

iov

II<

10V

II<

iov

MULLS mulr.rl, muld.rI, prod.wI

II<

MULW3 mulr.'I"\IV, muld.rw, prod.ww

II<

PUSHL erc.rI, I-(SP). wI)

II<

...

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

...

II<

SBWC sub.rl, dif.ml

II<

iov

SUBB2 sub.rb, dif.mb

II<

iov

2-14

Architectural Summary

----------------------

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

...
...

...

iov

...

iov

...

*
*
*

...

iov

...

iov

Exceptions

Integer, Arithmetic and LogicallJClStructions
C2

SUBL2 sub.rl, dif.m1

...

SUB'W2 SUb.TW, dif.mw

...

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

SUBL3 sub.rl, min.rl, wf.wI

at<

...

SUBW3 SUb.TW, min.rw, dif.wW

at<

TSTB'sre.rb

at<

TSTL src.rl

TSTW srC.rw

...

*
*
*

XORB2 mask.rb, dst.lnb

...

XORL2 mask.rl, dst.Dll

XORW2 mask.TW, dst,mw

*
*

*
'*
*

XORB3 mask.rb, sre.rb, dst.wb
XORL3 mask.rl, sre.rI, dst.wl

XORW3 mask.TW, sre.rw, dst.ww

*
*
*

o·

*
*
*

at<

iov

0
0

Address Instructions
9E

MOVAB sre.ab, dst.wl

...

at<

MOVAL{=F} sre.al, dst.wl
MOVAQ{=D=G} src.aq, dst.wl

MOVAW src.aw, dst. wI

...

*
*

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

PUSHAL{=F} src.al, HSP).wl}

*
*

PUSHAQ{=D=G} sre.ELq, {-(SP).wl)

...

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

...

...
...
...

0
0

Variable-Length Bit Field ,Instructions
EC

C:MPV pos.rl, size.rb, base.vb, {field.TV}, src.rl

...

rsv

CMPZV pos.rl, size.rb, base.vb, {field.TV}, sre.rl

...

rsv

DIGITAL CONFIDENTIAL

Architectural Summary

2-15

NVAX Plus CPU Chip Functional SpeclDcation, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

Exceptions

Variable-Length Bit Field Instructions

EXTV pos.rl, size.rb, base.vb, {field.TV}, dst.wl

II<

rsv

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

II<

rev

INSV src.rI, pos.rl, size.rb, base.vb, {field.wvl

FFC startpos.rl, size.rb, base.vb, {field.TV}, nndpos.wl

rsv

FFS startpos.rI, size.rb, base.vb, {field.rv\, nnd.:
pos.wl

rsv

ACBB limit.rb, add.rb, indeLmb, displ.bw

iov

ACBL limit.rl, add.rl, indeLml, displ.bw

II<

iov

ACB'W limit.TW, add.TW, indeLmw, displ.bw

II<

iov

AOBLEQ limit.rl, index-ml, displ.bb

II<

iov

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

iov

IE
IF

BCC{=BGEQUI displ.bb

BEQ.LI=BEQLUI displ.bb

BGEQ displ.bb

BGTR displ.bb

BGTRU dispI.bb

BLEQ displ.bb

BLEQU displ.bb

BLSS displ.bb

BNEQI=BNEQU} displ.bb

BVC displ.bb

BVS displ.bb

BBC pos.rI, base.vb, displ.bb, {neld.TV}

rev

BBS pos.rl, base.vb, displ.bb, {field.TV}

rsv

Control Instructions
9D
Fl

2-16

BCSI=BLSSUI displ.bb

Architectural Summary

DIGrTAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

Exceptions

Control Instructions

BBCC pos.rl, base.vb, displ.bb, f:6.eld.mv}

rsv

BBCS pos.rl, base.vb, displ.bb, ffield.mv}

rsv

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

rsv

BBSS pos.rl, base.vb, displ.bb, ffield.mv}

rsv

BBCCI pos.rl, base.vb, displ.bb, f:6.eld.mv}

rsv

BBSS! pos.rl, base.vb, clispl.bb, ffield.mv}

rsv

-'-.
E9
ES"

BLBC src.rl, displ.bb

BRB clispl.bb

BRW displ.bw

BSBB displ.bb, {-(SP).'wl)

BSBW displ.bw, {·(SP).wl)

CASEB selector.rb, ba.se.rb~ limit.rb, cli~pl.bw.
list
CASEL selector.rl, bSLSe.rl, limit.rl, displ.bw.
list
CASEW selector.TW, bs;se.TW, limit.rw, displ.bwlist

BLBS src.rl, clispl.bb

JMP dst.ab

JSB dst.ab, 1·(SP).wl}

RSB {(SP)+.rl)

SOBGEQ index..ml, disp1.bb

SOBGTR indeLmI, diapl.bb

DIGITAL CONFIDENTIAL

...

...
...

iov
iov

Architectural Summary

2-17

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

Exceptions

Procedure Call Instructions

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

rsv

CALLS numarg.rI, dst.ab, 1-(SP).w*}

rsv

RET {(SP).+.r*)

II:

rsv

II:

rsv
rsv

Miscellaneous Instructions

BICPSV\7 mask.rw
BISPSW mask.rw

BPT I-CKSP).w*1

HALT !-CKSP).w*1

INDEX Bubscript.rl, low.rI, high.rl, size.rl, indexin.rl, indexout. wI

MOVPSL dst.wl

NOP

BA
BB

POPR mask.rw, {(SP)+.r*1
PUSHR mask.rw, {-(SP).w*1

XFC lunspecifi.ed operands)

pTV

II:

sub

Queue Instructions

INSQID entry.ab, beader.aq
INSQTI entry.ab, beader.aq
INSQUE entry.ab, pred.ab

5E
5F
OF

REMQHI beader.aq, addr. wI
REMQTI beader.aq, ad dr. wI
REMQUE entry.ab, addr.wl

5C
5D

2-18

Architectural Summary .

II:

31<

II:

31<

II:

rs,7
rs,7

rsv
rsv

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip"Functional Specification, Revision 0.8, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instru,ction Set

Instruction

Ex'ceptions

Operating System Support Instructions
BD

CH:ME param.rw, 1-(ySP).wll<}

CHMK param.rw, 1-(ySP).w*}

CHMS param.TW, {-(ySP).w*)

CHMU param.rw, {-tvSP).w*}

LDPCTX {PCB.r*, -<KSP).w*}

:MFPR procreg.rl, dst"wl
MTPR erc.rI, procreg.rl

II<

rsv, p:n'

II<

rsv, prv

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

PROBE\V mode.rb, len.TW, base.ab

II<

REI l(SP)+.r*}

SVPCTX ((SP)+.r*, PCB.w*)

rsv, prv

II<

rsv

prv

Character String InstructioDS

CMPC3 len.TW, srcladdr.ab, erc2addr.ab

CMPCS srcllen.TW, src:laddr.ab, fill.rb,src2len.rw,
src2addr.ab

II<

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

MOVC3len.TW, srcaddr.ab, dstaddr.ab, fR0-5.wl}

MOVCS srclen.rw, srca.ddr.ab, fill.rb, detlen.TW,
dstaddr.ab,{R0-5.wl}

II<

SOANC len.TW, addr.ab, tbladdr.ab, mask..rb

11<

SKPO char.rb, len.TW, uddr.ab

11<

SPANO len.TW, addr.ab, tbladdr.ab, mask..rb

DIGITAL CONFIDENTIAL

~rchttectural Summary

2-19

NVAX Plus CPU Chip Functional Specificatio~ Revision 0.3, October 1991

Table 2-6 (Cont.):

NVAX Instruction Set
N

Exceptions

ADDD2 add.rd, sum.md

II<

...

rsy, fov, fuv

ADDF2 add.rl, sum.mf

'11<

II<

rsv, fov, fuv

40FD

ADDG2 add.rg, sum.mg

II<

rsv, fov, fuv

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

II<

rsv, foY, fuv

ADDF3 addl.rl, add2.rl, sum.wf

01<

II<

rs", foY, fuv

41FD

ADDG3 addl.rg, add2.rg, sum.wg

II<

rsv, fov, fu,,·

CMPD srcl.rd, src2.rd

01<

rsv

CMPF srel.rl, sre2.rl

II<

rsv

51FD

CMPG srel.rg, src2.rg

01<

rsv

CVTBD sre.rb, dst.wd

II<

CVTBF src.rb, dst.wf

CVTBG sre.rb, dst.wg

*
*

4CFD

*
*
*
*

II<

01<

nv, io'v

*
*

*
*
*

rs", fov
rsv, iov

,rsY, iov

rsv, iov

II<

Opcode

Instruction

Floating Point Instructions
60

CVTDB ere.rd, dst. wb

CVTDF sre.rd, dst.wf

CVTDL STe.rd, dst. wI

CVTD'W src.rd, dst. ww

CVTFB src.n, dst. wb

CVTFD STe.n, dst. wd

II<

.
.
..

*
*
*
*

II<

rsv

II<

rsv

II<

rsv, iov

II<

rsY, iov

rsv, iov
rsv, fov, fuv

99FD

CVTFG sre.rl, dst.wg

CVTFL sre.n, dst. wI

II<

CVTF\V sre.n, dst.ww

II<

48FD

CVTGB STe.rg, dst.wb

II<

33FD

CVTGF sre.rg, dst.wf

4AFD

CVTGL sre.rg, dst.wl

01<

II<

rsY, iov

49FD

CVTGW src.rg, dst.ww

01<

II<

rsY, iov

CVTLD sre.rl, dst.wd

CVTLF src.rl, dst. wf

...

4EFD

CVTLG STe.rl, dst.wg

CVTWD srC.TW, dst. wd

4D
4DFD

2-20

.*
II<

..
II<

...

CVTWF sre.rw, dst.wf

01<

CVTWG src.rw, dst.wg

01<

...

Architectural Summary

DIGITAL CONFIDENTIAl.

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

Exceptions

Floating Point Instructions

CVTRDL sre.rd, dst.,~1

II<

rev, iov

CVTRFL sre.rf, dst. wI

II<

rev, iov

4BFD

CVTRGL sre.rg, dst:w1

II<

rev, iov

DIVD2 divr.rd, quo.D:td

II<

rev, fov,fuv, fdvz

DIVF2 divr.rf, quo.mf

II<

rev, fov, fu'v, fdvz

46FD

DIVG2 divr.rg, quo.mg

II<

rsv, fov, fuv, fdvz

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

II<

rsv, fov, fuv, fdvz

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

II<

rev, fov, fuv, fdvz

47FD

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

II<

rsv, fov, fuv, fdvz

:MNEGD sre.rd, dst.wd

II<

rsv

:MNEGF src.n, dst. wf

II<

rsv

52FD

MNEGG sre.rg, dst. wg

II<

rev

MOVD sre.rd, dst.wd

II<

rsv

MOVF sre.n, dst.wf

II<

rsv

50FD

MOVG src.rg, dst.wg

II<

rsv

MULD2 mulr.rd, prod..md

II<

rev, fov,fuv

MULF2 mulr.rf, prod.mf

II<

re'v, fov, fuv

44FD

MULG2 mulr.rg, prod.mg

II<

rsv, fov,fuv

MOLD3 mulr.rd, muld.rd, prod.wd

II<

rev, fov, fuv

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

II<

rev, fov, fuv

45FD

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

II<

rsv, fov, fuv

SUBD2 sub.rd, dif.md

II<

rsv, fov, fuv

SUBF2 8ub.n, dif.mf

II<

rsv, fov, fuv

42FD

SUBG2 8ub.rg, dif.mg

II<

rev, fov, fuv

DIGITAL CONFIDENTIAL

Architectural Summary

2-21

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):
Opcode

NVAX Instruction Set

Instruction

Exceptions

Floating Point Instructions

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

II:

rav, fov, fuv

SUBF3 sub.n, min.n, dif.wi

II:

rav, fov, fuv

43FD

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

II:

rav, fov,fuv

TSTD src.rd

II:

rav

TSTF sre.n

II:

rav

53FD

TSTG sre.rg

II:

rav

Microcode-Assisted Emulated Instructions

ADDP4 addlen.l"W,
sumaddr.ab

sumlen.TW,

II:

rav, dov

ADDP6 addllen.TW, addladdr.ab, add.21en.TW,
add2addr.ab, sumlen::rw, sumaddr.ab

II:

rav, dov

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

rav, dov

C:MPP3 len.TW, srcladdr.ab, src2addr.ab

II:

CMPP4 srellen.TW, sreladdr.ab, sre21en.rw,
src2addr.ab

II:

CRe tbl.ab, inicrc.rl, strlen.rw, stream.ab

II:

CVTLP src.rl, dstlen.TW, dstaddr.ab

CVTPL srclen.rw, srcaddr.ab, dst. wI

*
*

ray, dov

*
*

o·

II:

rav, iov

CVTPS srelen.TW, srcaddr.ab, dstlen.rw, dstaddr.ab II:

II:

-II:

ray, dov

CVTSP srclen.TW, srcaddr.ab, dstlen.l"W, dstaddr.ab *

ray, do'v

CVTPT srclen.TW, srcaddr.ab, tbladdr.ab, dstlen.rw, *'
dstaddr.ab

II:

rav, dov

CVTTP srclen.rw, srcaddr.ab, tbladdr.ab, dstlen.rw, *'
dstaddr.ab

II<

rav, dov

DIVP divrlen.rw, divraddr.ab, divdlen.rw, dive
daddr.ab, quolen.rw, quoaddr.ab

if<

II<

rav, dov, ddvz

2-22

Architectural Summary

addaddr.ab,

II<

DIGITAL CONFIDENTlAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Tabte 2-6 (Cont.):
Opcode

NVAX tnstruction Set

Instruction

Exceptions

rsv, dov

Microcode-Assisted Emulated Instructions

38 '

EDITPC src1en.rw,
dstaddr.ab

pattern..ab,

MATCHC objlen.rw, (~bjaddr.ab, src1en.rw, sr·
caddr.ab

MOVP len.rw, srcaddr.ab, dstaddr.ab

MOVTC src1en.TW, srcaddr.ab, fill.rb, tbladdr.ab,
dstlen.rw, dstaddr.ab

MO'VTUC srclen.rw, srcaddr.ab, esc.rb, tbladdr.ab, '"
dstlen.rw, dstaddr.ab

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

•

rsv, dov

SOOP4 sublen.TW, subaddr.ab, diften.rw, difaddr.ab •

•
•

rsv, dO,T

rsv, dov

srcaddr.ab,

SOOP6 sublen.TW, subaddr.ab, minlen.rw, mi-

•

naddrab djfiep ny difaddrab

DIGITAL CONFIDENTIAL

Architectural Summary

2-23

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-6 (Cont.):

NVAX Instruction Set

The notation used fOT operand specifiers is <name>.<aC'.cess type><data type>. Implied operands (those locations that are
referenced by the instruction but not specified by an operand) are denoted by curly braces O.
Access Type
a :: address operand

=branch displacement

m:: modified operand <both read and written)
T :: read only operand

=if not "Rn", same as a, otherwise R[n+lJ'R[nJ

=write only operand

Data Type

b :: byte
d :: D_floating
f :: F_floating
g G_floating
1 :: longword
q:: quadword
-v :: field (used only in implied operands)
w:: word
'" :: multiple longwords (used only in implied operands)

Condition Codes Modiflcation

'" :: conditionally set/cleared
- = not affected
0:: cleared
1 :: set
:E%ceptions
rs-v = reserved operand fault

io~
integer overflow trap
idvz :: integer divide by zero trap
fov floating overflow fault
fuv = floating underflow fault
fdvz = floating divide by zero fault
dov == decimal overftow trap
ddvz = decimal divide by zero trap
sub subscript range trap
P"' = privileged instruction fault
vee = vector unit disabled fault

2-24 Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

2.6

Memory Management
The NVAX Plus 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 Buffe:r Invalidate Single (TBIS), and Translation Buffe:r Invalidate All
(TElA).

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.

I 0

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

c·

MAPEN .Register

3: 30 2~
2'123
02 01
____
__ • 281:7
__ + __ + 2£
__ 25
__ + __
__ 22 21,+20119
__ + __ +18
__ + l
__' + 16115
__ + __ + 14
__ + 1~
__ +12111
__ __ +10
__ + O~
__ + 08J07
__ + __ + 06
__ + 05
__ 04103
__ + __ +_D.
__ + 00
__
~

Figure 2-11:

I : MAPEN

. . --,+--+--+--+--+--+--.;.--+--+--+--+--+--+--.,..--".---+---+--+--+--+--+--+
!'!ME --+

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:

TBIS Register

31 30 29 28127 26 25 24123 22 2l 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 OC
Virtual Address

:TB!S

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.
Figure 2-13:

TBIA Register

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

I 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 0 0 0 0 I : TEIA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-_.+-----+

DIGITAL CONFIDENTIAL

Architectural Summary

2-25

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

2.6.2

System Space Address Translation

A virtual address with bits <Sl> = 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 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 2**22-1 pages in system space may be addressed. AB 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

The extended SO space descibed above is implemented on the NVAX Plus chip.
NOTE

·\hlhen the CPU is configured to generate SO-bit physical addresses, SBR<Sl:30> are
ignored.
Figure 2-14:

System Base and Length Registers

31 30 29 281:7 26

24123 Z2 21

2011~

lS 1i l6115 14 l3 121ll lO 09 0810i 06 05 04103 02 01 00

Physical Page Address o! SP!

1 0

0 1 : SBR

3: 30·29 28127 26 25 2~123 22 21 20119 l8 17 16115 14 l3 l21l1 lO 09 0810i 06 05 04103 02 01 00
! 0

Length of SP~ in Longwords

1 :SLR

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

2-26

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-15:

System SpacE~ Translation Algorithm
3

+---+----_. . _------------+-------. .
, 1 ,virtual pagE number'
bytE'
+---+----_. . _------------+-------+

system-spaCE
,·irtual address:

3
1

,
1
2 12
4,3

e:ctract VPN,
checr. length,
and add

1 \
1 \
,\ '
211 0 \

\
\
\
\

+--------.
. ----_ .._------------+---+
\
, physical
of SP! baSE
, \
+--------------------------------+
I sign-extend PJI<29> to P.A<3l:30>1
1

addl~ess

SBR:

, i f in 30-bit modE
1

yields

,
,
,
1

I'
01
1

.'.1--------------_._-------,---------+
,
physical acldress of SPT£
,
. .--------------_._----------------+ ,

,
1

,
,
,
1

,
,

fetch
322
SPTE:

mode,
sign-extend PT£<20> to
PT£<22:2l> if in 30-bit
mergE
13
11
physical address:

,
,
,

,
1

1
,
1
1

m~E

2.6.3

+---------------,-----------------+
,
pagE .framE numbe=
1
+--------------,-----------------+
,,
check access in current

1
1
1

/
/
9, /B

/
/

+-------------------------+-------+
, byte
1page frame number
+-------------------------+-------+

Process Space Address Translation

A virtual address with bit <31> = 0 is an address in the process virtual address space. Process
space is divided into two equal sized, separately mapped regions. If virtual address bit <30> =0,
the address is in region PO. If virtual address bit <30> = 1, the address is in region Pl.
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 tof the PO Page Table. The POLR contains the size of the POPT in
longwords, that is, the numbe',r 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.

DIGfTAL CONFIDENTIAL

Architectural Summary

2-27

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

The PO space translation algorithm is shown graphically in Figure 2-17.
Figure 2-16:
2~

31 30

PO Base and Length Registers

26127 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 OSl07 06 05 04103 02 01 00
Syntml Virtual

: 1

31 30

Pa9E! Address of POP'I'

I 0

: POBR

26127 26 25 24123 22 21 20119 IS 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
I :POloR

Figure 2-17:

PO Space Translation Algorithm
3 :3 :2
: 0 9

process-spaCE!
vinual address:

.---.-------------------.-------~

Ivirtua: P89~ number 1

1 0

bJ~~

+-------------------"----+--------.
1\
\
3

212
312

enract: VPN,
checr. length,
anc add

1 \
1

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

POBP.:

I virtual address o! POP! bas~

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

98
1

\
\
I
I

I
01

I
I

byt:~

I
I

.---.---------------------------+
Ivirtual
number
pag~

yields

13 3 2
1109

virtual address
o! POPTE.:

211 0 \

1
1

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

3
1

I
I

fetch using system-spac. translation I
algoritl"m., including length check,
I
I
but: without access checr.
:: 2
3.:

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

POP'I'E:

I mode,

I sign-extend PTE<20> to

I PTE<22: 21> i f in 3D-bit I
I
I mode
I
I
merge
I I
I
13
I /
11
91/B

physical address:

2.6.3.2

I
I
I
I
I
I
I

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

P1 Region Address Translation

The PI region of the address space is mapped by the PI Page Table (P1PT), which is defined
by the PI Base Register (PlBR) and the PI Length Register (P1LR). Because PI space grows
towards smaller addresses, and because a consistent hardware interpretation of the base and
length registers is desirable, P1BR and P1LR describe the portion of PI space that is NOT
2-28

Architectural Summary

DIGITAL CONFIDENTIAL

' - - - - - - - - - - - - - - - - - - - - - -__
• •_ _ _ _ _ _ _ _M

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

accessible. Note that PlLR contains the number of nonexistent PTEs. P1BR contains the pagealigned virtual address of what would be the PTE for the first page of P1, that is, virtual byte
address 40000000 (hex). The address in P1BR is not necessarily an address in system space,but
all the addresses of PrEs mu.st be in system space.
The PI space translation algorithm is shown graphically in Figure 2-19.
Figure 2-18:

P1 Base and L.ength Regtsters

31 30 29 28127 26 2S 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04102 02 01 00
+--+--+--+--.... ---!---.p.--+--~-- --+-.~+--+--.--+---+--+--+--+--+--+--....
--+
Virtual PagE Address of P1P'l'
I 0
0 0 0 0 0 0 0 01 : P1BR

--+_ . _+-_ . .

. . .--+--+--+--+--+--. .

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

1 0

Figure 2-19:

--+--+--+--.
. 21) - Lengtr. of P1P'l' in Longwords
(2

--+--+--,+--+--~--+--+--+--+--~--+--+--+-

...--..,..---+-

I :P1I.P.

P1 Space Translation Algorithm
1-

:. (: 9

+---.
. -------------------+-------~
I 0 Ivirtual page number I byte I

process-space .
virtual address:

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

2 I2

extraet VPI;,
eheck length,
and add

312

P1BR:

\
\

211 0 \

+-------+-------------------+---+
\\
I virtual address 0: P1P'l' base
+-------------------------------+ I
1

1
1

I
1

1
01

1
1

yields

13 3 2
11 0 9

virtual address
0: P1PTE:

I \

9 8

\
\
\
I
1
1

I
I
I

+---+---------------------------+
Ivirtual page number I byte
I
+---+----------.-----------------+
I
fetch using syst.am-space translation

I
I
I
I

algorithm, inclu.:iing length check,
but without acce$S eheck

P1PTE:

2 2

3:2

I
I

mode,
sign-QX~end PTE<20> to
PTE<22:21> if in 30-bit
mode

merge
13
11

DIGITAL CONFIDENTIAL

+------+-------------------------+
page frame number
+------+--------,-----------------+
check a.::eess in current

physical address:

I
I
I
I

I
I
I
1

/
1 /
91/8

+-------_._----------------+-------+
I
page frame number
I byte
+--------,-----------------+-------+

Architectural Summary

2-29

NVAX Plus CPU Chip Functional Specification, Revision O.3~ October 1991

2.6.4

Page Table Entry

If the CPU is configured to generate 30-bit physical addresses, it interprets PTEs in the 21bit 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~3> of the 25-bit PFN format are ignored by the NVAX Plus CPU chip, which implements
only 32-bit physical addresses. The PTE formats shown below are described in DEC Standard
032.
Figure 2-20:
3~

I VI

30 29

PTE Format (21-blt PFN)

2812~

PRO:

26 25 24123

I MI ZI OWN

Figure 2-21 :

21 20119 16 1i 1611:

SI 51

13 12111 10 09 08107 06 05 04103 0: 01 00

Pag_ Frame Number

I :PTt

PTE Format (25-bH PFN)

3: 30 29 281: i 26 :5 241:3 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
I Vi

2-30

PROT

M! 51

sa: I

Architectural Summary

Page Frame Number

:PT:E

DIGITAL CONFIDENTIAL

I_ _ _ _ _ _ _~il

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-7:

PTE Protection Code Access Matrix

Code

Current Mode

Decim.al Binary

MDemonic

0000
·0001
0010
0011
0100
0101
. 0110

1
2
3
4·
5
6

0111
1000
1001
1010
1011
1100
1101
1110
1111

8
9

10
11
12
13
14
15

no access
unpredictable

UW
EW
ERKW
ER
SV\7
SREV\7
SRKV\7

R'W

UREV\7

RW
RW
R
RW
RW
RW
R
RW
RV\7

URKW
UR

RW
R

SR
URSV\7

Comment

R'W

RW
R
R
RW
RW
R
R
RV\7

....... ~ ._4

RW
R
R

reserved

~".

~;::""."

RW
R
R
R
RW
R
R
R

RW
"

all access

to:

R
R
R

Access Modes

K = Kernel
E =Executive
S = Supervisor
U User

Access Types
R
W

=Read
=Write

- = No access

2.6.5

Translation Buffer

In order to save actual memory references when repeatedly referencing pages, the NVAX Plus
CPU Chip uses a translation buffer to remember successful virtual address translations and page
status. The translation buffE~r contains 96 fully associative entries. Both system and process
references share these entries.
TI'anslation buffer entries are replaced using a not-last-used (NLU) algorithm. This algorithm
gtl.B.rantees 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
bl.mer 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 sta.tus, the machine updates the translation buffer by replacing the
entry that is sel~cted by the replacement pointer.
DIGITAL CONFIDENTIAL

Architectural Summary

2-31

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 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 flow 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 current process. An intelTUpt 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 (SCB). 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 29 281:' 26 25 24123 :2 21 20119 16 17 16115 l ' 13 12!11 10 09 08107 06 05 04103 02 01 00

: (SP)

PSl.,

This minimum stack frame is used for all interrupts. Certain exceptions expand the stack. frame
by pushing additional parameters on the stack above the PC/PSL pair as shown in Figure 2-23.
Figure 2-23:

General Exception Stack Frame

31 30 29 28127 26 25 24123

21 20119 16 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00

Parame't.er n

: (SP)

Parameter 1
PC
PSl.,
+--~--+--+--+--+--+--+--+--+--+--+--+--+--~--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

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

2.7.1

Interrupts

DEC Standard 032 defines 31 interru.pt priority levels, a subset of which is implemented by the
NVAX Plus CPU. When an interrupt request is generated, the hardware compares the request
with the cu.rrent IPL of the CPU. lfthe 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, updates

2-32

Architectural Summary

~.IIIIIIIEI_~ _ _ _'_ _ _ _ _ _ __

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

the IPL, pushes a PCtPSL pair on the stack, and dispatches to a macrocode interrupt handler
through the appropriate location in the SCB.
Of the 31 interrupt priority lev'els defined by DEC Standard 032, the :N'VAX Plus CPU makes use
.
of 23 of them, as shown in Table 2-8.
Table 2-8:

Interrupt Priority lLevels

lPL (hex)

IPL (deciDuu)

Interrupt Condition

BALT_B asserted (non maskable)

IE
ID

31
30
29

ERR..B asserted (or internal hard error detected)

Unused

27
26

Performance Monitoring Interrupt(internally handled by microcode)

18-19
17
16

Unused

Internal soft error detected

24-25

Unused

mQ..B<3> asserted
~Q..B<2> or interval timer (IBQ..B<2> takes priority)

14
10-13

22
21
20
16-19

01-OF

01-15

2.7.1.1

mQ..B<l> asserted
JltQ..B<O> asserted

Unused
. Software inteITUpt asserted

Interrupt Control Registers

The inteITUpt system is controlled by three processor registers: the Interrupt Priority Level
Register (IPL), the Software Interrupt Request Register (SIRR), and the Software Interrupt
Swnmary 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 2-24.
Interrupt Priority LE~vel Register

Figure 2-24:

3l 30 29 28127 26 25 24123 22 2l 20119 l8 17 l6115 l4 13 12111 lO 09 08107 06 05 04103 02 01 00
i 0

()

0 I PSL<20: l6> I : IPl..

+--+--+-'-+--+--+--+--~--+---r--+--+--+-"'+--+--+--+--.- -+--+--+--,+--+--+--+--~--+--+--~--+--+--+--+

DIGfTAL CONFIDENTIAL

Architectural Summary . 2-33

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

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

Software Interrupt Request Registers

3: 30 29 28127 26 25 24123 22

201l~

l8 17 16115 l4 l3 l21ll lO

08107 06 05 04103 02 01 00

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

I c)

OIRequest IPi I :SIRR

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

Software Interrupt Summary Register

3: 30 2i 28127 26

I 0

24123 :: 21

G C

201l~

oDe

18 17 16115 l4 l3 12111 10
0

08107 06 05 04103 02 01 00

I 0I

:SISR

IPL 15 reques~ --'
IPL l' reques~ --'

2.7.2

IPL 2 reques~ --'
IPL 1 reques~ --'

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 overflow trap
Integer divide-by-zero trap
Subscript range trap
Floating overflow fault
Floating divide-by-zero fault
Floating underflow fault

Memory management exceptions

Access control violation fault
Tnmslation not valid fault
. M=O fault
ReserVed addressing mode fault
Reserved operand fault or abort

Operand reference exceptions

2-34

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-9 (Cont.):

Exception Classes

Exception. Class

Instances

Instruction execution exceptions

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

trap

Tracing exceptions

'!race fault

System failure exceptions

Kernel-stack~not-valid abort
Interrupt-stack-not-valid halt
Console en-or 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. Afte~r 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 regis-

ters and memory UNPREDICTABLE such that the instruction cannot necessarily be correctly
restarted, completed, simulated, or undone. In most instances, the NVAX Plus 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 Plus CPU,
or where DEC Standard 032 is not clear about the implementation.
2.7.2.1

Arithmetic Exceptions

Arithmetic exceptions are det1ected during the execution of instructions that perform integer or
fioating point arithmetic manipulations. Whether the exception is reported as a: trap or a fault
is a function of the specific ev'ent. 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.

DIGITAL CONFIDENTIAL

Architectural Summary

2-35

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

Figure 2-27:
31 30

Arithmetic Exception Stack Frame

281:7 26 25 241:3 22 21

2011~

18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
Type Code

: (SP)

PC
PSl.

Table 2-10:

Arithmetic Exceptions

Type Code
Decimal

Hex

Type

Exception

'!Tap

Integer overfiow

'!Tap

Integer divide-by-zero

'!Tap

Subscript range

Fault

Floating oveI"fiow

Fault

Floating cbvide-by-zero

Fault

Floating underfiow

2.7.2.2

Memory Management Exceptions

Memory management exceptions are detected during a memory reference and are always reported
as faults. The five memory management exceptions are listed in Table 2-11. All four 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

3C (hex)

Modify fault

2-36

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

Figure 2-28:

Memory Management Exception Stack Frame

3l 30 29 28127 26 25
1 0

2~12!

2: 21
0

2011~

18 17 16115 14 1312111 10
0

08107 06 05 04103 02 01 00

(;

0 I 01 01 M \ F 1 1.1 : (SF)

Some Vi~ual Address in the Faulting Page

-+--+-- ...

--+--+--+--.--.--+--+--. .--. .--+--. .

Table 2-12:

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

Memory Management Exception Fault Parameter

Bit

Mnemonic

Mela.niDg

Len.gth violation

L
p

Modify or write intent

2.7.2.3

. .--.--+--.--.--+--. .--+--+

PTlC reference

Emulated Instructlon Ex(~ptions

The NVAX Plus CPU implements the VAX base instruction group. For certain instructions outside
that group, the NVAX Plus microcode provides support for the macrocode emulation of instruc·
tions. There are two types of c3mulation exceptions, depending on whether PSL<FPD> is set at
the beginning of the instructio:n.
If PSL<FPD>=O at the beginning of the instruction, the exception is reported through SeB 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.

DIGITAL CONFIDENTIAL

Architectural Summary

2-37

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-29:

Instruction Emulation Trap Stack Frame

31 30 29 2812: 26 2S 24123 22 21 20119 18 17 16115 14 13 12111 lei 09 08107 06 OS 04103 02 01 00
Opcod4i!

: (SP)

Old PC
Specifier fl
Specifier f 2
Specifier f 3
specifier ~ 4
specifier if 5
Specifier .6
Spec,ifier >Ii
SpecHier

PC
PSI.

Table 2-13:
Location

Instruction Emulation Trap Stack Frame
Use

Opcode

Zero-extended opcode of the emulated instruction

Old PC

PC of the opcode of the emulated instruction

Specifiers

Address of the specified operand for specifiers of access type write (.wx) or address
(.ax). Operand value for specifiers of access type read (.n). 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

IfPSL<FPD>=l at the beginning of the instruction, the exception is reported through 8CB vector
CC (hex) as a fault with the stack frame shown in Figure ~O. In this case, PC is that of the
opcode of the emulated instruction.

2-38

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-30:
31 30

Suspended Emulation Fault Stack Frame

28127 26 25 24123 22 21 20119 18 17 16115 14 1Z 12111 10 09 08107 06 05 04103 02 01 00

(SP)

PSI,

2.7.2.4

Machine Check Exceptions

A machine check exception is: reported through SCB vector 04 (hex) when the NVAX Plus 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.
Fig~re 2-31 :

Generic Machine Check Stack Frame

3l 30 29 281:7 26 25 24123 :: 2l 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 0:' 0: 00
Byt~

Coun~

of Parameters, Excluding This I,ongword

: (SP)

PC
PSI,

2.7.2.5

Console Halts

In certain microcode flows, the NVAX Plus microcode may detect an inconsistency in internal
state, a kernel-mode HALT, or a system reset. In these instances, the microcode initiates a
ha.rdware restart sequence which passes control to the console program.
***"When a hardware restart sequence is initiated, the NVAX Plus microcode sa:ves the current
CPU state, partially initializes the CPU, and passes control to the console program at the physical
address contained in the COJ:\rSOLE_REG register. ***
During a hardware restart sequence, the stack pointer is saved in the appropriate stack pointer
IPR (0 through 4), the current PC is saved in IPR 42 (SAVPC), and the current PSL, halt code,
and validity flag are saved in IPR 43 (SAVPSL). The format of SAVPC and SAVPSL are shown
in Figure 2-32.

DIGrTAL CONFIDENTIAL

ArchItectural Summary

2-39

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-32:

Console Saved PC and Saved PSL

3: 30

2f 25 24123 22 21

28::~

2011~

18 17 16115 14 13 12111 10 09 08107 06 05 0410! 02 01 00

Saved PC
31 30

I :SAVPC

281:7 26 25 24123 22 21 20119 18 17 16115 14 13 12111 10 09 08107 06 05 04103 02 01 00
PSL<31:16>

Halt Code

PSL<7:0>

I :SAVPSL

MAPEN<O> --'

Invalic SAVPSL it 1 --'

.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:
3: 30

281=~

System Control Block Base Register
26 25 24123 2: :1 20119 18 17 16115 14 13 l21l1 10 09 0810i 06 05 04103 02 01 00
Physical

2.8.1

Pa9~

Address of

SC~

SBZ

I 0

0 I :SCBB

System Control Block Vectors

An SCB vector is an aligned longword in the SCB through which the NVAX Plus 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.

2-40

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-34:

System Control Block Vector

31 30 2i 28127 26 25 24123 22 21 20119 l8 17 16115 14 13 l2111 10 09 08107 06 05 04103 02 Ol 00

longword Ilddr&ss of

Table -2-14:

s&rvic~

routin~

Icoci~

System Control Block Vector

Bits

Contents

31:2

Virtual address of the service routine for the interrupt or exception. The routine must be
longword aligned, as 1~he 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 rallsed 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
Type

Notes

Vector

Name

unused

machine check

abort

parameters reflect machine state;
must be serviced on interrupt stack

kernel stack not valid

abort

must be serviced on interrupt stack

unused

Param

**NVAX passiverelease**

**NVAX power fail**

reserved/privileged instruction

fault

customer reserved instruction

fault

XFC instruction

reserved operand

fault/abort

not always recoverable

reserved addressing mode

fault

access control violation/vector
alignment fault

fault

parameters are virtual address,
status code

translation not valid

fault

parameters are virtual address,
status code

DIGrTAL CONFIDENTIAL

Architectural Summary

2-41

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-15 (Cont.):

System Control Block Layout

Vector

Name

Type

Param

trace pending

fault

breakpoint instruction

fault

-ao

unused

arithmetic trap/fault

38-3C

unused

40
44

Notes

compatibility mode in other VAXes
trap/fault

parameter is type code

CHMK

trap

parameter is sign-extended operand
word

CHME

trap

par~meter is sign-extended operand

word
48

CHMS

trap

parameter is sign-extended operand
word

CHMlJ

trap

parameter is sign-extended operand
word

unused

soft error notification

interrupt

IPL is 1A (hex)

Performance monitoring counter interrupt
overfi.ow

59-5C

unused

hard error notification

unused

vector unit disabled

6C-80

unused

See Chapter 18 for details

interrupt

IPL is lD (hex)

fault

vector instructions
**80 was NVAXinterprocessorin.
terrupt**

software level 1

interrupt

software level 2

interrupt

ordinarily used for AST delivery

software level 3

interrupt

ordinarily used for process schedul·
. ing

90-BC

software levels 4-15

interrupt

interval timer

interrupt

unused

emulation start

fault

same mode exception, FPD=O; pa~
rameters are opcode, PC, speci~
fien

emulation continue

fault

same mode exception, FPD:l; no
parameters

device vector

interrupt

IPL is 14 (hex)

device vector

interrupt

IPL is 15 (hex), includes console
interrupts

2-42

Architectural Summary

IPL is 16 (hex)

.:..

DIGITAL CONFIDENTIAL

NVAX Plus CPT] Chip Functional Specification, Revision 0.3, October 1991

System Con~rol Block Layout

Table 2-15 (Cont.):
Vector

Name

device vector

EO-F4

unused

F8-FC

unused

Param

Notes

interrupt

IPL is 16 (hex)!, includes interprocessor interrupts

interrupt

IPL is 17 (hex)

**FB was NVAX console receiverFC was console transmitter -IPL
15**
**was NVAX Device interrupt vec-

100-FFFC unused

tors**

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:

CPU 10 Register

31 30 29 2812i 26 25 24123 22 21 20119 16 17 16115 14 13 12111 10 09 08107 06 OS 04103 02

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

I 0

CPU ldem:.ifica'tion

I :CPuID

The CPUID processor register is implemented internally as an 8-bit read-write! register. The
source of the CPU ID informa.tion 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 IDENTIFICA1'ION

The System Identification Register, IPR 62 (SID), is, a read-only register implemented per DEC
Standard 032 in the NVAX Plus CPU. This 32-bit register is used to identify the processor type
and its microcode revision level.

DIGITAL CONFIDENTIAL

Architectural Summary

2-43

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-36:
31 30

System Identification (SID)

26 27 26 25 24 23 22 :1 20 19 18 17 16
RC

I 0

14 13 12 11 10

IRO!

o
I

:SIt.

~--> Microcode revision
~--------------> NS
~-------------------------> Patch Revision
~----------------------------------------------------- ---------------------> CPU t~

2-44

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3" October 1991

Table 2-16:

SID Field Descriptions

Name

Extent

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, ot
the patch is a standard patch. If
this bit is a one, a non-standard
microcode patch is loaded. A nonstandard 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 inicrocode
patch is loaded. If this field is nonzero, 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, 23 (decimal), indicating that this is an NVAX Plus

Description

CPU.

In order to distinguish between different CPU implementations that use the same CPU chip, the
LNP, along with all VAX prOCE~ssors which use the NVAX Plus chip, implements a System Type
Register (SYS_TY'PE). SYS_TYPE resides at the physical address pointed to by the CONSOLE_
REG -I- 4. This 32-bit read-only register is implemented in the LNP console image. The format
of this register is shown in Figure 2-37.
Figure 2-37:

System Type (S;YS_TYPE)

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

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--.
RO

1 : SYS _ T:G>£

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
I.

+-> Architeetural ID
+-------------------------> system Variant
+--------------~----------------------------------> Revision level
+---------------------------------------------------.---------------------> System type
The fields in this register are as follows:

DIGrTAL CONFIDENTIAL

Architectural Summary

2-45

NVAX Plus CPU Chip Functional Specification, Revision. 0.3, October 1991

Architectural ID: This field contains licensing bits which distinguish timesharing systems from
workstations. Because the LNP module is included in a timesharing system, this field contains
01 (hex).
System Variant: This field distinguishes variants of similar systems. Because this is the first
LNP variant, this field contains 01 (hex).
Revision level: This field contains the revision number of the LNP console software. The first
LNP console revision will be 01 (hex).
System type: This field indicates the type of system. Because this is a Laser system, this field
contains TBD (hex).
SID and SYS_TYPE are accessible only to the CPU on the LNP module. Other devices on the
LSB determine the type of node by reading its Laser Device Registers (LDEV).

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-38. The format of the process control block is shown in
Figure 2-39. 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 SO-bit physical addresses, PCBB<Sl:30> are
ignored.
Figure 2-38:

Process Control Block Base Register

3: 30 29 2812' 2( 25

241~3

22 21 20119 18 17 16115 14 13 1211110 Oi 08107 O( 05 04103 02 01 00

Physical Lon9word Aodress of the PCB

2-46

Architectural Summary

1 0

:PCBE

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 2-39:

Process Co ntr'o I Block

31 30 29 281=' 26 25 24123 22 :1 20119 18 17 16115 14 13 l2111 10 09 08107 06 OS 04103 02 01 00

KSF

:PC~

ESP

SSF

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

+l2

USP
+-~+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RO
+20

P.1

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

+24

+-.. +--+--+--~--+--+--+--+--+--+--,+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
R3
~-

+28

.. +--+--+-----+--+--+--+--+--+--,+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-----+--+--+--+--+--+
R4

+32

R5
+-... +--+--+--..--~--+--+-- --+---+--.;.--+--+--+--+--+--+ --+--+--+--+--+--+--+--+--+--+--+--.... --+--+--+
R6

+36

. .--.+--.,.--. .--. .--.,.--+--. .
...
R7
. . +--+--.--'"'"'--+--+--. . --+--.--+--. . --+--+--+--. .--+--.--+--+--+--.,.--+--. .

...

+40

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

--+--+--""'--+--+--.--'~--+--+

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

... --+--+--+--+--+-----+--+--+--+--+--+--+--+

+52

lUO

+56

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

Rll

+60

AP (R12)
FP (Rl3)

+68

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

PC,

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

PSI.

---+--+--+--+--+.--+--+--+--+--... --~.--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-----+--+--+--+
POBP",
+80
I 0

01 ASTLVL I 0

P0LR

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

.--+--+--.--.--+--+--+--+--+--+--. .

--.~--

. .-..

+84
~

+86

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

: 0

PUR

+92

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

DIGITAL CONFIDENTIAL'

Architectural Summary

2-47

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

2.12

Mailbox Structure

**For NVAX Plus LASERJ(COBRA) Bus systems CSRs exist on external 110 busses which are accessed via mailbox structures that exist in main memory. Read requests are posted in mailboxes,
and data is returned in memory with status in the following quadword. Mailboxes are allocated
and managed by operating system software (successive operations must not overwrite data which
is still in use).
The 110 module will service mailbox requests via four mailbox pointer CSRs (LM:BPR) located in
the 110 modules nodespace. There is one LM:BPR for each CPU node. The software sees only one
LMBPR address~ but the CPU module replaces the least significant two bits of the address (i.e.
D<2:1» with the least significant 2 bits of the node ID (i.e. NIOD<l:O».· If a given LMBPR is
in use when it is written to, the 110 module will not acknowledge it, CNF will not be asserted.
Processors use the lack of CNF assertion on writes to the LMBPR to indicate a busy status and
the write is replayed at a later point in time under software control.
The mailbox pointer CSR has the following format:
Figure 2-40:

LMBPR Register

:: 3
2 1

~-------+--------------------------+-------~~
I

lunused I

MBZ

.-------.--------------------------.--------*
Table 2-17:

LMBPR Description

Name

Bit(s)

Type

Description

MBX

This field contains the 64-byte-aligned physical address of the mailbox data structure in memory where the lIO module can find information to complete the required operation.

The least significant 6 bits of the mailbox address are always 0, to force 64-byte_alignment. The
upper six bits are unused in NVAX Plus systems since NVAX Plus only has a 32 bit wide physical
address. The 110 module does however implement these bits. The NVAX Plus chip will always
drive 0'5 on the upper data lines on 110 space writes such that these bits will be written with O's.
LMBPR points to a naturally aligned 64 byte data structure in memory that is constructed by
software as follows:

2-48

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CJ?U Chip Functional Specification, Revision 0.3, October 1991

Figure 2-41:

ov: 0

ow ~
OW :.>

OW .<I

or;' 5
ow 6

Mailbox t?ata :Structure

6 55 5

0 96 7

4':
B i

.<I:l
(I

:: 332
:2 lOS'

2 :.>

1 1

.: 3

6 5

B i

+----+--+----------+----+
..------+---+----~------~-~--------+--------~
BUS
IMBZ I MAS? I
+----+--+----------+----+.._-----+---.----*--------+--------+--------+
RBADR<63:0>
+----+--+----------+-----.. _-----+---+-------------------------------+
WOATA<63:0>
+-----------------------_ .. _-----------------------------------------+
+-----------------------_ .. _-----------------------------------------+
RDATA<63:0>
+----------------------_._._-------------------------------------+-+-+
IEIDI
CM!)

STATUS

IRIOI
IRINI

+------------------------..UNPREDICTABLE
_-------------------------------------+-+-+
+------------------------_._-----------------------'----~-

OW i

UNPP.ED!CTABLE

. .-----------. .

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

Table 2-18:

Mailbox Data Structure Description

Name

Bit(s)

Type

Description

CMD

Rv~r

This field contains the command. The 110 module supports read and
write commands.

MASK

RV7

This field contains the byte mask. The 110 module does not use this
field.

BUS

RVl

This field contains the BUS field, which is used to determine which
remote bus this command is meant for.

RBADR

This field contains the address to be broadcast on the remote bus.

WDATA
RDATA

R~r

This field contains the write data to be broadcast on the remote bus.

R'W

This field contains read data returned from the remote bus.

DON

R~T

This field contains a status bit which is set by thE~ 110 module once
a mailbox operation is complete.

ERR

R~r

This field contains a status bit which indicates that a mailbox operation failed..

For a more complete description of the Laser system mailbox protocol refer to the lOP and LAMB
module specifications.

DIGITAL CONFIDENTIAL

Architectural Summary

2-49

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

2.12.1

Mailbox Operation

To perform an 1/0 read or write on one the remote 110 busses software must create a maibox data
structure in memory. The command, bus, and address fields must be filled in and the status bits
must be cleared. For a write command the write data field must also filled in. At this point the
physical address of the maibox data structure must be written to the LMBPR register to initiate
the 110 operation. A simple 110 space write, such as with a MOVL, could be used to start the
remote 110 operation. However, since writes to LMBPR may be rejected by the 110 module, and no
state is preserved across a macro instruction boundry to notify software of this, another method
must be used. Microcode implements an IPR register which can used to perform the LMBPR
write and return status to software via the condition code bits.
In order for microcode to perform the LMBPR it must know the address of the LMBPR register
and the address of the mailbox data structure. Another memory data structure must be created
to pass this information to microcode. This structure is called the Mailbox Pointer and consists
of 2 longwords which begin at a quadword aligned address.

Figure 2-42:

Mailbox Pointer

650

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

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

+--------------------------+--------*
Table 2-19:
Name

Mailbox Pointer Description
Bit(s)

Type

Description

32
32

wo
wo

This field contains the virtual address of the LMBPR register.
This field contains the physical address of the mailbox data structure. Since the mailbox data structure must be aligned on a 64 byte
boundry, bits<5:0> of MB_ADDR must be zero.

Once software creates the mailbox data structure and the mailbox pointer structure it may now
start the 1/0 operation. An MTPR to the MAILBOX IPR will initiate the 110 operation. The
MAILBOX IPR has the following format:
Figure 2-43:

MAILBOX Register
o

+-----------------------------------+
MBXREG
+-----------------------------------~

2-50

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-20:

MAILBOX Register Description

Name

Bit(s)

Type

Description

MBXREG

This field contains the address of the mailbox pointer structure.

Microcode will read the M:B_ADDR field out of the mailbox pointer structure and then write this
value to the LMBPR using the address of the LMBPR provided in the mailbox pointer structure.
NOTE

Note:Non QW aligned addresses for the L:MBPR_ADDR results in Undefined Operation.
An EDAL store conditional command is used to perform the write. Microcode will then check
a status bit in the CBOX to determine if the write passed or failed. If the write passed, the
PSL<Z> bit will be set, othenqise PSL<Z> will be cleared. Software can loop on the MTPR to the
MAILBOX Register until the write passes.

After the 1/0 module has accepted the write to LMBPR it will perform the 110 operation. Software
can now poll the status bits in the mailbox data structure until the I/O operation is complete.
One the 1/0 operation is complete the DON bit will be set, if an error occured te ERR bit will also
be set. If this was an I/O write operation no further action is needed. If this was an 110 read
operation, software can now fetch the returned data from the RDATA field in the mailbox data
structure.

DIGrTAL CONFIDENTIAL

Architectural Summary

2-51

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

2.13

Processor Registers

The processor registers that are implemented by the NVAX Plus CPU chip are logically divided
into three groups, as follows:
•
•
•

Normal-Those IPRs that address individual registers in the NVAX CPU chip or system
environment.
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-44.
Figure 2-44:

IPR Address Space Decoding

Normal !PR Address
31 30 29 281:7 2( 25 24:Z3 Z: 21 20119 18 17 16115 l' 13 12111 10 09 0810i 06 05 04103 02 01 00

SB:'

!PR Number

SB:

1 O!

Pcache Tag IPR Address
31 30 29 281:, 26 25 241:3 22 21 20119 18 1i 16115 l ' 13 l21l1 10 09 0810i 06 05 04103 02 Ol 00

SBZ

I 11 II

SBZ

Pcach. Tag

SBZ

Incie~:

Pcacne Set Select (O-left, l-right) -+
Pcacne Data Pari~y IPR Address
31 30 29 2812i 26 25 24123 22 21 20119 18 1i 16115 14 13 12111 10 09 0810i 06 05 04103 02 01 00

SBZ

I II 11 II

SB:

Pcacne Set Select (O-left, l-right) -+

SBZ

Pcach. Tag Index
Subblocy. select +

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

2-52

Architectural Summary

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3;, October 1991

Table 2-21:

IPR Address SpacE~ Decoding

IPR Group

Mnemonic 2

IPR Address Range
(hex)

Contents

OOOOOOOO ..OOOOOOFF1 . 256 individual IPRs.

Normal
Pcache Tag

PCTAG

01800000.. 01801FE0 1

Pcache Data Parity

PCDAP

OlCOOOOO .. OIC01FFS 1 1024 Pcache data parity IPRs, 512 for each
Pcache set, each separated by 8(hex) from the
previous one.

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

- 256 Pcache tag

1 Unused fields in the IPR addresses for these groups should be zero~ Neither hardware nor microcode d~tects and faults on
an add:ress in which these bits are non-ZE!TO. Although non-contiguous address ranges are shown for these groups, the entire
IPR address space maps into one of the these groups. If these fields are non-zero, the opf!!ration of the CPU is UNDEFINED.

2Tbe mnemonic is for the first IPR 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> ~nd 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 IPJR address for the first subblock of Pcache data parity is 01COOOOO
(hex), and the IPR address fOT the second subblock of Pcache data parity is 01C00008 (hex). The NVAX Plus chip does not support the Bcache Tag or Bcache Deallocate IPRs. IPR addresses
which do not correspond to chip IPRs are NOT converted to- I/O space addresses, with IPR reads
retunring UNPREDICTABLE data, and IPR writes not completed.
The processor registers imple:mented by the NVAX CPU are are shown in Table :2-22.
NOTE

Many of the processor registers listed in Table 2-22 are used internally by the microcode during normal operation of the CPU, and are not intended to be referenced by
software except during tE~st 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 ISummary

2-53

NVAX Plus CPU Chip Functional Specification, Revision O.3 t October 1991

Table 2-22:

Processor Registers
Number

Mnemonic (Dec) (Hex) Type

Kernel Stack Pointer

KEP

Executive Stack Pointer

ESP

Supervisor Stack Pointer

SSP
USP
ISP

Reserved

User Stack Pointer
lnterrupt Stack Pointer

R'W
RW
RW
RW
RW

1·1

RW
RW
RW

1·2

PO Base Register

POBR

PO Length Register

POLR

P1 Base Register

PIBR

P1 Length Register

P1LR

R~7

RW
RW
RW

System Base Register

SBR

System Length Register

SLR

CPU Identification 1

CPUID

Process Control Block Base

PCBB

System Control Block Base
Interrupt Priority Levell

SCBB

IPL

AST Levell

ASTLVL

Software Interrupt Request Register

SIRR
SISR

Reserved

Software Interrupt Summary Register

Cat
1·1
1·1
1·1
1·1

1·2
1·2
1-2
1-2
1·2
2-1
1-1

RW
RW
RW
RW

1-1

Reserved

1-1
1-1
1-1

Interval Counter Control/Status 1.2

lCCS

24-

1-3

N ext Interval Count

NIOR

1-3

Interval Count

lOR

1-3

Time of Year Register

TODR

R
RW

Reserved
Reserved

Reserved

1-3

1 Initialized on reset

2NVAX Plus implements the full Interval Timer functionality on chip

2-54

Architectural Summary

DIGITAL CONFIDENTIAL

- - - - - - - - - - - -_ _ _' -_ _ _ _. _
. _1_1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-*'I

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-22 (Cont.):

Processor IRegisters
Number

Mnemonic: (Dec) (Hex) Type

Reserved
.Reserved

Reserved

28
29

Machine Check ElTor Register.

MCESR

Cat

2-1

Console Saved PC

SAVPC

2-1

Console Saved PSL

SAVPSL

2-1

Reserved

Memory Management Enable l

MAPEN

1-2

Translation Buffer Invalidate All

TBIA

1-1

Translation Buffer Invalidate Single

TBIS

1-1

59
60

PME

R'W

!~-1

System Identification

SID

1-1

Translation Buffer Check

TBCHK

1-1

Reserved
Reserved
Perlonnance Monitor Enable 1

1 Initialized on reset

DIGITAL CONFIDENTIAL

Architectural Summary

2-55

l'1VAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-22 (Cont.):

Processor Registers
Number

Mnemonic (Dec) (Hex) Type

Reserved

65
66
67
68
69
70

Reserved
Reserved
Reserved
Reserved
Reserved

Reserved

71
72
73
74
75
76
77
78
79
80
81
82
83

Reserved

85
86
87
88
89
90
91
92
93
94
95

Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved

Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved

2-56

Architectural Summary

Cat

40
41
42
43
44

45
46
47
48
49~

4A
4B

4C
4D

4E
4F
50
51
52
53
54
55
56
57
58
59
5A
5B
5C
5D

5E
5F

DIGITAL. CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-22 (Cont.):

Processor lilegtsters
Number

Mnemonic (Dec) (Hex) Type

Reserved

Cat

Reserved

Reserved for VM

100

Reserved for VM

101

Reserved for VM

102

Reserved

103

Reserved

104

Reserved

105

Reserved

106

Reserved

107

Reserved

108

Reserved

109

Reserved

110

Reserved

111

Reserved

112

Reserved

113

Reserved

114

Reserved

115

Reserved

116

7.4

Reserved

117

Reserved

118

Reserved

119

77
!~-4

120

LASER MAILBOX

LMBOX

121

2-1

Interrupt System Status Registers

INTSYS

122

!~-1

Performance Monitoring Facility Count

PMFCNT

123

RW
'RW

2-1

Patchable Control Store Control RegisterS

POSCR

124

2-1

Ebox Control Register

ECR

125

2-1

Mbox TB Tag Fills

MTBTAG
MTBPTE

126

2-1

127

!~-1

Reserved for Ebox

Mbox TB PTE Fills

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

DIGITAL CONFIDENTIAL

Architectural Summary

2-57

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-22 (Cont.):

Processor Registers
Number

Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved .
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved

2-58

~-.-

Architectural Summary

,----------------------,

Mnemonic (Dec) (Hex) Type

128
129
130
131
132
133
134135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
1M
155
156
157
158
159

80
81
82
83
84

85
86
87
88
89
8A
8B
8C
8D
8E
8F
90
91
. 92
93
94
95
96
97
98
99
9A
9B
9C
9D
9E
9F

Cat

2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
2-4
'2-4
2-4
2-4
2-4
2-4

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3" October 1991

Table 2-22 (Cont.):

Processor Flegisters
Number

Mnemonic (Dec) (Hex) Type

Cat

BID Control Register

BIU_CTL

160

2-3

Diagnostic Control RegisteT

DIAG_CTL 161

2-3

Bcache En-or Tag

BC_TAG

162

2-3

163

Reserved fOT Cbox
BID Status

BIU_STAT 164

165

BIU_ADDR 166

Reserved fOT Cbox
BID Address
Reserved for Cbox
Fill Syndrome

167

FILL_SYN 168

169

FILL_ADDR170

Reserved fOT Cbox
Fill Address
Reserved for Cbox
STxC Pass FaillCEFSTS

IPR_STR_
COND

Reserved for ·Cbox
Software ECC

BCDECC

Reserved fOT Cbox
CONSOLE REG

CHALT

Reserved fOT Cbox
Seri~ll!O

SIO

Reserved fOT Cbox
SROM._oelSROM_fast

2-4
W1C

2-3
2-4

171

172

2-3

173

2-3

175

AD
AE
AF

176

177

178

179

174

2-4
2-4
2-3
2-4
RW

2-3
2-4

2-3

180

Reserved fOT Cbox

181

2-4

Reserved for Cbox

182

2-4

Reserved fOT Cbox

SOE-IE

183

B7
B8

2-3

Clear QW 10 Pack

QW_PACK 184
CLR_IO_ 185
PACK

2-3

Reserved fOT Cbox

186

:2-4

Reserved fOT Cbox

187

2-4

Reserved fOT Cbox

188

2-4

Reserved fOT Cbox

189

~2-4

Reserved fOT Cbox

190

2-4

Reserved fOT Cbox

191

:i-4

Pack 10 to QW

DIGITAL CONFIDENTIAL

2-4

Architectural Summary

2-59

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

Ta ble 2-22 (Co nt.):

Processor Registers
Number

Mnemonic (Dec) (Hex) Type

Reserved

192

Reserved

193

C1
C2

Reserved

194

Reserved

195

Reserved

196

Reserved

197

Reserved

19B

Reserved

199

Reserved

200

Reserved

201

Reserved

202

Reserved

203

Reserved

204

Reserved

205

Reserved

206

Reserved

207

VIC Memory Address Register

VMAR

20B

VIC Tag Register

VTAG

209

VIC Data Register

VDATA

210

!box Control and Status Register

ICSR

211

!box Branch Prediction Control Registe~

BPCR

212

213

Reserved for !box

RW
RW
RW
RW
RW

Cat

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

Ibox Backup PC'

BPC

214

2-3

!box Backup PC with RLOG Unwind"

BPCUNW

215
216

2-3

Reserved for Ibox

2-4

Reserved for Ibox

217

2-4

Reserved for Ibox

21B

2-4

Reserved for !box

219

2-4

Reserved. for !box

220

2-4

Reserved for Ibox

221

2-4

Reserved. for Ibox

222

2-4

Reserved. for Ibox

223

2-4

3Testability and diagnostic use only; not for software use in normal operation
'Chip test use only; not for software use

2-60

Architectural Summary

DIGJTAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

Table 2-22 (Cont.):

Processor Registers

Mhox PO Base RegisterS
Mhox PO Length RegisterS
Mhox PI Base RegisterS
Mbox PI Length Registers
Mhox System Base RegisterS
Mbox System Length RegisterS
Mbox Memory Management Enables
Mbox Physical Address Mode
Mhox:MM:E Address'
Mhox :MM:E PTE Address
Mbox :MME Status

Number
Mnemonic (Dec) (Hex) Type

MPOBR
MPOLR
MPIBR
MPlLR
MSBR
MSLR
MMAPEN
PAMODE
MMEADR
MMEPI'E
MMESTS

Reserved for Mbox
Mhox TB Parity Address
Mhox TB Parity Status

TBADR
TBSTS

Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Mbox Pcache Parity Address

PCADR

Reserved for Mbox
Mhox Pcache Status

POSTS

Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Mbox Pcache Control
Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Reserved for Mbox
Reserved for Mbox

PCCTL

224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243

EO
El
E2
E3
E4

E5
E6
E7
E8
E9
EA

RW
RW
RW
RW
RW
RW
RW
RW

2;-3
2i-3

2-3
2,-3
2~-3

2-3
2,-3
2-3
2-3
2-3
2-3
2-4

R
R

EC
ED

Cat

~~-3

2-3
2-4

~~-4

FO
F1
F2
F3
F4
F5
F6
F7
F8
F9
FA'

2-4

244

245
246
247
248
249
250
251
252
253
254
255

FB
FC
FD
FE
FF

~~-4

2-3
2-4

~~-3
~~-4

!~-4
!~-4

!~-3

2-4
!~-4

2-4
2-4
2-4

sTestability and diagnostic use only; not f()r software use in normal operation

DIGITAL CONFIDENTIAL

Architectural Summary

2-61

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 2-22 (Cont.):

Processor Registers
Number

Unimplemented

Mnemonic (Dec) (Hex) 1YPe

Cat

100017FFFFF

See Table 2-21

01800000-

FFFFFFFF
Type:
R

=Read-only register

RW = Read-write register
iN Write-only register

W1C = Write 1 Clear
Cat(egory), class-subclass, where:
class is one of:

1 Implemented as per DEC standard 032
2 = NVAX Plus specific implementation which is unique or different from the DEC standard 032 implementation
subclass is one of:

1 Processed as appropriatel:?Y Ebox microcode
2 = Converted to Mhox IPR number and proce88ed via internal IPR command
3 = Processed by internal IPR command
4
May be block decoded; reference causes UNDEFINED behavior

2-62

Architectural Summary

--------,-------------------------------------------,

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

2.14

Revision History

Table 2-23:

Revision History

'Who

'When

Mike Uhler

06·Mar·1989

Release for external review.

Mike Uhler

15·Dec·1989

Update for second·pass release.

Mike Uhler

2O-Jul·1990

Update to reflect implementation.

:Mike Callander/Gil
Wolrich

15·Nov·19~W

NVAX Plus release for external review.

Gil Wolrich

15·M.AR·1991

Reverse mailbox pointer operands, add clr_io_pack ipr.

DIGITAL CONFIDENTIAL

Description of change

Architectural Summary

2-63

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Chapter 3
External Interface

3.1

Overview
NVAX Plus can share system platforms which use EV chips in 128 bit mode. The CPU_CLK
runs at a cycle time as fast as IOns, and SYS_CLK can be set to 2,3,01' 4, times the CPU cycle
time. NVAX Plus usable in a wide range of systems: workstations, small deskside servers and
timesharing machines, and midrange multiprocessor servers and timesharing machines.

3.2

Signals
The following table lists all of the 291 signals on the NVAX_PLUS chip. In the "type" column, an
til" means a pin is an input, an. "0" means the pin is an output, a tIT" means the pin is a tristate
output, and a "B" means the pin is tristate and bidirectional.

Table 3-1:

NVAX PLUS Signals

Signal Name
clkln_h, _1

Count

Type

Function

Clock input-

testClkln_h, _1

Clock input for testing

cpuClkOut_h

CPU clock output

sysClkOutl_h, _1

System clock output, delayed

sysClkOut2_h, _1

System clock output, delayed

icMode_h[l]

Enables pp_cmd_h<2:0> for test mode

clk_rst_h

Put cpu and sys_clk timing gen. to known state
Parallel Test Port Data, MAE clock

pp_data_h[ll]

pp_data_h[7 .. 6]

pp_data_h[5 .. 0]

B
B
B

osc16m_h

Interval timer 16l\mz oscillator mput

dcOk_h

Power and clocks ok

DIGITAL CONFIDENTIAL

Parallel port [7:6] if enabled, EV tagAdr_h[33 ..32]
Dedicated Parallel Test Port Data

External Interface

3-1

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 3-1 (Cont.):

NVAX_PLUS Signals

Signal Name
reset_l

Count

Type

Reset

Function

sRomOE_l

Serial ROM output enable

sRomD_h

Serial ROM datalRx data

sRomClk_h

Serial ROM clockl'Tx data

icMode[0)/pp_cmd[2]

Serial ROM fast fill, sRomFast_h1used as pp_
cm.d[2] in test mode

adr_h[33 .. 32]

Address bus 33,32

adr_h[31..17]

Address bus tag section

adr_h[16 .. 5]

tagEq,J

data_h[127 .. 0]

128

Data bus

Address bus index section
. Tag compare output

check_h[27 .. 0]

B
B

dOE_l

Data bus output enable

pp_cmd[1:0]

EV dWSel_h[l .. O] used to select port function in
test mode

dRAck_h[2]

dRAck_h[1]

~~h[l] cache/no_cache

dRAck_h[O]

bus read acknowledge, check ece/parity

tagCEOE_h

tagCtl and tagAdr CEIOE

tagCtl'WE_h

tagCtl WE

tagCtlV_h

Tag valid

Check bit bus

bus read acknowledge, load data

tagCtlS_h

Tag shared

tagCtlD_h

Tag dirty

tagCtlP_h

Tag VISfD parity

tagAdr_h[31..20]

Tag address [31..20]

tagAdr_h[19]

Tag address [19J, Parallel Port [10] if enabled

tagAdr_h[18]

Tag address [18J, Parallel Port[9] if enabled

tagAdr_h[17]

Tag address [17J, Parallel Port[8] if enabled

tagAdrP_h

Tag address parity

tagOk_h, _1

Tag access from CPU is ok

dataCEOE_h[3 .. 0]

data CElOE, longword

data WE_h[3 .. 0]

data WE, longword

dataA_h[4]

data A[4]

dataA_h[3]

data A(3)

holdReq_h

Hold :request

holdAck_h

Hold acknowledge

3-2 External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 3-1 (Cont.):

NVAX_PLUS Signals

Signal Name

Count

Type

cReq_h[2 .. 0J

Cycle request

c·WMask_h[7 .. 0J

Cycle write mask

cA.ck_h[2 ..0J

Cycle acknowledge

Function

iAdr_h[ 12.. 5J

Invalidate address

plnvReq_h[l ..OJ

Invalidate request, Pcache

pMapWE_h[l..O]

Backmap WE, Pcache

err_hfirG-h[ 5J

External en-or inteITUpt

halt_hlirq_h[4J

Halt inteITUpt

irq_h[3 ..0J

Interrupt requests

• vref

Input reference/not used by NVAX Plus

tristate_l

Tristate for testing

cont_l

Continuity for testing

test_mode_h

Enables pull-downs on check_h bits, was eclOut_
h

The following table lists· all of the signals that were not on EVAX which are being implemented
on the NVAX_PLUS chip. In the "type" column, an "I" means a pin is an input, an "0" means
the pin is an output, and a "Bt' means the pin is tristate and bidirectional.

Signal Name

Count

Type

test_mode_h

Enables check_h pull downs

osc16m_h

Interval timer 16MRz oscillator input

pp_data_h[6 .. 0J

Parallel Test Port Data

plnvReG-h[l..O]

Invalidate request, Pcache

pMapWE_h[l ..O]

Backmap WE, Pcache

Function

The following table lists all of the signals that were on EVAX which are not being implemented
on the NVAX_PLUS chip. In the "type" column, an ''1'' means a pin is an input, an "0" means
the pin is an output, and a "B" means the pin is tristate and bidirectional.
Table 3-3:

EVAX Signals
Count

Type

dlnvReq_h

dMapWE_h

Backmap WE, Dcache

Performance monitor outputs

Signal Name

perf_h[S .. O]

DIGITAL CONFIDENTIAL

Function

Invalidate request, Dcache

External Interface

3-3

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 3-3 (Cont.):

EVAX Signals

Signal Name

3.2.1

Count

Type

Function
Scan

Clocks

External logic supplies NVAX Plus with a differential clock at the desired frequency of the internal
phases via the clkln_h and clkln_l pins. The NVAX Plus Clock Generator circuit produces the
required four single phase clocks, four inverted single phase clocks, and four dual phases clocks
required for internal operation.
l\TVAX Plus dlvides the input clock by **two** to generate the cpuClkOut_h. The false-to-true
transitiop of cpuClkOut_h is the "CPU clock" used in the timing specification for the tag Ok_l
signal.
The CPU clock is dlvided by a programmable value of 4,6,or 8 (2,3 or 4 cpu cycles) to generate a
system clock, which is supplied to the external interlace via the sysClkOutl_h and sysClkOutl_l
pins. The system clock is delayed by a programmable number of CPU clocks between 0 and 3 to
generate a delayed system clock, which is supplied to the external interface via the sysClkOut2_h
and sysClkOut2_1 pins.
The clock generator runs, generating cpuClkOut.h, and the (correctly timed and positioned) any
time an input clock is supplied. In particular, it runs during reset, so that systems can phase-lock
the clocks of several chips together before any of them are released from reset.
**The sysClkOut value of 6 times the cpuClkOut, results in an asymmetric clock, asserted for 4
cpuClkOut periods, then deasserted for 2 cpuClkOut periods. **
The false-to-true transition of sysClkOutl_h is the "system clock" used as a timing reference
throughout this specification.
Almost all transactions on the external interlace run synchronously to the CPU clock and phase
aligned to the system clock, so the external interface appears to be running synchronously to the
system clock (most setup and hold times are referenced to the system clock). The exceptions to
this are the fast, NVAX Plus controlled tranactions on the external caches and the sample of the
tagOk_l input, which are synchronous to the CPU clock., but independent of the system clock.

3.2.2

DC_OK and Reset

NVAX Plus contains a ring oscillator which is switched into service during power up to provide an
internal chip clock.. The dcOk_h signal switches clock sources between the on-chip ring oscillator
and the external clock oscillator. If dcOk_h is false then the on-chip ring oscillator feeds the
clock generator, and NVAX Plus is held in reset, independent of the state of the reset_l signal. If
dcOk_h is true then the external clock oscillator feeds the clock generator, (NVAX. Plus does not
use the vRefinput) and NVAX Plus is held in reset by reset_I.
Note if the dcOk_h signal is generated by an RC delay, there is no check that the input clocks
are really running. This means that if a board is powered up in manufacturing with a missing,
defective, or mis-soldered clock oscillator then NVAX Plus will enter a possibly destructive highcurrent state. Furthermore, if a clock oscillator fails in stage 1 burn-in then NVAX Plus may also

3-4

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Ftmctional Specification, Revision 0.3, October 1991

enter this state. The frequency and duration of such events need to be understood by the module
designer to decide if this is really a problem.
The reset_l signal forces the CPU into a known state.The reset_l signal is asynchronous, and
must be asserted for at least tbd CPU cycles after the assertion of dcOk_h to guarantee that the
CPU is reset. This should always be .the case, since it also has to be held true for long enough to
guarantee that the serial ROM has reset its address counters (which takes about lOOns).
The NVAX Plus CPU chip useB a 3.3V power supply. This 3.3V supply must be stable before any
input goes above 4V.
'While it is reset, NVAX Plus reads sysClkOut and external bus configuration information off the
irq_h pins. External logic should drive the configUration information onto the ir'l-h pins any time
reset_l is true.
NOTE

NOTE: The irq_h pins are latched with the deasserting edge of reset_I.
The irq_h[2 .. 1J bits' encode the value of the divisor used to generate the system clock from the
CPU clock.
Table 3-4:

System Clock Divisor

ircL-h[2]

inL,h[l]

Ratio

F
T
F
T

T
T

2
3 asymmetric

The irq_h[4 .. 3J bits encode the delay, in CPU clock cycles, from the "system clock" teo sysClkOut2.
Table 3-5:

System Clock Delay

ircL.h[4]

inL-h[3]

Delay

F
T
F
T

F
T
T

3.2.3

2
3

Initialization and Diagnostic Interiace

After the reset_l signal is deBlsserted, but before NVAX Plus executes its first instruction, the
Pcache is written with bits Ollt of a serial ROM (such as an AMD Am1736). The serial ROM
contains enough VAX code to complete the configuration of the external interface, e.g. setting the
tinting on the external cache :R.AM:s and diagnose the path between the CPU chip and the real
ROM.

DIGITAL CONFIDENTIAL

External Interface

3-5

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Three signals are used to interface to the serial ROM. The sRomOE_l output signal supplies the
output enable to the ROM, serving both as an output enable and as a reset (refer to the serial
ROM specifications for details). The sRomCIk_h output signal supplies the clock to the ROM that
causes it to advance to the next bit. The ROM data is read by NVAX Plus via the sRomD_h input
signal. The format of the bits in the serial ROM is tbd , however driving sRomD_h false clears
the Pcache.
Once the data in the serial ROM has been loaded into the Pcache, sRomD_h can be used for a
serial input line, and sRomClk_h can be used as a serial output line.
It is possible to override the loading of the entire Pcache by driving the icMode_h<O> signal true
when reset is asserted. If icMode_h<O> (sRomFast) is asserted the SROM is not copied to Pcache
and the first instruction is fetched from address E0040000(16), the console start address. This
f~ture is also used for test purposes to minimize chip tester time.

3.2.4

Address Bus

The tristate, bidirectional adr_h pins provide a path for addresses to flow between NVAX Plus
and the rest of the system. The adr_h pins are connected to the buffers that drive the address
pins of the external cache RAMs, and to the transceivers that are located between CPU local
address bus and the CPU module address bus.
The address bus is normally driven by NVAX Plus. NVAX Plus stops driving the address bus
during reset and during external cache hold. In these states the address bus acts like an input,
and the tagEq_l output is the result of an equality compare between adr_h and tagAdr_h. Only
bits that are part of the cache tag, as specified by the Be_SIZE field of the BIU_CTL IPR,
participate in the compare.
**The NVAX Plus tagEq_l determination does not include tagAdr parity.**

3.2.5

Data Bus

The tristate, bidirectional data_h pins provide a path for data to flow between NVAX Plus and
the rest of the system. The data_h pins connect directly to the I/O pins of the external cache data
RAMs and to the transceivers that are located between !\TVAX Plus local data bus and the CPU
module data bus.
The tristate, bidirectional check_h pins provide a path for check bits to flow between the CPU
and the rest of the system. The check_h pins connect directly to the I/O pins of the external
cache data RAMs and to the transceivers that are located between the CPU local check bus and
the CPU module check bus. In "P\T" mode the check_h pins do not drive when the data_h pins
are driving write data, allowing the PV byte parity generation logic to drive the check_h lines for
byte parity. The check_h lines not used for parity are contain receivers and should be pulled up.
The check_h are not connected at wafer probe due to contraints in the number of signal which
can be probed. If the test_mode_h pin is asserted internal pull ups for check[27 .. 0] are enabled.
The data bus is driven by NVAX Plus when it is running a fast write cycle on the external caches,
and when some type ·of write cycle has been presented to the external interface and external logic
has enabled the data bus drivers (via dOE_I).

3-6

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

If NVAX Plus is in ECC mode then the check_h pins carry 7 check bits for each longword on
the data bus. Bits check_h[G .. OJ are the check bits for data_h[3l..0). Bits check_,h[13 .. 7) are the
check bits for data_h[63 .. 32). Bits check_h[20 .. 14J are the check bits for data_h[9S .. 64J. Bits
check_h[17 ..21J are the check bits for data_h[127 .. 96).
The following ECC code is used. This code is the same one used by the IDT49C460 and
AMD29C660 32-bit ECC gene~rator/checker chips.

dddddddddddddddddddddddddddddddd
332:::::2::2ll111111110000000000
109876543:1098765432109676543210
c: 6 XOP, x,,:x,j:x,j:Y,j;
Y..xl:x,j:X7.z
c5 XOR XXJO:YJ.XJ:
xxxxy.x:c:
c4
XOP, x,,;
:lo:X7.xxx
x,,;
xxxx:r.x
c:3 XNOR
x."O;
XY.Y.
xx xv.
'::lo".Y.
Xl:
c,~ XNOR ,; x
Xl; ,;
xx xx x xx x xx x
c:l
XOR
,: j: x x j: xxx
:Yo x ,; x ,; :lo:x,j:
cO
XOR j; j~; j;
j; X7.z
x
x XXXl; x
x

By arranging the data and check bits correctly, it is possible to arrange that any number of errors
restricted to a 4-bi t group can be detected. One such arrangement is as follows:
cJ f 00), d f OlJ ,
0·10:), d f 04 J,
d [05J, d[07],
o [08), df09J,
d.[10j, d[13],
d. [16), d[17],
0[18], d[:3),
d(20), d [27],
o[:lJ, d[:6J,
d(24), d (29),

d f 03],
df06J,
d(12),
dIll],
d[15),
d [2:],
d[30),
e [04),
c [0: J,
d[31J

d 125J
e [06J
e[03J
0[14J
d 119]
dl2SJ
c [05]
c [00)
e [01)

If NVAX PI us is in PARITY m()de then 4 of the check_h pins carry EVEN parity for each longword
on. the data bus, and the rest of the bits are unused. Bit check_h[OJ is the parity bit for data_
h[3l..0). Bit check_h[7) is the parity bit for data_h[63 .. 32]. Bit check_h[14) is the parity bit for
data_h[95 .. 64]. Bit check_h[21) is the parity bit for data_h[127 .. 96].
IfNVAX Plus is in "PV" mode then check_h[3 .. 0J are the byte parity bits for data_h[3l..0], check_
h[10 .. 7) are the byte parity bits for data_h[63 .. 32], check_h[l7 .. 14J are the byte parity bits for
data_h[9S .. 64), check_h[24 ..2l) are the byte parity bits for data_h[127 ..9G). The four byte parity
bits for each longword are 'xo:red' to produce a single longword parity bit.
The ECC bit in the BIU_CTL IPR determines ifNVAX Plus is in ECC mode or in, PARITY mode.

3.2.6

External Cache Control"

The external cache is a direct-mapped., write-back cache. NVAX Plus always views the external
cache as having a tag for each 32-byte block <the same as the NVAX Plus Pcache).
The external cache tag RAMs are located between NVAX Plus' local address bus and NVAX Plus'
tag inputs. The external cache data RAMs are located between the CPU's local address bus and
the CPU's local data bus. NVAX Plus reads the external cache tag RAMs to determine if it can
complete a cycle without any module level action, and NVAX Plus reads or writes the external
cache data RAMs if, in fact, this is the case.

DIGrTA~L CONFIDENTIAL

Externallntertace

3-7

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

A cycle requires no module level action ifit is a non-LDxL read hit to a valid block, or a non-STxC
write hit to a valid but not shared block when not in "PV' mode. All other cycles require module
level action. All cycles require module level action if the external cache is disabled (the Be_EN
bit in the BIU_CTL IPR is cleared).
All NVAX Plus controlled cycles on the external cache have fixed timing, described in terms of
NVAX Plus's internal clock. The actual timing of the cycle is programmable allowing for flexibility
in the choice of CPU clock frequencies and cache RAM speeds.
The external cache RAMs can be partitioned into three sections; the tagAdr RAM, the tagCtl RAM,
and the data RAM. Sections do not straddle physical RAM chips in non "PV' mode systems.
NOTE

For "PV' mode systems since NVAX Plus only reads from the tagAdr RAM and tagCtl
RAM these sections can be implemented in the same RAM chips.
3.2.6.1

The TagAdr RAM

The tagAdr RAM contains the high order address bits associated with the external cache block.,
along with a parity bit. The contents of the tagAdr RAM is fed to the on-chip address comparator
and parity checker via the tagAdr_h and tagAdrP_h inputs.
NVAX Plus verifies that tagAdrP_h is an E'VEN parity bit over tagAdr_h when it reads the tagAdr
RAM. NVAX Plus asserts c%cbox_hard_error if the parity is wrong and stops the reference.
The number of bits of tagAdr_h that participate in the address compare and the parity check is
controlled by the BC_SIZE field in the BIU_CTL IPR. The tagAdr_h signals go all the way down
to address bit 17, allowing for a 128Kbyte cache built out of RAMs that are 8K deep.
The chip enable or output enable for the tagAdr RAM is normally driven by a two input NOR gate
(such as the 74AS805B). One input of the two input NOR gate-is driven by tagCEOE_h, and the
other input is driven by external logic. NVAX Plus drives tagCEOE_h false during reset, during
external cache hold, and during any external cycle. The OE bit in the BIU_CTL IPR determines
if tagCEOE_h has chip enable timing or output enable timing.
3.2.6.2

The TagCtI RAM

The tagCtl RAM contains control bits associated with the external cache block, along with a
parity bit. NVAX Plus reads the tagCtl RAM via the three tagCtl signals to determine the state
of the block. NVAX Plus writes the tagCtl RAM-via the three tagCtl signals to make blocks dirty.
N'VAX Plus verifies that tagCtlP_h is an E'VEN parity bit over tagCtlV_h, tagCtlS_h, and tagCtlD_
h when it reads the tagCtl RAM. NVAX Plus asserts c%cbox_hard_err if the parity is wrong and
stops the reference. NVAX Plus computes E'VEN parity across the tagCtlV_h, tagCtlS_h, and
tagCtlD_h bits, and drives the result onto the tagCtlP_h pin, when it writes the tagCtl RAM.
The following combinations of the tagCtl RAM- bits are allowed. Note that the bias toward
conditional write-through coherence is really only in name; the tagCtlS_h bit can be viewed
simply as a write protect bit.

3-8

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 3-6:

Tag Control Encc)dlngs

tagCtlV_h

tagCtlS_h

tagCtlD_h

Meaning

X
F
F

X
F

Invalid
Valid, private

Valid, private, dirty

T
T

Valid, shared

Valid, shared, dirty

T
T
T
T

NVAX Plus can satisfy a read probe if the tagCtl bits indicate the entry is valid (tagCtlV_h =T).
NVAX Plus can satisfy a writE~ probe if the tagCtl bits indicate the entry is valid and not shared
(tagCtlV_h =T, tagCtlS_h =F).
The chip enable or output enable for the tagCtl RAM is normally driven by a two input NOR gate
(such as the 74AS805B). One input of the two input NOR gate is driven by tagCEOE_h, and the
other input is driven by .extenlallogic. NYAX Plus drives tagCEOE_h false during reset, during
external cache hold, and during any external cycle. The OE bit in the BIU_CTL IPR determines
if tagCEOE_h has chip enable timing or output enable timing.
The write enable for the tagCtl RAM is normally driven by a two input NOR gate (such as the
74AS805B). One input of the 1;wo input NOR gate is driven by tagCtlWE_h. and the other input
is driven by external logic. NVAX Plus drives tagCtlWE_h false during reset, during external
cache hold, and during any external cycle.
3.2.6.3

The Data RAM

The data RAM contains the ac:tual cache data, along with any ECC or parity bits.
The most significant bits of the data RAM address are driven, via buffers, from the address bus.
The least significant bit of thE~ data RAM address is driven by a two input NOR gate (such as
the 74AS805B). One of the inputs of the two input NOR gate is driven by dataA_h[4), and the
other input is driven by extenlal logic. NVAX Plus drives dataA_h[4J false during reset, during
extenlal cache hold, and during any extenlal cycle.
The chip enables or output enables for the data RAM are driven by a two input NOR gate (such
as the 74AS805B). One input of the two input NOR gate is driven by dataCEOE_h[3 ..0), and
the other input is driven by E~xternal logic. NVAX Plus drives dataCEOE_h[3 .. 0J false during
reset, during external cache hold, and during external cycles. (NVAX Plus sometimes drives
dataCEOE_h[3 .. 0J true during extenlal write cycles, to simplify merging old cache data with new
write data). The OE bit in the BIU_CTL IPR determines if dataCEOE_h[3 .. 0J has chip enable
timing or output enable timing.
The write enables for the data RAM are normally driven by a two input NOR gaite (such as the
74AS805B). One input of the two input NOR gate is driven by data WE_h[3 .. 0), and the other
input is driven by external logic. NVAX Plus drives data WE_h[3 .. 0J false during reset, during
external cache hold, and durin.g any extenlal cycle.

DIGrTAL CONFIDENTIAL

External Interface

3-9

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

3.2.6.4

Backmaps

Some systems may wish to maintain backmaps of the contents of the Pcache to improve the
quality of their invalidate filtering. NVAX Plus must maintain the backmaps for external cache
read hits, since external cache read hits are controlled totally by NVAX Plus. External logic
maintains the backmaps for external cycles (read misses, invalidates, and so on).
The backmaps are only consulted by external logic, so that their format, or, for that matter, their
existence, is of no' concern to NVAX Plus. All NVAX Plus does is generate backmap write pulses
at the right time. Simple systems will not bother to maintain backmaps, will not connect the
backmap write pulses to anything, and will generate extra invalidates.
The NVAX Plus Pcache is 8kB and can be configured as either a single set of 256 indexes, or two
sets of 128 indexes each. If NVAX Plus is allocating Pcache as two way s-et associative NVAX
Plus drives pMapWE_h[O] or pMapWE_h[l] depending on the Pcache set which is to be allocated
whenever it fills the Pcache from the external cache, and systems must assert the corresponding
plnvReq_h[l:O] to invalidate an entry in Pcache.
If NVAX Plus is allocating Pcache as direct mapped pMap'WE_h[O] is driven and systems assert
plnvReq_h[OJ to invalidate an entry in" Pcache.

The pMap'WE_h[l..OJ signals assert two .cpuClkOut cycles into the second (ast) data read cycle
and negate at the end of that cycle.
3.2.6.5

External Cache Access

The external caches are normally controlled by NVAX Plus. Two methods exist for gaining access
to the external cache RAMs.
3.2.6.5.1

HoldReq and HoldAck

The simple method for external logic to access the external caches is to assert the holdReq_h
signal.
A holdReq_hlholdAck_h sequence can happen at any time, even in the middle of an external cycle.
All of the acknowledge-like signals (dOE_I, dRAck_h, cAck_h) work normally. The system logic
can use this functionality to maintain cache coherency operations while a system read/write is in
progress.

If the NVAX Plus ARB sequencer is 'IDLE' and a HoldReq is received, the HoldAck signal is
asserted. with the next rising edge of SysClkOut. NVAX Plus discontinues cache cycles if the
HolReq signal is recognized before the tag compare is completed. The NVAX Plus ARB sequencer
enters a 'stall' state in which HoldAck is asserted. If a read or write sequence is in progress
and has advanced beyond the tag compare cycle, the operation is completed. For read hits the
second octaword of data is read and the hold is acknowlegded as the block is being filled to
the Pcache. For read misses the CREQ of read_block or LD_LK is driven to the system. The
hold is then acknowledged, allowing the system to access the Bcache. For write hits the write
completes and the hold is acknowledged in the next ARB cycle, which is an 'IDLE' before the next
operation can be dispatched. For write misses (or writes which do not probe Bcache), the CREQ
of write_block or STxC is driven to the system . .As for system reads, the hold is acknowledged
allowing the system access to the Bcache before completing the NVAX Plus write operation. 'When
HoldAck is asserted, NVAX Plus tri-states adr_h, tagCtlV_h, tagCtlS_h, tagCtlD_h, and tagCtlP_
h, drives tagCEOE_h, tagCtl'WE_h, data CE OE_h, data'WE_h, and dataA_h false, (the cReq_h

3-1 0

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus Cl?U Chip Functional Specification, Revision 0.:-1, October 1991

and cWMask_h signals are not modified in any way). Note data_h (and check_h if not "PV') are
driven only if dOE_l is assertes during a write_block or STxC cycle; dOE_l needs to be deasserted
to tristate data_hUcheck_h) during system write operations. When external logie is finished with
the external caches it negates holdReq_h. :NVAX. Plus detects the negation of holdReq_h, negates
holdAck_h, and re-enables its outputs. If the hold is acknowledged after a CREQ has been issued
the system must then complete the operation and respond with the appropriate cAck. When
HoldReq_h is received the address bus begins driving in 1 1/2 cpu cycles at internal phase 3
prior to the deassertion of HoldAck_h, and dataOEOE_h<3:0> and tagCEOE_h reassert at phase
2 after the next drive_first cpu cycle (2 114 cpu'cycles for drv_clk =2 cpu cycles, and sys_clk =2
cpu cycles ) if the hold sequence occurred during an idle NVAX Plus cycle. tagCEOE_h reasserts
at phase 2 after the next drive_first cpu cycle if NVAX Plus is stalled in a write probe sequence.
NOTE'

NoTE:tagCEOE_h and dataCEOE_h may deassert one-phase after the assertion of
holdack_h whereas the other signal affected by holdack_h are either deasserted or
tri-stated at the assertion of holdack_h .

.. ** Systems which use tagOK to obtain access to the cache can assert HoldReq with tag OK
deasserted in order to have NVAX Plus tri-state adr_h, data_h, check_h, tagCtlV_h, tagCtlS_
h" tagCtID_h, and tagCtlP_h, drives tagCEOE_h, tagCt]~1E_h, dataCEOE_h, dataWE_h, and
dataA_h false, and asserts holdAck_h. This allows system which do not use external muxing
access to the tag store. **
.
The holdReq_h signal is synchronous, and external logic must guarantee setup and hoid requirements with respect to the system clock. The holdAck_h signal is synchronous to the CPU clock
but phase aligned to the syst.em clock, so it can be used as an input to state machines running
off the system clock.
The delay from holdReq_h assertion to holdAck_h assertion depends on the programming of
the external cache interface, and exactly how the system clock is aligned with a pending external
cache cycle. In the best case the external cache is idle or just about to begin a cycle, and holdAck_
h asserts at the same system clock edge that samples the holdRe~h assertion. The worst case
latency for holdAck_h is three cache access cycles.
3.2.6.5.2

TagOk

The fastest way for external logic to gain access to the external caches is to use the tag Ok_l
signal. TagOk_l is an :NVAX Plus bus interface control signal that allows extemallogic to stall
a CPU cycle on the external c~ache RAMs at the last possible instant. All tradeoffs S'!JlTOunding
the tagOk_l signal have been made in favor of high-performance systems making tagOk_l next
t'o impossible to use in low-en.d systems.
The tagOk_1 signal is synchronous, external logic must guarantee setup and hold requirements
with respect to the CPU clock. This implies very fast logic, since the CPU clock can run at 200
MHz for the binned parts.
The :NVAX Plus ARB sequencer enters a stall state if the deassertion of tagOK_l is detected preventing the completion of a read or write which is in progress. 'When tagOK_L asserts indicating
the Bcache is again controlled by NVAX. Plus any read or write sequence which was previously
stalled returns to the first bus cycle of the sequence. For cache reads if either pMapWE<1:0>
asserts that read is completed. :NVAX. Plus does not tri-state the busses that run between NVAX

DIGITAL CONFIDENTIAL

External Interface 3-11

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Plus and the external cache RAMsC unless HoldReq is asserted). External logic must supply the
necessary multiplexing functions in the address and data path.
.
If the tagOk_l signal is true at the falling edge of the CPU_CLK prior to a cache cycle, the
el..'ternal logic is guaranteeing that the tagCtl and tagAdr RAMs were owned by NVAX Plus in
the previous cache_speed cycles, that the tagCtl RAMs win be owned by NVAX Plus in the next
cache_speed cycles, that the data RAMs were owned by NVAX Plus in the previous cache_speed
cycles, and that the data RAMs will be owned by NVAX Plus in the next two cache_speed cycles.
J\TVAX Plus samples the tagOk_1 signal at the very end of the tag read of an external cache cycle.
If tagOk_1 is true then NVAX Plus knows that no conflict is possible between external logic and
its cycle. If tagOk_1 is false NVAX Plus stalls. NVAX Plus knows that there is some kind of
conflict (it may have already happened, or it may be going to happen before NVAX Plus can finish
its cycle). In this case NVAX Plus stalls until tag Ok_l is true (at which time all of the above
assertions are true, which means, in particular, that any address NVAX Plus has been holding on
the address bus all this time has made it through the external cache RAMs), and then it retries
any stalled cache references.

3.2.7

External Cycle Control

NVAX Plus requests an external cycle when it determines that the cycle it wants to run requires
module level action .
.An external cycle begins when NVAX Plus puts a cycle type onto the cReCl-h outputs. Some cycles

put an address on the adr_h outputs, and additional information Oow-order address bits, IID
stream indication, write masks) on the c~TMask_h outputs. All of these outputs are synchronous,
and NVAX Plus meets setup and hold requirements with respect to the system clock.
The cycle types are as follows.
Table 3-7:

Cycle Types

Type

cRe~h[2]

cRe~h[l]

cR.e<t-h[ 0]

F
F
F
F

F
F

F
T

IDLE
not generated-BARRIER
not generated-FETCH
not generated-FETCHM
READ_BLOCK
WRITE_BLOCK
LDxL

STxe

The BARRIER, FETCH and FETCHM cycles are functions generated by EV instructions and are
not generated in NVAX Plus systems.
The READ_BLOCK cycle is generated on read misses. External logic reads the addressed block
from memory and supplies it, 128 bits at a time, to NVAX Plus via the data bus. External logic
may also write the data into the external cache, after writing a victim if necessary.

3-12

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

The 'VRITE_BLOCK cycle is generated on write misses, and on writes to shared blocks. External
logic pulls the 128 bits of write data from NVAX Plus via the data bus, and writes the valid
longwords to memory. The c"WMask_h[7 .. 0J signals for NVAX Plus has either c'WMask[7 ..4] =
0000, or c'WMask[3 ..0] = 0000 during WRITE_BLOCK cycles. If external logic sequences the
dWSel[lJ, l\TVAX Plus drives the same octaword with each dOE_l, and the cWMask bus indicates
which longwords are valid. E:d,ernal logic may also write the data into the external cache, after
writing a victim if necessary.
The LDxL cycle is generated READ_LOCK microinstruction or for writing byte/word data. The
cycle works just like a READ•.BLOCK although the external cache has not been probed (so the
external logic needs to check for hits), ·and the address has to be latched into a locked address
register.
The STxC cycle is generated by the WRITE_UNLOCK microinstruction and for writes of merged
byte/word data. The cycle works just like a WRITE_BLOCK, although the external cache has not
been probed (so .that external logic needs to check for hits), and the cycle can be acknowledged
with a failure status.
On WRITE_BLOCK and STxC cycles the cWMask_h pins supply longword write masks to the
external logic, indicating which longwords in the 3Z-byte block are, in fact, valid. The cWMask_
h[7 .. 0] signals for NVAX Plus has either cWMask[7 .. 4] = 0000, or c'WMask[3 .. 0J = 0000 during
WRITE_BLOCK and STxC cyc:les as NVAX Plus writes at most one octaword per WRITE_BLOCK
or STxC cycle. A cWMask_h bit is true if the longword is valid .. 'WRITE_BLOCK commands can
have any combination of mask bits set.
NOTE: For NVAX PLus STxC I=ycles can have all the mask bits set for the octaword being written,
where STxC cycles for EV can only have combinations that colTespond to· a single longword or
quadword.
On READ_BLOCK and LDxL cycles the cWMask_h pins have additional information about the
miss overloaded onto them. The cWMask_h[l..O] pins contain miss address bits [4 .. 3J (indicating
the address of the quadword that actually missed), which is needed to implement quad word
read granularity to I/O devices. The cWMask_h[2] pin is true if the address is not I/O space
and will be filled to Pcache. Thus c'WMask_h[2] looks like an EV D-stream reference to enable
system logic to backmap the NVAX Plus mixed lID stream Pcache with the D-Map backmap. The
cV\'M.ask_h[3] pin is false for references that are targeted to bank 0 of the on· chip Pcache, and
tnle for references that are ta.rgeted to bank 1 of the on-chip Pcache. The cw:Mask_h[4] pin is
true for I-stream references for use by system logic, i.e. possible I-Stream prefetch to memory.
The cWMask_h[5] pin contains address bit [2], providing longword information for "PV" mode I/O
space reads.
The cycle holds on the external interface until external logic acknowledges it, by placing an
acknowledgment type on the cAck_h pins. The cAck_h inputs are synchronous, and external
logic must guarantee setup and hold requirements with respect to the system clock.
The acknowledgment types are as follows.

DIGITAL CONFIDENTIAL

External Interface

3-13

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table 3-8:

Acknowledgment Types

cAck_h[2)

cAck_h[l]

cAck_h[O]

Type

F
F
F
F

F
F
T

IDLE

HARD_ERROR

SOFT~ERROR

STxC_FAIL
OK

The HARD_ERROR type indicates that the cycle has failed in some catastrophic manner. NVAX
Plus latches sufficient state to determine the cause of the error, and machine checks or initiates
the hard error interrupt.
The SOFT_ERROR type indicates that a failure occurred during the cycle, but the failure was
corrected. NVAX Plus latches sufficient state to determine the cause of the error, and initiates a
soft error interrupt.
The STxC_FAIL type indicates that a STxC cycle has failed. It is UNDEFINED what happens if
this type is used on anything but an STxC cycle.
The OK type indicates success.
The dRAck_h pins inform NVAX Plus that read data is valid on the data bus, and ifECC checking
and correction or parity checking should be attempted. NVAX Plus loads Pcache based for non I/O
space READ_BLOCK and LDxL transactions based on dRAck_h[l). I/O space references' do not
use dRAck_h[l) and are not allocated to the Pcache. The dRA.ck_h inputs are synchronous, and
external logic must guarantee setup and hold requirements with respect to the system clock. If
dRAck_h is sampled IDLE at a system clock then the data bus is ignored. If dRAck_h is sampled
non IDLE at a system clock then the data bus is latched at that system clock, and external logic
must guarantee that the data meets setup and hold with respect to the system clock.
The acknowledgment types are as follows.
Table 3-9:

Read Data Acknowledgment Types

F
T

F
F

T
F

IDLE
OK_NCACHE_NCHK
OK_NCACHE
OK_NCHK
OK

The first non IDLE sample of dRAck_h tells NVAX Plus to sample data bytes [15 .. 0), and the
second non IDLE sample of dRAck_h tells NVAX Plus to sample data bytes [31..16]. Normally
el...~mal logic will drive the second dRAck_h and the cA.ck_h during the same system clock
READ_BLOCK and LDxL transactions may be terminated with HARD_ERROR status before all
expected dRAck_h cycles are received.
It is UNDEFINED what happens if dRAck_h is asserted in a non-read cycle.

3-14

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0..3, October 1991

NVAX Plus checks dRAc~h[OJ (the bit that determines if the block is ECC/parity checked) during
both halves of the 32-byte block. It is legal, but probably not useful, to check only one half of the
block.
NVAX Plus checks dRAck_h[l](the bit that determines if a memory reference is to be cached
or not) during the second half of the 32-byte block. dRack_h[lJ is not necessary for 10 space
references. 10 references are not allocated to Pcache for NVAX Plus.
For 110 reads two dRack assertions are expected, however systems (PV) may return a single
octaword if a c.Ack is asserted at the same sysClkOut_h edge as the single dRack.
The dOE_I inputs tells NVAX Plus if it should drive the data bus. It is a synchronous input,
so external logic must guarantee setup and hold with respect to the system clock. If dOE_l is
sampled true at a system clock then NVAX Plus drives the data bus at the system clock if it has
a WRITE_BLOCK or STxC r'equest pending (the request may already be on the cReq pins, or it
may appear on the cReq pins at the same system clock edge as the data appears). ·If dOE_l is
sampled false at the system cloc,k then NVAX Plus tri-states the data bus on the next system
clock cycle. The cycle type is factored into the enable so that systems can leave dOE_l asserted
unless it is necessary to write a victim.
The dWSel_h inputs of EV a're not needed as NVAX Plus only presents 1 octaword to the data
bus.

3.2.8

Primary Cache Invalidate

E:rternallogic needs to be able to invalidate primary cache blocks to maintain coherence. NVAX
Plus provides a mechanism to perform the necessary invalidates, but enforces no policy as to
when invalidates are needed. Simple systems may choose to invalidate more or less blindly, and
complex systems may choose to implement elaborate invalidate filters.
There are two situations where entries in the on-chip Pcache may need to be invalidated.
The first situation is the obvious one. Any time an external agent updates a block in memory (for
example, an 110 device does a DMA transfer into memory), and that block has been loaded into
the external cache, then the E!xternal cache block must be either invalidated or updated. If that
external cache block has been loaded into a block resident in the Pcache then that Pcache entry
must be invalidated.
External logic invalidates an entry in bank 0 of the Pcache by asserting the plnvReq_h[OJ signal.
NVAX Plus samples pInvReq_h[OJ at every system cloCk. 'When NVAX Plus detects plnvReq_h[O]
asserted, it invalidates the block in bank 0 of the Pcache whose index is on the iAdr_h pins.
External logic invalidates an E~ntry in bank 1 of the Pcache by asserting the plnvReq_h[lJ signal.
NVAX Plus samples plnvReq_h[lJ at every system clock. When NVAX Plus detects plnvReq_h[lJ
asserted, it invalidates the block in bank 1 of the Pcache whose index is on the iAdr_h pins.
If the Pcache is set to direct map allocation only PinvReq[OJ is asserted, iAdr[12J selects the
section of Pcache to be invalidated.
**It is legal to both plnvReqJrl[l..OJ in the same cyele.**
NVAX Plus can accept an invalidate at every system clock.

DIGITAL CONFIDENTIAL

E.xternal Interface

3-15

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

The plnvReq_h[l..O] inputs are synchronous, and external logic must guarantee setup and hold
with respect to the system clock. The iAdr_h inputs are also synchronous, and external logic
must guarantee setup and hold with respect to the system clock in any cycle in which any of
plnvReq_h[l..O] are true.
.

3.2.9

Interrupts

External interrupts are fed to NVAX PI us via the irq_h bus. The 6 interrupts are wired to
IRQ<3;O>, halt, and error. The timer interrupt is internal to NVAX Plus. The interrupts are
asynchronous, and level sensitive.

3.2.10

Electrical Level Configuration

NVAX Plus drives and receives CMOS levels.
The input circuits do not use the vRef input.

3.2.11

Testing

The tristate_l signal, if asserted, calJ,Bes NVAX Plus to fioat all of its pins, with the exception of
the clocks.
The cont_l signal, if asserted, causes NVAX Plus to connect all of its pins to VSS, wit~ the
exception of the clocks, vref, dcOk_h, tristate_I, reseCl and cont_I.

3.3

64-Bit Mode

NVAX Plus does not support the EV 64-bit external mode.

3.4

Transactions

3.4.1

Reset

External logic resets NVAX Plus by asserting reset_I. When NVAX Plus detects the assertion of
reset_l it terminates all external activity, and places the output signals on the external interface
into the following state. Note that all of the control signals have been placed in the state that
allows external access to the external cache.
Table 3-10:

Reset State

State

sRomOE_l

sRomClk_h

adr_h

data_b

check_b

3-16

External Interlace

DIGITAL CONFIDENTIAL'

NVAX Plus CPU Chip Functional Specification, Revision 0.3" October 1991

Table 3-10 (Cont.):

Reset S~ate

State

tagCtlWE_h

F
F

tagCtlV_h

-z

tagCtlS_h

tagCtlD_h

tagCtlP_h

Z
F
F
F
F
FFF
FFFFFFFF

tagCEOE_h

dataCEOE_h
dataWE_h
dataA_h
holdAck_h
cRe~h

c'WMask_h

After asserting reset_l for long enough to reset the serial ROM (100 ns), external logic negates
reset_I.
When NVAX Plus detects reset_l negate, it begins internal initialization. When this initialization
is completed NVAX Plus microcode asserts sRomOE_l, enabling the output of the serial ROM
onto sRomD_h, and then determines if the SROM is to be read by reading the SOE-IE'IPR which
contains the state of icMode<O>(sRomFast) at the deassertion of reset. If sRomfast NVAX Plus
deasserts sRomOE_l and fetches an instruction from address E0040000. If not sRomfast NVAX
Plus begins clocking bits out of the serial ROM and placing them into the Pcache. The timing is
the following (assuming NVAX Plus only read 3 bits from the serial ROM).
reset_l
--------1
sRomOE_l
sRomCli: h
Sample sRomD_h

1-------------------1
---- 1 1----- 1 1----- I 1--

Each half-tick of the sRomClk_h signal is 27 CPU cycles long, which guarantees the minimum
260ns clock high and clock low specifications and the 520ns clock to data specification of the serial
ROM with IOns CPU cycles.
The format for NVAX Plus sROM data is 8 Kbytes of continous data, with the first bit being the
least significant bit of the first byte of the data.
At the deassertion of reset, sRomOE_l is not asserted. The high to low transition of of sRomOE_l
is generated when microcode writes the SOE-IE IPR. This maintains compatability with EVand
allows sRomOE_l to indicate a reset to sROM bit counters if required. The LNP implementatiqn
of the sRom is a parallel ROM and discrete shift registers, using reset_l to initialize the bit
counters.
After asserting sRomOE_I n:ucrocode writes the Pcache TAG IPR Address for pache index
addr<11:5> = 0000000 specifying the left bank (address<12>=O) with a tag<3l:12>=OOOOO(hex)
and thus validating the 32 byte block of Pcache. Microcode then reads the 32 bits of the sROM
shifting the bits into a temporary register until a longword is completed. The bits shifted so

DIGITAL CONFIDENTIAL

External tnterface

3-17

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

that the first bit input is the least significant. SIO<serial_line_out> is hardware cleared at rese( There is an inversion from SIO<serial_line_out> to the sRomClk_h pin, thus the state of
sRomClk_h at reset is high. Microcode reads each bit of the sROM by
1.
2.
3.
4.
5.

writing SIO<serial_line_out> with 0 to set sRomClk_h to a high
waiting 27 CPU cycles to insure sRomClk_h is high "for 260ns for a IOns part
writing SIO<serial_line_out> with 1 to set sRomClk_h to a low
waiting 27 CPU cycles to insure sRomClk_h is low for 260ns for a IOns part
reading the IPR for SIO<serial_line_in>

The sROM uses the high to low transition of sRomClk_h to load it's output register and the low
to high transition of sRomClk_h to shift to the next bit. Initializing sRomClk_h to a high results
in the first edge of sRomClk_h being high to low, thus loading the initial ROM outputs to the
output shift register. Since the low to high transition of sRomClk_h is an input to a shift register,
the processor loads the the output register and then inputs the first bit before the first shift clock
edge is driven.
After the first 32 bits are read, microcode writes the longword to addr<31:0>=000000000(hex),
The write hits in the Pcache and the first longword is written to the Pcache data section. The
write data is also written through the CBOX. This write will be packed with the next longword
and be put into the Write Queue. External Write Commands are removed from the Write Queue
by the Arb Sequencer when sRomOE_I is asserted but are not written to memory, preventing the
writing of the sROM data.
.
The next 32 bits are read. The second longword is then written to addr<31:0>=00000004. The
next 32 bits are read, the third longword is written to addr<31:0>=00000008. Longwords 4,5,6,7,
and 8 are written to address C, 10, 14, 18, and lC. After the first 8 longwords are written,
microcode writes the Pcache TAG IPR Address for pache index addr<11:5> = 0000001 specify:i.D:g
the left bank (address<12>=O) with a tag<31:12>=00000(hex) and thus validating the second 32
byte block of Pcache. Again 8 longwords are read from the sROM and wriiten to the Pcache block
with the address being incremented by 4 bytes after each write. After the first 4 kbytes of data
has been written to the PCache, microcode writes the Pcache TAG IPR Address for pache index
addr<11:5> = 0000000 specifying the right bank (address<12>=l) with a tag<31:12>=00001(hex)
and thus validating the first 32 byte block of Pcache for that bank. The next 4 kbytes are then
loaded to the right bank with a tag<31:12>=00001(hex). Thus the sROM data is places into NVAX
Plus Pcache as
Write Pcache TAG IPR. tag<31:12>=00000(hex), bank=O, index=OOOOO
set up initial addr<3l:0>=00000000(hex)
read longword from sROM
write longword to addr<31:0>
add 4(hex) to addr<31:0>
if addr<4:2> not 000 repeat step 3
after 8 longword writes addr<4:2>=000, 32 byte block completed, increment index
if index not 000000, bank is not completed, write TAG IPR of next index, go to step 3
if index=OOOOOO and bank=O, set bank= 1 for second 4 kbyte bank, write TAG IPR, go to step
3
10. ifindex=OOOOOO and bank=l, sROM load is done
1.

2.
3.
4.
5.
6.
7.
8.
9.

3-18

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3'1 October 1991

After completion of the sROM load, microcode initiates a macrocode fetch of the first instruction
from addr<31;O>=OOOOOOOO.

3.4.2

Fast External Cache Read Hit

'A fast external cache read consists of a probe read (overlapped with the first data read), followed
by a compare cycle and then a second data read. If the probe hits and tagOK_l is asserted and
HoldReq is deasserted (i.e. no stall) the pMapWE_h of the allocated PCache set is driven.
The following diagram aSSUDles that the external· cache is using 4X cache_speed timing, chip
enable control (OE_HlCE_L =: L).
CPU CYCLE
c:pu_clk
phas~

ad:- h

clat.aA h[4j
't~agcEoE_h

tagCt.1WE h

10
11
12
13
14
15
16
15 16 Ii
18 19 110 III I
10 11 12 13 14
1 2 3 4 1 2 3 4 1 : 3 4 1 2 3 4 1 2 3 4 1 234

1-------------··------------------------------------I
1-------------------1
1------------_··_--- I
-J:am-I
-ram-I

t.agAdr_t:t.agCt.l h

pMapWE-h
dat.aCEOE h
ciat.aWE_hc1at.a_i:

1-------1

1--------------------------------------------------1
-ram-l-I
-ram-1-1

-=arn-O-I
-rarll-O-I

c:hecy._h

If the probe misses then pMap~TE_h does not assert, and the sequence aborts at the end of CPU

CYCLE 2.
The address is driven from phase 3 prior to CPU CYCLE 0 and the data is latched at phase 4
of CPU CYCLE 1, providing:9 phases for external access at cache_speed = 4 times the cpu_clk
(2CPU CYCLES).

3.4.3

Fast External Cache Write Hit

A fast external cache write C'.onsists of a probe read, followed by a compare cycle, and then a
single data write.
The following diagram assunles that the external cache is using 2X system clock timing, chip
enable control (OE_HlCE_L =L), and a 1 cycle write pulse starting from cpu clock falling edge.
CPU CYCLE
cpu elY.
pha"i.

lOll
12 13 14 15 16 17 18 I 9 110 III I
3 4 1 2 3 4 1 2 3 ~ 123 4 1 Z 3 4 1 Z 3 4 1 2 3 4
sar h/aat.a.f.. h [4j I -------------•• ------------------------------------------- I
t.agCEOE h t.agCtnlE_h
t.agAdr_h
-J:am-I
t.agCt.l h
-l:am-I
I-cpu-----------I

1-------------··_--- 1

dat.aCEOE_h
dat.aWE_h
dat.a h
chec}:_h

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

I,,-------1
------- I
1-.------1

1-------1

I-cpu------.:----I
I-cpu-----------I

If the probe misses then the cycle aborts at the end of cpu clock cycle 3.

DIGITAL CONFIDENTIAL

External Intertace

3-19

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

3.4.4

Fast External Cache Byte/Word Write Hit

A fast external cache byte/word write consists of a probe read, followed by a compare cycle, a
data merge cycle, and then a single data write.
The following .diagram assumes that the external cache is using 2X system clock timing, chip
enable control (OE_HlCE_L =L), and a 1 cycle write pulse starting from cpu clock falling edge.
lnternal Clock
phase
ad::_h/dztaA_h [4j
tagCEOE h
taaCtlwE h

10
11
12
13
14
15
16
Ii
18
10 11 12 13 I' 15 16 Ii
Ie 19 110 III 112 113 114 115 I
3 , 1 : ~ .:: 1 : 3 4 1 2 3 .:: 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 123 4
1------------------------------------------------------------------1
1-----------------1
1-------1
1-------1

tagAdr_h-

-rani-I

tagC-:'l_h
datsCEOE_h
d2lt2lWE_h
datc_h
checy._h

-ram-I
1-----------------1

I-cpu-----------I
1-------1
1-------1
I-cpu-----------I
I-cpu-----------I

-ram-i
-ram-I

If the probe misses then the cycle aborts at the end of cpu clock cycle 3. If a correctable ECC
error occurs on the read data the write is executed delayed from cpu cycles 6 and 7, to cpu cyles
8 and 9.

3.4.5 Transfer to SysClk. for External tranactions
The r~mainder of the transactions described in this chapter, READ_BLOCK, 'WRITE BLOCK,
LDxL, and STxC, involve the external system logic, and are described with respect to sysClkOutl.
This section describes the delay from the internal cpu cycle which initiates a tranction requiring
external system logic, and SYS_ CLK cycle 0, where cReq_h is driven with the command request.
adr_h and c""Mask are valid prior to the start of SYS_CLK cycle 0.
The :NVAX Plus I/O sequencer runs once every CACHE_SPEED cycles .. If the output of the I/O
sequencer initiates a transaction requiring external logic, the cReq_h command is asserted with
the next rising edge of sysClkOutl_h. For systems with the CACHE_SPEED and sysClkOut both
programmed for 2 CPU cycles, the start of the SYS_ CLK cycle is always one CPU cycle after the
I/O sequencer initiated the tranaction.
I2
13
I .Q
I5
I6
Ii
IB
11
12
13
I
10 11 12 13 14 15 16 Ii 18 19 110 III 112 113114 Il5 I
3 .Q 1 2 3 4 1 2 3 .Q 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 .Q 1 2 3 .Q 1 2 3 4

CPt' CYCLE
I0
I/O SEQUENCER CYCLE 10

cpu_clk
phaSE
SYS CLK Cycle

(2~-sysc1kOut) -----1

1
0
1-------1

1-------1

1---...---1

1-------

+---------< cReq asserts, SYS_CLK Cycle 0
+-----------------< I/O sequencez initiates READ_BLOCK,
WRITE BLOCK
LDxl., STxC.
If CACHE_SPEED and sysClkOut are not programmed to the same multiple of cpu_elk, the delay
to the rising edge of sysClkOutl_h and the assertion of cReq_h may be a full SYS_ CLK cycle.

3-20

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

3.4.6

READ_BLOCK TranSiaction

A READ_BLOCK transaction appears at the external interface for reads which miss in the Pcache
for external cache read misses, either because ithe read really was a miss, or because the external
cache has not been enabled.
SYS_CI.R Cycle
sysClkOutl_h

adr_h
dat.6_h

checy._h
cReC;_h

cWMasy._h
ciRAck_h
CAcy._h

1--- 1

I':

1--- 1

:3
1--- 1

1--- 1

1---------------·.-----------------------....
------1
i-O-----I
1-1-----1
1-0-----1

1-1-----1

1-------1

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

1--------------_··_----------------------I
1--------------_·_-----------------------I

O. The READ_BLOCK cycle begins. NVAX Plus places the address qf the block containing
the miss on adr_h. NVAX Plus places the quadword-within-block and the IID indication on
c'WMask_h. NVAX Plus places a READ_BLOCK command code on cReq_h. The external logic
detects the com~and at the end of this cycle.
1. The external logic obtains the first 16 bytes of data. Although a single stall cycle has been
shown here, there could b~~ no stall cycles, or many stall cycles.
2. The external logic has the :first 16 bytes of data. It places it on the data_h and check_h busses.
It asserts dRAck_h to tell NVAX Plus that the data and check bit busses are valid. NVAX
Plus detects dRAck_h at the end of this cycle, and reads in the first 16 bytes of data at the
same time.
3. Th-e external logic obtains the second 16 bytes of data. Although a single staU cycle has been
shown here, there could be no stall cycles, or many stall cycles.
4. The external logic has thE~ second 16 bytes of data. It places it on the data_h and check_h
busses. It asserts dRAck_h to tell NVAX Plus that the data and check bit busses are valid.
NVAX Plus detects dRAck.•h at the end of this cycle, and reads in the second 16 bytes of data
at the same time. In addition, the external logic places an acknowledge code on cAck_h to tell
NVAX Plus that the READ_BLOCK cycle is completed. NVAX Plus detects the acknowledge
at the end of this cycle. The address remains in the cycles after cAck as NVAX Plus fills
Pcache.
5. Everything is idle on the l~D.AL. NVAX Plus moves fill data to MBOX. A new external cache
cycle does not start until the fill is completed. dataceoe are asserted 1 cpu cycle after cAck is
recognized. by the ARB sequencer.
Note that this picture did not mention the external caches. NVAX Plus drove all of the external
cache control signals false when it placed the READ_BLOCK command on the cReq_h outputs.
The external logic controls thE~ updating of cache.
NVAX Plus performs EOC chl~cking and correction (or parity checking) on the data supplied to
it 'via the data and check bUSHes if so requested by the acknowledge code. It is not necessary to
place data into the external cache to get checking and correction.

. DIGrTAL CONFIDENTIAL

E.xtemal lnterface

3-21

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

3.4.7

Write Block

A ~TR.ITE_BLOCK transaction appears at the external interface on external cache write misses
(either because it really was a miss, or because the external cache has not been enabled (or the
system is "PV'), or on external cache write hits to shared blocks.
SYS_Cl.F~

CYClE

1--- I 1--- i 1--- I I--- I 1--- I 1--- I 11-----------------------------------------------1
1-0-----1
1-0-----1-0-----1
chec-;'-_h(no-: PV)
1-0-----1
1-0-----1-0-----1
cReo_n
1---------------------------------------1
cWMasi: h
1---------------------------------------1
dOE_l i-------I
1-------1-------1
cAcy._h
Innnnnnni
1-------1
sysClkOu-:. h

adr_h
data h

3.
4.

The WRITE_BLOCKcyc1e begins. NVAX. Plus places the address of the block on adr_h. NVAX.
Plus places the longword valid masks on c~"Mask_h. NVAX Plus only write a single octaword
at a time, thus c"W:Mask[7:4] = '0000 if adr_h[4] = '0 or c\VMask[3:0] = '0000 if adr_h[4] =
'1. The dWsel_h from EV are. not needed as NVAX. Plus drives the same octaword at the
assertion of dOE_I.
NVAX. Plus places the ~TR.lTE_BLOCK command code on cReq_h. The external logic detects
the command at the end of this cycle.
The external logic detects the command, and asserts dOE_l to tell NVAX. Plus to drive the 16
bytes of data of the block onto the data bus. Since NVAX Plus only writes a single octaword
the write_block .can be cAck in the same cycle in which is driven. Systems which choose
to handle v.'l"ite_blocks the same for EVAX. and NVAX. Plus will continue the sequence with
NVAX. Plus driving out the same octaword of data. 1\TVAX Plus continues to drive the data in
the system cycle following cack (if dOE_I) providing data hold time. Although a single stall
cycle has been shown here, there could be no stall cycles, or many stall cycles.
If the external logic asserts dOE_l a second time to tell NVAX Plus to drive a second 16 bytes
of data onto the data bus the same octaword is driven.
The external logic places an acknowledge code on cAck_h to tell NVAX Plus that the 'WRlTE_
BLOCK cycle is completed. NVAX. Plus detects the acknowledge at the end oftrus cycle. NVAX
Plus holds the address till the cAck is recognized by the ARB sequencer and a subsequent
bus operation is dispatched.
Everything is idle.

Note that this picture did not mention the external caches. NVAX Plus drove all of the external
cache control signals false when it placed the WRITE_BLOCK command on the cReq_h outputs.
The external logic controls the updating of cache.
NVAX Plus performs ECC generation (or parity generation) on data it drives onto the data bus.
The check_h lines remain tristated for ttpv' systems.

3-22

Exterhal Interface

DIGrTAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

3.4.8

LDxL Transaction

An LDxL transaction appear8 at the external interlace as a result of a READ_LOCK microinstruction or byte/word write which misses in the BCache being executed. The external cache
is not probed.
Sj~S_CLK

Cycl~

svsClkOut h
Bctr_h

123

1--- I 1--- I 1--- " 1--- I I--- I 1--- 1 11---------------··-------------------------------I
1-0-----1
1-1-----1
1-0-----1

dst.!._h
c:hec:k_h
cF<eCZ_h
cv/Masy._h

1--------------_··_----------------------1

dRAcy._h

1-------1

I-l----~I

I-----------~---------------------------I

CAck_h

1.
2.

3.
4.

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

The LDxL cycle begins. NVAX Plus places the address of the block containing the data on
adr_h. NVAX Plus places the quadword-within~block and the ltD indication on cWMask_h.
LDxL cycles for byte/word writes indicate I so that system logic does not enter the block into
the backmap. 1\TVAX Plus places a LDxL command code on cReCl-h. The external logic detects
the command at the end of this cycle.
The external logic obtains the first 16 bytes of data. Although a single stall cycle has been
shown here, there could be no stall cycles, or many stall cycles.
The external logic has the first 16 bytes of data. It places it on the data_h and check_h busses.
It asserts dRAck_h to tell NVAX Plus that the data and check bit busses are valid. NVAX
Plus detects dRAck_h at the end of this cycle, and read in the first 16 bytes of data at the
same time.
The external logic obtains the second 16 bytes of data. Although a single stall cycle has been
shown here, t}:lere could be D:o stall cycles, or many stall cycles.
The external logic has the: second 16 bytes of data. It places it on the data_h and check_h
busses. It asserts dRAck_h to tell NVAX Plus that the data and check bit busses are valid.
NVAX Plus detects dRAck._h at the end of this cycle, and read in the second 16 bytes of data
at the same time. In addition, the external logic places an acknowledge code on cAck_h to
tell NVAX Plus that the LDxL cycle is completed. NVAX Plus detects the acknowledge at the
end of this cycle, the address holds while the data is either being loaded to Poache or merged
for a STxC to complete the byte/word write sequence.
Everything is idle.

Note that with the exception of the command code output on the cReq pins, the LDxL cycle is the
same as a READ_BLOCK cycle.

3.4.9

STxC Transaction

An STxC transaction appears at the external interface as a result of a WRITE_UNLOCK micro_
instruction or byte/word write in which the initial read probe missed in the BCache. The external
cache is not probed.

DIGITAL CONFIDENTIAL

External Interface

3-23

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

I
0
I 2
I 3
I
I
S
I
1--- I
1--- I
I--- I
I--- 1
I--- I
I--- I
11-----------------------------------------------1
dats_h
1-0-----1
1-0-----1-0-----1
checy._h(not PVi
1-0-----1
1-0-----1-0-----1
SYS_CLK Cycle

svsClkOut h

ad!" h

cReo__h
cWMasy. h
dOE_l -

i---------------------------------------I
1---------------------------------------1
1-------1
1-------1-------1

c:ACk_h

Innnnnnni

1-------1

The STxC cycle begins. NVAX Plus places the address of the block on adr_h. NVAX Plus
places the longword valid masks on cWMask_h. NVAX Plus places an STxC command code
on cReq_h. The external logic detects the command at the end of this cycle.
The external logic detects the command, and asserts dOE_l to tell NVAX Plus to drive the 16
bytes of the block onto the data bus.
NVAX Plus drives 16 bytes of write data onto the data_h and check_h busses, and the external
logic writes it into the destination. Since NVAX Plus only writes a single octaword the write_
block can be cA.ck in the same cycle in which is driven. Systems which choose to handle
write_blocks the same for EVAX and NVAX Plus will continue the sequence with NVAX Plus
driving out the same octaword of data. NVAX Plus continues to drive the data in the system
cycle following cack (if dOE_I) providing data hold time. Although a single stall cycle has
been shown here, there could be no stall cycles, or many stall cycles.
The external logic asserts dOE_l and dWSel_h to tell NVAX Plus to drive the second 16 b~s
of data onto the data bus. NVAX continues to drive the same octaword of data. The cWMask_
h output indicates which octaword contains the write data.
NVAX Plus drives the same octaword of write data onto the data_h and check_h busses, and
the external logic writes it into the destination. Although a single stall cycle has been shown
here, there could be no stall cycles, or many stall cycles. In addition, the external logic places
an acknowledge code on cA.ck_h to tell NVAX Plus that the STxC cycle is completed. NVAX
Plus detects the acknowledge at the end of this cycle. NVAX Plus holds the address till the
cA.ck is recognized by the ARB sequencer and a subsequent bus operation is dispatched.
Everything is idle.

Note that with the exception of the code output on the cReq pins, and the fact that external logic
has the option of making the cycle fail by using a cA.ck code of STxC_FAIL, the STxC cycle is the
same as the WRITE_BLOCK cycle.

3.4.10

BARRIER Transaction

NVAX Plus does not generate the BARRIER transaction.

3.4.11

FETCH Transaction

NVAX Plus does not generate the FETCH transaction.

3.4.12

FETCHM Transaction

NVAX Plus does not generate the FETCHM transaction.

3-24

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus C:PU Chip Functional Specification, Revision 0.3, October 1991

3.5 Summary of NVAX Plus options
The l\TVAX Plus chip can be used in system platforms intended for the EV processor chip (LASER,
COBRA., Flamingo). In addition NVAX Plus has an optional mode "PV" for use in systems in which
NVAX Plus is a replacement for the Mariah CPU. This section summarizes the key features which
are implemented by the NVAX Plus chip pertaining to system eonfiguration.

3.5.1

System Clock Divisors

The sysClkOut period, the number of CPU cycles per sysCl~Out cycle, is determined from IRQ
fines at reset.
•

•
•

3X ASYMMETRIC (COBRA)
4X SThfMETRIC CLOCK >40NS PERIOD FOR FLAMINGO

3 .. 5.2

Cache Access

. The Cache access time can be set to 2,3, OR 4 CPU cycles, from BIU_CTL<BC_SPD>.

3.5.3

Flamingo 1/0 Addres:s Mapping

1/0 space addresses can be mapped to Flamingo 'sparse' and 'dense' space by setting BIU_

CTL[WS_I 0 J.

3.5.4

Direct Mapped Pcache

The NVAX Plus chip can support a two-way set associative or direct-mapped Pcache as selected
from BIU_CTL<PCACHE_MODE>. This allows systems to backmap the Pcache exactly as the
Dcache for EV by selecting the direct-mapped option. When the direct-mapped option is selected
allocate to a Pcache bank are based on address<12> instead of allocate bit. To support the directmapped option the MBOX allocates fills to the bank Pcache bank selected by the Miss latch
latch for two-way associative operation and address<12> for direct-mapped oper,ation. In direct·
mapped mode the CBOX sends an invalidate request to the MBOX for bank 0 if iAdr<12> = 0,
and sends an invalidate request to the MBOX for bank 1 if iAdr<12> = 1.

ad.r<33:32> for I/O space refE~rences is selected from BIU_CTL<14:13>. I/O space for LASER
systems requires adr_h<33:32>=11, for COBRA systems adr_h<33:32>=10, and for Flamingo systems adr_h<33:32>=Ol. The BIU_CTL register field allows for 10 space mapping of different
systems.

DIGfTAL CONFIDENTIAL

External lnterface

3-25

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

3.5.6

OW I/O WRITES/MTPR MAILBOX

Writes to the LMBPR require more than 32 bits, i.e. bits <39:32> =00000000. In order to pack
more than a longword to an I/O space a "pack_even_for_1I0" function can be enabled by writing
to IPR B8. This function can be disabled by a subsequent write to IPR B9. For the MTPR
:MAILBOX instruction, the write to the LMBPR is done under microcode control. iPR B8 is
written to enable to I/O space quadword packing. Two longwords which make up the ME_AD DR
(address of mailbox data structure) are then written. IPR B9 is written to clear the 110 packing
function.
The 110 pack function can be enabled with a MTPR B8 and can be disabled with a MTPR B9. For
writes to 110 space other than to the LMBPR where a quadword write is required (e.g. COBRA
systems) use the following macrocode sequence while in kernel mode.

•

•
•
•
•
•

MFPR #PR$_IPL,-(SP)
MTPR #31,#PR$_IPL
MTPR #O,enable_io_pack
MOVQ R,y
MTPR #O.disable_io_pack
MTPR (SP)+,#PR$_IPL

The followi;ng restrictions need to be met to write quadword 10.
1.
2.
3.
4.

3.5.7

The source mode for the MOVQ to 10 space transaction must be register
The MOVQ and MTPR B9 must be aligned to a 32-byte block
The MOVQ destination must be quadword aligned
The page where the quadword I/O is to be written cannot encounter an AC'V or TNV memory
management exception. (A TB miss is allowed)

OW I/O READS

For systems which contain quadword CSRs (Control Status Register) in I/O space (COBRA), a single
quadword read is necessary in order to obtain consistent data for the CSR. When **BIU_CTL<QW_
IO_RD> = 1** ,
1. a the high_LW register is loaded with data<63:32> of any I/O read
2. 110 reads with address<2> ='1 (not QW aligned) are converted to an IPR_RD of the high_LW
register and data returns on dat<31:0>

3.5.8

PV mode

PV mode supports write-through caching and byte writes.
Write-through caching is supported by having writes not write Bcache directly.
•
•

3-26

the ARB sequencer dispatches directly to 'SYS_WR' if "PV' mode
check_h<27:0> output drivers remain tristated for writes, parity/ecc not needed on "PV'
writes; PV system logic must generate byte parity.

External Interface

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0 ..3, October 1991

PV mode supports byte writes, c'WMask_h drives the byte mask instead of a longword mask.

•
•

dataA_h<3> indicates for which QW the cWlv.task_h lines are the byte mask
data \VE<1:0> contain byte mask informatiom for the QW not addressed by dataA_h<3>

Other features of PV mode
•
•
•
•

•

3.6

on reads combine byte p.arity on check bits into LW parity, by providing xor tree for 4 check
bits for each LW being input, for conversion into single LW parity bit
address<2> ->c'WMask<S>; needed to specify 10 space read addresses to the LW
dataA_h[4J tristates on read_blockILD_LK enabling PV system to control octaword address
for Bcache fills.
PV systems can respond to 110 space reads with a single dRack provided cAck is also sent at
the same sysClkOut
supports byte/word write to I/O space within same LW address

Revision History

Table 3-11:

Revision Htstolry

'Who

When

Description of change

Gil Wolrich

15-Nov-1990

NVAX PLUS release for external review.

Gil Wolrich

15-Jan-1991

Remove Vector references/update.

Gil Wolrich

S-Apr-1991

Include PV options/update.

Gil Wolrich

l-Aug-1991

update.

DIGITAL CONFIDENTIAL

External Intertace

3-27

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Chapter 4
. Chip Overview

NVAX Plus CPU Chip E~ox and Section Overview

4.1

The NVAX Plus 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, :z..way set associative, physicallyaaddressed, write through, mixed
instruction and data strealIl
Instruction Cache: 2 KJ8, clirectamapped, virtUally addressed, instruction stream only
Translation Buffer: 96 .~ntries, fully associative
Floating Point: 4 stage, pipelin~, integrated floating point unit
.EDAL Interface: Support for six cache sizes (4MB, 2MB, 1MB, 512KB, 256KB, 128KB),
and four RAM speeds.

The NVAX chip is designed in CMOS-4 with a typical cycle time of 14 ns, 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 macropipelineci design.: it pipelines macroinstruction decode and o-perand 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
running smoothly, the Ibox (instruction parser/operand fetcher) is running several macroinstructions ahead of the Ebox (execut.ion 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.
This chapter gives an overview of the different sections, or "boxes", that comprise the NVAX Plus
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.

DIGfTAL CONFIDENTIAL

Chip C)verview

4-1

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 4-1:

NVAX Plus CPU Btock Diagram

IBOX

I%IBOX IW BUS H.
1°;'OPEF\;\ND:eus~

E%IBOX 1,1.. BUS
E%80 ~TI'F!E' R

E°;.OO:FlETlFlE·,)1

~%MD_BUS_H

"........-l"--l,

"----

FBOX

USEO

MBOX

EO""ABUS HL_--r~....J-1
E%BBUS_"J.<
IBOX

CBOX

......
1
_ __

I
NDAL. _ _--.1._ __

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 !box prefetches instruction stream data. into the prefetch queue (PFQ) , which can hold 16
bytes. The !box has a dedicated instruction· stream-only cache, called the virtual instruction cache
(VIC). The VIC is a 2 KB, with a block and fill size of 32 bytes.
The !box 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 !box 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.

4-2 . Chip Overview

DIGITAL CONFIDENTIAL

NVAX Plus C:PU Chip Functional Specification, Revision 0.8, October 1991

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 infOrIIlation 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 Micrc)sequencer

l'be Ebox and MicrosequenCE!r 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 Icontains the actual operand value. In the case of register, memory,
a.nd immediate type operands, th~ source queue holds a pointer to the data in t.he 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%VA_BUS and
E%WBUS.

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.
'Ihe 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 specia.lized hardware features in order to speed the execution of certain
VAX instructions: the population counter (CALLx, PUS Em, 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 staged pipelined execution unit for the floating point and integer
multiply instructions. Operands are supplied by the Ebox up to 64 bits per cycle on E%ABUS and
E%BBUS. Results are returned to the Ebox 32 bits per cycle on F%RESULT. The Ebox is responsible
for storing the Fbox result in memory or the GPRs.

DIGfTAL CONFIDENTIAL

Chl'p Overview 4-3

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 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 whlch 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 TE. 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 aKB, writethrough, with a block
and fill size of 32 bytes.
The Pcache can be configured at reset to be either direct mapped or 2-way set associative.
The Pcache state is maintained as a subset of the Backup Cache. System logic, possibly using
backmaps, is responsible for insuring the Pcache is maintained as a subset of the Backup Cache.
The Mbox ensures that Ibox specifier reads are ordered con-ectly 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 initiates access to the second level cache (the Backup Cache, or Bcache), and issues
memory requests. Both the tags and data for the Bcache are stored in off-chip RAMs. The size and
access time pf the Bcache R.Alv.1s can be configured as needed by different system enVironments.
The Bcache sizes supported are 4 ME, 2 ME, 1 ME, 512 KB, 256 KB, and 128 KB. System logic
is responsible for BCache tills and coherency functions. The Cbox packs sequential writes to the
same octaword in order to minimize Bcache write accesses. Multiple write commands are held
in the eight-entry 'VRITE_QUEUE.

4.1.6

Major Internal Buses

This is a list of the major interbox buses:
•

Bo/d36_DATA:

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:

This bus is used to transfer the physical address of a Pcache invalidate from the Cbox to the
MBox.
•

Eo/cABUS, E%BBUS:

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.
•

E%mOX_IA...BuS:·

This bus is used by the Ibo~ 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.
4-4

Chip Overview

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

•

E%DQ..,RETIRE*:

This collection of related buses transfers information from the Ebox to the Ibox when a destination queue entry is retired.

•

E%SQ..,RETIRE*:

This collection of related buses transfers information from the Ebox to the Ibox when a source
queue entry is retired.

•

E%V~BUS:

This bus transfers an addr~~ss from the Ebox to the MBOx.

•

E%WBUS:

This 32-bit bus transfers wcite data from the RMUX to the register file and the Mbox.

•

E_USQ..,CSMo/clMIB:

This bus carries Control Store data from the Microsequencer to the Ebox.
e'

E_BUS%UTEST:

This 3-:bit bus transfers mic:robranch conditions from the Ebox to the microsequencer.

•

F%RESULT:

This bus is used to transfer results from the Fbox to the Ebox.

•

I%mOX":ADDR:

This bus transmits the virtual addres~ of an Ibox memory reference to the Mbox-. The address
may be for instruction prefE~tch or an operand access.

•

I%IQ..,BUS:

This bus carries instruction information from the Ibox to the Instruction Queue in the
Microsequencer.

•

I%mOX_IW_BUS:

This bus is used by the Ibox to write t~e Ebox Register File for autoincrement/decrement type
specifiers and to deliver imlnediate operands to the Register File.

•

IO/oOPERAND_BUS:

This bus transfers information from the Ibox to the source and destination queues in the
Ebox.

•

M%MD_BUS:

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:

This bus transfers the addr.~ss for a backup cache reference from the MBox to the Cbox.

4.2 Revision History
Table 4-1:

ReviSion History

Who

When

Description of change

Debra Bernstein

06-Mar-1989

Release for external review.

Mike Uhler

18-Dec-1989

Update for second-pass release.

Gil Wolrich

15-Nov-1990

Update for NVAX Plus external release.

DIGITAL CONFIDENTIAL

Chip Overview 4-5

NVAX Plus C:PU Chip Functional Specification, Revision 0.3, October 1991

Chapter 5
Macroinstruction and Microinstruction Pipelines

5.1

Introduction
This chapter discusses the a.rchitecture of the NVAX Plus CPU macroinstruction and microinstruction pipeline. It includes a section of general pipeline fundamentals to set the stage for the
specific NVAX Plus CPU implementation of the pipeline. This is followed by an. overview of the
NVAX Plus CPU pipeline, an examination of macroinstruction execution, and a mscussion 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 Plus 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 encouI'~ged to skip (or at most skim). this section.

5.2.1

The Concept of a Pilpeline

The execution of a VAX mac:roinstruction 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 Plus CPU Chip Functional Specificatio~ Revision 0.3, October 1991

Figure 5-1:

Non-Pipellned instruction Execution
--------------- Time

--------------->

Ins~ruction

~--------------------.
IS015115:IS31S41551S61

Ins~ruction

+--------------------+
+--------------------+
IS01511S21531S41S51S61
+--------------------~
~--------------------4

Inst.ruction 3

IS01511521531S41551S61

.--------------------~

In this diagram, "SO", "82", ... , "86" denote particular steps in th~ 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:

Partlalty·PlpeUned Instruction execution
--------------. Time

Innruc..ion 1
Inst.ruction :2
Instruction :;

------------~-->

+--------------------+
ISO I 51 1S2 1531 S4 1551561
+--------------------+
+--------------------.
ISOlSl1S2lS31S41551S61

+--------------------+
+--------------------+
ISOl511521S31541551S61
+--------------------~

In this example, step 86 of each instruction is overlapped in time (or executed in parallel) with
step 80 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 Plus CPU Chip Functional Specification, Revision O.3 t October 1991

Figure 5-3:

Fully-Pipellned Instruction Execution
--------------- Ti,rne

Instruction 1
Instruetion :2
Instruct-ion 3

--------------->

..,.-----------------,----+
1SO I 51152 1531 541 s:~, 1561

+-----------------,---of.

.--------------------+
ISOl511521531S41551S61
+---------------------+
+---------------------+
ISOIS1lS21S31541S51561'
+---------------------+

Ins'Crue-:ion "

+--------------------+
1501511521531S41551561
+---------------------+

Instruct.ion 5

+--------------------~
1501511521531S41551561

+---------------------+
In this example every step of instruction execution is performed in parallel with every other step.
This means that a new instruction is started as soon as step SO is completed for the previous
instruction. If each step, SO .. SE), took the same amount of time, the apparent instnlction through·
put would be seven times greal ter 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 exa:mples of the concept of instruction pipelining, in which one or
more steps necessary to execu.te 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 parti,ally 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 i:n 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 fum::tion 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 reduce 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, inform.ation 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.

DIGfTAL CONFIDENTIAL

Macroinstruetlon and Microinstruction Pipelines

5-3'

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 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
Access

.-----------~

+-----------+
Memory

1-> 1Computation 1->1
1 1
1 1

Read

+-----------. .-----------~ ------------~
Figure 5-5 illustrates what happens when the pipeline control wants to use the result of the
memory read as an operand.
tnformation Ftow Against the Pipeline

Figure~:

.-----------+
Memor:y
1----..

~-----------* ~-----------~
! Operand
1-> 1Computation 1->1

Access

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

Read

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

.-------------------------------------~
1

+-----------.. ------------..

+-----------+
Result

+---->1 Operand 1-> 1computation 1->1
1 Access!
1 1

~-----------~

Store

... -----------... .,.------------+.

In this case, the operand access segment. of 12 can not supply an 'operand to the computation
segment because the memory read done by 11 has not yet completed. As a result, the pipeline
must stall until the memory read has completed. This is shown in Figure 5-6.
Figure 5-6:
Il

Stalls Introduced by Backward Pipeline Flow

+-----------*
~-----------~ +----~------+
1 Operand 1->IComputationl->1 Memory
1----..
1

Access

Read

.-----------.. +-----------+ +-----------+

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

+---->1
1

+------------------->1
1
1
1
1

1
1

Stall

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

1->1
1 1

S~all

+-----------*
Stall

1->1
1 1

+-----------+ +-----------.. +-----------..
+-----------..
+-----------..
+-----------..
Stall
1->1
Stall
1->1
Stall
1

+-----------+ +-----------.. +-----------+

+-----------+ +-----------+
+----------------------.------------>+-----------..
1 Operand 1-> IComputation 1-> 1 Result.
1 Access 1 1
1 1
Store

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

5-4

Macrolnstructio'n and Microinstruction Pipelines

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

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

In this diagram, the memory read data from II 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 segnlent.
This situation is an excellent example of an age-old problem with instruction pipelining. The
natural and desired direction of information :flow 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-left 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 segmemt 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 Ineans 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 tak,e this into account and be prepared to handle the condition.
A common stall condition occ:urs when each pipeline segment has the same average speed, but

different peak speeds. For el~mple, 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
ta.ke new inputs as fast if it is doing a memory reference rather than a result store. A common
technique to minimize this p:roblem is to place buffers between pipeline segments, as shown in
Figure 5-7.
Figure 5-7:

Butters Between Pipeline Segments

+------------t+------0+ .,.----.. ------0+ +------0+ +------------t1 Operand 1-> 1Esuffer 1-> 1Comp\1tation 1-> 1Esuffer 1-> 1 MeInory
1

Access

Read

+-----------+ +------+ +----.,------+ +------0+ +-----------+
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 intet'-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 ful1/buffer empty conditions.

DIGITAL CONFIDENTIAL

Macroinstruction and 'Microinstruction Pipelines

5-5

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

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 '~umpy" 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 PTE from memory, refill the TB, and
restart the request that caused the fault. This can add considerable complexity to the design.

5.3

NVAX Plus CPU Pipeline Overview
The remainder of this chapter discusses the NVAX Plus 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 Plus 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
micro pipeline operations. That is, if more than one operation is required to process a macroinstruction, the multiple operations are also pipelined within a section.

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
Plus 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 prefetching
operands to support Ebox execution of the instruction.

5-6

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Figure 5-8:

NVAX Plus CPU Pipeline

-....----.,.....-~

M
Cf)

('II

Cf)

Q
Cf)

DIGrTAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines

5-7

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

The Ibox is distributed across segments SO through 83 of the pipeline, with most of the work
being done in 81. In SO, instruction stream data is fetched from the virtual instruction cache
MC) using the address contained in the virtual instruction buffer address register MBA). The
data is written into the prefetch queue (PFQ) and VIBA is incremented to the next location.
In segment 81, 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 IROM
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 simplespecifiers, it is considered to be a complex specifier and is processed by the small microcodecontrolled complex specifier unit (eSU), which is distributed in segments 81 (control store access),
82 (operand access, including register file read), and 83 (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 esu 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
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 Mlcrosequencer

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.

5-B

Macroinstruction and Microinstruction Pipellnes

DIGITAL CONFIDENTlAL

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

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 reisponsible for evaluating all exception requests, and for providing
a pipeline flush control signal to the Ebox. For certain exceptions and interrupts, the micros~
quencer 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. Th~= Ebox is distributed through segments 83 (operand access, including register file read), S4 (ALU and shifter operation, Rmux request), and 85 (Rniux completion,
register write, completion of l\Irbox 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 itself for short literal specifiers,
and a pointer to an entry in the register file for other operand types.
An entry in the field queue is n:lade 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 addressels 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 specifiers, the source queue points to the
appropriate GPR in the registeir file. For other non-short literal specifier 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 Eo/oABUS and EO/oBBUS 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 sE~gment. 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.
The 84 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, an.d F%RESULT at the end of the cycle. The RMUX actually spans the
S41S5 boundary such that its C)utputs 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) neJct. Non-selected RMUX sources are delayed until the retire queue
indicates that they should be processed.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines

5-9

NVAX Plus CPU Chip Functional Specification, Revision O.3 t October 1991

As the source queue points to instruction operands, so the destination queue points to the des-

tination 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 RMlJX selects the appropriate source of result information, it either requests Mbox
service, or sends the result onto E%WBUS 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-length 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/aABUS and E%BBUS.
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 F%RESULT to t'.tle 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 PTE reads), and from the Obox (for invalidates and cache fills).
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 (PA 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 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 ac.cess can be started each cycle in the absence of a TB or cache miss.
5-10

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

5.3.1.6

The Cbox

The Cbox is responsible for acc:essing the backup cache (Bcache), and for memory requests. The
Cbox receives input from the ~[box in the S6 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 processing. 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 fill from the system:. When
the system returns the data, it is written to the Pcache (and potentially to the VIC). Although
Pcache fills are done by makin.g a request to the Mbox pipeline, data is returned to the original
requester as quickly as possible by driving data directly onto B%S6_DATA, and from there onto
M%MD_BUS as soon as the bus is free.
Because the Pcache operates a!s a write-through cache, all memory writes are passed to the Cbox.
To avoid multiple writes to the same Bcache block, the Cbox contains a write buffer in which
multiple writes to the same quadwords are packed. If possible two quadwords (an octaword) are
assembled together before the Bcache is actually written.

5.3.2

Stalls in the Pipeline

Despite our best attempts at keeping the pipeline fiowing 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:
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.
1.

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 isover-simpli:fied in some cases because some globa1 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 Plus, a memory data stall does not stall the ALU segment (a no-op is inserted into the S4
segment when S4 advances to 85).

DIGITAL CONFIDENTlAL

Macroinstruction and Microinstruction Pipelines

5-11

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

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:
Thox:

•

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 StaUs

Stalls 'that occur in the 81 segment of the pipelin~ are as follows:
Thox:

•

5-12

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 urrit 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. To 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.
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 urrit stalls until a free entry becomes available,
which occurs when an instruction is retired through the RMlJX.
Complex specifier unit busy: If the burst unit decodes an instruction component that must
be processed by the e8U pipeline, it makes a request for service by the esu through an Sl
request latch. If this latch is still valid from a previous request for service (either due to a
multi-cycle flow or a esu stall), the burst unit stalls until the valid bit in the request latch
is cleared.

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTlAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

•

5.3.2.3

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 COInes from one of the Ibox instruction PLAs which is accessed based
on the opcode of the instruction. If the PLA aCGess 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 S2 seglnent of the pipeline are as follows:
!box:
•

•

Outstanding Ebox or Fbo::s: GPR write: In order to calculate certain specifier memory addresses, the CSU 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 S2 segment of the CSU 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 S2 segment of the CSU pipeline
stalls until the data is retulTIled by the Mbox.

Microsequencer:
•

5.3.2.4

Instruction queue empty: ~rhe final microinstruction of a macroinstruction e~ecution flow in
the Ebox is indicated when a SEQ.MUXlLAST.CYCLE* microinstruction is decoded by the microsequencer. In response t..o this event, the Ebox expects to receive the first microinstruction
of the next macroinstruction flow based on the initial address in the instruction queue. If the
instruction queue is empty, the Microsequencer supplies the instruction queue stall nricroinstruction in place of the nE~ macroinstruction flow: In effect, this stalls the micro sequencer
for one cycle.
S3 Stalls

Stalls that occur in the 83 segment of the pipeline are as follows:
!box:
•

•

Outstanding Ebox GPR read: In order to complete the processing for auto-increment, autodecrement, and auto-incre:ment deferred 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 Gl?R write by stalling the 83 segment of the CSU pipeline. The stall
continues until the Ebox reads the GPR.
Specifier queue full: For most complex specifiers, the CSU 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 83 segment of the CSU pipeline stalls until a free entry becomes available.

DIGITAL CONFIDENTIAL

Macroinstruction and MlcrolnstructionPlpeUnes

5-13

NVAX Plus CPU Chip Functional Specification, Revision 0.8, October 1991

•

RLOG full: Autoaincrement, autoaciecrement, and auto-increment deferred 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 83 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. When 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 83 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
nllCT\Qbranch 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 83 segment of the Ebox pipeline stalls until the Fbox GPR write occurs.
Fbox instruction queue full: V\r:hen 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 83 segment of the
Ebox pipeline stalls until a free entry becomes available.

EboxlFbox:

•

5.3.2.5

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 83 segment of the Ebox pipeline
stalls until the entry becomes valid.
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 83
segment of the Ebox pipeline stalls until the entry becomes valid.
S4 Stalls

Stalls that occur in the 54 segment of the pipeline are as follows:
Ebox:

•

5-14

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 84
segment of the Ebox pipeline stalls until the entry is made.

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

• 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 54 segment
of the Ebox pipeline stalls tmtil a free entry becomes available.
Fhox:
•

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: lDestination 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 rE~ferenced in two cases: when the Ebox or Fbox store instruction
results via the RMlJX, 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 meInory result ready, the R.M1JX stalls until the entry becomes valid.
As a result, the source of the R.M1JX 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 staUs until the previous request is completed. As a
result, the source of the ruvrux input (Ebox or Fbox) also stalls.
R.M1JX selected to other sou.rce: 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 R.M1JX request, the other source stalls until the
retire queue indicates that the next instruction should come from that source.

5.3.3 Exception Handling
A pipeline exception occurs whl~n 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
con'ected, 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.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines

5-15

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

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 Plus
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 83,84, and 85 of the Ebox pipeline. If an exception is reported for the macroinstruction
in the 83 segment, the two macroinstructions that are in the S4 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 S41S5 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 Ebox to break all its stalls, aborts the
Ebox pipeline (by asserting E_USQ%PE_ABORT), 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
SCB vector.
'
There are a number of exceptions detected by the NVAX Plus 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

lnterrupts

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 CUlTent 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-16

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

5.3.3.2

Integer Arithmetic Exceptions

There are three integer arithrnletic 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 instruc:tion, which allows that instruction to complete.

Integer Overflow Trap
An integer overflow is detected by the- RMliX at the end of the S4 segment of the Ebox
pipeline. If P8L<IV> 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 instro.ction. 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 :Boating point arithmetic ex.ceptions are detected by the Fbox pipeline during the execution of
the instruction. The event is rE~ported by the RMUX when it selects the Fbox as the source of the
next instruction to process. At that point, a microtrap is requested.
5.3.3.4

Memory Management Exceptions

Memory management exceptio'ns 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 :MM:E
fault :Bag and stops. Mem,ory 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, intelTUpt, exception, or branch), it will reference one of the queues, which does
not have a valid entry be~luse 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 :Bag is set whEm an empty queue entry is referenced, the error is reported in one
of four ways.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipeline$

5-17

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

If the Ibox global M:ME 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 84 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 Fhox pipelines, depending on the type of instruction. To avoid a deadlock, 83 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 RMtJX,
a lnicrotrap 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 84
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 !box global M:ME flag is set when the RMUX references an invalid destination queue
entry for a store request, a microtrap is requested.

•

5-18

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, 83 stalls do not prevent forward prgress of the flag in the
pipeline. ~'ben the flag reaches the S4 segment of the pipeline and is selected by the RMUX,
a microtrap is requested.

Macroinstruction and Microinstruction Pipelines

DIGrTAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 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 RMtJX, 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 eJcplicit Ebox 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-bit 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: via the MD file or PA queue fault flags, or via an immediate micro trap 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 Ibox to back out all GPR modifications. that are in the RLOG and
retrieve's 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 PrE 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 specisJ FPD handling, as described below).

5.3.3.5

Translation Buffer Miss

Transla tion 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 CUITent reference and invokes
the services of the memory management exception sequencer in the Mbox, whkh 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 MOlde Faults

Reserved addressing mode faults are detected by the Ibox 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 Dlode fault flag is set when the Ebox references an invalid source
queue entry, a fault flag is injeeted 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. The fault flag is carried along the Ebox or Fbox pipeline and passed to the RMtJX,
which reports the event by requesting a microtrap when that source is selected.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction Pipelines

5-19

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 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 S4 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., ar.e 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
flows 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 micro sequencer substitutes the address of the microcode trace fault handler for
the address of the next macroinstruction.
5.3.3.10

Conditional Branch Mispredlct

'When the Ibox deCodes a conditiona'l -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 Plus CPU Chip Functional Specification, Revision 0.3, October 1991

5.3.3.1'1

First Part Done Handlin!g

During the execution of one of the 8 string instructions that are implemented by the CPU, an
exc:eption 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
exc:eption.
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 substitut.es the address
of a special FPD handler for the instruction execution flow.
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 Pca'che), it is reponed via a soft error interrupt request a.nd 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 recov'erable by hardware are reported via the assertion of a soft error
interrupt, and also in a manner that is similar to t~t used for memory managem;ent exceptions,
as described above". In fact, the~ MD file, PA queue, and the Ibox all contain a hardware error :Rag
in parallel with the memory management fault :Rag. With the exception ofTB parity errors, which
calIse 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 wlIecoverable error on a specifier read would set the hardware error
flag in the MD file. 'When the fiag is referenced, the error flag is injected into the pipeline. 'When
the flag advances to the S4 segment and is selected by the RMtJX, 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 thei 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 flag 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 ,ria the original
reference.

DIGITAL CONFIDENTIAL

Macroinstruction and Microinstruction IPipelines

5-21

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

5.4

Revision History

Table 5-:1:

Revision History

Who

When

Description of change

Mike Uhler

06-Mar-1989

Release for external review.

Gil Wolrich

15·Nov·1990

Update for NVAX Plus external release.

5-22

Macroinstruction and Microinstruction Pipelines

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Chapter 6
Microinstruction Formats

6.1

Ebox Microcode
The NVAX Plus microword conl;ists of61 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, Stanclard and Special, are selected by bit <60>, the FORMAT bit. In
addition, bit <45>, the LIT bit., selects the constant generation form~t of the microword, which
may be either an 8-bit constant or a 10-bit constant, depending on a decode in the MISe field.
Pictures of the microword fonnats are in Figure 6-1. and Figure 6-2. A brief description of each
field is given in Table 6-1 and Table 6-2.
Figure 6-1:

Ebox Data Path Control, Standard Format

61555 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 e i 615 ~ 3 211 0 ~ 81i 6 5 413 2 1 Ol~ e i 615 4 3 211 0 9 eli 6 5 413 2 1 019 8 i 615

+-~---------~---------+-~-----+-+---------+---------+-+-+-+-----------+-----------+---------+
1.01
ALO
MRQ
IQ! SHF 101
VAL
B
ILIWIVI
OST
A
I MIse

~-+ .. ------~-+---------+-+-----+-+---------+---------+-+-+-+-----------+-----------+---------+
111POSI
CONST
I MIse not equal CONST.10

+-+-,--+---------------+
III
CONST.10
I MISe equal CONST.10

+-+-------------------+
Table 6-1:
Bit Position

EBOX Data Path Con1trol Microword Fields, Standard Format
Microword Field

FORMAT

59:55

ALU

DIGITAL CONFIDENTIAL

Microword
Format

Description

Both

ALU function select

Microword format-Standard or Special

Microinstruction Formats

6-1

NVAX Plus CPU Chip Functional Speci1ication, Revision 0.3; October 1991

Table 6-1 (Cont.):

EBOX Data Path Control Microword Fields, Standard Format

Bit. Position

Microword Field

Microword
Format

Description

54:50

MRQ

Both

Mbox request select

Standard

Q register load control

48:46

SHF

Standard

Shifter function select

LIT

Both

ALU/sbi'fter B port control-register or literal

44:40

VAL

Standard 1

B
pas

Both

ALU/shifter B port select

Both

Constant position

S-bit constant value

39:35
44:43

Constant shift amount

42:35

CaNST

Both

44:35

CaNST. 10

BothS

lO·bit constant value

Both

Length control

Both

'Wbus driver control

Both

VA write enable

31;26

DST

Both

WEUS destination select

25;20

Both

ALU/shifter A port select

19:15

MISe

Both

Miscellaneious function select, group 0

1 NOT Constant generation microword variant

2S-Bit Constant generation microword variant, when MISe :field not equal CONST.IO
810-Bit Constant generation microword variant, when MISe :field equal CONST.IO

Figure 6-2:

Ebox Data Path Control, Special 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
e i 615 4 3 211 0 9 ~Ii 6 5 413 2 1 019 6 i 615 4 3 211 0 9 81i 6 5 413 2 1 019 e i 615

Ol~

~-~---------~---------+-------+-~-------+-+---------+- +-+-+-----------+-----------+---------+
DS'!'
I MIse
III
ALU
MRQ I MISCl 101 MISC2 IDI
ILIWIVI

11IPOSI

CONS'!'

I MIse not equal CONS'I'.lO

+-+---+---------------+
CONST.10
I MISe equal CONS'I'.lO
III
+-+-------------------+
Table 6-2:

EBOX Data Path Control Microword Fields, Special Format

Bit Position

Microword Field

FORMAT

6-2

Microinstruction Formats

Microword
Format

Description
Microword format-Standard or Special

DIGITAL CONFIDENTIAL

NVAX Plus CPU Chip Functional Specification, Revision 0.3, October 1991

Table ~2 (Cont.):

EBOX Data P,ath Control Microword Fields, Special Format

Bit Position

Microword Field

Microword
Format

Description

59:55

ALU

Both

ALU function select

.54:50

MRQ

Both

Mbox request select

49:46

MISCl

Special

Miscellaneous function select, group 1

LIT

Both

ALU/shifter B port control-register or literal