Digital PDFs

EK-382AB-UG-002

May 1990

435 pages

Original

20MB

view download

OCR Version

23MB

view download

Document:	rtVAX 300 Hardware User's Guide
Order Number:	EK-382AB-UG
Revision:	002
Pages:	435
Original Filename:

OCR Text

CEEEERK

pANSAIATSS
FHAEAIT
TALHLY,
$EY

XXX
XAXXX

XAUAAXAX

KUEXAAXX
AXXXXXXKXKEK

KUXAXXAXAKXXK

AXAXXKXKAXXHAXKX

XX XX MK KK KAXKKKKXX
}0.9.4.8.0.60.4.84960604.494
KAUXAXX
KK XAKXX KKK AAKXXA
J000080444
8.8.608 4006046004

p8.0.0.0.0.4.08 0460684506 64068¢9

XUK
KA AKX KHEXAKLAKEKKX
KAELAA
XXX

XA XK

KK XX A XKL XK KKAAXAX

XXX AL XA EA KKK KX KA KL KA

XXX

000006846
0600
880.0.060
PO O O 40000

866491
)96.000.0000.0004.008000805080464

}9.6.0.0.60.0.9.000000:0800.0$ 690806090V 80480¢
PO B0 bbb EODH0.60608 00000804 80060.¢8988009

GG 0D 00600000000 86¢80.0460000980508,
00
9
0600.4$000985000860
000060
0.0.00 4006
b008080
¢804
J0:8.0.06:0.6.0.06000.0.0.0009009:¢880.606890000860890
19000

NP0 0000 000866.0.040.080588.800000480¢

OGS0 P0G EO TS ISP CIEE090048480.80.9908600080960,
J V000006008880 00868 06080008009600000080800.000080088

rtVAX 300 Hardware Usgr's Guide
Order Number: EK-382AB-UG-002

This manual contains technical and physical specifications of the tVAX 300
processor and information necessary for configiring it into host and target
configurations—that is, information on the following interfaces: memory
gystem, console and boot ROM, network interconnect, and I/O device.

Revision/Update information:

T 's manual supersedes the VAX 300
Hardware User’s Guide, EK-382AA-UGHON

Software Revision:

VAXELN Version 4.2

Hardware Revision:

rtVAX 300 Version C1

Firmware Revision:

Version 1.1

Digital Equipment Corporation
Maynard, mussacnusetts

First Printing, May 1990
Revised, April 1991

The information in this document is subject to change without notice and should not be
construed as a commitment by Digital Equipment Corporation.
Digital Equipment Corporation assumes no responsibility for any errors that may appear in this
document.

Any software described in this document is furnished under a license and may be used or copied
only in accordance with the terms of such license. No responsibility is assumed for the use or
reliability of software or equipment that is not supplied by Digital Equipment Corporation or its
affiliated companies.

Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (cX1Xii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013.

© Digital Equipment Corporation 1990, 1991.
All right- reserved. Printed in U.S.A.
The Reader’s Comments form at the end of this document requests your critical evaluation to
assist in preparing future Jocumentation.

The following are trademarks of Digital Equipment Corporation: DDCMP, DEC, DECnet,
DECnet-VAX, DECwindows, DELUA, DEQNA, DEUNA, DSSI, IVAX, MicroVAX, PDP, Q22-bus,
RQDX, rtVAX 300, ThinWire, VAX, VAXcluster, VAX DOCUMENT, VAXELN, VMS, and the
DIGITAL logo.

IBM PC/AT is a registered trademark of the International Business Machines Corporation.
PROMLINK is a registered trademark of the DATA I/C Corporation. Signetics is a registered
trademark of the Signetics Company.
51537

This document was prepared with VAX DOCUMENT, Version 1.2.

Contents
Xix

Preface . ..

Overview of the rtVAX 300 Processor
1.1
1.2
1.3
1.4
15

Central Processor . . . . ... ... . .
Floating-Point Accelerator ... .........
... .. ... ......
... ... .....
Ethernet Coprocessor . . . ... ................
System Support Functions . . . ... ... .. ... ... . ... ... ..
Resident Firmware .. ... .. ... ... ....... ... ... ... . ...

1-2
1-2
1-3

1-3
1-3

. 2 Technical Specification

2.1
2.1.1
2.1.2
2.1.3
214
215
216
217

... .. ... ... ..
Functional Description . . . ... ... .. ...
...
...
...
...
.
.
.
Architecture Summary
CPUand CFPA . . ... ... .. . . ..
... ...
ROM and Reserved Memory Locations ... .........
Network Interface ... ...... ... ... ... ... ... ... .. ...
..
Decode and Control Logic. . .. ......................
Interrupt Structure . . ... ... ... ... ...
DMA Structure . . . ... ...

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

2.19
2.2
2.21
222
2.3
2.31
232
233

Internal Cache . . . ... ... . . . ... ...
i
Minimum Hardware Configuration . ..... .................
System RAM . ... .. . ... ... ... ...
Console .. ... . ...
Bus Connections. . . . ..........
. ...
Power Connections . . . ... . ... .............
... ..
Reset and Power-Up Requirements . ... ........
... .. ...
Power-Down Sequencing: Power-Fail. . .........
.. ... ...

2-5
2-5
2-5
2-5
2-6
2-6
2-6
2—7

24
241
242

Pin and Signal Description .. ....... ... ... .. ... ... ...
Dataand Address Bus ... ............
... ... .. ... .
Ethernet Connections . . . . .. ... ...

2.1.8

24.3

Interval Timer ... ... . .. . . ... ... .

Bus Control Signals . .. ... .. .. ... ... .. ... ... ...

2-4

2-8
2-11
2-12

2-13

244

BusRetryCycles . ....... ... ... . ...

245
Status and Parity Control Signals ... ..................
246
Interrupt Control . . ... .. ... ... .. ... . .
247
DMAControl Signals .. ... ...... ... ... ...
248
System Control Signals . .........
... ... .. .. .. ... . ...
249
ClockSignals . . ......... ... ... i,
24.10
Power Supply Connections . . . ............
.. ..........
2.5
Memoryand VO Space...............
... ... ...
25.1
Address Decode and Boot ROM . ...................
...
25.2
Boot ROM .. ... . e
253
Programming the User ROMs .. ......................
254
Network Interface Registers . ........................
255
Board-Level Initialization and Diagnostic ROMs . . .. ... ...
2.6
BusCyclesand Protocols . .. .............
... ... ... ......
2.6.1
Microcycle Definition . . .........
... .. ... ... . ...
26.2
Single-Transfer Read Cycle . .........................
26.3
Quadword-Transfer Read Cycle . ... ... .. ... ... ... ...
2.6.4
Octaword-Transfer Read Cycle . . . .......
... ... .........
2.6.5
Single-Transfer Write Cycle . . . .......................
266
Octaword-Transfer Write Cycle ....................
...
26.7
Interrupt Acknowledge Cycle . .. ... ... ... ... ... ....
268
External IPRCycles. . . ...........
... .. it
26.8.1
External IPRRead Cycle . .. ..............
... .. ...
2682
External IPR WriteCycle. . ... ..............
... ...
269
Intermal Cycles. .. ....... ... ... . .. ..
2.6.10
DMACycle. ........ ..
2.6.11
Cache InvalidateCycle. . . ... ... ... .. ...t

2-16 ‘

2-16
2-18
2-18
2-19
2-19
2-20
2-20
2-22
2-22
2-23
2-23
2-23
2-24
2-24
2~24
2-26
2-29
2-32
2-35
2-37
2-37
2-37
2-39
2-40
2~41
242

Hardware Architecture
31
Central Processor . .. ...ttt
311
DataTypes. .. .......cuiii
i,
312
Imstruction Set . . . ....... ... .. e
313
Microcode-Assisted Emulated Instructions. . .. ...........
314
Processor State . ...............
.
it
3141
General-Purpose Registers . . .. ....................
3142
Processor Status Longword ... ....................
3143
Internal Processor Registers ......................
315
Interval Timer ... ... ... i
316
ROM Address Space. . ........ ...
innn.
317
Resident Firmware Operation . .......................

3-2
3-2
3-2
3-3
35
3-5
3-5
37
-9
3-10
3-10

3.1.8
3.1.8.1
3.1.8.2
3.1.9
3.1.10
3.1.11

Memory Management . ....................
... ...
Translation Buffer . . .............
... ............
Memory Management Control Registers .. .......
.. ..
Exceptions and Interrupts ................
... . ... . ...
Interrupt Control . .. ... .. ... ... ... ..o
Internal Hardware Interrupts ... ........
... ... .. .. ..

3-11
31
3-12
3-12
3-13
3-13

3.1.12
3.1.121
3.1.12.2

Dispatching Interrupts: Vectors.........
... .. ... .. ... ..
Interrupt Action. . . . ....... .. ... ... .
L
Halting the Processor. . .. .............
... .......

3-13
3-14
3-16

3.1.12.3
3.1.124
3.1.125

Exceptions ......... ... ... ... . .. . .
.
Information Saved on a Machine Check Exception ... . .
System Control Block . . . ....... .. ... ... ... ... ...

3-16
3-19
3-24

3.1.126

Hardware Detected Errors . . . .........
... ... ... ...

3-26

Hardware Halt Procedure ..........
... ...........
System Identification . . . ..........
... .. ... ..
L.
CPUReferences .. ... ...,
3.1.141
Instruction-Stream Read References . .. ... .....
... .
3.1.14.2
Data-Stream Read References .. ................
...
3.1.143
Write References . . .........
... ... ....... ...
3.2
Floating-Point Accelerator . . ..........
... .. ... . ........
3.2.1
Floating-Point Accelerator Instructions . ... .............
3.22
Floating-Point Accelerator Data Types. . . .............
..
3.3
Cache Memory . ... ...t
e
3.3.1
Cacheable References . . . ............
... ... ... .. ...
3.3.2
Internal Cache . . ......... ... ... ... . .. . ..
...
3.3.2.1
Internal Cache Organization ......................
3.3.2.2
Internal Cache Address Translation. . ... ............
3.3.23
Internal Cache Data Block Allocation ...............
3.3.24
Internal Cache Behavioron Writes . . ... ............
3.3.25
Cache Disable Register ..........................
3.3.26
Memory System Error Register . .. .. ............
...
3.3.27
Internal Cache Error Detection . ... .........
... ... ..
3.4
Hardware Initialization . .. ...........
... .. ... .. .......
3.441
Power-Up Initialization .............................
3.4.2
/O Bus Initialization . . . ..........
... ... .
..
3.4.3
Processor Initialization ...................
... ........
3.5
Console Interface Registers . . .............
... ...........
3.5.1
Boot Register .. ....... ... ... ... . . .. i
3.5.2
Console DUART Register . . ...........
...
... ...
353
Memory System Control/Status Register . .. .............
354
Status LED Register . ............
... ... .iivuun..
3.6
Ethernet Coprocessor . . . . . . ... oottt
inn ..

3-27
3-28
3-29

3.1.127
3.1.13
3.1.14

3-28

3-29
3-30
3~-30
3-30

3-31
3--31
3-31
3-32
3--32

3-33

3-34
3-35
3-36
3-38
3-39
340
3-40
3-41
3-41
3-41
3—41
3-43
344
345

3-47

3.6.1
3.6.1.1
3.6.1.2
3.6.1.3
36.1.4
3.6.1.5
3.6.1.6
3.6.1.7
3.6.1.8
3.6.1.9
3.6.1.10
3.6.1.1
36.2
3.6.2.1
3.6.2.2
3.6.2.3
3.6.2.3.1
3.6.2.3.2
3.6.2.3.3
3.6.2.3.4
3.6.2.3.5
3.6.3
3.6.3.1
3.6.3.2

3.64.2

3-57

3-61
3-62
3-63
3-64

3-64
3-65

3-66

3-67
3-72
3-78

3-78

3-78
3-79

3-80
3-82

3-84
3-85

3-86
3-87
3-87

...

Error Reporting .. ........ ... ... ... .. .. ... .....
On-Chip Diagnostics .. .............
... ... . .....
Internal Self-Test . . . ....... ... ... . ... ......
LoopbackModes . . .. ..........
... ... ... .....
Time Domain Reflectometer . ... ................

3-87
3-87
3-88
3-88
3-89
3-89

Firmware
4.1
4.1.1

412
4.2

3-50

3-51
3-53

Serial Interface .............
.. ... .. ... .. ... . . ...
Transmit Mode . .. ..........
... ... . ... . .......
Diagnosticsand Testing . .. ..........
... ... ..........

3.6.5.1
3.6.5.2
3.6.5.2.1
36522
3.6523

349

3-86

Receive Mode . . ... ... ... ... ... ... .

3.65

40 @

. ....... ... ... .. e

Interrupts

3.6.4
3.6.4.1

Control/Status Registers .. ..........................
Vector Address, IPL, Sync/Asynch (CSRO) . ... ........
Transmit/Receive Polling Demands (CSR1, CSR2) .. .. ..
Descriptor List Addresses (CSR3,CSR4) . ............
Status Register (CSRB) ..........
... ... ... ......
Command and Mode Register (CSR6) . ..............
System Base Register (CSR7) .....................
Watchdog Timer Register (CSR9) ... ................
Revision Number and Missed Frame Count (CSR10). . . .
Boot Message Registers (CSR11, CSR12, CSR13).......
Breakpoint Address Register (CSR14) .. ............
.
Monitor Command Register (CSR15) ... .............
Descriptor and Buffer Formats .......................
Receive Descriptors ... ...... ... ... .. ... . .......
Transmit Descriptors . . . .................
... .....
SetupFrame ..........
... .. .. . ... ...
i
First Setup Frame . . ... ... ................
...
Subsequent Setup Frame .. ....................
Setup Frame Descriptor . . . . ...................
Perfect Filtering Setup Frame Buffer .. ... .......
Imperfect Filtering Setup Frame Buffer ... ... ....
OpPeration . . ... ... vttt
Hardware and Software Reset . ... .................

System Firmware ROM Format . .. .......................

4-2

System ROM Part Format . . .........................

4-2

System ROM Set Format . .. .........................
System Firmware Entry. .. . ... . ...

...

.. ... ...

...

4.2.1

Restart . . .. ... ... . ... .

4-7

422

Boot . ...

4-7

4.2.3

Halt ...

. e

4.3
4.3.1
4.3.2

Console Program .................
Entering the Console Program . . ......................
Compatible Console Interface. .. ......................

4-9

Console Keys .. ...ty

4-9

4.3.3
4.3.4

4.3.5
4.3.6

4.3.6.1
4.3.6.2

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

Entering and Exiting from Console Mode ...............

4-9

.
... .ot
.......
Console Command Syntax . ....
.... Co
... ........
Console Commands . ..........

4-11

BOOt . . e

4-11

4-11
4-12

4-12

4.3.6.3

4--15

4.364

4365

...................

4~15

4.3.6.6

...................

4-15

4.3.6.7

HHEID - o v oo et

e e e

4.3.6.8
4.3.6.9

...................

4.3.6.11

..................

4.3.6.13

4-18

4-19

...............

4-20

4.3.6.14

4-20

4.3.6.15

4.3.8

4-17

4-19

4.36.12

4.3.7

4-17
4~17

4.3.6.10

4.3.6.16

4-16

P (Comment).

tt
e
ot
e
. ..

4-21

Supported Boot Devices . .. ...... ... . ...
Console Program Messages . .........................

4-21

Capabilities of Console Terminals .....................

4--24

4-22

4-24

4-25

......
....
... ...
Console Entryand Exit . ..........
....
.........
..
.
Listener
Ethernet
Entity-Based Module and

4.5

Startup Messages

439

4.3.10
4.3.11

451

452
453
454

455
4.6

4.7
.1
4.7

472
4.8

4.8.1
4.8.2
4.8.3

Console Device . . . . ...

....................................

Power-On Display ........ ... ... it
Boot Countdown Description .. .......................
Halt ACtiON .. ..t ettt
e
Boot DeVvICE .. .. it
BootFlags ... ......citiiiiii i
Diagnostic Test List . .. ............
System Scratch RAM .. ... .........

4--26

4-27
4-28

4-28

4-29
4-29

....................

4-34

....................

4-39

....................

4-39

User-Defined Board-Level Boot and Diagnostic ROMs . . . ... ...
Optional User Initialization Routine

Memory Bitmap Descriptor Format

4-26

....................

SCR$A_SAVE_CONSOLE .......
SCR$A_RESTORE_CONSOLE ...

Input Parameters..............

4-25

4-39

...................

440

....................

4-41

....................

4-42

vii

484

Optional User-Supplied Diagnostic Routines . . .. .........

4.84.1
Self-Test Routine Input Parameters . . .. . ............
4.8.4.2
Self-Test Routine Qutput . .............
.. ... .....
. ........
...
.
.
ROM
Test
Linking User Initialization/User
4.8.5
4.9
Creation and Down-Line Loading of Test Programs . . ...
... ...
4.9.1
Writing Test Programs . . .. ...............
... ... ... ..
4.9.2
Using MOP to Run Test Programs . .. ................
..
410
Serial-Line Boot Directions .. .............
...
...,

411
4111

ROM Bootstrap Operations . ............................
Booting from Cached ROM Address Space. . . ............

4.11.2

Booting from ROM I/O Address Space .. . ...............

4-43
4-43
4-44

4-44
4-44
4-45
4-45
4-47
4-49
4-49

Memory System Interface
5.1
Memory Speed and Performance .. ... ...... ... ...........
5.2
Staticand Dynamic RAMs .. . ...........
... ... ... . ...,
5.3
Basic Memory Interface . . .. ....... ... ... ... ... .
L.
54
CycleStatus Codes. . . ......... ...
5.5
Byte Mask Lines .............
... ... .. . .
..
.......
..
...
.......
...
Data Parity Checking. . . .......
5.6
57
Internal Cache Control ...............
... ... .. ... ... ...
5.8
Memory Management Unit ... ............
... . ... ... ....
5.9
Memory System Design Example. ... .....................
5.9.1
Address Decoder . ............ ...t
i,
i
AddressLatches . . ........ .. .. ... . ..
592
5.9.3
DRAM Memory Refresh . . . . .........
... ... ... ...
..
5.9.4
DRAM Row and Column Address Multiplexer . . .. .. ... ...
595
AM-Byte DRAM ArTray .. ... ..ccoiniiininiiinnnn.
5.9.6
DRAM Terminating Resistors . .......................
597
DRAM Data Latches . .........
. ... ... ... ... ... ...
5.9.8
Memory Controller State Machine . . . ..................
5.10
Memory Timing Considerations . . . .......................
5.10.1
Calculating Memory Access Time. . ....................
5.10.2
State Machine Input Setup Time . . ....................
5.10.3
Memory Subsystem Longword and Quadword Read Cycle
TN . . ottt e
e
e
e
e
5.10.3.1
Calculating DRAM Row Address Setup Time. .........
5.10.3.2
Calculating DRAM Row Address Hold Time ..........
5.10.3.3
Calculating DRAM Column Address Setup Time .. . .. ..
Calculating DRAM Column Address Hold Time........
5.10.3.4
5.10.4
Memory Subsystem Octaword Write Cycle Timing. .. ... ...
5.10.4.1
Calculating DataInSetup Time ...................
5.10.4.2
Calculating DataIn Hold Time ....................

viii

4-42 ‘

52
5-2
5-3
5-4
5-5
57
5-8
5-9
59
5-9
5-11

5-12
5-12
5-15
5-16
5-17
5-17
5-21
5-21
5-22
5-23
5-27
5-27
5-28
5-28
5-28
5-30
5-30

5.10.5
Memory Subsystem Refresh Timing . . .. ................
5.10.6
RASPrecharge Time .. ..........
... 0iiiiinnnn...
5.10.7
DALBus Turnoff Time. ... ... ..........
... ... .. ....
5.11
Memory System Illustrations and Programmable Array Logic. . .
5.11.1
Application Module Address Decoder PAL . . .............
5.11.2
Memory Subsystem Sequencer State Machine PAL ..... ...

5-30
5-32

5-32
533
5-33
5-43

6 Console and Boot ROM Interface
6.1
Console System Interface . . ............
... .. ... ... .....
6.1.1
Console ACCESS . . ... vttt ettt e
e
6.1.2
Console State Machine . . . ..............
. ... ........
6.1.3
Console Interrupt Acknowledge Cycles .................
6.1.4
Console Timing Parameters . . . .......................
6.1.4.1
Console Address Setup and Hold Times . . . .. .........
6.1.4.2
Console Data Turn-Off Time . .....................
6.1.4.3
Console Read Cycle Timing Analysis . . ..............
6.1.4.4
Console Write Cycle and Data In Setup and Hold Timing

6-3

67
6-9
69

Analysis . . ... ...
e
e

6-10

6.1.5
6.1.6
6.1.7
6.2

Console Oscillator .................
... ... ........
Line Drivers and Receivers ..........................
Console Break Key Support . . ........................
Booting from External ROM .. ... ...... .. ... ..........

6~11
611

6.2.1
6.2.2
6.2.3
6.2.4

Base Address of External ROM . ......................
Programming the Boot ROMs . .......................
Boot ROM Interface Design ... .......................
Boot ROM Address Decoder . .. .......... ............

6-12

6.25
626

ROM Address Latch . . . ........ ...... ... ...........
ROMRead CycleTiming .. .............
.. ... .....

6-14

6.2.7

ROM Turmn-Off Time . . . ... ...

6-18

6.2.8
6.3

ROM Speed Versus rtVAX 300 Performance .............
rtVAX 300 Processor Status LED Register . . .. ..............

6-19

6.4

Console Interface and Boot ROM Illustrations and
Programmable Array Logic ............
... ... ... ... .. ...
Application Module Address Decoder PAL . . .............
Console Sequencer State Machine PAL . ... .............
Interrupt Decoder PAL.. . . . ..........
.. ... ...........

6.4.1
6.4.2

6.4.3

6-11
6-12
612
6-13

6-14
6~14

6-19

6-19
6~21

6—29
6-33

Network Interconnect interface
7.1

7.2

7.3
7.4
7.5
7.6

DECnet Communications . . . . . .......cvin

.,
Ethernet Interface .. ....... ... .. .. . .
.........
Thickwire Network Interconnect . ...............
ThinWire Support .. ....... ... i

... ....
Ethernet Coprocessor Registers ... ................
Hardware Implementation Example ..................
....
QOverview of Ethernet Interface ... ....................
7.6.1
Ethernet Interface Functions . . . ...................
7.6.1.1
7612
DP8392 Transceiver Chip. ... .....................
Implementationof Design . . .........................
76.2
76.2.1
ThinWire Transceiver. . . .. ... ... eiinunans
7622

Layout Requirements . . . .........................

7.6.2.3
7.62.4
76.3
7.6.3.1
7.6.3.2
7.63.2.1
7.6.3.2.2
7.6.3.3
7.6.3.4
7.6.3.5
7.6.3.6

Typical Ethernet Board Parts List . . ... .............
DCDC Converter . ... ...ttt
Detailed Design Considerations .. .....................
Differential Signals .. ............
... ... ..... ...
et
.ivt
...
..
.
.
.
.
DP8392 Transceiver
External Components. . .......................
Layout Considerations . .......................
ThinWire Application Hints . . . . .........
... ... ....
POWET . . . e
Grounding .. .......... .
Isolation Boundary. .. ... ... ... ... ...
in.

1/0 Device Interfacing
8.1
8.1.1
8.1.2

8.1.3
8.2
8.2.1
8.22

8.3
8.3.1
832
8.3.3
834
8.4
8.4.1

VODeviceMapping .. ... ... ..ttt
Address Latch .. ...... . ... ... .. . . . . ...
...
Address Decoding . .. ........ ... ... .. ...

/O Access: Cache Control, Data Parity, and 1/0 Cycle

TYPeS . . o et
rtVAX 300 Interrupt Structure. . . . ...... ... ... .. ...

Interrupt Daisy-Chaining . . . .........................
Interrupt Vector . . ........

... ...

. ...

General Bus Interfacing Techniques .. ....................
BusErrors . ... ...
Using the rtVAX 300 asa BusMaster . ... ... ...........
.. .
Using the rtVAX 300 asa Bus Slave ... .. ... ......
Building a DMA Engine for the tVAX 300 ..............
DMA Device Mapping Registers. . . . ......................
Q22-bus to Main Memory Address Translation ...........

7-11
7-12
7-12
7-12
7-12
7-14
7-15
7-16
7-18
7-19
7-20

8.4.2
8.4.3
8.5

8.5.1
8.5.2
8.5.3

8.54
8.55
8.5.5.1

Q22-bus Map Registers . ...........
...
iy

8-12

Dual-Ported Memory .. .........
... ...,

8-13

rtVAX 300 to Digital Signal Processor (DSP) Application

e
Example. .. ... ..ot
i
......
...
.......
.
.
.
Memory
DSP Private

4K Words of DSP Private RAM . ......................
DSP 4K-Word Private Initialization ROM ...............
DSPDMACycles . ...t
Control and Status Register. . . . . .....................

... ...
....
... ...
1-Way Mirror Register . . .......

8-13

8-16
8-16
8-17

8-17
8-19
8-19

8.6

Interrupt, Reset,and Hold Bits . ... ................
DMA Base Address Register .. .......................
Reset/Power-Up .. ... ... it

8.7

Halting the Processor.

. .. .........
... .. ... ... ... .....

8-21

8.8

I/0O System Ilustrations . . . . ..............
.. ... ... .....

8-23

8.5.5.2
8.5.6

8-19

8-20
8-20

Physical, Electrical, and Environmental Characteristics
A

Physical Characteristics . . . . .........
... ... ...
...

Electrical Characteristics . . . . . . .
i ittt e it e et et e
e
..
...
...
.
...
..
......
..
.
Environmental Characteristics.

Acronyms

Address Assignments

User Boot/Diagnostic ROM Sample

Sample C Program to Build Setup Frame Buffer

index

Examples
31

Perfect Filtering Setup Buffer Fragment . ... ... .........

3-81

3-2

Imperfect Filtering Setup Frame Buffer ... ...........
..

3-83

4-1

Firmware Dispatch Code ... ... ......................

4-6

E-1

Hash Filtering Setup Frame Buffer Creation C Program . ..

E-1

2-1

rtVAX 300 Block Diagram . ..........................

2-3

2-2

Typical rtVAX 300 Environment

......................

2-6

2-3

Timing Cycle for Reset Function . ... .......
... .......

2-7

rtVAX 300 FinLayout .. ........
... ... ... ...........

2-11

2-5

Thickwire Connections . . . . . .........................

2-13

2-6

rtVAX 300 Memory and /O Space . . ... ... ... .........

2-21

2-7

rtVAX 300 Memory Bank Organization .. ...............

2-22

2-8

Microcycle Timing . ... ... ... ... .. .. . ... . ... .. ... ..

2-24

2-9

Single-Transfer Read Cycle Timing .. .............
... ..

2-25

2-10

Quadword-Transfer Read Cycle Timing . ... .............

2-28

2-11

Octaword-Transfer Read Cycle Timing . . ... .. ...........

2-31

2-12

Single-Transfer Write Cycle Timing . .. .................

2-34

2-13

Octaword-Transfer Write Cycle Timing .. ... ............

2~36

2-14

Interrupt AcknowledgeCycle . ... ...... ... ...

... .....

2-38

2~-15

Internal Read or WriteCycle . ... ... ... ... ... . .......

2-41

2-16

DMACycle . ...

2-42

2-17

Octaword Cache Invalidate Cycle.

... ..................

2-43

2-18

Quadword Cache Invalidate Cycle . .. ..................

2-44

Processor Status Longword

. . . ... ... ... .. ... ... .. ...

3-6

3-2

Interval Timer . .. .. ...

... . .. ... ... ... . ... ...,

3-10

Interrupt Registers

.. ... ... .. ... ... .. ... ... ....

3-16

Information Saved on a Machine Check Exception ........

3-19

System Control Block Base Register . ... ............

3-24

System Identification Register . . .. ..... . ... ... ........

3-29

3-7

Internal Cache Organization . .......
... ... ..........

3-32

3-8

Internal Cache Entry . ... .. ...

.. ...........

3-33

3-5

Internal CacheTagBlock . . .. ...........
... ... .........

3-33

3-10

Internal CacheDataBlock . . .........................

3-33

Figures

... ...

...

.. ...

3~11

Internal Cache Address Translation. . ..................

3-35

3-12
3-13

Cache Disable Register . ............................
Memory System Error Register ... ... .................

3-36
3-38

3-14

Boot Register .. ...............
. ... i,

3-42

3-15

Memory Systemn Control/Status Register .. ..............

3-44

3-16

LED Display/Status Register . . ..............
... ... ...

3-45

3-17

Ethernet Ceprocessor Block Diagram . ... ...............

3-47

3-18

CSRO Format . ...ttt

3-50

3-19

CSRI/CSR2Format .. ...........

3-51

3-20

CSR3/CSRAFormat .. ........ ...,

3-52

3-21

CSREFormat ... .......o ittt

3-53

3-22

COREFOIMAL . . ...

3-57

3-23

CSR7Format . ....... ... ittt

3-61

3-24

CSROFormat ....... ... ... .. it

3-62

3-25

CSRIOFormat .............. 0.0t

3-63

3-26

CSR14 Format . ..... ...ttt

3-64

3-27

CSR1I5SFormat . ....... ... ... ....

3-65

3-28

Receive Descriptor Format . . . .....................
...

3-67

3-29

Transmit Descriptor Format . .......................

3-72

3-30

Setup Frame Descriptor Format ......................

3-79

3-31

Perfect Filtering Setup Frame Buffer Format .........
...

3-81

3-32

Imperfect Filtering Setup Frame Buffer Format ..........

3-82

4-1

System ROM Format . ...........
... .. ... ... ......

4-2

System KOMPart ... ... ... ... ...

...

4-3

Systera ROM SetData . . ............................

System Type Register. . .. ... ... ... ... ... ... .....

4-5

HelpDisplay ......... ...

4-16

4-6
4-7

Console Mailbox Register (CPMBX) Offset 0015. ... .......
Console Program Flags .................
.. ... ... ...

4-34
4-36

4-8

Default Boot Device Register (BOOTDEV). . .............

4-37

4-9

User Boot/Diagnostic ROM ... .......
... ... ... .. ...

4-41

4-10

Memory Bitmap Descriptor .. .........
... ... ...
..

4-42

4-11

ROMBootBlock............
... ... ..... .....

4-48

Memory Organization

.............
... .. ... ... ... ...

5-5

5-2

Sample Design: Memory Subsystem Functional Diagram . . .

5-10

5-3

Sample Design: DRAM AddressPath ..................

5-14

Sample Design: Memory Controller Sequence . . ..........

5-19

oottt

.. ..

xiii

Sample Design: Memory Controller Longword Timing . .. ..
Sample Design: Memory Controller Octaword Read Cydle
Timing ............

.........................

s@
5-25

Sample Design: Memory Controller Octaword Write Cycle
Timing ... .........

..............................

5-29

Sample Design: Memory Controller Refresh Timing .. ... ..

5-31

5-9

Sample Design: Address Decoder and Power-Up Reset . . . ..

5-35

5-10

RAM Memory Map. . .

5-36

5-11

Sample Design: Address Latches

.....................

3-37

512

Sample Design: DRAM Memory Array(1)...............

5-38

5-13

Sample Design: DRAM Memory Array (2} . ... . ..........

5-39

5-14

Sample Design: RAM Daia Latches. .. . ................

5-15

Sample Design: Memory Controller

6-1

Sample Design: Console Terminal Interface Block

... ... ... ..........

..............................

5-41

6~3

IRTTIIT

Diagram...........

..............................

Sample Design: Console Cycle Sequence .. ... ...........

Sample Design: Boot ROM Functional Block Diagram . .. ..

6-13

Sample Design: Address Decoder. .. ..................

6-15

Sample Design: Address Laiches

6-16

Sample Design: ROM Read Cycle Timing ... ............

6—-17

Sample Design: Processor Status Display ... ..........
..

6—-20

6-10

Application Module Address Decoder Memory Map . . . ...
..

6-21

611

Sample Design: Console Interface . ....................

6—23

6-12

Sample Design: User Boot ROM Bank 1 with Drivers. ... ..

6-25

6-13

Sample Design: User Boot ROM Bank 2 .....
.. ........

6--27

7-1

Network Interconnect: Controller Block Diagram . ... ....

7-3

Sample Design: Interrupt Acknowledge Cycle Timing . . . . ..
Sample Design: Console Read and Write Cycle Timing . . . ..

Network Interconnect: Isolation Transformer and
Jumpers...........

..............................

7-4

7-3

Network Interconnect: Ethernet Interface Block Diagram. . .

7-6

7-4

Network Interconnect: DP8392 Chip Block Diagram ... . ...

7-8

7-5

Network Interconnect: Transceiver, BNC Connector, and AUI
..............................

7-€

Network Interconnect: de-to-dc Converter . .. ... .........

7-10

7-13

Network Intercc nect: Layout of ThinWire Medium
..............................

7-8

xiv

Network Interconnect:

7-16

7-17

8-1

1/0 Device Interfacing: Address Latches . . ..

8-2

I/O Device Interfacing: Address Decoding Block Diagram . . .

8-3

/O Device Interfacing: Interrupt Daisy-Chain Block

Diagram . .. .... .. ... ...
i
e

I/O Device Interfacing: DMA Read Cycle Timing. ... ... ...

8-S

Q22-bus to Main Memory Address Translation

8-11

Q22-bus Map Register
8—7

..................

8-12

............

1/0 Device Interfacing: DSP and rtVAX 300 Processor
Interface Block Diagram

8-15

................

1/0 Device Interfacing: DMA State Machine Sequence . . ...

8-18

8-9

1/0 Device Interfacing: Reset Timer Logic . . .

8-21

8-10

I/0 Device Interfacing:

8-11

1/O Device Interfacing:
Reset . ...
e e

8-24

8-12

I/0 Device Interfacing:

8-25

8-13

1/0 Device Interfacing:

8-14

1/0) Device Interfacing: DRAM Memory Array

8-15

O Device Interfacing: DRAM Memory Array 2) .........

8-16

I/O Device Interfacing: RAM Data Latches . .

817

1/0 Device Interfacing: DSP PGM Loader ROM

8-30

8-18

/0 Device Interfacing: rtVAX 300 ThinWire/Thickwire
Network Connections

8-31

8-19

I/0 Device Interfacing:

8-33

8~-20

I/0 Device Interfacing: Memory Controller .7

8-21

I/0 Device Interfacing: Console Interface

8-22

/O Device Interfacing: User Boot ROM Bank 1 with
e

............

. ..

(1)

............

e e

/O Device Interfacing:

8-24

I/0 Device Interfacing: DSP and Private RAM

8-25

1/0 Device Interfacing: DSP DMA Transceiver and Parity

..........

...........

.......................................

8-26

1/0 Device Interfacing:

827

I/0 Device Interfacing:
Register .. ...

...........

... .. .. e

8-28

I/0 Device Interfacing:

8-29

I/0 Device Interfacing:

8-30

I/0 Device {nterfacing:

8-31

I/O Device Interfacing:

8-26

8-27

.........

8-23

Generator

8-22

............

..................

DaVeLS . . .t et

............

8-28

8-29

8-35

8-37
8-39
841

8-43

8-45

8-47
8-49

8-51
............

...........

.....

8-53
8-55

8-57

8-32
A-1
A-2
A-3

I/O Device Interfacing: DecouplingCaps .. ..............

8-59 .

.. .. ... ...
....
... ...
BusInterface Signals . . ....
... ...
rtVAX 300 Processor Pin Description . . . ..........
DAL LINes . ... i
ByteMasks ......... ... .. ... . ... . i
rtVAX 300 Bus Status Signals . .......................
Interrupt Priority Assignments . ......................
rtVAX 300 Responses to a Quadword-Transfer Read Cycle ..
rtVAX 300 Responses to Octaword-Transfer Read Cycle . . ..
Microcode-Assisted Emulated Instructions. . . . ...........
Processor Status Longword Bit Map . ... ...............
Internal Processor Registers .. .......................
Interrupts . ......... .. e
Exceplions ... ... ...t
System Control Block Format ........................
Nonmaskable Interrupts That Can Causea Halt. ... ... ...

2-8
2-9
2-12
2-14
2-17
2-18
2-29
2-32
3-3
36
3~7
3-15
3-18
3-24
3-28

Exceptions That Can Causea Halt ....................
System Identification Register Fields. . . ................
Cache Disable Register Fields . ... ....................
Memory System Error Register Fields . . ................
..
i
.
........
Boot Options ......
Console Registers SCN 2681 DUART . .. ................
Memory System Control/Status Register Fields . . . ... ....
LED Display/Status Register Fields. . .. .. ..............
...
. ... ... ... ... .
... .......
LEDDisplavChart ....

3-28
3-29
3-36
3-39
342
3-43
3-44
345
3-46

Ethernet Coprocessor Registers . ......................
COROBIts . ... ...
CORIBIits . ... it
CORZ Bits .. ..ot
. ...ttt ittt e
CSR3/CSRA Bits.

348
3-50
3-51
3-51
3-52

rtVAX300 Top View . .. ... ... ... .. i,
rtVAX 300 Bottom View . . . .. ...... ... .. ... ... ... ..
rtVAX 300 Side View .. ... .. ... ... . ...

A-2
A-3
A4

Tables

2-1
2-2
2-3
2-4
2-5
2-6
2-7
2-8
3-1
3-2
3-3
34
3-5
36
3-7
3-8
3-9
3-10
6 b
312
3-13
3-14
315
3-16
3-17
3-18
3~19
3-20
321

322

xvi

CSREBIS ..ttt

3-53 .

3-23

CSREBits ......... ... . .y

3~-57

3-24

CORT BitS . ...ttt
ittt ettt

3~61

325

CORO BitS ...

3-62

3-26

CSRIOBIts ... ...... ittt

3-63

3-27

CSR11, CSR12,CSR13Bits . . ...............oiunn..

3-64

3-28

CSRIA BitS . ...ttt ittt
et e e

3-64

3-29

CORIG Bits . .....ciiii
it
e
i

3-65

3-30

RDESO Fields. . ... ...ttt

3-68

3-31

RDES1Fields. .. ..........
..
i,

3-70

3-32

RDES2Fields. ...........
... .. .
..

3-71

3-33

RDES3 Fields. ........ ... i

3-71

334

Receive Descriptor Status Validity . . ................
...

3-72

3-35

TDESOFields. . ......... ... ... ... ..

...

3-72

3-36

TDES1Fields.

. ...........
... ... .
..

3-74

3-37

TDES2 Fields . .. ........ ... ... i

3-76

3-38

TDES3 Fields. . ........ ... ... .

3-77

3-39

Transmit Descriptor Status Validity. . .. ................

3-77

340

Setup Frame Descriptor Bits . . . . .....................

3-79

341

Ethernet Coprocessor CSR Nonzero Fields After Reset . . . ..

3-85

342

Ethernet Coprocessor Summary of Reported Errors. . ... ...

3-88

4-1

System Type Register Fields ... .........
.. ..... .. ....

4-5

4-2

Firmware Error Messages . . .........................

4-22

4-3

Countdown Status Codes . ...........................

4-27

Boot Countdown Indications .. ......................

4-27

4-5

LED Test Number Code List . ........................

4-29

4-6
4-7

Scratch RAM Offset Definitions . . .....................
Console Mailbox Register Fields ......................

4-34
4-35

4-8

Console Program Flags Fields .. ...........
... .......

4-36

4-9

Default Boot Device Register Fields. . ... ...............

4-38

5-1

rtVAX 300 Data Transfer and Bus Cycle Types ... ........

5-2

rtVAX 300 DAL Parity and Byte Masks . . . ...

..........

5-7

5-3

rtVAX 300 CSDP<4:0> IPR and IACK Codes . . ...........

5-11

Memory Read Cycle Selection . .......................

5-15

Q-_adword and Octaword Read Cycle Transfers .. .........

5-20

5-6

Memory Controller Setup Times . .....................

5-22

DRAM Timing Parameters for 80 ns Page Mode 1M . . . . . ..
Bit x 1. ... . e

5-26

. .

xvii

5-8

xvii

DRAM CAS Before RAS Refresh Timing Parameters . ... ..

5-32 '

5-9
5-10

Application Module Address Decoder PAL . ... ...........
Application Module Address Decoder Equations ..........

5-34
5-36

5-11

Memory Subsystem Sequencer State Machine PAL ... ... ..

543

6-1

SCN 2681 DUART Timing Parameters .................

6~7

6-2

Typical ROM Access Time .. .........................

618

6-3

Decoder Equations . . ..............
... ... .
L,

621

Application Module Address Decoder . ... ...............

6~22

6-5

Console Sequencer State Machine PAL . .. ...........
...

629

6—6
67

Interrupt Decoder . .........
.. ... ... ... . ...
...
Interrupt Decoder PAL Equations . ....................

6~-33
6~35

7-1

MAU Signals Description . . . . ........
... .. ... ........

7-6

7-2

Etnernet Board Parts List . . . ........
... ... .........

7-11

8-1

Response to Bus Errors and DAL Parity Errors

. ... ... ...

8-7

8-2

Q22-bus Map Register Bits . . ..........
... ... ... .....

8-13

8-3

TMS320C25 Digital Signal Processor Memory Map . . . .. ...

8-16

A-1

Recommended Operating Conditions . ..................

A~5

A-2

DC Characteristics . . . ...... ... .ttt

A-5

A-3

ACCharacteristics . . . ... ... .. ittt

A-6

C~1

Memory Space .. ........u ittt

C-1

c-2

Input/Output Space . .........
... ... .. ... ... . .....

Cc~1

c-3

Local Register Input/Output Space ....................

C-2

Preface
The rtVAX 300 is a target processor designed to be embedded in a Digital
Equipment Corporation computing network. The rtVAX 300 processor permits
the coupling of realtime instruments, peripheral devices, sensors, and similar
devices to DECnet, VAX computers, servers, workstations, and terminals. The
rtVAX 300 processor is also compatible with DECwindows applications.
The rtVAX 300 is the minimal hardware that you apply by adding required
memory, I/O devices, interrupt logic, and peripheral chips in order to customize
it to the specific application that you have designed. You can also interface
your own proprietary LSI/VLSI custom integrated circuits to your design,
because the rtVAX 300 permits direct access to its microprocessor bus.

. intended Audience

This book is intended for hardware and software technical personnel who
design and program subsystems and hardware configurations based on
the rtVAX 300 processor. Readers should be familiar with the information
presented in the VAX Architecture Reference Manual.

Document Structure
This document consists of eight chapters and five appendixes:

Chapter 1, Overview of the rtVAX 300 Processor, provides brief descriptions
of the central processor, floating-point accelerator, Ethernet coprocessor,
system support functions, and resident firmware.

Chapter 2, Technical Specification, provides a functional description of
the rtVAX 300 and describes the minimum hardware configuration, bus
connections, pin and signal descriptions, memory and I/O space map and
registers, and bus cycles and protocols.

Chapter 3, Hardware Architecture, contains more detailed information on
the central processor, floating-point accelerator, cache memory, hardware
initialization, console interface registers, and Ethernet coprocessor.

xiX

Chapter 4, Firmware, describes the system firmware ROM format, system
firmware entry, console program, entity-based module and Ethernet
listener, startup messages, hardware CSRs referenced by the rtVAX
300 firmware, a diagnostic test list, user-defined board-level boot and
diagnostic ROMS, creation and down-line loading of test programs, and
ROM bootstrap operations.
Chapter 5, Memory System Interface, describes memory speed and
performance, static and dynamic RAMs, basic memory interface, cycle
status codes, byte mask lines, data parity checking, internal cache control,
mermory management unit, a memory system design example, memory
timing considerations, memory system illustrations, and programmable
array logic.
Chapter 6, Console and Boot ROM Interface, discusses console system
interface, booting from external ROM, the processor status LED register,
console interface and boot ROM illustrations, and programmable array
logic.

Chapter 7, Network Interconnect Interface, describes the rtVAX 300
DECnet communications, Ethernet interface, thickwire network
interconnect, ThinWire support, Ethernet coprocessor registers, and a
hardware implementation example.
Chapter 8, I/O Device Interfacing, discusses I/O device mapping,

the interrupt structure, general bus interfacing techniques, DMA
device mapping registers, an rtVAX 300-to-digital signal processor
application example, reset/power-up, halting the processor, and I/O system
illustrations.
Appendix A describes the physical, electrical, and environmental
characteristics of the rtVAX 300 processor.

Appendix B lists and defines acronyms used frequently in this guide.
Appendix C lists address assignments for memory space, input/output
space, and local register input/output space.
Appendix D is a template for user boot/diagnostic firmware routines.

Appendix E contains a C program that builds a setup frame buffer for the
hashing filtering mode.

. Conventions
This manual adheres to the following numbering and signal-naming
conventions.
Numbering Conventions

All computer addresses are hexadecimal numbers; for example, address
10000000 denotes 10000000,4. All other numbers are decimal-based, unless
otherwise specified.
Digital Sighal-Naming Conventions

A signal name begins with a letter and may end with either H or L.

* H means that the signal is active high—that is, the signal voltage is
between 2.4V and 5.0V.

L means that the signal is active low—that is, the signal voltage is between
0.0V and 0.8V.

The term “Asserted” means that a signal voltage is within the active voltage
range for that signal. For example, the signal AS L is an active low signal; if
this signal is asserted, a voltage between 0.0V and 0.8V is present.

All voltages are specified with respect to the +5V power supply ground that is

used to power the rtVAX 300: 1 is equivalent to high; 0 is equivalent to low.

Signal buses are specified by the following notation:
Signal_Name<HIGHEST_BIT_IN_BUS:LOWEST_BIT_IN_BUS> assertion

For example, the signal DAL<31:00> H represents a 32-bit-wide bus named
DAL, whose bits are numbers 0 to 31; each signal in this bus is active high.
Therefore, if bit number 5 of this bus is connected to a gate, the signal name
for that bit is DAL<05> H.

. Associated Documents
¢

Brunner, Richard A, ed. VAX Architecture Reference Manual. 2d ed.
Bedf~rd, MA: The Digital Press, 1990.

Levy, Henry M., and Eckhouse, Richard H., Jr. Computer Programming
and Architecture: The VAX. 2d ed. Bedford, MA: The Digital Press, 1989.

rtVAX 300 Programmer’s Guide

VAXELN-rtVAX 300 Supplement

xxi

rtVAX 300 Test Box

You can order an rtVAX 300 test box and user’s guide from Design Analysis
Associates. The Design Analysis Associates part number for the text box is
DAA-20RTVX-01.

The address for Design Analysis Associates is:
Design Analysis Associates, Inc.
75 West 100 South
Logan, UT 84321 U.SA.
Phone: (801) 753-2212
FAX: (801) 753-7669

Xxii

s asss E

pAANNA
SA
CHELEL
LY
b4

XXKXX
XRXAXKX
XHKXXKXEXK

AXAEXXLAKKX

P8$.0.0.4.0.0.0.6.0.¢04
P8.0:4.9.0.0.4.5.5.9.0.00.04

.0.00
4 .5.0.9.6.6.4.64
POS.0.0

§ 0.00.4.6.99.0¢.6.8.00094694

b0.0.0.60.0.6.4.0.0.0.¢.0.8¢.66.0.0,04

XXX

XL XA XK AL KK LL XK KKK

PS8400.08.0.60.0.0560606000000
80]
PO OISO GO E0080900608804
60840
08000556
400
000006600
P08

D0 0066000800500 000.80806¢8889.6
PO O EN 000000000886 0868880480¢8004
11010.0.0.0.9.9.6.0.0.0.0.005.8.8.0.0.89.98669989564$00

000000009.0.0.000.000050.606.606898066¢5¢0
J o000 000900000800 0000.08.0.8086988000004]
P00 0000 00.0.0.0.4.8.0.0.6660049.989.668800800008

1004000000 0O IE0$.0800060408898663008800040
000080
PSP P EIIDOD G 9.9.69.8.0.9.0000800¢94.¢808080
PP OOP O IIO DN 5.0.0.0.0006080849.088.60808008988,
0
08,
PRGOS PO OPOPINEI IO EN GO 0E PN I0.8.8000.808800

PO O POV EIEOTO PTG OOF OO OIS D0.0.9.8.8.9.0.800,0.8.0.8.60.00063

Overview of the rtVAX 300 Processor
The rtVAX 300 is a realtime target processor that is adaptable to running

applications that benefit from a fully supported network connection. Designed
to be embedded in a robust computing network, the rtVAX 300 processor is a
117 mam x 79 mm (4.61 in. x 3.11 in.) module encapsulated in a black painted
metalilic cover.
The rtVAX 300 processor 1s intended to work in the following situations:

Distributed applications that are part of a Digital computing network

Customized, embedded, standalone hardware

Remote data acquisition and computing platform that can be linked to use
Digital da.a communication message protocc.

DDCMP) serial lines

Applcations that use proprietary I/O buses and industry-standard buses,

such a¢ the VME bus or the IBM PC/AT
e

App

s that interface with industry-standard LSI/VLSI peripheral

chias
The rtVA.
handle y¢

'~
-

-ocessor is the basic hardware element that you extend to
3,

:ation, adding only the memory and I/O devices that you

need.

Many face - - £ ithe final system, from memory and I/O to power and packaging,
are under . 7 control.
When a &::5:

.5 2681 dual universal asynchronous receiver/transmitter (SCN

2681 DUA!:T)

serial-line chip is added to its configuration, the rtVAX 300

processor ¢. 1 support a console terminal.

Overview of the tVAX 300 Processor

1-1

1.1 Central Processor

‘

The central processor is implemented by using Digital's CVAX chip. This chip
contains about 180,000 transistors and supports full VAX memory management
and a 4G-byte virtual address space.
The CVAX chip contains all VAX vigible general-purpose registers (GPRs), a
1K-byte instruction/data cache, all memory management hardware, including
a 28-entry translation buffer, and several system registers—~such as the cache
disable register (CADR), memory system error register (MSER), and system
control block base register (SCBB).

The CVAX chip provides the following functions:
¢

Fetches all VAX instructions

Executes 181 VAX instructions

Assists in the execution of 21 additional instructions

Passes 70 floating-point instructions to the CFPA chip

‘

The remaining 32 VAX instructions (including H-floating and octaword) must
be emulated in macrocode.

The CVAX chip provides the following subset of the VAX data types:
¢

Byte

Word

Longword

°*

Quadword

Character-string

¢ Variable-length bit field
Macrocode emulation can provide support for the remaining VAX data tyves.
The cache is a 1K-byte, 2-way associative, write-through cache memory that is
implemented within the CVAX chip.

1.2 Floating-Point Accelerator
The floating-point accelerator is implemented by the CVAX floating-point
accelerator (CFPA) chip. The CFPA chip contains about 60,000 transistors and
executes 70 floating-point instructions. The CFPA chip receives operations code
information from the CVAX chip and receives operands directly from memory
or from the CVAX chip. The floating-point result is always returned to the
CVAX chip.
1=2

Overview of the tVAX 300 Processor

‘

. 1.3 Ethernet Coprocessor
The rtVAX 300 processor contains the second-generation Ethernet coprocessor
(SGEC) chip and can pass data and instructions to and from other stations on
a network without processor intervention.
The Ethernet coprocessor has the following attributes:
Supports ThinWire and thickwire Ethernet interfaces to the rtVAX 300

processor’

Contains 16 control and status registers (CSRs) that control its operation
Resets hardware and software and handles interrupts

Supports the full IEEE 802.3 frame encapsulation and media access control
Supports three levels of testing and diagnostics

1.4 System Support Functions
System support functions provided by the rtVAX 300 processor include:
Halt/boot-request arbitration logic
Interval timer with 10 ms interrupts
Flexible interface to the rtVAX 300 processor’s DAL bus
Ethernet thickwire connections

Control logic to attach a console terminal

1.5 Resident Firmware
Resident firmware consists of 256K bytes of ROM. Firmware gains control
when the processor halts; it contains programs that provide the following
services:

Board initialization

Power-up self-testing of the rtVAX 300 processor and its attached memory
system

Ethernet is synonymous with IEEE 802.3; ThinWire, with IEEE 802.3 10BASEZ2;
thickwire, with IEEE 802.3 10BASES5.

Overview of the ntVAX 300 Processor

1-3

Emulation of a subset of the VAX standard console (automatic/manual
bootstrap and a simple command language for examining/altering the state
of the processor)

Booting from ROM, network, or DECnet DDCMP

The rtVAX 300’s firmware interface is extensible: you can use it to add your
own power-up initialization and self-test diagnostics.

1~4

Overview of the rnVAX 300 Processor

XL
AXXEK

KUXAAK

K,
KAKAXKKK

p69090090481
XK
XAXKKAKAX

p10.9.4.4.4.4.9.9.0.9.0.$.9.04¢

X
KN EAKAKAAXX
XXMAE

KAXXEAAAKAXKXKELKAKAK
p.9.6.0.9.0.0.6.9.0.40.0.8.640,44664

KAXX KA XA XX KX XK XX XX KL XLX
00009008008008¢8094
PO 08860

0484
P OO H 0000400008.050005048488

PP E 0PN IS
PO OSSN P

IO L 0P8 60.080.¢0

S0 0000069005004804

O 4 00.6.0.6.0.0.00.800000060848 0086000060

K AXXEXKKAXKKLX
KX KX KK R XX XEKAE
XAAKA
8806490
}4.0.9.60.9.0.0.0.0.0.0.68.0900.869.90560.00¢8

8
6808
Pe.80.0600.809.600.¢86660006¢.0.06000089004
P 00000088.6.0.8.0000006086008000680048000840
KUXR XXX XL KX KA KA AKX LKA KK XX AR KK LXK IAKKKK XK

P OOV OO

D 0.9806000.900.00.000.909.080068088088;

P o9 000000.6000.0.0¢90.90040.08.69.06¢9$6.8609004090099.8,
PO00.9.0:0.9.0,0:0:0.0.08.0:0.0.0:0.0.6.5.6.0,089.0.60.0.6:0,0.0.:0.89.60,009¢6.8¢0;

P O060

00PN SIS 000000007806¢0.000000.69900840,

2
Technical Specification
0

This chapter discusses the technical specifications of the rtVAX 300 processor,
covering the following subjects:

Functional description (Section 2.1)
Minimum hardware configuration (Section 2.2)
Bus connections (Section 2.3)

Pin and signal description (Section 2.4)
Memory and I/0 space (Section 2.5°

Bus cycles and protoecols (Section 2.6)

2.1

Functional Description
The functional description of the rtVAX 300 processor consists of the following:
Architecture summary (Section 2.1.1)

Processor and floating-point accelerator (Section 2.1.2)
L4

ROM and reserved memory locations (Section 2.1.3)
Network Interface (Section 2.1.4)

Decode and control logic (Section 2.1.5)
Interrupt structure (Section 2.1.6)
DMA structure (Section 2.1.7)
Interval timer (Section £.1.8)
Internal cache (Section 2.1.9)

Technical Specification

2-1

2.1.1

Architecture Summary
Based on Digital’s CVAX microprocessor chip, the rtVAX 300 processor contains
an Ethernet coprocessor, a floating-point accelerator, an interval timer, control
logic, and a diagnostic and boot ROM. Figure 2-1 shows a block diagram of the
rtVAX 300 processor.

The rtVAX 300 processor provides a common interface to the user logic as

close t» the CVAX microprocessor bus interface as possible. The rtVAX 300
processor can access up to 510M bytes of physical memory; 256M bytes are

read/write memory, and 254M bytes are recad/only memory. All memory is
directly accessible by its Ethernet coprocessor and is cacheable by the CVAX.
The rtVAX 300 also provides access to 512M bytes for I/0 space. Accesses in
170 space are not cached.

2.1.2 CPU and CFPA
The processor on the rtVAX 300 is Digital's CVAX chip with its associated
CVAX floating-point accelerator (CFPA). The rtVAX 300 runs VAXELN software
based on the VAX instruction set. The VMS and ULTRIX operating systems
are¢ not supported on the rtVAX 300.

2.1.3 ROM and Reserved Memory Locations
The upper 2M bytes of memory space are reserved for Digital. The lowest 2M

bytes of /O space are the rtVAX 300 lecal register 1/0 space intended for the
user. The rtVAX 300 processor stores in /O space its self-diagnostic routines,
console emulation program, other routines that it needs to boot bootstrapsupported devices, registers, and the Network ID ROM. The rtVAX 300 tester,
console serial-line unit (SLU), and boeard-level initialization and diagnostic
ROMs can also use a portion of this I/O space.

2.1.4 Network Interface
The Ethernet controller, or Network Interface (NI), shown in Fizure 2-1,

cunnects the rtVAX 300 processor to the Ethernet. It consists of the Ethernet
coprocessor, which interfaces to the CVAX chip data and address line (DAL) bus
and the serial interface adapter (SIA), to allow users t. connect to Ethernet.
Details of the connection to thickwire and ThinWire Ethernet are in Chapter 7.
The Ethernet coprocessor can perform direct memory access (DMA) to any

location in memory space. This controller is programmed by reading from,
and writing to, a set of registers in the Ethernet coprocessor, SGEC Refer to
Section 2.5.)

2-2

Technical Specification

rtVAX 300 Block Diagram

Figure 2-1

CLKA

CLKB

CLKIN
CLK20
I

—3

IRQ<3:0>

| IRQ<t>

CSDP<d>

interrupt
Arb. Logic

oSOP

SDP«3:0>

BM<3:0>

CVAX
IACK

BM and

| cspp

Buffers

IRQ

]

Ethernet

SIA

Coprocessor

DAL<31:00>

>
<
>

€

DAL
Buffers

DMR

DMG

NI_DMR

NI_DMG

DMA

Arb. Logic |

USER_DMG

1TM
|
System
and NI

ROMs

USER_DMR

Buff

Boot
Reg.

Decode ___]
Logic

AS, DS

CFPA

Buft

CCTL, RDY, ERR
MLO-006367

Technical Specification

2--3

2.1.5 Decode and Control Logic

The control logic consists of state machines responsible for the following: RDY
signal generation for the ROMs, DMA and interrupt arbitration between DMA
devices and the Ethernet coprocessor, and decoding internal addresses to
control the output buffer direction and to assert CSDP<4> L.

‘

The control logic also provides the counters for generating the timeout error
signal and the 10 ms interval timer interrupt.

2.1.6 Interrupt Structure
The rtVAX 300 processor has access to the four interrupt request lines that the

CVAX chip uses. Interrupt request line 1 (IPL 15,4) is daisy-chained to the

user through the Ethernet coprocessor, giving the Ethernet controller a higher
priority than devices connected to this line.

‘

Interrupt acknowledge cycles responding to the Ethernet coprocessor are
marked as internal cycles and are indicated by the assertion of CSDP<4> L.

Hardware external to the rtVAX 300 processor should ignore such cycles.

2.1.7 DMA Structure
The rtVAX 300 processor issues a DMA grant signal that is daisy-chained to

the user through the Ethernet coprocessor, giving the Ethernet controller the ‘
highest DMA priority.

The rtVAX 300 processor relinquishes the bus once it grants DMA control to
the user hardware; however, the rtVAX 300 processor monitors the AS L line,
the CCTL L line, and the DAL lines to invalidate the appropriate cache entries
during DMA write cycles, if the CCTL L line is asserted.
Note

A DMA device should not hold the rtVAX 300 bus for more than 6 ps.
If such a device requires the bus for a longer time, it should relinquish
the rtVAX 300 DAL lines by deasserting DMR L and request it again.

2.1.8 interval Timer
The interval timer generates a 50% duty cycle 100 Hz TTL square wave.

This signal interrupts the CVAX once every 10 ms for VAXELN system clock
updates.

2-4

Technical Specification

. 2.1.9 internal Cache

The CVAX has a 1K-byte write-through cache as part of the chip. Chapter 3
describes the organization of this cache.

2.2 Minimum Hardware Configuration
The rtVAX 300 processor is a platform that requires additional hardware
to be usable. Section 2.2.1 and Section 2.2.2 list the minimum hardware
requirements needed for the rtVAX 300 processor.

2.2.1

System RAM
The rtVAX 300 processor contains no RAM; however, in order for the rtVAX
300 processor to run its power-on self-test diagnostics successfully and issue
the console program prompt, the processor needs at least 64K bytes of RAM.
Under DECnet Phase IV, at least 512K bytes are needed to boot a VAXELN
system image with the Ethernet driver, local and remote debuggers, and a
200K-byte user application. The RAM resides in VAX memory space beginning
at physical address 00000000.

2.2.2 Console
The rtVAX 300 processor needs no console; however, a console port is required
in order for the processor to use the console emulation program, report errors
and warnings, and display system crashes.

The rtVAX 300 processor supports the Signetics 2681 dual universal
asynchronous receiver/transmitter (SCN 2681 DUART) or a compatible
device as a console interface. The data lines of the SCN 2681 DUART should
be connected to the DAL<07:00> H lines. When the DUART is read from or
written to, the BM<0> L line should be asserted. The rtVAX 300 processor uses
channel A of the DUART for the console. Channel B is available and can be
used by the application, for example, to load an application image over serial
lines. A VAXELN device driver supports both channels.
The console (IPL 14,¢) is associated with interrupt request line IRQ<0> and
the vector 02C05¢.
The control logic has assigned locations for the registers that the SCN 2681
DUART uses. These registers are decoded/assigned addresses in the rtVAX
300's local register I/O space. (Table 3—-13 lists the physical address of each
register. Chapter 6 contains details on how to connect the SCN 2681 DUART
to the rtVAX 300.)

Technical Specification

2-5

2.3 Bus Connections

Figure 2-2 shows a typical interface configuration of the rtVAX 300 processor

and includes control signals and bus connections. All signals are TTL levels,
except for the Ethernet differential pairs.
Figure 2-2

Typical rtVAX 300 Environment

VAN
tVAX 300

Thickwire

DAL<31:00>

Network

Backbone

...
M

.
Isolation

User'

Defined

Transformer j—

Hardware

Console

Control
Lines

MLO-008368

2.3.1

Power Connections
The rtVAX 300 processor requires a +5V/2A dc power supply. Seven pins are
provided to connect to +5V, and seven pins for +5V return. The four mounting

holes can also serve as a ground connection. The power decoupling and proper
ground connections are very important. (Refer to Section A.Z for detailed
information.

2.3.2 Reset and Power-Up Requirements
Asserting the RST L signal for a minimum of 30 clock periods resets the
rtVAX 300 processor. This line must be deasserted within the specified time
before the rising edge of CLKA. Figure 2-3 shows the timing cycle of the reset
function.

2-6

Technical Specification

‘

Figure 2-3 Timing Cycle for Reset Function
P1

aa /N

../
./
\.
awe \_/ \_/ "‘“’ /S
R&T

DMG

DAL
BM
WR
DPE

CsDP

MLO-004380

Note

Timing diagrams within this manual often contain circled numbers;
Table A-3 explains their meanings.

2.3.3 Power-Down Sequencing: Power-Fail

The system power supply conditions external power and transforms it for use
by the processor. When external power fails, the power supply requests a
power-fail interrupt of the processor by asserting the PWRFL L signal. The

PWRFL L signal is a maskable interrupt at IPL 1E¢.

The power supply must continue to provide power to the processor for at least
2 ms after the interrupt is requested, in order toc allow the operating system
to save state. When the power supply can no longer provide power to the
processor, the processor halts through the assertion of the HLT L signal. (Refer
to Appendix A for a summary of electrical characteristics.)

Section 2.4.8 and Table 2-1 define the PWRFL L control signal and its
functions.

Technical Specification

2-7

2.4 Pin and Signal Description

This section briefly describes the input-output signals and power and ground
connections of the rtVAX 300 processor. Table 2-1 lictc bus and interface
signals and their functions. Table 2-2 lists pin assignments; Figure 2—4 shows
the pin layout.

Table 2-1

Bus Interface Signhals

Signal

Meaning

+5V

+5V power supply

ASL

Address strobe

BM«<3:0> L

Byte masks

BOOT<3:0> L

Boot select pins

BTREQ L

Ethernet coprocesser boot request signal

CCTL L

Cache control, for cache invalidation and selective caching

CLRK20

20 MHz clock output

CLKA/CLKB

CPU clock outputs

CLKIN

System clock input signal

COL+/COL~

Ethernet collision detect differential pair

CSDP<«4:0> L

Control status/data parity

DAL<31:00> H

Data and address lines

DMG L

Direct memory grant

DMR L

Direct memory request

DPE L

Data parity enable

DSL

Data strobe

ERR L

Bus error input

GND

+5V ground (return)

HLT L

Halt processor interrupt

INTIM

10 ms timer—100 Hz 50% duty cycle output

IRQ<3:0> L

Interrupt request

PWRFL L

Powerfail

RCV+/RCV-

Ethernet receive data differential pair
{continued on next page}

2-8

Technical Specification

Table 2-1 (Cont.) Bus Interface Signals

Signal

Meaning

RDY L

Bus ready input

RST L

Reset input

WR L

Read/write

XMT+/XMT-

Ethernet transmit data differential pair

Table 2-2 ntVAX 300 Processor Pin Description

Signal

In/Out Definition/Function

Al, Al15 A31,B6,

GND

+5V ground return

A2, Al6, A32, B5,

45V

+5V dc power

A6-A3

BOOT<3:0> L

Defines the boot device

BTREQ L

INTIM

B14, B32, B50

B13, B31, B49

Remote Ethernet boot request from

the coprocessor

100 Hz interval timer clock output

Al12-A9

BM<3:0> L

OfZ

Byte masks

Al3

DMG L

DMA grant

Al4

DMR L

DMA request

Al7

RST L

Reset

AlB

HILT L

Halt processor

Al9

PWRFL L

Indicates loss of ac power

A24-A21

A25

IRQ<3:0> L

User-defined in*errupt request lines

A26

CCTL L

RDY L

I/0/Z

Bus ready

A27

ERR L

VO/Z

Bus error

A28

DSL

OrZ

Data strobe

A29

WR L

10/

Read/write

A30

ASL

O7Z

Address strobe

A36

XMT-

Thickwire transmit data —

/O/Z Cache control

(continued on next page

Technical Specification

Table 2-2 (Cont.)

rtVAX 300 Processor Pin Description

Signal

in/Out

Definition/Function

A38

XMT+

Thickwire transmit data +

A40

RCV-

Thickwire receive data —

A42

RCV+

Thickwire receive data +

Ad4

COL~

Thickwire collision detect —

A46

COL+

Thickwire collision detect +

CLKIN

System clock input

CLKA

Clock A output

CLK20

20 MH:z clock output

CLKB

Clock B output

B10-B7

CSDP<3:0> L

VO/Z

Control status and parity information

B11

CSDP«4> L

O/Z

Ethernet interrupt acknowledge cycle

B12

DPE L

V/O/Z

Data parity enable

B48-B33,

DAI<31:00> H

I/O/Z

Data and address multiplexed bus

B30-B15

Note

All TTL inputs except CLKIN have an internal 2K {2 pull-up. All
outputs are driven by the ACTQ 244 or ACTQ 245 buffers. Signal
designations are as follows:
Signal

2-10

Designation

Meaning

Input

Output

Open-drain bidirectional

Tri-stateable bidirectional

Technical Specification

Figure 2-4

rtVAX 300 Pin Layout

View of Application Board Socket

A
i1

B
2

GND
BOOT<0>]
BOOT<2>]
BTREQ
BM<0>
BM<2>
OMG

O O +8v
O O BOOT<«1>
O O BOOT<3>
O O INTIM
O O BM<1>
O O BM<3>
O O DMR

GND
RST

O O 45V
O OHLT

DAL<00s O O | DAL<O1>
DAL<02> O O | DAL<O3>

PWRFL
IRQ<GC>
IRQ<2>
CCTL

0]
blank keypin
O O IRQ<«1>
O O IRQ<3>
O O RDY
O 0ODs

DAL<04> O O | DAL<O5S>
DAL<06> O O | DAL:07>
DAL<08> O O | DAL<09>
DAL<10> © O | DAL<11>

ERR
WR
GND
reserved
reserved
raserved
reserved
reserved
resarved
reserved
reserved
reserved

O C AS
O O +5v

MLO-006378

2.4.1

Data and Address Bus
The data and address lines, DAL<31:00> H (I/O/Z), form a time-multiplexed
bidirectional bus that transfers address, data, and other information during
bus cycles.

Technical Specification

2-11

During the address portion of a bus cycle, the following occurs:
e

DAL<31:30> H provide information on the type of cycle, as indicated in
Table 2-3.

DAL<29> H is asserted when the rtVAX 300 processor accesses I/O space;
otherwise, it is deasserted.

DAL<28:02> H provide the physical address of the device being accessed.

DAL<01:00> H are reserved.

During the data portion of a bus cycle, the DAL lines carry data to or from the
user hardware.
Table 2-3

DAL<30> H

Description

Longword read/write

Quadword read (Quadword writes do not occur)

Octaword read/write

2.4.2 Ethernet Connecticns
The rtVAX 300 processor allows you to connect to Ethernet by means of
standard thickwire connections through a 75 nH isolation transformer, as
shown in Figure 2-5. Connection to ThinWire is also straightforward. (For
more information, refer to Chapter 7.)
Signals are as follows:
Collision Detect (COL+, COL~) (non-TTL)

This differential pair of wires connects through a user-supplied isolation
transformer to a user-supplied 15-pin D-sub connector, when the rtVAX

300 processor is counected te a media attachment unit (MAU) with a
transceiver cable. See Figure 2-5. These two signals are used for the
collision detect. The rtVAX 300 supplies 78 2 termination on these lines.
Chapter 7 discusses this connection in greater detail.
e

Receive (RCV+, RCV-) (non-TTL)

This differential pair of wires connects through a user-supplied isolation
transformer to a user-supplied 15-pin D-sub connector, when the rtVAX 300
processor is connected to an MAU with a transceiver cable. The rtVAX 300
supplies 78 12 termination on these lines. See Figure 2-5.

2-12

DAL Lines

DAL>31> H

‘

Technical Specification

‘

®* Transmit (XMT+, XMT-) (non-i7'L)
This differential pair of wires connects through a user-supplied isolation
transformer to a user-supplied 15-pin D-sub connector, when the rtVAX 300
processor is connected to an MAU with a transceiver cable. See Figure 2-5.

Thickwire Connectiana

Figure 2-5

15 Not Connected —— ——O

14 Chassis GND

—~O

12 +12V Source

—-.O

12 RCV -

-O

11 Chassis GND

—.O

10 XMT -

9 COL -

O.— —— 7 Not Gonnected
Oo— ——— 6 Reference GND

O--—-— 5 RCV +
0- 4 Chassis GND

O-—- e 3 XMT +
O.— — 2COL +

€

——— 8 Chassis GND

——— 1 Chassis GND

15~Pin D-Sub (Female) View
.

MLO-004391

2.4.3

Bus Control Signals
Bus control signals are as follows:
¢

Address Strobe (AS L) (O/Z)

This signal indicates that valid address information is available on the
DAL<29:02> H bus, and valid status information is on the BM«<3:0> L,

CSDP<4:0> L, and WR L lines. The leading edge of this signal can be used
to latch the address and status information.

Technical Specification

2-13

Note ___

‘

BM«<3:0> L must be latched during quadword and longword cycles and
must flow through during octaword access cycles.

During a DMA transfer, the rtVAX 300 processor uses the assertion of AS

L to latch the DMA address, which is used in a cache invalidate cycle when
CCTL L is asserted.
*

Data Strobe (DS L) (O/Z)

This signal indicates that the DAL<31:00> H and CSDP<3:0> L lines are

free to receive data and parity information during a vead cycle or that

valid data is on the DAL<31:00> H lines and valid parity on CSDP<3:0> L
during a write cycle.

‘

Byte Masks (BM<3:0> L) (0/Z)

These signals indicate which bytes of the DAL lines contain valid data, as
listed in Table 2—4.
Table 24

Byte Maske

Byte Mask

Description

Data Byte

BM<0> L

Low byte of low word

DAL«07:00> H

BM«1> L

High byte of low word

DAL<15:08> H

BM<2>L

Low byte of high word

DAL«<23:16> H

BM<3> L

High byte of high word

DAl<31:24> H

For a read cycle, byte masks indicate which bytes of the DAL lines must

have data driven onto them; for a write cycle, they indicate which bytes
of the DAL lines contain valid data. Lines BM«<3:0> L are valid when

the AS L signal is asserted during quadword and longword access cycles.
Octaword transfer cycles require that these lines not be latched.
*

Write/Read (WR L) (O/Z)

This signal specifies the direction of a data transfer on the DAL bus
for the current bus cycle. When the signal is asserted, the rtVAX 300
processor is perferming a write operation; when the signal is deasserted, it
is performing a read operation or interrupt acknowledge cycle. The WR L
signal is valid when AS L is asserted.

2-14

Technical Specification

‘

Ready (RDY L) VO/2)

External logic asserts this signal to indicate the cumpletion of the current
bus cycle. When this signal is not asserted, the rtVAX 300 processor
extends the current bus cycle for a slower memory or peripheral device.
The RDY L or ERR L signal must be asserted to end the current bus
cycle. These signals must be driven by tri-state drivers. Both signals can
be asserted simultaneously to force the rtVAX 300 processor to retry the
current pus cycle.
During internal cycles (CSDP<4> L asserted), the rtVAX 300 processor
drives RDY L high. The rtVAX 300 processor asserts RDY L before the end
of an internal cycle. The rtVAX 300 processor dees not drive the RDY L
signal on non-internal cycles.
Note

During quadword cache invalidate cycles, AS L must remain asserted
for at least 250 ns, which equates to a 4-microcycle write cycle. (Two
wait states must be added.) Memory systems faster than 400 ns must
delay cache invalidate write cycles at least two microcycles by holding
off the assertion of RDY L. Slower memory systems already adhere
to the minimum AS L assertion requirement during cache invalidate
cycles. Write cycles that do not involve cache invalidation (CCTL L not
asserted) and read cycles can occur without wait states.

Error (ERR L) (1/0/Z)
External logic asserts this signal to indicate an error associated with
the current bus cycle and to end the bus cycle. The rtVAX 300 processor
asserts this signal when a bus timeout condition occurs. Either the ERR L
or the RDY L signal must be asserted to end the current bus cycle. RDY L
and ERR L are synchronous inputs and must be asserted within the timing
values specified in Section 2.6.
Note

The rtVAX 300 processor has an internal timer that aborts any read
or write cycle if an RDY L or an ERR L signal is not received from
16 to 32 ps after AS L is asserted. This provides for the bus timeout
feature and prevents the rtVAX 300 processor from hanging when
communicating with a nonexistent or faulty memory or I/0 device.

Technical Specification

2-15

® Cache Control Signal (CCTL L) (VO/Z)

During a DMA cycle, assertion of this signal by external logic initiates a
conditional cache invalidate cycle. The internal Ethernet controller also
asserts this signal during DMA write cycles.
During an rtVAX 300 read cycle, this signal is asserted to prevent the
accessed data from being stored in the internal cache memorv of the rtVAX

300. CCTL L is level-sensitive and must be asserted synchronousiv with
the timing sampling point for the rtVAX 300 processor read cycle.

2.4.4 Bus Retry Cycles

External hardware can force the rtVAX 300 processor to retry the current
bus cycle by asserting both RDY L and ERR L at the same time. This has no

effect on the current bus cycle; the data are transferred later, when the cycle is
successfully retried. Only longword and quadword processor access cycles can
be retried; octaword and Ethernet controller cycles cannot be retried.

2.4.5 Status and Parity Control Signals
Status and parity control signals are as follows:
¢

Data Parity Enable (DPE L) (I/0/2)

This signal controls the checking and generation of data parity. During an
rtVAX 300 read cycle or an interrupt acknowledge cycle, DPE L is asserted

by external logic to enable data parity checking by the rtVAX 300. During
an rtVAX 300 write cycle, the rtVAX 300 asserts DPE L to indicate to

external logic that valid parity information is on CSDP<3:0> L.
*

Control Status and Data Parity (CSDP<4:0> L) (1/0/Z)
These lines transfer cycle status and data parity information between the
rtVAX 300 processor and external devices. During the first part of the

bus cycle, CSDP<4:0> L and WR L provide status information about the

current bus cycle, as listed in Table 2-5. CSDP<3> L indicates the set
in internal cache memory that is being allocated during a cacheable read
operation and is undefined during all other bus cycles. CSDP<3> L is

asserted to specify set 1 and negated to specify set 2.

216

Technical Specification

Table 2-5 rtVAX 300 Bus Status Signais
CSDP

WRL

«d>L

«2>L

«<1>L

«<«0>L

BusCycle Type

Request D-stream read

Reserved

External IPR read

External interrupt acknowledge

Request I-stream read

Demand D-stream read (lock)

Demand D-stream read (modify intent)

Reserved

External IPR write

Reserved for use by DMA devices

Reserved

Write unlock

Reserved

Write no unlock

Reserved (rtVAX 300 internal interrupt

Demand D-stream read (no lock or

modify intent)

acknowledge cycle only)

During the second part of the bus cycle, the CSDP<3:0> L lines are used
to transfer byte parity information for the DAL line data during a read or
write cycle. During the read cycle, the rtVAX 300 processor checks parity
on all four bytes, regardless of the assertion of the BM<3:0> L signals. On
a write cycle, the rtVAX 300 generates data parity on the CSDP<3:0> L
lines.

Technical Specification

2-17

2.4.6 Interrupt Control

The IRQ<«3:0> L lines are asynchronous interrupt request lines. External logic
uses them to indicate interrupt requests to the CVAX. The rtVAX 300 sainples
‘he lines every microcycle, and they must stay asserted until the end of the
interrupt acknowledge cycle.
Although the rtVAX 300 Ethernet coprocessor shares IRQ<1> L on the CVAX,
the coprocessor is serviced before the user interrupt. Table 2-6 lists the
interrupt priority level (IPL) assignments as they relate to IRQ<0> L and
IRQ<1> L.

Table 2-6

Interrupt Priority Assignments

IRQ L

IPLse

Device

IRQ<0>

User-defined, shared with external console

IRQ<1>

User-defined, shared with the Ethernet coprocessor

IRQ<2>

User-defined, shared with the interval timer

IRQ<3>

User-defined

2.4.7 DMA Control Signals
DMA control signals are as follows:
¢

DMA Request (DMR L) (I)

External logic uses this signal to request control of the DAL bus and its
related control signals.
DMA Grant (DMGL){O)

This signal indicates that the rtVAX 300 processor has granted the use of
the DAL bus and its related control signals.
Note

Both DMA request and DMA grant signals are daisy-chained from

the CVAX processor through the Ethernet coprocessor chip inside the
rtVAX 300 to the user-defined hardware. Therefore, the Ethernet
coprocessor has the first priority for a DMA. In addition, to prevent
Ethernet FIFO overfiows, a user device cannot remain bus master
longer than 6 ps.

2-18

Technical Specification

‘

. 2.4.8 System Control Signals

System control signals are as follows:
Reset (RST L) (I)

This signal initializes the rtVAX 300 processor to a known state. This line
must be asserted on power-up.
Halt (HLT L) (I)
This signal causes a nonmaskable interrupt at IPL 1F;g that causes
the rtVAX 300 processor to enter the console emulation program in
the firmware. This signal is negative-edge-triggered and internally
synchronized.
Power Failure (PWRFL L) (I)

This signal allows external logic to notify the rtVAX 300 of a power failure.
The rtVAX 300 processor samples the signal every microcycle. The PWRFL
L signal generates an interrupt at IPL 1E;g. This interrupt is internally
acknowledged by the rtVAX 300 and does not use an interrupt acknowledge
bus cycle. This signal is edge-sensitive and internally synchronized.
Boot (BOOT<3:0> L) (I)

These pins determine the default boot actions of the rtVAX 300. These
signals are pulled up internally and default to 1. When a pin is low, it
registers a . (See Table 3-12 for different allowable boot devices.)
Boot Requests (BTREQ L) (OD)

This signal is asserted low once a valid trigger request is received over the
Ethernet from a host system. This lead is gated with a board-level remote
trigger enable signal and fed into the HLT L signal.

2.4.9 Clock Signals
Clock signals are as follows:

20 MHz Clock Output (CLK20) (O)
This taps into the internal oscillator and can be fed back into CLKIN to
drive the rtVAX 300.
Note

Use this signal only to drive CLKIN.

Technical Specification

2-19

e System Clock Input (CLKIN) (I)

This system clock input must be a TTL-compatible oscillator at a maximum
frequency of 20 MHz. A lower frequency clock can be used to lower power
consumption or to match the processor to slower memory devices. The duty

‘

cycle must be 50%.

Basic Clock Output (CLKA) (O)
This TTL buffered clock must be used to synchronize the rtVAX 300
external logic and the CPU bus cycles. This clock provides the P1 and P3
timing reference.

Note

‘

In the following two items, all timing is referenced to CLKA and CLKB.

Basic Clock Output (CLKB) (O)
This TTL buffered clock must be used to synchronize the rtVAX 300
system. This clock provides the P2 and P4 timing reference.

10 ms Interval Timer (INTIM) (O)
This signal produces a 10 ms TTL square wave (50% duty cycle).

2.4.10 Power Supply Connections
Power supply connections are as follows:
*

+5V dc power (+5V)

Reference ground, +5V return (GND)

2.5 Memory and I/O Space
The rtVAX 300 processor can access 510M bytes (256 R/W and 254 R/O) of
memory space and an I/O space of 512M bytes. The Ethernet coprocessor has
direct access to all memory space.
2M bytes of I/O space are used for local registers. (Refer to Appendix C.)
Figure 2-6 shows the partitioning and layout of memory. (Undesignated
shaded areas are reserved.) In addition to the registers shown in Figure 2-6,
the rtVAX 300 processor contains internal processor registers, as described in
Chapter 3. Table 3-3 lists and describes internal processor registers.

2-20

Technical Specification

‘

Figure 2-6 rtVAX 300 Memory and /O Space

201FEF
FFFFC
201

,.'!

3FFFFFFF

20110003

20200000

201FFFFF

Local Register /1O

;

[}

User /O

Space

'.'

User Boot

FORFEEY
10000000
OFFFFFFF

00000000

ROM

System RAM

2010003F

00
201000
Console Registers | 200
FFFFF
or Dlagnostic

AFFFFFFF

0000
FDFFFFF

20110000

ROM

20080000

Boot FOMs

2007FFFF

Boot Registeer
\

200
3FF00FF
200400

2003FFEC

2001007F

20010000

‘

0803F
4 200
20008000

s| [

MLO-006366

The rtVAX 300 accesses memory in bytes, words (2 bytes), longwords (4 bytes),
quadwords (8 bytes), or octawords (16 bytes). However, quadword and octaword
accesses are restricted to the system RAM portion of the memory space.

The rtVAX 300 read/write memory is organized into four banks, as shown
in Figure 2-7. The rtVAX 300 issues longword addresses on the DAL bus.
You can read from or write to any byte of any memory location by using the
different byte mask signals.

Technical Specification

2-21

Figure 2-7 rtVAX 300 Memory Bank Organization

Bank 3

Bank 2

< DAL <31:24>
BM<3>

Bank 1

qe ]

DAL <23:16>

BM<2>

Bank 0

qel

DAL <15:08>
BMci>

DAL <07:00>
BM<0>
MLO-006380

2.5.1

Address Decode and Boot ROM
The internal ROM address latch logic latches the address on the DAL bus
and drives it on the ROM address bus to the boot and diagnostic ROMs, the
Network Interface address decode logic, and the Network Interface address
ROMs. The ROM address decode logic decodes the address on the DAL bus to
provide control signals for the ROMs and the boot register.

2.5.2 Boot ROM
The boot ROM contains the boot drivers, self-test diagnostics, and console
emulation program. It also accesses the registers used by the Ethernet

coprocessor and the registers used by the user-provided console ports.
The boot register is a read-only register that resides at address 2003FFEC.
The firmware reads this register on power-up to determine the default boot

device and whether or not to enable remote console and remote trigger. (For
additional information on the boot register, see Figure 3-14.)

2~-22

Technical Specification

' 2.5.3 Programming the User ROMs

The system image generated by the VAXELN System Builder (EBUILD) is
first down-line loaded by using the network as the booting device on the
rtVAX 300 target. You can use the remote and local debuggers to debug the
application software. Once the application software is running correctly, you
should generate a new system file by selecting the ROM as the boot method
and then run the resulting .SYS file through the PROMLINK program to
create a loadable file for the EPROM burner. The ROMs are then inserted
into the EPROM programmer, programmed, and then inserted into their
correct sockets. Then, the BOOT pins <2:0> L can be connected, as shown in
Table 312, and the rtVAX 300 will boot from these ROMs.

2.5.4 Network Interface Registers
The Network Interface on the rtVAX 300 is programmed by reading from and

writing to a set of 16 Ethernet coprocessor registers located from 20008000
to 2000803F. In addition to the 16 registers, the Ethernet ID ROM, providing
the physical network address for the rtVAX 300, is located from 20010000 to
2001007F.

For detailed information on programming the Ethernet coprocessor chip, refer
to Chapter 3.

2.5.5

Board-Level Initialization and Diagnostic ROMs
1/0 space locations 20080000 through 200FFFFF are available for use by
the user-supplied board-level initialization and diagnostic ROMs. After the
firmware finishes executing the processor, CFPA, and ROM self-tests, it checks
for an external ROM mapped to 20080000. If the ROMs exist, control is

transferred to them. They can then perform board-level initialization and
diagnostics, define a new boot device, and execute the RET instruction to
return to the internal firmware for memory testing and bootstrapping. If
user/boot diagnostic ROMs do not exist, the rtVAX 300-resident firmware
continues with memory tests and Yootstrapping. Chapter 4 provides further
programming information.

Technical Specification

2-23

‘

2.6 Bus Cycles and Protocols

The rtVAX 300 processor performs bus cycles when one of the following occurs:
e

The CVAX is reading or writing information to or from memory, internal or
external ROM, internal or external registers, the Ethernet coprocessor, or
any other external memory or peripheral device.

The Ethernet coprocessor is reading from or writing to external RAM.

The CVAX is acknowledging an interrupt internal or external to the rtVAX
300.

2.6.1 Microcycle Definition

A microcycle is the basic timing unit for a CVAX bus cycle. A microcycle is
defined as four clock phases, as shown in Figure 2-8. A microcycle equals two
CLKIN cycles.
Figure 2-8
|

Microcycle Timing
1 microcycle

CLKA M

50 ns

RAAWAAAWAAAY

CLKB WN JPZ

/PN P2\

MLO-004305

2.6.2 Single-Transfer Read Cycle
Both the CVAX and the Ethernet coprocessor inside the 1tVAX 300 can initiate
a single-transfer read cycle. This cycle requires at least two microcycles;

microcycles can be added in increments of one microcycle Figure 2-9 shows
the timing of a single-transfer read cycle.

— Note

1/0 space read references always occur as single-transfer read cycles.

2-24

Technical Specification

‘

Figure 2-8

Single-Transfer Read Cycle Timing

CLKA

CLKB

P3
P2

PI\__/Pa\__
P4

\__/P\L
AW

DAL

DPE

coTL

CSDhP

Cycle Type

Pari

TM\

RDY.ERR
MLO-004306

The sequence of events is as follows:

The CVAX transfers the physical address onto the DAL<29:02> H lines.
The DAL<31:30> H lines are set to 01; to indicate a single longword
transfer.

The BM<3:0> L and CSDP«4:0> L lines are asserted as required, and the
WR L line is negated.

Technical Specification

2-25

3. The CVAX asserts AS L, validating CSDP L, BM L, WR L, and address ‘
information.

The CVAX asserts DS L to indicate that the DAL lines are available to
receive the incoming data.

The CVAX checks for a complete cycle once every two phases starting at
the next possible P1 rising edge. External logic indicates that the cycle is
complete by one of the following three responses:
a.

If no error occurs, external logic places the requested data on the
DAL<31:00> H lines and parity information on CSDP<3:0> L, asserts
DPE L if parity is to be checked, and asserts RDY L while ERR L
is deasserted. If the CVAX detects a parity error, appropriate error
information is logged in the memory system error register (MSER); the
CVAX ignores the data on the DAL<31:00> H lines and generates a
machine check if the cycle was a demand read cycle.

If a bus error occurs, external logic asserts ERR L with RDY L

deasserted. The CVAX ignores the data on the DAL<31:00> H lines
and generates a machine check if the cycle was a demand read cycle.
An error is recognized only if RDY L is deasserted for two consecutive
P1 sample points.

External logic can request a retry of the cycle by asserting RDY L and

ERR L. Certain request read cycles do not reissue a bus cycle if they
are retried. Specifically, if the retry occurs on a prefetch reference,
the cperation may not be reissued because the processor may execute
a branch operation before the prefetch can be retried. In addition,
Ethernet controller cycles cannot be retried.

The CVAX completes the read cycle by deasserting DS L and AS L.

2.6.3 Quadword-Transfer Read Cycle

‘

During a quadword-transfer read cycle, the CVAX reads two longwords from
main memory. A quadword-transfer read requires at least three microcycles.
Each longword transfer may be increased in increments of one microcycle The
sequence of events of a quadword-transter read cycle is as follows:
1.

2-26

The CVAX transfers the physical address of the preferred longword onto
the DAL<29:02> H lines. This address can be aligned with either of the
two longwords of the quadword. DAL <02> H indicates whether the upper
or lower longword is transferred first. DAL<31:30> H lines are set to 10
to indicate a quadword transfer. The CVAX sends an address of only the
initial longword (preferred). The address of the second associated longword ‘

Technical Specification

(cache fill) is implied and, therefore, is not transferred. External logic can
generate the implied address by inverting bit 02 of the preferred address.

BM«<3:0> L and CSDP<4:0> L are asserted as required, and WR L is
negated.

The CVAX asserts AS L, validating CSDP<4:0> L, BM<3:0> L, WR L, and
address information on DAL<31:62> H.

DS L is asserted for each data transfer to indicate that the DAL lines are
available to receive the incoming daia.

The CVAX checks for a complete cycle once every microcycle, after each
longword cycle, starting at the next possible P1 rising edge. External
logic indicates that the cycle is complete by one of the following three
responses:

If no error occurs, external logic places the requested data on the
DAJ<31:00> H lines and parity information on CSDP<3:0> L, asserts
DPE L if parity is to be checked, asserts CCTL L if data caching is to
be disabled, and asserts RDY L, while ERR L is deasserted for each
data transfer. The CVAX reads the data and parity information and
deasserts DS L for every transfer. If the caching is prevented (CCTL L
asserted), the cycle immediately terminates without reading the cecond
longword. If the CVAX detects a parity error, the appropriate error
information is logged in the MSER; the CVAX ignores the data on the
DAL<31:00> H lines and generates a machine check if the cycle was
a demand read. If a parity error is detected on the first longword, the
CVAX performs the second data transfer and ignores all the data.

If an error occurs on either longword, external logic asserts ERR L with
RDY L deasserted. The CVAX ignores the data on the DAL<31:00> H
lines, terminates the cycle without reading any additional data, and
generates a machine check if the cycle was a demand read. Only the
first transfer can be a demand cycle. An error is recognized only if RDY
L is deasserted for two consecutive P1 sample points.

External logic can request a retry of the cycle by asserting RDY L and
ERR L. If the retry occurs during the second longword transfer, the
read cycle is not reissued.

The CVAX completes the read cycle by deassertinz DS L and AS L.

Technical Specification

2-27

Figure 2-10 illustrates quadword-transfer read cycle timing, and Table 2-7
shows responses to this cycle.

CLKB

P1\__/Ps
\_)'?\
/Pa\
-\
:g
v_
/—F_
3)

DAL ipK Address

/Pa

77727

e TR

Data
>—K
10)
o

CCTL

|/ p2\

Parity ———%
14

)

®
6

@ 1

D
ow QL
”f - ;;,"/'
y-yl}'z'}”_f:’T

CLKA

Quadword-Transfer Read Cycle Timing

Figure 2-10

Byte Mask

RLY.ERR
MLO-004367

2-28

Technical Specification

Table 2-7 rtVAX 300 Responses to a Quadword-Transfer Read Cycle
Parlty

CCTLL

RDYL

ERRL

Error

Action for First Reference

Wait for data.

Reference

Wait for data.

Macnine check if demand

No machine check.

read. Invalidate cache
entry. No second reference.

Invalidate cache entry.

No machine check. Update = No machine check. Update
cache. Proceed to second
reference.

Action for Second

cache.

No machine check.

No machine check. Update

Invalidate cache entry.
No second reference.

cache.

Machine check if demand

No machine check.

read. Invalidate cache
entry. Log error in MSER.

Invalidate cache entry.
Log error in MSER.

No second reference.

Machine check if demand
read. Invalidate cache
entry. Log error in MSER.
No second referencs.

No machine check.
Invalidate cache entry.
Log error in MSER.

o machine check. No
cache change. No second
reference-retry.

No machine check.
Invalidate cache entry.
No retry.

2.6.4 Octaword-Transfer Read Cycle
During an octaword-transfer read cycle, the rtVAX 300 reads four consecutive

longwords, supplying the address of only the first longword. An octawordtransfer read cycle requires at least nine microcycles. Only the Ethernet
coprocessor initiates octaword-transfer reads. The sequence of events of an
octaword-transfer read cycle is as follows:
1.

The rtVAX 300 transfers the physical address of the preferred longword

onto the DAL<29:02> H lines. This address is always octaword-aligned,

and DAL<03:02> H lines are always zero. The DAL<31:30> H lines are set
to 11, to indicate an octaword transfer. The rtVAX 300 sends an address
of only the initial longword (preferred). All other associated addresses are
implied and, therefore, are not transferred. These implied addresses are
generated by incrementing the count on address b'ts 2 and 3.
2.

Lines CSDP<4:0> L are 1X111, (demand read), and lines BM<3:0> L are

asserted as required; WR L is negated.

Technical Specification

2-29

3. The rtVAX 300 asserts AS L, validating lines CSDP<4:0> L, BM<3:0> L, .
WR L, and the address information on DAL<31:02> H.

Lin: DS L is asserted for each data transfer to indicate that the DAL lines

#ve available to receive the incoming duta. BM«3:0> L are changed with

each assertion of DS.
5.

The rtVAX 300 checks for a complete cycle after slipping one microcycle.
This is done once every microcycle, starting at the second possible P1 rising
edge. External logic indicates that the cycle is complete by one of the
following three responses:

a. If no error occurs, external logic places the requested data on the

DAL<31:00> H lines and parity information on CSDP<3:0> L, asserts

DPE L if parity is to be checked, and asserts RDY L, while ERR L 1s
deasserted for each data transfer. The rtYAX 300 reads the data and
parity information and deasserts DS L for every transfer. If the rtVAX
300 detects a parity error, the processor is interrupted, and the rtVAX
300 ignores the data on the DAL<31:00> H lines and terminates the

cycle.
b.

If an error occurs on any longword, external logic asserts ERR L with

RDY L deasserted. The rtVAX 300 ignores the data on the DAL<31:00>
H lines and terminates the cycle without reading any additional data.
¢.

External logic cannot request a retry of the cycle for octaword-transfer
reads.

The rtVAX 300 completes the read cycle by deasserting DS L and AS L.

Figure 2-11 illustrates octaword-transfer read cycle timing, and Table 2-8
shows responses to this cycle.

2-30

Technical Specification

Figure 2-11 Octaword-Transfer Read Cycie Timing

CLKA

e1\pz2/ra\pafr\P2/Pa\p4

CLKB

p1fp2\p3fra\pifr2\rafps
2H(3

oAL

Data

eavatid

Address

DPE TR

cetL

CSDP

AS
13

225

First Longword Byte information

3rd Longword Byte Mask info. X 4th Longword tiyts Mask Into.
Y2nd Longword Byte Mask Info.X

@
RDY, ERR

Lg~2 uoneoypedg jeajuyosy

MLO-004398

Table 2-8

rtVAX 300 Responses to Octaword-Transfer Read Cycie
Parity

Action for

CCTLL

RDYL

ERRL

Error

Actlon for First Reference

Other References

Wait for data.

Cycle is aborted after end of

Cycle is aborted after

reading current longword.

end of reading current
longword.

Proceed to second reference.

Proceed to next longword
reference.

Interrupt processor. Abort

Finish reading longword.
Abort cycle. No retry.

cycle.

2.6.5 Single-Transfer Write Cycle
During an rtVAX 300 single-transfer write cycle, the rtVAX 300 writes one

longword to the main memory or to an I/O device. An rtVAX 300 write cycle
requires at least two microcycles. Each transfer can be increased in increments
of one microcycle. The sequence of events of an rtVAX 300 write cycle is as

follows:
1.

The rtVAX 300 transfers the physical address onto the DAL<29:02> H
lines. The DAL<31:30> TM lines are set to 015 to indicate a single longword
transfer.

BM<3:0> L and CSDP<«4:0> L are asserted as required, and WR L is
asserted.

The rtVAX 300 asserts AS L, validating CSDP<4:0> L, BM<3:0> L, WR L,

and the address information on DAL<31:02> H.
The rtVAX 300 transfers the output data on the DAL<31:00> H lines and
byte parity information onto CSDP<3:0> L, and CSDP<«4> L is deasserted.
The rtVAX 300 then asserts DPE L to indicate that valid parity information
is available and asserts DS L to indicate that the DAL lines contain valid

data.

2-32

Technical Specific: tion

The rtVAX 300 checks for a complete cycle once every two phases starting
at the second possible P1 rising edge. External logic indicates that the
cycle is complete by one of the following three responses:
a.

If no error occurs, external logic reads the DAL line’s data and asserts
RDY L while ERR L is deasserted.

If an error occurs, external logic asserts ERR L with RDY L deasserted.
The rtVAX 300 generates a machine check. An error is recognized only

if RDY L is deasserted for two consecutive P1 sample points.
c.

External logic can request a retry of the cycle by asserting RDY L and

ERR L. DAL arbitration occurs after the write operation is terminated.

The rtVAX 300 completes the write cycle by deasserting DS L and AS L.

Figure 2-12 illustrates single-transfer write cycle timing.
Notes

1. I/O space writes always occur as single-transfer write cycles.
2. The Ethernet controller can issue longword write cycles. To
maintain CPU cache consistency, it asserts CCTL L at the beginning

of the write cycle to start a quadword cache invalidation cycle. Cache
invalidation cycles require a minimum of four microcycles; therefore, if
CCTL L is asserted at the beginning of the cycle, the memory system
must add two wait states (a total cycle time of 400 ns) to the cycle by
holding off the assertion of RDY L. If CCTL L is not asserted at the
beginning of the cycle, this is a CPU longword write cycle, and 0 or 1
wait state (200 or 300 ns) memory access can be applied.

Technical Specffication

2-33

Figure 2-12

cka

Single-Transfer Write Cycle Timing

_/er\__

P1\_/_P_3—\__/ P1

CLKB

DAL

DPE

CsDpP

RDY.ERR

—
MLO-004309

2-34

Technical Specification

. 2.6.6 Octaword-Transfer Write Cycle

During an octaword-transfer write cycle, the rtVAX 300 writes four consecutive
longwords, supplying the address of only the first longword. An octawordtransfer write cycle requires at least nine microcycles. Only the Ethernet
coprocessor initiates octaword-transfer writes. The sequence of events of an
octaword-transfer write cycle is as follows:
1.

The rtVAX 300 transfers the physical address of the preferred longword
onto the DAL«<29:02> H lines. This address is always octaword-aligned.
DAL<«03:02> H are always zero. The DAL<31:30> H lines are set to 119
to indicate an octaword transfer. The rtVAX 300 sends an address only of
the initial longword (preferred). All other associated addresses are implied
and, therefore, are not transferred. These addresses are generated by
incrementing the count on address bits 2 and 3.
The CSDP<4:0> L lines are 1X111, (write no unlock); the BM«<3:0> L lines
are asserted as required, and WR L is asserted.
The rtVAX 300 asserts AS L, validating CSDP<4:0> L, BM<3:0> L, WR L,
and the address information on DAL<29:02> H.
The rtVAX 300 drives the DAL<31:0C> H lines with valid data, places
parity information on CSDP<3:0> L, and CSDP<4> L remains deasserted.

The rtVAX 300 then asserts DS L to indicate that the DAL lines contain
valid data and asserts DPE L to indicate that CSDP<3:0> L contain
valid parity information. BM<3:0> L are changed as required with each
assertion of DS L.
The rtVAX 300 checks for a complete cycle once every microcycle, starting
at the second possible P1 rising edge. External logic indicates that the
cycle is complete by one of the following three responses:
a.

If no error occurs, external logic asserts RDY L, while ERR L is
deasserted for each data transfer.

If an error occurs on any longword, external logic asserts ERR L with
RDY L deasserted. The rtVAX 30( continues the octaword write with
BM«<3:0> L set to 1, and only then completes the cycle.

External logic cannot request a retry of the cycle for octaword-transfer
reads.

The rtVAX 300 completes the write cycle by deasserting DS L and AS L.

Figure 2-13 illustrates octaword-transfer write cycle timing.

Technical Specification

2-35

uogeoyoedg feoluyoe
] 9g~2

Figure 2-13 Octaword-Transfer Write Cycle Timing

CLKA

Jpi\p2/ra\rafri\r2fra\r4fei\r2/ra\Pafri\p2/P3\r4

CLKB \F:/FZ\FE/N' r1fr2\rafrar1fra\rafrayr1fra\rP3fra
aHq

DAL ussuins¥ Addrese Y

Data

19)

Data

i9)

Cyclel Typd

CSDP ahaeR

i8)

Data

Parity

Parlty

Parily

Data

r
13

BM \\ U

First Longword Byle information

13—(€

Xan Longword Byle Mask Info Xl 3rd Longword Byle Mask Info.xiflh Longword Byte Mask info.
+

RDY, ERR

. 2.6.7 Interrupt Acknowledge Cycle

An interrupt acknowledge cycle sequence is similar to a single-transfer read
cycle. The sequence of events follows:
1.

During the address portion of the cycle, DAL<06:02> H transfers the IPL
of the interrupt being acknowledged. The DAL<«31:30> H lines are set to
01,, and the DAL«<29:07> H and DAL<01:00> H lines are set to 0.

During the data portion of the cycle, external logic should transfer vector
information on the DAL lines. Lines DAL<15:02> H contain the vector
offset within the system control block. The new processor status longword
priority level is determined either by the external interrupt request level
that caused the interrupt or by DAL<00> H. If DAL<00> H is 0, the new
IPL is determined by the interrupt being serviced; otherwise, the new IPL
is changed to 17;6. Lines DAL<31:16> H and DAL<01> H are ignored.

Assertion of ERR L and RDY L in the proper sequence causes the rtVAX
300 to abort or retry the cycle. An abort or a data parity error causes the
rtVAX 300 to ignore the data being read and to release the bus at the end
of the cycle. This results in a passive release of the interrupt.

Figure 2-14 illustrates interrupt acknowledge cycle timing.

. 2.6.8 External IPR Cycles

Section 2.6.8.1 and Section 2.6.8.2 discuss external IPR cycles.

2.6.8.1

External IPR Read Cycle
An external processor register read cycle is initiated when an MFPR
(move from processor register) instruction reads a category 3 processor
register. (Section 3.1.4.3 defines processor register categories.) The only
IPR register that should be implemented externally is IPR 3715. This is the

I/O reset register, and any write to this register should reset all external
devices. Implementing any other IPR externally may cause future software
incompatibilities.

The external processor register read cycle protocol is the same as that of a
single-transfer CPU read cycle, as shown in Figure 2-9; however, CSDP<2:0>
L reads 010;, indicating an external IPR cycle. This cycle requires at least two
microcycles and can be extended in increments of one microcycle. The sequence
of events for an external processor register read cycle i8 as follows:

Technical Specification

2-37

Figure 2-14 Interrupt Acknowledge Cycle

CLKA

jfi'\__/ Pa\_

oke

\__/P2\__/Pa\

p1\__f?3\___/ P1

IPL of Interrupt

DAL
DPE
3

CCTL

bnmaiia
intemal Cyc

CSDP<4>7

)zt

ParitN y

Cycle Type

CSDP

<3:0>

(5)

)

4//&;%3”%/{ A

@,_*\-

RDY.ERR
MLO-004401

The rtVAX 300 transfers the processor register onto DAL<07:02> H, and
DAL<31:30> H are set to 01 to indicate a longword transfer. DAL<28:08>
H and DAL<01:00> H are zero.

BM<3:0> L are all asserted, CSDP<2:0> L read 0105, and WR L is

The rtVAX 300 asserts AS L, indicating that the register number, BM<3:0>
L, CSDP<3:0> L, and WR L are valid and can be latched.

unasserted.

2-38 Technical Specification

4. The rtVAX 300 asserts DS L to indicate that DAL are available to receive
incoming data.

The rtVAX 300 checks for a compiete cycle once every two clock cycles,
starting at the next possible P1. The response of external logic is as
follows:

If the processor register is implemented, external logic transfers the
required data on DAL<31:00> H, asserts DPE L if parity is to be
checked, and asserts RDY L with ERR L deasserted. The rtVAX 300
reads the data from DAL<31:00> H.

b. If the processor register is not implemented, external logic asserts

ERR L with RDY L deasserted. The rtVAX 300 ignores the data on
DAL<31:00> H and internally forces the result to zero. A detected
parity error will force the result to zero and is not reported. Therefore,
it is recommended that DPE L remain asserted during a processor
register read. The unimplemented response will be recognized only
if RDY L is deasserted for two consecutive P1 sample points. If this
response (ERR L asserted and RDY L deasserted) is detected at the

first P1 sample point but RDY L is asserted at the second P1 sample
point, the cycle will terminate according te the retry protocol.

.
c.
6.
2.6.8.2

To request a retry, external logic asserts both RDY L and ERR L. DAL
arbitration occurs after the initial read cycle is terminated.

The rtVAX 300 completes the read cycle by deasserting AS L and DS L.

External IPR Write Cycle
An external processor register write cycle is initiated when an MTPR
(move to processor register) instruction writes a category 3 processor

IPR register that should be implemented externally is IPR 37;6. This is the
L/O reset register, and any write to this register should reset all external
devices. Implementing any other IPR externally may cause future software

incompatibilities.

An external prucessor register write cycle protocol is the same as an rtVAX
300 write cycle, as shown in Figure 2-12; however, CSDP<2:0> L reads 0105,
indicating an external IPR cycle. The cycle requires at least two microcycles
and may be extended in increments of one microcycle. The sequence of events
for an external processor register write cycle is as follows:
1.

The rtVAX 300 transfers the processor register number onto DAL<07:02>
H, and DAL<31:30~ H are set to 013 to indicate a longword transfer.

DAL<28:08> H and DAL<01:00> H are zero.

Technical Specification

2-39

2. BM<3:0> L are all asserted, CSDP<2:0> L read 0105, and WR L is
unasserted.

The rtVAX 300 asserts AS L to indicate that the register number, BM<3:0>
L, CSDP<«3:0> L, and WR L are valid and can be latched.

The rtVAX 300 transfers the data onto DAL<31:00> H and asserts DS L to

‘

indicate that the DAL contains valid data.

The rtVAX 300 checks for a completed cycle once every two clock phases,
starting at the next possible P1. The response of the external logic is as
follows:

a. If the processor register is implemented, external logic reads the data .
from DAL and asserts RDY L while ERR L is deasserted.

If the processor register is not implemented, external logic responds
either as if the register is unimplemented by asserting ERR L when
RDY L is deasserted or as if the register is implemented by asserting
RDY L with ERR L deasserted. Both respenses have the same effect,
and no special action is taken. The unimplemented response indicates
no special action only if RDY L is deasserted for two consecutive P1
sample points. If this response is detected at the first P1 sample

point but RDY L is asserted at the second P1 sample point, the cycle
terminates according to the retry protocol.

c.
6.

To request a retry, external logic asserts both RDY L and ERR L. DAL
arbitration occurs after the initial write cycle is terminated.

The 1tVAX 300 completes the write cycle by deasserting AS L and DS L.

2.6.9 Internal Cycles
The internal cycles start off as regular read/write cycles. However, by the end

of the address portion of the cycle, all data lines are undefined. The beginning ‘

of an internal cycle is indicated by an address within the reserved space or the
assertion of CSDP<4> L. The end of the cycle is indicated by the deassertion of
AS L. See Figure 2-15.

2-40 Technical Specification

. Figure 2-15 Internal Read or Write Cycle
P\
_/
cka PN/

__/Pi\

CLKB "\__/T:E\__/m\_/Pz

Pi\__/Pa\__/lP1

P3
P4

/p2\

[ra\l

[/ P2\

ERR,RDY
MLO-004402

2.6.10 DMA Cycle
The rtVAX 300 can relinquish the DAL lines and related control signals upon
request from an external DMA device or other processor. The sequence is as
follows:
1.

The external device requests control of the bus by asserting DMR L.

Once the rtVAX 300 finishes the current bus cycle and no pending DMA
requests are present from the Ethernet coprocessor, the rtVAX 300 causes
the DAL<31:00> H lines, AS L, DS L, WR L, BM<3:0> L, and CSDP<4:0>

L to become high impedance and asserts DMG L. DAL bus arbitration

occurs at the end of each bus cycle, so that DMA devices can intervene

between bus retry cycles.

Technical Specification

2-41

3. To return bus control to the rtVAX 300, the external device deasserts DMR '
L, and the rtVAX 300 responds by deasserting DMG L and returning to

regular bus cycles. The rtVAX 300 does not invalidate cache entries, unless
tne CCTL L line is asserted appropriately.

Figure 2-16 illustrates DMA cycle timing.
Note

If an external DMA device remains DAL bus master longer than 6 us,
the Ethernet coprocessor FIFO may overflow when receiving packets.
See Figure 2-16.

Figure 2-16

CLKA

DMA Cyrle

CLKB

DMR

_@?

DMG

/‘

DS (from DMA device)

Ds, AS, DBE,
DPE, WF, BM
CSDP
DAL

“a

MLO-004403

2.6.11

Cache Invalidate Cycle
External logic initiates a conditional cache invalidate cycle to allow the CVAX
to detect and invalidate stale data stored in cache. A cache invalidate cycle
requires at least four aicrocycles. The sequence of events is as follows:

2-42

Technical Specification

After DMG L is asserted, external logic drives the address on the
DAL<31:00> H lines and asserts AS L to latch the address into the
rtVAX 300. External logic should also assert CCTL L to start the cache
invalidate cycle.

The rtVAX 300 invalidates the quadword entry selected by the DMA
address if the location is stored in cache.

External logic deasserts CCTL L and optionally reasserts CCTL L to
conditionally invalidate the alternate quadword formed by inverting
DAL<«03> H. This allows external logic to detect and invalidate stale data

stored in any naturally aligned octaword.
4.

The cycle ends when external logic deasserts CCTL L and AS L.

If a cache parity error is detected during a conditional cache invalidate cycle,
no machine check is generated, no invalidate occurs, and the error is logged in
the MSER.

Figure 2-17 illustrates the octaword cache invalidate cycle. Figure 2-18
illustrates the quadword cache invalidate cycle.
Figure 2-17 Octaword Cache invalidate Cycle

awka

\_/P\_fr\_/riPs\_/P1 _\_/_\_/—\__/'-’3
Pa

oLKB fm
eJ_\g\\
\._
CCTL

@
\

;

DAL
MLO-008378%

Technical Specification

2-43

Figure 2-18

Quadword Cache Invalidate Cycle

CLKA Wpa\ 2 _\Jp—s\_fi\_fi;'fi\fi
__ _fr\__
[P\
fe\__ _fr\_fr\
/P4
fr2\
[P\
cike
CCTL

MLO-006320

2-44

Technical Specification

XAKX

XARKAKS

p00040044

KXXXXALAXL

b0.4.0.066.040804

$0.8.0.0.94.800.64000

KA KX KL IOUXHXK)

)0.6.6.0.0.0.0.0.68004440848

KL KAKXD
XA

p9.0.0.60064 044083880 00800
J0 0000404098 9004806849040

10060060948 404.08608800 048406

p 0600080 00048084064000688080

)0.0.6.8.00.0.0.4.0.80.4649.0.96.960408040649
4
8809
P088.06.06.060.06600906.0.8.0908960

PED0.0.0.0.6:6.¢.00.06069.90.08090.6.00.00056600

190080000060 0040080095058.884800880¢00
}0.0.0.0.060 000864000000 0000896.6008086600608

POV

GG EH00.00800.000880.9.4.90008060¢05084044
GO0 086:08.0.4.0.06:5.60.6506909.0.8888688844

P OOV OV 0069.006.0.6.6.00.0.60.80.0.6.00.66066.699896688606
.01
PO 0600008V 000.00.50.6:0.4:5:0:0,0.0.6.6.0.0.8.0.0.0.9.69.6.88006680.00
XXX XA KKK KRN XXX LKA XY WL XA KA KA XKL KA L KX KA KL KA KA AL

3
Hardware Architecture
This chapter discusses the hardware architecture features of the rtVAX 300
processor. The VAX Architecture Reference Manual discusses VAX hardware
architecture in general and in detail.

The rtVAX 300 processor implements a compatible subset of the VAX
architecture. Visible machine state consists of virtual and physical memory, 16
general-purpose registers, the processor status word, and 16 system registers.
The instruction set architecture responds to all 304 native-mode VAX
instructions. Of these, 251 are implemented in the microprocessor, and the
remaining 53 instructions may be implemented through software emulation, of
which 21 are assisted by the chip’s microcode.

All VAX data types are recognized. Of these, nine are implemented in the
microprocessor: byte, word, longword, and quadword integers; variable length
bit fields, variable length character strings, single precision, double precision,
and extended double precision floating-point numbers. The remaining data
types are supported through software emulation.

This chapter discusses the following topics:
¢

Central processor (Section 3.1)

Floating-point accelerator (Section 3.2)

Cache memory (Section 3.3)

Hardware initialization (Section 3.4)

Console interface registers (Section 3.5)

Ethernet coprocessor (Section 3.6)

Hardware Architecture

3-1

3.1 Central Processor
The central processor of the rtVAX 300 supports the CVAX chip subset (plus
gix additional string instructions) of the VAX instruction set and data types
and full VAX memory management. It is implemented by a single VLSI chip
called the CVAX.

3.1.1

Data Types

The rtVAX 300 processor supports the following subset of VAX data types:
e

Byte

Word

Longword

Quadword

Character string

Variable length bit field

Macrocode emulation can provide support for the remaining VAX data types.
3.i.2 Instruction Set

The rtVAX 300 processor implements the following subset of VAX instruction
set types in microcode:

3-2

Integer arithmetic and logical

Address

Variable length-bit field

Control

Procedure call

Miscellaneous

Queue

Charactsy string moves (MOVCS, MOVCS5, CMPC3, CMPC5, LOCC,

SCANC. WKPC, and SPANC)

Operating system support

F floating

G_floating

D_floating

Hardweare Architecture

The rtVAX 300 CVAX chip provides special microcode assistance to aid the
macrocode emulation of the following instruction groups:

Character string (except MOVC3, MOVC5, CMPC3, CMPC5, LOCC,
SCANC, SKPC, and SPANC)

Decimal string

CRC

EDITPC

H_floating

Octaword instruction groups are not implemented but may be emulated by

macrocode.

3.1.3 Microcode-Assisted Emulated Instructions
The rtVAX 300 processor provides microcode assistance for the emulation of

these instructions by system software. The processor processes the operand
specifiers, creates a standard argument list, and takes an emulated instruction
fault. Table 3—1 describes microcode-assisted emulated instructions.

. Table 3—~1 Microcode-Assisted Emulated Instructions

Mnerronic and Arguments

Description

nzvc

Exceptions'

ADDP4 addlen.rw, addaddr.ab,

Add packed 4-operand

**x*x0

rsv, dov

Add packed 6-operand

** %0

rsv, dov

sumlen.rw, sumaddr.ab

ADDP6 addllen.rw, addladdr.ab,
add2len.rw, add2addr.ab, sumlen.rw,

sumaddr.ab

ASHP cnt.rb, srclen.rw, srcaddr.ab,

Arithmetic shift and

*xxQ

CMPP3 len.rw, srcladdr.ab,

Compare packed 3-

**00

CMPP4 srcllen.rw, srcladdr.ab,
src2len.rw, src2addr.ab

Compare packed 4operand

**00

CRC tbl.ab, inicrc.rl, strlen.rw,

stream.ab

redundancy check

Calculate cyclic

**00

CVTLP src.rl], dstlen.rw, dstaddr.ab

Convert long to packed

%% 0

round.rb, dstlen.rw, dstaddr.ab
src2addr.ab

round packed
operand

rsv, dov

rev = reserved operand fault; iov = integer overflow trap; dov = decimal overflow trap; ddvz = decimal

divide by zero trap.

(continued on next page)
Hardware Architecture

3-3

Table 3-1 (Cont.) Microcode-Assisted Emulated Instructions

Mnemonic and Arguments

Description

hzve

Exceptions’

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

Convert packed to long

*%xxQ

rsv, iov

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

Convert packed to
leading

*%x(

rsv, dov

separate

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

Convert leading
separate to packed

* % % Q

r8v, dov

CVTPT srclen.rw, srcaddr.ab,
thladdr.ab, dstlen.rw, dstaddr.ab

Convert packed to
trailing

* %%k Q

rsv, dov

26
27

tbladdr.ab, dstlen.rw, dstaddr.ab

CVTTP srclen.rw, srcaddr.ab,

trailing

Convert. packed to

*% X0

rev, dov

DIVP divrlen.rw, divraddr.ab,

Divide packed

**xQ

rsv, dov, ddvz

rsv, dov

divdlen.rw, quolen.rw,
quoaddr.ab

EDITPC srclen.rw, srcaddr.ab,

Edit packed to character

** **

MATCHC objlen.rw, objaddr.ab,

Match characters

0*00

pattern.ab, dstaddr.ab

string

srclen.rw, srcaddr.ab

MOVP len.rw, srcaddr.ab,

Move packed

¥**¥00

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

Move translated
characters

* % Q*

MOVTUC srclen.rw, srcaddr.ab,

Move translated until

* kKK

MULP mulrlen.rw, mulraddr.ab,

Multiply packed

**%(0

rav,dov

Subtract packed

**xQ

r8v, dov

Subtract packed

*x % Q)

rav, dov

22
23

dstaddr.ab

esc.rb, tbladdr.ab, dstlen.rw,
dstaddr.ab
muldlen.rw, muldaddr.ab,
prodlen.rw, prodaddr.ab

SUBP4 sublen.rw, subaddr.ab,

diflen.rw, difaddr.ab

SUBPS sublen.rw, subaddr.ab,

minlen.rw, minaddr.ab, diflen.rw,
difaddr.ab

character

4-operand
6-operand

rev = reserved operand fault; iov = integer overflow trap; dov = decimal overflow trap; ddvz = decimal

divide by zero trap.

3-4

Hardware Architecture

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

. 3.1.4.1 General-Purpose Registers

The rtVAX 300 implements 16 general-purpose registers as specified in the VAX
Architecture Reference Manua!. These registers are used for temporary storage,

as accumulators, and as base and index registers for addressing. These
registers are denoted RO through R15. The bits of a register are numbered
from the right <0> through <31>.
Certain of these registers have been assigned special meaning by the VAX
architecture.

R15 is the program counter (PC). The PC contains the address of the next
instruction byte of the program.

R14 is the stack pointer (SP). The SP contains the address of the top of the
processor defined stack.

R13 is the frame pointer (FP). The VAX procedure call convention builds
a data structure on the stack called a stack frame. The FP contains the
address of the base of this data structure.

R12 is the argument pointer (AP). The VAX procedure call convention uses
a data structure called an argument list. The AP contains the address of
the base of this data structure.

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

Processor Status Longword

The processor status longword (PSL) is implemented as specified in the VAX
Architecture Reference Manual, which should be consulted for a detailed
description of the operation of this register. The PSL is saved on the stack
when an exception or interrupt occurs and is saved in the process control

block (PCB) on a process context switch. Nonprivileged software can access
bits <15:00>; only privileged software can access bits <31:16>. Processor

Hardware Architecture

3.5

initialization sets the PSL to 041F0000,6. Figure 3-1 shows the format of the
processor status longword; Table 3-2 describes the fields within the PSL.
Figure 3-1

Processor Status Longword

0807060504 0302 01 00
1615
3130202807 262524232221 20
CT'
i
1
1
riTTtT1r 1TrverviertT olFl 1

MPO

VUVTNZVC:

iPL

1.1

-——— PRV MQD

CURMOD
FPD

Table 3-2

Processor Status Longword Bit Map

Data Bit

Definition

<31>

MLO-006380

Compatibility mode (CM). Reads as zero. The rtVAX 300 does not support

compatibility mode.

<30>

Trace pending (TP).

<29:28>

Unused. Must be written as zero.

<27>

First part done (FPD).

<26>

Interrupt stack (IS).

<25:24>

Current mode (CUR »MOD).

<23:22>

Previous mode (PRV MOD).

<21>

Unused. Must be written as zero.

<20:16>

Interrupt priority level (IPL).

<15:8>

Unused. Must be written as zero.

<7>

Decimal overflow trap enable (DV). Has no effect on rtVAX 300 hardware.

<6>

Floating underflow fault enable (FU).

<5>

Integer overflow trap enable (IV).

<4>

Trace trap enable (T).

Can be used by macrocode which emulates VAX decimal instructions.

(continued on next page)

3-8

Hardware Architecture

Table 3-2 (Cont.)

3.1.4.3

Processor Status Longword Bit Map

Data Bit

Definition

<3>

Negative condition code (N).

<2>

Zero condition code (Z).

<1>

Overflow condition code (V).

<0>

Carry condition code (C).

Internal Processor Registers

The rtVAX 300 IPRs can be accessed by using the MFPR and MTPR privileged
instructions. Each IPR falls into one of the following categories:
1.

Implemented by rtVAX 300 (in the CVAX chip).

Implemented by rtVAX 300 (and all designs that use the CVAX chip)
uniquely.

Not implemented, timed out by the DAL bus timer after 32 ps. Read as 0.
NOP on write.

4. Access not allowed; accesses result in a reserved operand fault.
Accessible, but not fully implemented. Accesses yield unpredictable results.
Externally implemented on application module.

Table 3-3 lists each rtVAX 300 IPR, its mnemonic, its access type (read or
write), and its category number.

Table 3-3

Internal Processor Registers

Decimal

Hex

Mnemonic Type

Category’

Kernel stack pointer

KSP

r'w

Executive stack pointer

ESP

/'w

Supervisor stack pointer

SSP

r/w

User stack pointer

Usp

r/w

Interrupt stack pointer

ISP

r/w

7:5

Reserved

! = register initialized on power-up and by negation of RST when the processor is halted.

(continued on next page)

Hardware Architecture

3-7

Table 3-3 (Cont.)

Internal Processor Registers

Decimal

Hex

Mnemonic

Type

Category'

PO base register

POBR

r/'w

PO length register

POLR

r/w

P1 base register

P1BR

Y/w

P1 length register

P1LR

r/w

System base register

SBR

r/'w

System length register

SLR

r/w

15:14

Reserved

Process control block base

PCBB

r/w

System control block base

SCBB

r'w

Interrupt priority level

IPL

r'w

AST level

ASTIVL

r/w

Software interrupt request

SIRR

Software interrupt summary

SISR

r/w

J |

23:22

17:16

Reserved

Interval clock control/status

ICCS

v/w

Next interval count

NICR

Interval count

ICR

Time-of-year clock register

TODR

r/w

Console storage receiver status

CSRS

r'w

Console storage receiver data

CSRD

Console storage transmit status

~ CSTS

r'w

Console storage transmit data

CSTD

Console receiver control/status

RXCs

r/w

Console receiver data buffer

RXDB

Congole transmit control/status

TXCS

r/w

Console transmit data buffer

TXDB

Translation buffer disable

TBDR

r'w

Cache disable

CADR

r/w

{ = register initialized on power-up and by negation of RST when tie processor is halted.

{continued on next page) ‘

3-8

Hardware Architecture

Table 3-3 (Cont.)

Internal Processor Registers

Decimal

Hex

Mnemonic

Type

Category'

Machine check error summary

MCESR

Memory system error

MSER

r/'w

41:40

29:28

Reserved

Console saved PC

SAVPC

Console saved PSL

SAVPSL

47:44

2F:2C

Reserved

SBI Fault/status

SBIFS

r'w

SBI silo

SBIS

SBI silo comparator

SBISC

r'w

SBI maintenance

SBIMT

r/w

SBI error

SBIER

r/w

SBI timeout address

SBITA

SBI quadword clear

SBIQC

/O bus reset

IORESET

Memory management enable

MAPEN

r’w

TB invalidate all

TBIA

TB invalidate single

TBIS

TB data

TBDATA

r/w

Microprogram break

MBRK

r'w

Performance moniior enable

PMR

System identification

SiD

Translation buffer check

TBCHK

127:64

7F:46

Reserved

'] = register initialized on power-up and by negation of RST when the processor is halted.

3.1.5 Interval Timer
The rtVAX 300 interval timer, IPR 24, is implemented according to the VAX
Architecture Reference Manual for subsct processors. The interval clock control
/status register (ICCS) is implemented as the standard subset of the standard

VAX ICCS in the CVAX chip; NICR and ICR are not implemented (Figure 3-2).

Hardware Architecture

3-9

Figure 3-2

LIS

Interval Timer

I NL

L N I

0 0 I O

070605

B B

0 N 6 IO O O A

I B

Li i1t

ACCS

MLO-004570

Bit

Definition

<31:07>

Unused. Read as zeros, must be written as zeros.

<06>

Interrupt enable (IE). Read/write. This bit enables and disables the

interval timer interrupts. When the bit is set, an interval timer interrupt

is requested every 10 ms with an error of less than 0.01 percent. When
the bit is clear, interval timer interrupts are disabled. This bit is cleared
on power-up.

<05:00>

Unused. Read as zeros, must be written as zeros.

Interval timer requests are posted at IPL 1635 with a vector of C0;5. The
interval timer is the highest priority device at this IPL.

3.1.6 ROM Address Space
The entire 128K-byte boot and diagnostic ROM may be read from local register
1/0 space (addresses 20040000 through 2007FFFF). Writes to this space result
in a machine check.

3.1.7 Resident Firmware Operation
The rtVAX 300 resident firmware can be entered by transferring program
control to location 20040000.

Section 3.1.9 lists the various halt conditions that cause the CVAX processor to
transfer program control to location 20040000.

When running, the rtVAX 300-resident firmware provides the services expected
of a VAX console system. In particular, the following services are available:
¢

Bootstrap following processor halts or initial power-up

An interactive command language allowing the user to examine and alter
the state of the processor

3-10

Diagnostic tests executed on power-up that check out the CVAX processor,
the memory system, and the Ethernet coprocessor

Hardware Architecture

. 3.1.8 Memory Management

The rtVAX 300 implements full VAX memory management, as defined in the
VAX Architecture Reference Manual. System space addresses are virtually
mapped through single-level page tables, and process space addresses are
virtually mapped through 2-level page tables. Refer to the VAX Architecture
Reference Manual for descriptions of the virtual to physical address translation
process and the format of VAX page table entries (PTEs).

Translation Buffer

To reduce overhead associated with translating virtual addresses to physical
addresses, the rtVAX 300 processor employs a 28-entry, fully associative
translation buffer for caching VAX PTEs in modified form. Each entry can
store a modified PTE for translating virtual addresses in either the VAX
process space or VAX system space. The translation buffer is flushed whenever
memory management is enabled or disabled, for example, by writes to IPR
56, when any page table base or length registers are modified, for example, by
writes to IPRs 8 to 13, and by writing to IPR 57 (TBIA) or IPR 58 (TBIS).
Each entrv is divided into two parts: a 23-bit tag register and a 31-bit PTE
register. The tag register stores the virtual page number (VPN) of the virtual

page that the corresponding PTE register maps; the PTE register stores the 21bit PFN field, the PTE<V> bit, the PTE<M> bit, and an 8-bit partially decoded
representation of the 4-bit VAX PTE PROT field, from the corresponding VAX

PTE, and a translation buffer valid (TB<V>) bit.
During virtual to physical address translation, the contents of the 28 tag

registers are compared with the virtual page number field (bits <31:9>) of
the virtual address of the reference. If there is a match with one of the
tag registers, a translation buffer hit has occurred, and the contents of the
corresponding PTE register are used for the translation.
If there is no match, the translation buffer does not contain the necessary
VAX PTE information to translate the address of the reference, and the PTE

must be fetched from memory. Upon fetching the PTE, the translation buffer
is updated by replacing the entry that is selected by the replacement pointer.

Since this pointer is moved to the next sequential translation buffer entry
whenever it is pointing to an entry that is accessed, the replacement algorithm
is not last used (NLU).

Hardware Architecture

3-11

3.1.8.2 Memory Management Control Registers

Four IPRs control the memory management unit (MMU): IPR 56 (MAPEN),

‘

IPR 57 (TBIA), IPR 58 (TBIS), and IPR 63 (TBCHK).
Memory management can be enabled/disabled through IPR 56 (MAPEN).
Writing 0 to this register with an MTPR instruction disables memory
management; writing a 1 enables memory management. Writes to this register

flush the translation buffer. To determine whether or not memory management
is enabled, IPR 56 is read by the MFPR instruction. Translation buffer entries
that map a particular virtual address can be invalidated by using the MTPR
instruction to write the virtual address to IPR 58 (TBIS).

Whenever software changes a valid PTE for the system or current
process region, or a system PTE that maps any part of the current

process page table, all process pages mapped by the PTE must be
invalidated in the translation buffer.

The entire translation buffer can be invalidated by using the MTPR instruction

to write a 0 to IPR 57 (TBIA).
The translation buffer can be checked to see if it contains a valid translation

for a particular virtual page by using the MTPR instruction to write a virtual

address within that page to IPR 63 (TBCHK). If the translation buffer contains
a valid translation for the page, the condition code V bit (bit <1> of the PSL) is
set.

Note

The TBIS, TBIA, and TBCHK IPRs are write only. The operation of an
MFPR instruction from any of these registers is undefined.

3.1.9 Exceptions and Interrupts
Both exceptions and interrupts divert execution from the normal flow of
control. An exception is caused by the execution of the current instruction

and is typically handled by the current process, for example, an arithmetic
overflow; an interrupt is caused by some activity outside the current process
and typically transfers control outside the process, for example, an interrupt
from an external hardware device.

3-12

Hardware Architecture

The following events cause interrupts:
e

HLT L (non=askable)

PWRFL L (IPL 1Eq¢)

Interrupt from a peripheral device received on IRQ<3:0> L (IPL 14,4 to
IPL 174¢):

Interval timer (IPL 16,¢)
Ethernet coprocessor (IPL 15:¢)

Console DUART (IPL 14,4)

Software interrupt invoked by MTPR sre, #SIRR (IPL 016 to OF¢)

AST delivery when REI restores a PSL with a mode > ASTLVL (IPL 02,4)

Each device has a separate interrupt vector location in the system control block
(SCB). Thus, interrupt service routines do not need to poll devices in order
to determine which device interrupted. The vector address for each device is
determined by hardware.
To reduce interrupt overhead, no memory mapping information is changed
when an interrupt occurs. Thus, the instructions, data, and contents of the
interrupt vector for an interrupt service routine must be in the system address
space or present in every process at the same address.

3.1.10 Interrupt Control
The IRQ<3:0> L, HLT L, and PWRFL L inputs to the processor and three

registers control the hardware interrupt system. Asserting any of the input
pins generates an interrupt at the hardware level given in Table 3—4. The
three registers are used to control the software interrupt system.

3.1.11

internal Hardware Interrupts
The rtVAX 300 10 ms interval timer interrupts at IPL 16,4, and the Ethernet
coprocessor can interrupt the rtVAX 300 at TPL 15;4. These interrupts have
higher priority than iRQ<2> L and IRQ<1> L, which also interrupt at IPL 16¢
and 'PL 1516-

3.1.12 Dispatching Interrupts: Vectors
The system control block is a page-aligned table containing the vectors used
to dispatch exceptions and interrupts to the appropriate service routines.
Only device vectors in the range of 100,4 to 7FFC;¢ should be used, except
by devices emulating console storage and terminal hardware. The console
reserves vectors 02C0 to 02CC and interrupts at IPL 14,4 by means of IRQ<0>
L.

Hardware Architecture

3-13

The rtVAX 300 internal Ethernet coprocessor can interrupt at IPL 15,¢. This
interrupt is daisy-chained to the external interrupt request IRQ<1> L and

is serviced before IRQ<1> L. The vector is set by writing to the Ethernet
coprocessor CSRO register at location 20180000.
3.1.12.1

Interrupt Action

Interrupts can be divided into two classes: nonmaskable and maskable.
Nonmaskable interrupts cause a halt through the hardware halt procedure
which saves the PC, PSL, MAPEN<0>, and a halt code in IPRs, raises the
processor IPL to 1F;g, and then passes control to the resident firmware. The
firmware dispatches the interrupt to the appropriate service routine, based on
the halt code and hardware event indicators. Nonmaskable interrupts with a
halt code of 3 cannot be blocked, because this halt code is generated after a
hardware reset.
Maskable interrupts save the PC and PSL, raise the processor IPL to the
priority level of the interrupt (except for vectors with DAL<0> H set to 1,
where the processor IPL is set to 17,6, independent of the lsvel at which the
interrupt was received), and dispatch the interrupt to the appropriate service
routine through the SCB.
Table 34 lists the various interrupt conditions for the rtVAX 300 plus their
associated priority levels and SCB offsets.
Note

If the external device sets DAL<00> H of the vector that it places
on the bus, the rtVAX 300 processor raises the IPL to 17,4 after
responding to interrupts gererated by the assertion of IRQ<3> L,
IRQ<2> L, IRQ<1> L, or IRQ<0> L. The rtVAX 300 maintains the IPL
at the priority of the interrupt, if DAL<00> H is zero.

3—-14

Hardware Architecture

Table 3—4

interrupts

Priority Levelys

interrupt Condition

SCB Oftset

Nonmaskable

Reset asserted

HLT L asserted

Unused

PWRFL L asserted

1D-18

Unused

IRQ<3> L asserted

Device vector on DAL<15:02> H

Interval timer interrupt

IRQ<2> L asserted

Device vector on DAlL<15:02> H

Ethernet coprocessor

Vector placed in Ethernet coprocessor

IRQ<1> L asserted

Device vector on DAL<«15:02> H

Console terminal

02C0

IRQ<0> L asserted

Device vector on DAL<15:02> H

interrupt

13-10

Unused

0F-01

Software interrupt requests

CSRO

84-BC

!This condition forces execution to the resident firmware’s dispatcher with a halt code of 3

(hardware reset).

%This condition forces execution to the resident firmware’s dispaicher with a halt code of 2 (external

halt).

Three IPRs control the interrupt system: IPR 18, the interrupt priority level
register (IPL), IPR 20, the software interrupt request register (SIRR), and
IPR 21, the software interrupt summary register (SISR). The IPL is used
for loading the processor priority. The SIRR is used for generating software

interrupt requests. The SISR records pending software interrupt requests at
levels 1 through 15. Figure 3—3 shows the format of these registers. Refer to
the VAX Architecture Reference Manual for more information on these registers.

Hardware Architecture

3-15

Figure 3-3

Interrupt Reglsters

0504

Tyrirrrrerry a1

1r1rvrrrriyroroerd

LI L

ignored, Retums
0

PSL<20:16>]

:IPL

NSNS
NN

0403

rryrrrir+1rrvyrryrryrvirervrrrurayrii

ignored
[

L W% S 0

15 NS (VIO T

O T

Request| SIRR
N

TN N

TN TN O

1]
]

31
1615
T T rirrrrrrrirrial
TiTrTorvrrrrroeeirini

L bbbty

Pending Scfiware Interrupts
|o]
IFEDCBAIQ8,716,5413,211

:SiSR

MLO-004407

3.1.12.2

Halting the Processor

The rtVAX 300 is a dynamic device and cannot be halted by disabling its clock
input (CLKIN). The CPU is halted either by executing the HALT instruction in
kernel mode or by asserting the HLT L signal.
Assertion of the HLT L signal results in the execution of a nonmaskable
interrupt by the CPU. HLT L is edge-sensitive and must be asserted for at
least two microcycles to guarantee its being sensed by the CPU. In order for
another HLT L to be recognized, HLT L must be deasserted for at least two
microcycles. A break detection circuit may be added to the console receive line
to assert the HLT line when the console break key is depressed. (Chapter 6
gives details of and illustrates this circuit.)
Execution of the HALT instruction or assertion of HLT L causes the execution

of macro instructions to be suspended and the restart process to be entered.
The initiation of the restart process is under control of the processor microcode,
which saves the processor state and passes control to the internal boot and
diagnostic ROMs beginning at physical address 20040000. These ROMs
implement the console emulation program and give control to the console,
displaying the >>> prompt when a halt condition is detected.
3.1.12.3

Exceptions
There are three types of exceptions:

3-16

Trap

Fault

Abort

Hardware Architecture

A trap is an exception that occurs at the end of the instruction that caused
the exception. After an instruction traps, the PC saved on the stack is the
address of the next instruction that would normally have been executed, and
the instruction can be restarted.
A fault is an exception that occurs during an instruction and leaves the
registers and memory in a consistent state, such that the elimination of
the fault condition and restarting the instruction gives correct results. After
an instruction faults, the PC saved on the stack points to the instruction that
faulted.

An abort is an exception that occure during an instruction and leaves the value
of the registers and memory unpredictable, such that the instruction cannot
necessarily be correctly restarted, completed, simulated, or undone. After an
instruction aborts, the PC saved on the stack points to the instruction that
was aborted, which may or may not be the instruction that caused the abort;
the instruction may or may not be restarted, depending on the class of the
exception and the contents of the parameters that were saved.
Exceptions are grouped into six classes:
*

Arithmetic

Instruction execution

Memory management

Operand reference

System failure

Tracing

Table 3-5 lists exceptions by class. Exceptions save the PC and PSL, and
in some cases, one or more parameters, on the stack. Most exceptions do
not change the IPL of the processor (except the exceptions in serious system
failures class, which set the processor IPL to 1Fg) and cause the exception
to be dispatched to the appropriate service routine through the SCB (except
for the interrupt stack not valid exception, and exceptions that occur while an
interrupt or another exception are being serviced, which cause the exception to
be dispatched to the appropriate service routine by the resident firmware).
The VAX Architecture Reference Manual describes the exceptions listed in
Table 3-5 (except machine check) in greater detail. Section 3.1.12.4 describes
the machine check exception in greater detail. Table 3-8 in Section 3.1.12.7
describes exceptions that can cccur while an interrupt or another exception are
being serviced.

Hardware Architecture

3~17

Table 3-8

Exceptions

SCB Offsety

Type

Meaning

Arithmetic Trap and Fault

Trap

Integer overflow

Trap

Integer divide-by-zero

Trap

Subscript range

Fault

Floating overflow

Fault

Floating divide-by-zero

Fault

Floating underflow

Instruction Execution Exceptions
10

Fault

Reserved/privileged instruction

Fault

Breakpoint

40-4C

Trap

Change mode (CHMK, CHME, CHMS, CHMU)

Trap

Instruction emulation

Fault

Suspended emulator

Memory Management Exceptions
20

Fault

Access control violation

Fault

Translation not valid

Operand Reference Exceptions
18

Abort

Reserved operand fault

Fault

Reserved addressing mode

System Failure Exceptions
1

Abort

Interrupt stack not valid

Abort

Machine check

DAL bus parity errors

Dispatched by resident firmware rather than through the SCB.
“Handled through machine check.
(continued on next page)

3-18

Hardware Architecture

Table 3-5 (Cont.)
SCB Offsetye

Exceptions
Type

Meaning

System Fallure Exceptions

Internal cache parity errors

ERR L asserted without RDY L

DAL bus timeout errors

Abort

Kernel stack not vahd

Fault

Trace

Tracing Exception
28

*Handled through machine check.
3.1.12.4

Information Saved on a Machine Check Exception
In response to a machine check exception, the PSL, PC, four parameters, and a
byte count are pushed onto the stack, as shown in Figure 3—4.
Figure 3-4

Information Saved on a Machine Check Exception

Byte Count (00000010 HEX)

Machine Check Code
Most Recent Virtual Address
internal State Information 1

Internal State Information 2
PC
PSL
MLO-004408

Byte Count

Byte count <31:00> indicates the number of bytes of information that follow on
the stack (excluding the PC and PSL).

Hardware Architecture

3-19

Machine Check Code Parameter
Machine check code <31:00> indicates the type of machine check that occurred.
Possible machine check codes and their associated causes follow:
*

Floating-point errors indicate that the floating-point accelerator (CFPA)
chip detected an error while communicating with the CVAX processor chip
during the execution of a floating-point instruction. The most likely causes
of these types of machine checks are: a problem internal to the CVAX
processor chip; a problem internal to the CFPA; or a problem with the
interconnect between the two chips. Machine checks due to floating-point
errors may be recoverable, depending on the state of the VAX can't restart
flag (captured in internal state information 2 <15>) and the first part done
flag (captured in PSL <27>). If the first part done flag is set, the error
is recoverable. If the first part done flag is cleared, then the VAX can’t
restart flag must also be cleared for the error to be recoverable; otherwise,
the error is unrecoverable, and depending on the current mode, either

the current process or the operating system should be terminated. The
information pushed onto the stack by .his type of machine check is from

the instruction that caused the machine check.

Codess

Error Description

The CFPA chip detected a protocol error while attempting to execute a
floating-point instruction.

The CFPA chip detected a reserved instruction while attempting to
execute a floating-point instruction.

The CFPA chip returned an illegal status code while attempting to execute
a floating-point instruction.

Memory management errors indicate that the microcode in the CVAX

processor chip detected an impossible situation while performing memory
management functions. The most likely cause of this type of a machine
check is a problem internal to the CVAX chip. Machine checks due
to memory management errors are nonrecoverable. Depending on the
current mode, either the current process or the operating system should
be terminated. The state of the POBR, POLR, P1BR, P1LR, SBR, and SLR

should be logged.

3-20

Hardware Architecture

Code,s

Error Description

The calculated virtual address for a process PTE was in the PO space
instead of in the system space when the CVAX processor attempted to
access a procese PTE after a translation buffer miss.

The calculated virtual address space for a process PTE was in the P1
space instead of in the system space when the CVAX processor attempted
to access a process PTE after a translation buffer miss.

The calculated virtual address for a process PTE was in the PO space
instead of in the system space when the CVAX processor attempted to
access a process PTE to change the PTE<M: bit before writing to a
previously unmodified page.

The calculated virtual address for a process PTE was in the P1 space
instead of in the system space when the CVAX processor attempted to
access a process PTE to change the PTE<M> bhit before writing to a
previously unmodified page.

Interrupt errors indicate that the interrupt controller in the CVAX
processor requested a hardware interrupt at an unused hardware IPL.
The most likely cause of this type of a machine check is a problem
internal to the CVAX chip. Machine checks due to unused IPL errors
are nonrecoverable. A nonvectored interrupt generated by a serious error
condition (memory error, power fail, or processor halt) has probably been
lost. Execution of the operating system should be terminated.
Code,;

Error Description

A hardware interrupt was requested at an unused IPL.

Microcode errors indicate that the microcode detected an impossible
situation during instruction execution. Note that most erroneous branches
in the CVAX processor microcode cause random microinstructions to be
executed. The most likely cause of this type of machine check is a problem
internal to the CVAX chip. Machine checks due to microcode errors are
nonrecoverable. Depending on the current mode, either the current process

or the operating system should be terminated.
Codey¢

Error Description

An impossible state was detected during an MOVC3 or MOVC5
instruction (not move forward, move backward, or fill).

Read errors indicate that an error was detected when the CVAX processor
tried to read from the internal cache, main memory, or an external /O
device. The most likely cause of this type of machine check must be

Hardware Architecture

3-21

determined from the state of the MSER. Machine checks due to read errors
may be recoverable, depending on the state of the VAX can ( restart flag
(- aptured in internal state information 2 <15>) and the first part done
flag (captured in PSL <275). If the first part done flag is set, the error
is recoverable. If the first part done flag is cleared, then the VAX can’t
restart flag must also be cleared for the error to be recoverable; otherwise,
the error is unrecoverable and depending on the current mode, either
the current process or the operating system should be terminated. The
information pushed onto the stack by this type of machine check is from
the instructio.a that caused the machine check.
Codes

Error Description

An error occurred while reading an operand, a process page table entry
during address translation, or on any read generated as part of an
interlocked instruction.

An error occurred while reading a system page table entry during address
translation, a process control block entry during a context switch, or a
system control block entry while processing an interrupt.

Write errors indicate that an error was detected when the CVAX processor
tried to write to either the internal cache, the main memory, or an external
I/O device. The most likely cause of this type of machine check must be
determined from the state of the MSER. Machine checks due to write
errors are nonrecoverable, because the processor can perform many read
operations out of the internal cache before a write operation completes. For
this reason, the information that is pushed onto the stack by this type of
machine check cannot be guaranteed to be from the instruction that caused
the machine check.

Code,¢

Error Description

An error occurred while writing an operand, or a process page table entry to
change the PTE<M> bit before writing a previously unmodified page.

An error occurred while writing a system page table entry to change the
PTE<M> bit before writing a previously unmodified page, or while writing
a process control block (PCB) entry during a context switch or during the
execution of instructions that modify any stack pointers stored in the PCB.

Most Recent Virtual Address Parameter

Most recent virtual address <31:00> captures the contents of the virtual
address pointer register at the time of the machine check. If a machine check
other than machine check 81 occurs on: a read operation, this field represents

3-22

Hardware Architecture

the virtual address of the location that is being read when the error occurs,
plus four. If machine check 81 occurs, this field represents the physical address
of the location that is being read when the error occurs, plus four.
If a machine check other than machine check 83 occurs on a write operation,
this field represents the virtual address of a location that is being referenced
either when the error occurs, or sometime after, plus four. If a machine check
83 occurs, this field represents the physical address of the location that was
being referenced either when the error occurs, or sometime after, plus four. In
other words, if the machine check occurs on a write operation, the contents of
this field cannot be used for error recovery.
internal State Information 1 Parameter

Internal state information 1 is divided into four fields. The contents of these
fields are described as follows:

<31:24> captures the opcode of the instruction that was being read or
executed at the time of the machine check.

<23:16> captures the internal state of the CVAX processor chip at the
time of the machine check. The four most significant bits are equal to
<1111>, and the four least significant bits contain highest priority software
interrupt <3:0>.

«15:08> captures the state of CADR<07:00> at the time of the machine
check. See Section 3.3.2.5 for an interpretation of the contents of this
register.

«07:00> captures the state of the MSER<07:00> at the time of the machine
check. See Section 3.3.2.6 for an interpretation of the contents of this
register.

internal State Information 2

Internal state information 2 is divided into five fields. The contents of these
fields are described as follows:

<31:24> captures the internal state of the CVAX processor chip at the time
of the machine check. This field contains SC register <7:0>.

<23:16> captures the internal state of the CVAX processor chip at the
time of the machine check. The two most significant bits are equal to 11
(binary), and the six least significant bits contain state flags <5:0>.

<15> captures the state of the VAX can'’t restart flag at the time of the
machine check.

Hardware Architecture

3-23

<14:08> captures the internal state of the CVAX processor chip at the time
of the machine check. The three most significant bits are equal to 111

(binary), and the four least significant bits contain ALU condition codes.

<07:00> captures the offset between the virtual address of the start of the

instruction being executed at the time of the machine check (saved PC) and
the virtual address of the location being accessed (PC) at the time of the
machine check.

PC<31:00> captures the virtual addrzss of the start of the instruction being
executed at the time of the machine check.
PSL

PSL<31:00> captures the contents of the PSL at the time of the machine check.
3.1.125 System Controi Block

The system control block (SCB) consists of at least two pages in memoery that
contain the vectors by which interrupts and exceptions are dispatched to the
appropriate service routines. IPR 17, the system control block base register
(SCBB), points to the SCB. Figure 3—5 represents the SCB; Table 3-6 describes
its format.

Figure 3-5 System Control Block Base Register
313029
|

0908
I

0
I

Y D

Physical Longword Address of PCB
T

O O OO

0
5

:SCcBB
A

MLO-004409

Table 3-6

System Control Block Format

sCB

interrupt/Exception

Unused

Machine check

Offset,s

Name

Type

Param-

eter

Notes
IRQ passive release on other

VAX systems

Abort

Parameters depend on error
type
(continued on next page)

3-24

Hardware Architecture

Table 3-6 (Cont.)

System Control Block Format

SCB
Offset,s,

interrupt/Exception
Name

Type

Parameter

Kernel stack not valid

Abort

Notes
Must be serviced on
interrupt stack

ocC

Power fail

Interrupt 0

IPL is raised to 1E¢

Reserved/privileged

Fault

)

Fault

XFC instruction

Fault/

Not always recoverable

instruction

Customer reserved
instruction

Reserved operand

Abort

Reserved addressing

Fault

Access control violation

Fault

mode

Parameters are virtual
address, status code

Translation not valid

Fault

Parameters are virtual
address, status code

Trace pending (TP)

Fault

Breakpoint instruction

Fault

Unused

Arithmetic

Compatibility mode in other
VAX processors

Trap/

Parameter is type code

Parameter is sign-

Fault

38:3C

Unused

CHMK

Trap

extended operand word

CHME

Trap

Parameter is signextended operand word

CHMS

Trap

Parameter is signextended operand word

CHN'TM

Trap

Parameter is signextended operand word

50:80

Unused

Software level 1

Interrupt 0O
(continued on next page)

Hardware Architecture

3-25

Table 3-5 (Cont.) System Control Block Format
Parameter

SCB
Offset;e

Interrupt/Exception
Name

Type

Software leve] 2

Interrupt 0

Software level 3

Interrupt 0

90:BC

Software levels 4-15

Interrupt 0

Interval timer

Interrupt 0

Unused

Emulation start

Fault

Emulation continue

Fault

DO:DC

Unused

EO:EC

Reserved for customer or

FO:FC

Unused

100:1FC

Adapter vectors

Interrupt 0

200:7FFC Device vectors

Interrupt 0

Notes
Ordinarily used for AST

delivery

Ordinarily used for process
scheduling

IPL is 1635 (INTIM)

Same mode exception,

FPD=0, parameters are
opcode, PC, specifiers

Same mode exception,

FPD=1: no parameters

CSS use

Reserved to Digital
Not implemented by the
rtVAX 300

Correspond to DAL

bus vectors placed on
DAL<15:02> H

3.1.12.6 Hardware Detected Errors

The rtVAX 300 can detect three types of error conditions during program
execution:

3--26

DAL bus parity errors indicated by MSER<6> (on a read) being set. (This
error cannot be distinguished if detected during a read reference.)

Internal cache tag parity errors indicated by MSER<0> being set.

Internal cache data parity errors indicated by MSER<1> being set.

Hardware Architacture

. 3.1.12.7 Hardware Halt Procedure

The hardware halt procedure is the mechanism by which the hardware assists
the firmware in emulating a processor halt. The hardware halt procedure
saves the current value of the PC in IPR 42 (SAVPC), and the current value
of the PSL, MAPEN<«0>, and a halt code in IPR 43 (SAVPSL). The current
stack pointer is saved in the appropriate internal register. The PSL is set to
041F0000 (IPL=1F¢, kernel mode, using the interrupt stack), and the current
stack pointer is loaded from the interrupt stack pointer. Control then passes
to the resident firmware at physical address 20040000 with the state of the
processor as follows:

New Contents

SAVPC

Saved PC

SAVPSL«31:16>, <07:00>

Saved PSL«<31:16>, <07:00>

SAVPSL<15>

Saved MAPEN<0>

SAVPSL<14>

Valid PSL flag (unknown for halt code of 3)

SAVPSL<13:8>

Saved restart code

Current interrupt stack

PSL

041F0000

20040000

MAPEN

ICCS

0 (for a halt code of 3)

MSER

0 (for a halt code of 3)

CADR

0 (for a halt code of 3, internal cache is also flushed)

SISR

0 (for a halt code of 3)

ASTLVL

0 (for a halt code of 3)

All else

Undefined

The firmware uses the halt code in combination with any hardware event
indicators to dispatch the execution or interrupt that caused the halt to the
appropriate firmware routine (either console emulation, power-up, reboot, or
restart). Table 3—-7 and Table 3—8 list the interrupts and exceptions that can
cause halts along with their corresponding halt codes and event indicators.

Hardware Architecturs

3-27

Table 3-7 Nonmaskable interrupts That Can Cause a Halt
Hait Code

Interrupt Condition

External halt (CVAX HLT L pin asserted)

Hardware reset (CVAX RST L pin asserted)

Table 3-8

Exceptions That Can Cause a Hait

Hal Code

Exception Condition

Halt instruction executed in kernel mode.

Exceptions While Servicing an Interrupt or Exception
4

Interrupt stack not valid during exception.

Machine check during normal exception.

SCB vector bits<1:0> = 11.

SCB vector bits<1:0> = 10.

CHMx executed while on interrupt stack.

CHMx ex:cuted to the interrupt stack.

ACV or TNV during machine check exception.

ACV or TNV during kernel stack not valid exception.

Machine check during machine check exception.

Machine check during kernel stack not valid exception.

PSL<26:24> = 101 during interrupt or exception.

PSL«26:24> = 110 during interrupt or exception.

PSL<26:24> = 111 during interrupt or exception.

PSL<«26:24> = 101 during REIL

PSL<26:24> = 110 during REL

PSL<«26:24> = 111 during REIL

3.1.13 System Identification
The system identification register (SID), IPR 62, is a 32-bit read-only register
implemented in the CVAX chip, as specified in the VAX Architecture Reference
Manual. This register identifies the processor type and its microcode revision
level. Figure 3-6 shows the system identification register; Table 3-9 describes
its fields.

3-28

Hardware Architecture

2423

§ @ §
§

Type
8 b

4§

4.2
3 1

2.l

o8 o7

Rosorved

g¢

4 3

Lo¢

HMicrocode
6

§F

F 0 b

F Bk
k

ME O-004410

Table 3-8 System Identification Register Fields
Data Bit

<31:24>

<23:08>

<07:00>

Definition

Processor type (TYPE). This field always reads as 0A;s, indicating

that the processor is implemented using the CVAX chip.

Reserved for future use.

Microcode revision (MICROCCDE REV.). This field reflects the

microcode revision level of the CVAX chip.

3.1.14 CPU References
All references by the CVAX processor can be classified into one of three groups:

3.1.14.1

Request instruction-stream read references

Demand data-stream read references

Write references

instruction-Stream Read References

The CVAX processor has an instruction prefetcher with a 12-byte (3 longword)
instruction prefetch queue (IPQ) for prefetching program instructions from
either cache or main memory. Whenever there is an empty longword in the
IPQ and the prefetcher is not halted due to an error, the instruction prefetcher
generates an aligned longword, reguest instruction-stream (I-stream) read
reference.

3.1.14.2

Data-Stream Read References

Whenever data is immediately needed by the CVAX processor to continue
processing, a demand data-stream (D-stream) read reference is generated.
More specifically, demand D-stream references are generated on operand, page
table entry (PTE), system control block (SCB), and process control block (PCB)
references.

Hardware Architecture

3-29

When interlocked instructions, such as branch on bit set and set interlock
(BBSSI) are executed, a demand D-stream read-lock reference is generated.
Since the CVAX processor does not impose any restrictions on data alignment
(other than the aligned operands of the ADAWI and interlocked ¢ ueue
instructions) and since memory can be accessed only one aligned longword at
a time, all data read references are translated into an appropriate combination
of masked and nonmasked, aligned longword read references.
If the required data is a byte, a word within a longword, or an aligned
longword, then a single, aligned longword, demand D-stream read reference is
generated. If the required data is a word that crosses a longword boundary,
or an unaligned longword, then two successive aligned longword demand Dstream read references are generated. Data larger than a longword is divided
into a number of successive aligned longword demand D-stream reads, with no
optimization.

3.1.14.3 Wrlte References
Whenever data is stored or moved, a write reference is generated. Since the
CVAX processor does not impose any restrictions on data alignment (other than
the aligned operands of the ADAWI and interlocked queue instructions) and
since memory can be accessed only one aligned longword at a time, all data
write references are translated into an appropriate combination of masked and
nonmasked aligned longword write references.
If the required data is a byte, a word within a longword, or an aligned
longword, then a single, aligned longword write reference is generated. If
the required data is a word that crosses a longword boundary or an unaligned
longword, then two successive aligned longword write references are generated.
Data larger than a longword is divided into a number of successive aligned
longword writes.

3.2 Floating-Point Accelerator
The floating-point accelerator is ipiplemented in a single VLSI chip.

3.2.1

Floating-Point Accelerator Instructions
The floating-point accelerator processes F_floating, D_floating, and G_floating
format instructions and accelerates the execution of MULL, DIVL, and EMUL
integer instructions.

3-30

Hardware Architecture

3.2.2 Floating-Point Accelerator Data Types
The rtVAX 300 floating-point accelerator supports byte, word, longword,
quadword, F_floating, D_floating, and G_floating data types. The H_floating
data type is not supported, but may be implemented by macrocode emulation.

3.3 Cache Memory
To maximize CVAX processor performance, the rtVAX 300 incorporates a
1K-byte cache implemented within the CVAX chip.

3.3.1

Cacheable References
Any reference that can be stored by the internal cache is called a cacheable
reference. The internal cache stores CVAX processor read references to the
VAX memory space (bit <29> of the physical address equals 0) only. It does not
cache /O space references or DMA references by external devices, including
the Ethernet coprocessor. The type(s) of CVAX processor references that
can be cached—either request instruction-stream (I-stream) read references,
or demand data-stream (D-stream) read references other than read-lock
references—is determined by the state of cache disable register CADR<5:4>.
The normal operating mode is for both I-stream and D-stream references to be
stored.

Whenever the CVAX processor generates a noncacheable reference, a single
longword reference of the same type is generated on the DAL bus.
Whenever the CVAX processor generates a cacheable reference stored in the
internal cache, no reference is generated on the DAL bus.
Whenever the CVAX processor generates a cacheable reference not stored
in the internal cache, a quadword transfer is generated on the DAL bus. If
the CVAX processor reference is a request I-stream read, then the quadword
transfer consists of two indivisible longword transfers, the first being a request
I-stream read (prefetch), and the second being a request I-stream read (fill). If
the CVAX processor reference is a demand D-stream read, then the quadword
transfer consists of two indivisible longword transfers, the first being a demand
D-stream read, and the second being a request D-stream read (fill).

Hardware Architecture

3-31

3.3.2 Internal Cache
The rtVAX 300 includes a 1K-byte, 2-way associative, write-through internal
cache with a 100-ns cycle time. CVAX processor read references access one
longword at a time; CVAX processor wriies access one byte at a time. A single
parity bit is generated, stored, and checked for each byte of data and each tag.
The internal cache can be enabled/disabled by setting/clearing the appropriate
bits in the CADR. The internal cache is flushed by any write to the CADR, as
long as cache is not in diagnostic mode.
3.3.2.1

Internal Cache Organization

The internal cache is divided into two independent storage arrays called set

1 and set 2. Each set contains a 64-row by 22-bit tag array and a 64-row by
72-bit data array. Figure 3-7 shows the organization of the two sets.

‘

Figure 3-7 Internal Cache Organization
Set 1

Set2

Rows

64 by 22-Bit|

Tag Array

64 by 72-Bit

64 by 22-Bit|

Data Array

Tag Array

64 by 72-Bit

Data Array

—Cache

Entry

~ 7271

7271

MLO-004411

A row within a set corresponds to a cache entry, so there are 64 entries in each
set and a total of 128 entries in the entire cache. Each entry contains a 22-bit
tag block and a 72-bit (8-byte) data block. Figure 3—8 shows the organization
of a cache entry.

3-32

Hardware Architecture

‘

Figure 3-8

Internal Cache Entry

7271
B

I
N

00
A

RO N

Tag Block

Data Block

NSNS
N

MLO-004412

A tag block consists of a parity bit, a valid bit, and a 20-bit tag. Figure 3-9
shows the organization of a tag block.

Figure 3-9 Internal Cache Tag Block
212019

00
rrrrrrrerrerrrrryynrey

Piv

Tag
| S

Parity
Valid

VO T

Oy O

Bit
Bit ——

e O O

MLO-004413

A data block consists of 8 bytes of data, each with an associated parity bit. The
total data capacity of the cache is 128 8-byte blocks, or 1024 bytes. Figure 3-10
shows the organization of a data block.
Figure 3-10

Internal Cache Data Block
Data Bits

Byte7

|P|

Byte
6

|P|

Byte5

|P|

Byte4

{P|

Byte3

|P|

Byte
2

{P|

Byte1

|P|

Byto
0

Parity Bits

MLO-004414

3.3.2.2

Internal Cache Address Translation
Whenever the CVAX processor requires an instruction or dat3, the contents of
the internal cache are checked to < ‘termine if the referenced location is stored
there. The cache contents are checked by translating the physical address as
follows:

On noncacheable references, the reference is never stored in the cache, so
an internal cache miss occurs and a single longword reference is generated

on the DAL bus.

Hardware Architecture

3-33

On cacheable references, the physical address must be translated to
determine if the contents of the referenced location resides in the cache.
The cache index field, bite <8:3> of the physical address, is used to select
one of the 64 rows of the cache, with each row containing a single entry
from each set. The cache tag field, bits <28:9> of the physical address, is
then ompared to the tag block of the entry from both sets in the selected
YOW.

If a match occurs with the tag block of one of the set entries and the valid bit
within the entry is set, the cache contains the contents of the referenced

location, and a cache hit occurs. On a cache hit, the set match signals
generated by the compare operation select the data block from the appropriate
get. The cache displacement field, bits <2:0> of the physical address, is used
to select the byte(s) within the block. No DAL bus transfers are initiated on
CVAX processor references that hit the internal cache.
If no match occurs, the cache does not contain the contents of the referenced
location, and a cache miss occurs. In this case, the data must be obtained
from either second-level cache or the main memory controller, so a quadword
transfer is initiated on the DAL bus (Figure 3-11).
3.3.2.3 Internal Cache Data Block Allocation

Cacheable references that miss the internal cache initiate a quadword read on
the DAL bus. When the requested quadword is supplied by either the secondlevel cache or the main memory controller, the requested longword is passed on
to the CVAX processcr, and a data block is allocated in the cache to store the
entire quadword.
Because the cache is 2-way associative, only two data blocks (one in each set)
can be allocated to a given quadword. These two data blocks are determined
by the cache index field of the address of the quadword, which selects a unique
row within the cache. Selection of a data block within the row (for example, set
selection) for storing the new entry is random.

Since the rtVAX 300 supports 2566M bytes (32M quadwords) of physical
memory, up to 512K quadwords share each row (two data blocks) of iire cache.
Contiguous programs larger than 512 bytes or any noncontiguous programs
separated by 512 bytes have a 50 percent chance of overwriting themselves
when cache data blocks are allocated for the first time for data separated by
512 bytes (one page). After six allocations, there is a 97 percent probability
that both sets in a row will be filled.

3-34

Hardware Architecture

Figure 3-11 internal Cache Address Translation
2828
N

0302

Cache Tag
]LLLLLIILJ_IIIIIIIIJ

/O Space

Cache index—

Cache Displacement ~——Valid Bit

Valid Bit

Set 1

{

20-Bit|
64-Bit
Tag | Data Block .

Set2

20-Bit|
64-Bit
Tag | Data Block

pA
Set | 1Match?

0008
L

Set | 2Match?

A
Data

3.3.2.4

MLO-004567

Internal Cache Behavior on Writes
On CVAX processor-generated write references, the internal cache is write-

through. All CVAX processor write references that hit the internal cache cause

the contents of the referenced location in main memory to be updated as well
as the copy in the cache.

On DMA write references that hit the internal cache, the cache entry

containing the copy of the referenced location is invalidated. If the internal
cache is configured to store only I-stream references, then the entire internal
cache is also flushed whenever an REI instruction is executed. (The VAX
architecture requires that an REI instruction be executed before executing
instructions out of a page of memory that has been updated.)

Hardware Architecture

3-35

3.3.2.5 Cache Disable Register
The cache disable register (CADR), IPR 37, controls the internal cache, and is

unique to processor designs that use the CVAX chip. Figure 3-12 shows the
cache disable register, and Table 3—10 lists its fields.
Figure 3-12

Cache Disable Register
0807 0605040302 0100

31
tv

rrrrrarrerrrrrrrrrryu

a1 g0

2|1IS|S|1]1|W!

IEEEE

PiA

MLO-006381

Table 3-10

Cache Disable Register Fields

Data Bit

Definition

<31:08>

Unused. Always read as zeros. Writes have no effect.

<07:06>

Used selectively to enable or disable each set within the cache.

<07>

S2E. Read/write. When set, set 2 of the cache is enabled. When
cleared, set 2 of the cache is disabled. Cleared on power-up by the
negation of RST L.

<06>

S1E. Read/write. When set, set 1 of the cache is enabled. When
cleared, set 1 of the cache is disabled. Cleared on power-up by the
negation of RST L.

<05:04>

Used selectively to enable or disable storing I-stream and D-stream
references in the cache.

<05>

ISE. Read/write. When set, I-stream memory space references are
stored in cache, if it is enabled; when cleared, .hey are not stored in
cache. Cleared on power-up by the negation of RST L.

<04>

DSE. Read/write. When set, D-stream memory space references are
stored in cache, if it is enabled; when cleared, they are not stored in
cache. Cleared on power-up by the negation of RST L.

<03:02>

Unused. Always read as 1s.

<01>

Write wrong parity (WWP). Read/write. When set, incorrect parity
is stored in the internal cache whenever it is written. When cleared,
correct parity is stored in the cache whenever the cache is written.
Cleared on power-up by the negation of RST L.

{(continued on next page)

3-36

Hardware Architecture

Table 3-10 (Cont.)
Data Bit

<00>

Cache Disable Register Flelds

Definition

Diagnostic mode (DIA). Read/write. When set, the internal cache is in

diagnostic mode, and writes to the CADR will not cause the internal
cache to be flushed. When cleared, the cache is in normal operating

mode, writes to the CADR cause the internal cache to be flushed (all
valid bits set to the invalid state), and the internal cache is configured
for write-through operation.

Note

The internal cache can be disabled either by disabling both set 1 and
set 2 (clearing CADR<07:06>) or by not storing either I-stream or
D-stream references (clearing CADR<05:04>).

For improved performance, the cache should be configured to store both I-

and D-stream references. I-stream only mode suffers from a degradation in
performance from what would normally be expected relative to I- and D-stream
mode and D-stream only mode, because invalidation of cache entries due to
writes to memory by a DMA device are handled less efficiently.
In I-stream only mode, the entire internal cache is flushed whenever an REI
instruction is executed. The VAX Architecture Reference Manual states that

an REI instruction must be executed before executing instructions out of a
page of memory that has been updated, whereas in the other two modes of
operation, cache entries are invalidated on an individual basis, only if a DMA
write operation results in a cache hit.

CVAX processor write references with a longword destination (for example,
MOVL) write the data into main memory (if it exists), as well as invalidate the
corresponding cache entry, irrespective of whether or not a cache hit occurred.
CVAX processor write references with a quadword destination (for example,
MOVQ) write the data into main memory (if it exists) and cause the second

longword of the quadword to be written into the longword of the cache data
array that corresponds to the address of the first longword of the destination,
irrespective of whether or not a cache hit occurred.

The data in the longword of the cache data array that corresponds to the
address of the second longword of the destination remains unaltered. In

addition, errors generated during write references, which would normally
cause a machine check, are ignored; they do not generate a machine check trap
or prevent data from being stored in the cache.

Hardware Architecture

3-37

Diagnostic mode is intended to allow the internal cache tag store to be fully ‘
tested without requiring 512M bytes of main memory. This mode makes it
possible for the tag Flock in a particular cache entry to be written with any
pattern by executing a MOVQ instruction with bits <28:9> of the destination
address equal to the desired pattern.

Two MOVQ instructions, one with a quadword aligned destination address and
one with the next longword aligned destination address, are required to write

to both longwords in the data block of a cache entry. Diagnostic mode does not
affect read references.

Note

At least one read reference must occur between all write references
made in diagnostic mode. Diagnostic mode should be selected when one
and only one of the two sets is enabled. Operation of this mode with
both sets enabled or both sets disabled yields unpredictable results.

3.3.2.6

Memory System Error Register
The memory system error register (MSER), IPR 39, records the occurrence of

internal cache hits, as well as parity errors on the DAL bus in the cache. This ‘
register is unique to CVAX processor designs. MSER<6:4,1:0> are peculiar in
the sense that they remain set until explicitly cleared. Each bit is set o2 the
first occurrence of the error it logs and remains set for subsequent occurrences
of that error. The MSER is explicitly cleared through the MTPR instruction
irrespective of the write data. Figrire 3-13 shows the memory system error
register; Table 3-11 lists its fields.
Figure 3-13

Memory Systam Error Register

0807060504 03020100
tvr

Pri

i1 1rv

11717t

1r++r171r1t0eq+d v

DUEE RSN

LiDIC

TIG
MLO-004569

3-38

Hardware Architecture

Table 3-11

Memory System Error Register Fields

Data Bit

Definition

<31:08>

Unused. Always read as zero. Writes have no effect.

<07>

Hit/miss (HM). Read only. Writes have no effect. Cleared on all

cacheable references that hit the internal cache. Set on all cacheable
references that miss the internal cache. Cleared on power-up by the

negation of RST L.

<06>

DAL parity error (DAL). Read/write to clear. Set whenever a DAL bus
parity error is detected. Cleared on power-up by the negation of RST
L.

<05>

Machine check (MCD). DAL parity error. Read/write to clear. Set
whenever a DAL bus data parity error causes a machine check.
These errors generate machine checks only on demand D-stream read
references. Cleared on power-up by the negation of RST L.

<04>

Machine check (MCC). Internal c~che parity error. Read/write to
clear. Set whenever an internal cacl.e parity error in the tag or data
store causes a machine check. These errors generate machine checks
only on demand D-stream read references. Cleared on power-up by
the negation of RST L.

<03:02>

Unused. Always read as zero. Writes have no effect.

<01>

Data parity error (DAT). Read/write to clear. Set when a parity
error is detected in the data store of the internal cache. Cleared on
power-up by the negation of RST L.

<00>

3.3.2.7

Tag parity error (TAG). Read/write to clear. Set when a parity error is
detected in the tag store of the internal cache. Cleared on power-up
by the negation of RST L.

Internal Cache Error Detection
Both the tag and data arrays in the internal cache are protected by parity.

Each 8-bit byte of data and the 20-bit tag are stored with an associated parity
bit. The valid bit in the tag is not covered by parity. Odd data bytes are stored
with odd parity; even data bytes are stored with even parity. The tag is stored
with odd parity.

The stored parity is valid only when the valid bit associated with the internal
cache entry is set. Tag and data parity (on the entire longword) are checked on
read references that hit the internal cache, but only tag parity is checked on
CPU and DMA write references that hit the internal cache.

Hardware Architecture

3-39

The action taken following the detection of an internal cache parity error

depends on the reference type:
e

During a demand D-stream read reference, the entire internal cache is
flushed, the CADR is cleared (which disables the first level cache and
causes the second-level cache to ignore all read operations). The cause of
the error is logged in MSER<4:0>, and a machine check abort is initiated.

During a request I-stream read reference, the entire internal cache is
flushed (unless CADR«<0> is set), the cause of the error is logged in
MSER«<1:0>, the prefetch is halted, but no machine check abort occurs,
and both caches remain enabled.

During a masked or nonmasked write reference, the entire internal cache
is flushed (unless CADR<0> is set), the cause of the error is logged in
MSER«<0> (only tag parity is checked on CVAX processor writes that hit
the internal cache), there is no effect on CVAX processor execution, and
both caches remain enabled.

During a DMA write reference, the cause of the error is logged in
MSER<0> (only tag parity is checked on DMA writes that hit the internal
cache), there is no effect on CVAX processor execution, both caches remain

enabled, and no invalidate operation occurs.

3.4 Hardware Initialization
The VAX architecture defines three kinds of hardware initialization:

3.4.1

Power-up

T1/O bus

Processor

Power-Up Initialization
Power-up initialization occurs when power is restored and includes a hardware
reset, an I/O bus initialization, a processor initialization, and initialization
of several registers, as defined in the VAX Architecture Reference Manual. In
addition to initializing these registers, the rtVAX 300 firmware also configures
main memory and the local /O space registers.

An rtVAX 300 hardware reset occurs on power-up and the assertion of RGT
L. A hardware reset initiates the hardware halt procedure (Section 3.1.12.7)
with a halt code of 03. The reset also initializes some IPRs and most 1/0 space
registers to a known state. Those IPRs that are affected by a hardware reset
are noted in Section 3.1.4.3. The effect a hardware reset has on I/O space
registers is documented in the description of the registers.

3-40

Hardware Architecture

‘

. 3.4.2 /O Bus Initialization

An /O bus initialization occurs on power-up, the assertion of RST L when

the processor is halted, or as the result of an MTPR to IPR 55 (IORESET) or
console UNJAM command.
The I/0 bus reset register (IORESET), IPR 55, is implemented externally on
the rtVAX 300 application hardware. An MTPR of any value to IORESET
causes an I/O bus initialization.

3.4.3 Processor Initialization
A processor initialization occurs on power-up, on the assertion of RST L when

the processor is halted, as the result of a console INITIALIZE command, and
after a halt caused b an error condition.

3.5 Console Interface Registers
The following tables and figures list and show hardware registers that the
rtVAX 300 :rocessor references:

Boot register (Section 3.5.1)

Console registers for SCN 2681 DUART (Section 3.5.2)

Memory system control/status register (Section 3.5.3)

LED displ iy/status register (Section 3.5.4)

(Appendix C contains tables of rt VAX 300 address assignments.)

3.5.1

Bceot Register
The boot register is read once by the firmware when the system is powered on
or reset. Bits <3:0> define the initial value of bits <3:0> of the boot action cell.

This register is decoded by the rtVAX 300, and BOOT<3:0> L are used for the
contents of this register. If the user does not connect these pins, their default
value is 1. Figure 3—14 shows the boot register; Table 3-12 lists boot options

as they relate to register contents.

Hardware Architecture

3-41

Figure 3-14

Boot Register

04 03 02 01 00

Reserved

Remote Trigger

Power-On Boot Action
MLO-006371

Table 3-12

Boot Options

«2»L

<«1>L

<0=L

Device

Action

No boot performed. rtVAX 300 enters
console mode, executing the console
emulation program.

PRAO

Boot from ROM at location 10000000
in memory space.

PRBO

Boot from ROM in /O space.

PRB1

Copy ROM from I/O space to memory
space, and then boot.

CSBO

DECnet DDCMP boot using Channel
B of DUART at 1200 bps.

CSB1

DECnet DDCMP boot using Channel

B of DUART at 2400 bps.
X

CSB2

DECnet DDCMP boot using Channel
B of DUART at 9600 bps.

EZAO

Boot from Eth..aet using standard
MOQP protocol.

3-42

Hardware Architecture

Enable remote triggering.

‘

. 3.5.2 Console DUART Register

Table 3-13 lists the addresses for the console registers and their functions.
Table 3-13 Console Registers SCN 2681 DUART
Address

Read Function

Write Function

20100000

Channel A mode registers (MRA1,
MRA2)

Channe] A mode registers (MRA1,
MRA2)

20100004

Channel A status register (SRA)

Channel A clock select register

20100008

Reserved register

Channel A command register (CRA)

2010000C

Channel A receive holding register
(RHRA)

Channel A transmit holding register
(THRA)

20100010

Input port change register (IPCR)

Auxiliary control register (ACR)

Channel A/B interrupt status

Channel A/B interrupt mask register

20100018

Counter/timer interval register
upper (CTU)

Counter/timer interval register upper
(CTUR)

2010001C

Counter/timer interval register
lower (CTL)

Counter/timer interval register lower
(CTLR)

Channel B mode register (MRB1,

20100014

20100020

MRB2)

(CSRA)

(IMR)

MRB2)

20100024

Channel B status register (SRB)

Channel B clock select register

20100028

Reserved register

Channel B command register (CRB)

2010002C

Channel B receive holding register
(RHRB)

Channel B transmit holding register
(THRB)

20100030

Reserved register

20100034

Input port register

20100038

Start counter command register

2010003C

Stop counter commard register

(CSRB)

Output port configuration register

(OPCR)

Set output port bits command

Reset output port bits command

Hardware Architecture

343

3.5.3 Memory System Control/Status Register
To support systems with multiple processors sharing the same memory,
the rtVAX 300’s automatic memory system testing can be disabled. Digital
recommends that the memory testing be enabled, so that the firmware can
build a realistic page frame bitmap. Disabling the memory tests has the
advantage that self-tests will finish very quickly; however, the disadvantage of
doing this is that the page frame bitmap that is built lists all pages as “good.”
The firmware will not have tested each page, and bad pages will not have been
found and might be used by the VAXELN kernel. In addition, if parity or ECC
memory has been implemented, read cycles to locations that have not been
written to will cause par.ty error machine checks.

An external memory system control/status (MSCR) register located at physical
address 20110000 contains 1 bit; it can optionally be implemented to disable
memory tests. If this register is not implemented, the rtVAX 300 uses the
default bit value of 1, enabling memory tests. Figure 3—15 shows the layout of
this register; Table 3~14 describes its bit structure.
Figure 3-15

Memory System Control/Status Register

020100

L
O LML
R DR ML B

20110000

Undefined and Not Used
'

NS N

AN U

1
T

Enable Memory Tests
MLO-008348

Table 3-14
Bit

Memory System Control/Status Register Flelds

Description

<31:02> Unused.

<01>
<00>

Set if memory test is to be performed on power-up; cleared when test is not to

be performed. If the register is not implemented, the default is 1.

Unused.

Note

Digital does not recommend that memory tests be disabled. If they
are disabled, parity errors can occur when an uninitialized memory

3-44

Hardware Architecture

location is being read, and an untested page frame number bit map will
be generated.

3.5.4 Status LED Register
The rtVAX 300 allows you to connect a processor status LED display to display
the status of self-test and diagnostic routines. The rtVAX 300 will continue its
gelf-test routines if this optional register does not exist. The first digit indicates
the current state of the system; the second digit depends on the status of the
first digit. This register is mapped to the word location 201FFFFE.

Figure 3-16 shows the layout of this register; Table 3-15 describes its bit
structure. Table 3-16 is a LED display chart.
Figure 3-16

LED Display/Status Register

262524232221201918171615
IR

201FFFFC]

00
T

Reserved
[N

TT T T

Resarved

ISR TN N

Y St

YS G

BLANK LED B —A—
BLANK LED
LED_B<3» ————
LED B<2>
LED B<1>
LED_B<0>
LED A<3>
LED_A<2>
LED A<t>

LED_A<O>

Table 3-15

MLO-004509

LED Display/Status Register Fields

Bit
BLANK_LED_B

BLANK_LED_A

Description
Blank or turn off the most significant LED display digit: 1 means

blank or disable this display digit; 0 means to enable this display
digit.

Blank or turn off the least significant LED display digit: 1 means

blank or disable this display digit; 0 means enable this display
digit.

(continued on next page)

Hardware Architecture

3-45

Table 3-15 (Cont.)
Bit

Description

LED_B«3:0>

The 4-bit binary hexadecimal code to be displayed on the most

LED_A<3:0>

The 4-bit binary hexadecimal code to be displayed on the least
significant LED display. Note that these signals are inverted.

significant LED display. Note that these signals are inverted.

LED Display Chart

LED<3:0>

BLANK

1010
1011

1100

O
0P

O
o
0
O
O
o

1110

1111

1101

1001

W ok

1000

0111

0110

0101

HEX Code Displayed

0100

0011

0010

0001

Table 3-16

0000

Blanked

XXXX

3-46

LED Display/Status Register Flelds

Hardware Architecture

3.6 Ethernet Coprocessor
The Ethernet coprocessor supports the Ethernet interface to the rtVAX 300

processor. Figure 3-17 shows a block diagram of this function. This section
provides an overview of the following:
¢

Control/status registers (Section 3.6.1)

Descriptors and buffers format (Section 3.6.2)

Operation (Section 3.6.3)

Serial interface (Section 3.6.4)

Diagnostics and testing (Section 3.6.5)

Figure 3-17 Ethernet Coprocessor Block Diagram
16
)

DAL<31:00> «a—

AS w—=

BM/TEST<3:0> <¢—»
WR <—»

Receive

RDY

Receive

)

la—— RX

FIFO

Machine
4

1OP

RCLK
RXEN

CLSN

ERR ——~
<~a—bx

Bus
interface
Unit

Transmit | 16

[*TTM et > TX
TCLK
Machine

mF0

CSDP<3:0>

o= TXEN

I
AOM

%_‘ internal IOP Bus
)

RAM

f To All Blocks
e CLKA

Clocks

t— CLKB
ng— RESET
MLO-004415

Hardware Architecture

3-47

- 3.6.1 Control/Status Registers

The Ethernet coprocessor contains 16 CSRs, found at locations 20008000
through 2000803F, that are used to control its operation. The CSRs are located
in the I/O address space. The register addresses must be longword-aligned and
can be accessed only by using longword instructions. The CSRs are divided
into two groups: physical CSRs and virtual CSRs. The assigned locations for
the registers are defined in Table 3-17.
You program the Ethernet interface by reading and writing to these registers.
The network ID ROM provides the physical network address for the rtVAX 300
at 20008040 to 200080BF.

‘

The physical CSRs are CSR0 through CSR7 and CSR15. These registers are
physically present in the Ethernet coprocessor and are directly accessed by
the rtVAX 300 processor. The rtVAX 300 processor can access these registers
by a single longword instruction. The rtVAX 300 perceives no delay, and the
instruction completes immediately. The physical CSRs contain most of the
commonly used features of the Ethernet coprocessor.

The virtual CSRs are CSR8 through CSR14. These registers are not directly
accessible to the rtVAX 300 processor. When the rtVAX 300 processor accesses

one of these registers, the Ethernet coprocessor controls access to these

registers by fetching the requested information from on-chip memory and
passing it to the rtVAX 300 processor. Table 3-17 lists and describes Ethernet

‘

coprocessor registers.
Table 3-17
Address

Ethernet Coprocessor Registers

Name

20008000 CSRO

Vector Address, IPL, Sync/Async (see Section 3.6.1.1)

20008008 CSR2

Receive Polling Demand (see Section 3.6.1.2)

2000800C CSR3

Receive List Address (see Section 3.6.1.3)

20008010 CSR4

Transmit List Address (see Section 3.6.1.3)

20008014

Status Register (see Section 3.6.1.4)

20008004 CSR1

CSR5

Transmit Polling Demand (see Section 3.6.1.2)

20008018 CSR6

Command and Mode Register (see Section 3.6.1.5)

2000801C CSR7

System Base Register (see Section 3.6.1.6)

20008020 CSR8

Reserved
(continued on next page)

3-48

Hardware Architecture

‘

Table 3-17 (Cont.)
Address

3.6.1.1

Ethernet Coprocessor Registers

Name

20008024 CSR9

Watchdog Timer Register (see Section 3.6.1.7)

20008028 CSR10

Revision Number and Missed Frame Count (see Section 3.6.1.8)

2000802C CSR11

Boot Message Register (see Section 3.6.1.9)

20008030 CSR12

Boot Message Register (see Section 3.6.1.9)

20008034 CSR13

Boot Message Register (see Section 3.6.1.9)

20008038 CSR14

Breakpoint Address Register (see Section 3.6.1.10)

2000803C CSR15

Monitor Command Register (see Section 3.6.1.11)

Vector Address, IPL, Sync/Asynch (CSRO)
This register must be the first one written by the rtVAX 300, because the
Ethernet coprocessor may generate an interrupt on parity errors during rtVAX
300 writes to CSRs.
Caution

A parity error that occurs while the rtVAX 300 is writing to CSR0 may
cause an rtVAX 300 failure due to an erroneous interrupt vector. To
protect against failure, CSRO is written as follows while IPL 16,4 is

disabled:
1.

Write CSRO.

Read CSRO.

Compare value read to value written. If values mismatch, repeat
step 2.

Read CSR5 and examine CSR5<04> for pending parity interrupt.

Should an interrupt be pending, write CSR5 to clear it.

Figure 3—-18 shows the format of CSR0; Table 3-18 describes its bit structure.

Hardware Architecture

3-49

Figure 3-18 CSRO Format
3130292827262524 232221 201918171615

02 0100

IPA1111111111111

Interrupt Vector

‘

1{1] CSRO
O

MLO-004416

Table 3-18

CSRO Bits

Bit

Name

Access

Description

15:00

R/W

Interrupt Vector—During an interrupt acknowledge cycle
for an Ethernet coprocessor interrupt, the Ethernet
coprocessor drives this value on the rtVAX 300 bus
DAL<31:00> H pins.

DAL <31:16> and <01:00> H are set to 0. DAL<01:00> H
are ignored when CSRO is written and set to 1 when read.
29

R'W

31:30

R/'W

Sync/Asynch—Determines the Ethernet coprocessor

operating mode when it is the bus master. When this bit
is set, the Ethernet coprocessor operates as a synchronous
device; when clear, as an asynchronous device.
Interrupt Priority—Is the rtVAX 300 interrupt priority
level at which the Ethernet coprocessor interrupts.
P

IPLs

3.6.1.2 TransmitRecelve Polling Demands (CSR1, CSR2)

Figure 3-19 shows the format of both CSR1 and CSR2. Table 3-19 describes
the CSR1 bit structure; Table "-20 describes the bit structure of CSR2.

3-50

Hardware Architecture

Figure 3-19 CSR1/CSR2 Format
3130202827 26252423222120191817161514 13121 10080807 060504 03 02 0100

p CSR1
1111111111111111111111111111111D and

| CsRe

MLO-006382

Table 3-19

CSR1 Bits

Bit

Name

Access

Description

R/W

Transmit Polling Demand-—Checks the transmit list for
frames to be transmitted.

The PD value is meaningless.

Table 3-20

CSR2 Bits

Bit

Name

Access

Description

R/W

Receive Polling Demand—Checks the receive list for receive
descriptors to be acquired.

The PD value is meaningless.

3.6.1.3

Descriptor List Addresses (CSR3, CSR4)

The two descriptor list heads address registers are identical in function: one
is used for the transmit buffer descriptors and one for the receive buffer

descriptors. In both cases, the registers point the Ethernet coprocessor to the
start of the appropriate buffer descriptor list.

The descriptor lists reside in rtVAX 300 physical memory space and must be

longword-aligned.

Note

For best performance, Digital recommends that the descriptor lists be
octaword-aligned.

Cautlon

Initially, these registers must be written before the respective Start
command is given (see Section 3.6.1.5); otherwise, the respective
process remains in the stopped state. New list head addresses are

Hardware Architecture

3-51

acceptable only while the respective process is in the stopped or

suspended states. Addresses written while the respective process is

‘

in the running state are ignored and discarded.

If the rtVAX 300 attempts to read any of these registers before writing to them,

the Ethernet coprocessor responds with unpredictable values. Figure 3-20
shows the format of the descriptor list; Table 3-21 describes its bit structure.
Figure 3—20

313029

I, B

CSR3/CSR4 Format

][]

020100

Start of Receive List - RBA
)N

VO O

(N N U

ojo

0|0{ CSR3

Tt I

SN B O

Start of Transmit List - TBA
I

OO O

(Y Y

TS (N N

0|0} CSR4
T

0 = ignored by the SGEC

MLC-004418

Table 3-21 CSR3/CSR4 Blts

Bit

Name

Access

Description

CSP3

26:00

RBA

R/W

A 80-bit rtVAX 300 physical address of the start of
the receive list.

CSR4

29:00

TBA

R'W

A 30-bit rtVAX 300 physical address of the start of
the transmit list.

Note
The descriptor lists must be longword-aligned.

3-52

Hardware Architecture

. 3.6.1.4 Status Register (CSR5)

This register contains all the status bits that the Ethernet coprocessor reports
to the rtVAX 300. Figure 3-21 shows the format of CSR5; Table 3—22 describes
its bit structure.

CSRS5 Format

Figure 3-21
313029

06 0504 03 02 0100
2625242 ~212019181716151413121110090807
]

b s |s
1S

Table 3-22

RSt 1|OM
]

D
N

BI{TIRM|RIR|T}!

1111‘1111O

elulilils CSR5
MLO-004419

CSRS5 Bits

Bit

Name

Access

Description

R/W1

Interrupt Summary—The logical OR of CSR5<06:01>.

R/W1

Transmit Interrupt—When set, indicates one of the
following:
Either all the frames in the transmit list have been

transmitted (next descripior owned by the rtVAX

300), or a frame transmission was aborted due to a
locally induced error. The port driver must scan the
list of descriptors to determine the exact cause. The
transmission process is placed in the suspended state.
Chapter 5 explains the transmission process state
transitions. To resume processing transmit descriptors,

the port driver must issue the Poll Demand command.

A frame transmission completed, and TDES1<24> was
set. The transmission process remains in the running
state, unless the next descriptor is owned by the rtVAX
300 or the frame transmission aborted due to an error.
In the latter cases, the transmission process is placed
in the suspended state.
02

R/W1

Receive Interrupt—When set, indicates that a frame has
been placed on the receive list. Frame specific status
information was posted in the descriptor. The reception
process remains in the running state.

(continued on next page)

Hardware Architecture

3-53

Table 3-22 (Cont.)

CSRS Bits

Bit

Name

Access

Description

R/W1

Receive Buffer Unavailable—When set, indicates that
the rtVAX 300 owns next descriptor on the receive list

and could not be acquired by the Ethernet coprocessor. The
reception process is placed in the suspended state. Once set
by the Ethernet coprocessor, this bit will not be set again

until a poll demand is issued and the Ethernet coprocessor
encounters a descriptor that it cannot acquire. To resume

processing receive descriptors, the rtVAX 300 must issue

the poll demand command.

R/W1

Memory Error—Is set when any of the followi: ; occurs:

Ethernet coprocessor is the DAL bus master, and the

ERR L pin is asserted by external logic (generally
indicative of a memory problem)

Parity error detected on an rtVAX 300-to-Ethernet
coprocesaor CSR write or Ethernet coprocessor read
from memory

When Memory Error is set, reception and transmission

processes are aborted and placed in the stopped state.
Note: This point, port driver must issue a Reset command
and rewrite all CSRs.

R/W1

Receive Watchdog Timer Interrupt—When set, indicates

that the receive watchdog timer has timed out, indicating
that some other node is transmitting overlength packets
on the network. Current frame reception is aborted, and
RDESO«14> and RDES0<08> are set. Bit CSR5<02> is
also set. The reception process remains in the running
state.

R/W1

Transmit Watchdog Timer Interrupt—When set, indicates
that the transmit watchdog timer has timed out, indicating
that the Ethernet coprocessor transmitter was transmitting

overlength packets. The transmission process is aborted
and placed in the stopped state. (Also reported into the Tx
descriptor status TDES0<14> flag).
07

RW1

Boot Message—When set, indicates that the Ethernet
coprocessor has detected a boot message on the serial line
and has set the external pin BOOT L.
(continued on next page)

354

Hardware Arzhitecture

Table 3-22 (Cont.)

CSR5 Bits

Bit

Name

Access

Description
Done—When set, indicates that the Ethernet coprocessor

has completed a requested virtual CSR access. After a
reset, this bit is set.

1817

Operating Mode—These bits indicate the current Ethernet
coprocessor operating mode, as follows:

Value

Meaning

Normal operating mode.

Internal Loopback—Indicates that the Ethernet
coprocessor is disengaged from the Ethernet
wire. Frames from the transmit list are " oped
back to the receive list, subject to address
filtering.

23:22

External Loopback—Indicates that the Ethernet

Diagnostic Mode—Explained in Section 3.6.5.2.

coprocessor is working in full duplex mode.
Frames from the transmit list are transmitted
on the Ethernet wire and are looped back to the
receive list, subject to address filtering.

Reception Process State—Indicates the current state of the

reception process, as follows:
Value

Meaning

Stopped

Running

Suspended

Section 3.6.4.2 explains the reception process operation and
state transitions.

(continued on next page)

Hardware Architecture

3-55

Table 3-22 (Cont.)

CSRS5 Bits

Bit

Name Access

25:24

Description

Transmission Process State—Indicates the current state of

the transmission process, as follows:
Value

Meaning

Stopped

Running

Suspended

Section 3.6.4.1 explains the transmission process operation

and state transitions.

29:26

Self-Test Status—The self-test completion code (valid only

if CSR5<30> is set) is as follows:
Value

Meaning

0001

ROM error

0010

RAM error

0011

Address filter RAM error

0100

Transmit FIFO error

0101

Receive FIFO error

0110

Special loopback error

Note: Self-test takes 25 ms to complete.

Self-Test Failed—When set, indicates that the Ethernet

coprocessor self-test has failed. The self-test completion

code bits indicate the failure type.

Initiaiization Done—When set, indicates that the Ethernet
coprocessor has completed the initialization (reset and
self-test) sequences and is veady for further commands.
When clear, indicates that the Ethernet coprocessor ...
performing the initialization sequence and ignoring all
commands. After the initialization sequence completes, the
transmission and reception processes are in the stopped
state.

3-56

Hardware Architecture

‘

. 3.6.1.5 Command and Mode Register (CSR6)

This register is used to establish opzrating modes and for port driver
commands. Figure 3-22 shows the format of CSR6; Table 3-23 describes
its bit structure.

Figure 3-22 CSR6 Format
31302928

ElEr

2524
11

1615

121110090807060504
0302 0100
)

111122rrr1111$§omggrrgAFr.csne

J.J

Table 3-23

21201918

MLO-004420

CSR6 Bits

Bit

Name

Access

Description

2:1

R/W

Address Filtering Mode—Defines the way incoming frames
are addreas filtered:

Value

Meaning

Normal—Incoming frames are filtered
according to the values of the SDES1<25> and
SDES1«26> bits of the setup frame descriptor.

Promiscuous—All incoming frames are passed

to the rtVAX 300, regardless of the SDES1<25>
bit value.

All Multicast~—All incoming frames with
multicast destination addresses are passed to
the rtVAX 300. Inceming frames with individual

destination addresses are filtered according to
the SDES1<25> bit value.

Unused—Reserved.

(continued on next page)

Hardware Architecture

3-57

Table 3-23 (Cont.)

CSR6 Blts

Bit

Name

Access

Description

Pass Bad Frames Mode—When set, the Ethernet
coprocessor passes frames that have been damaged by
collisions or are too short due to premature reception
termination. Both events should have occurred within
the collision window (64 bytes), or else other errors are
reported.

When clear, these frames are discarded and never show up
in the rtVAX 300 receive buffers.
Note: Bad Frames is subject to the address filtering mode;
that is, to monitor the network, this mode must be set
together with the promiscuous address filtering mode.
6

R'W

Force Collision Mode—Allows the colligion logic to be
tested. This chip must be in internal loopback mode for FC
to be valid. If this bit is set, a collision is forced during the
next transmission attempt. This results in 16 transmission
attempts with excessive collision reported in the transmit
descriptor.

R/W

Disable Data Chaining Mode—When set, no data chaining
occurs in reception; frames no longer than the current

receive buffer are truncated. RDES0<09:08> are always
set. The frame length returned in RDES0<30:16> is the
true length of the nontruncated frame, while RDES0<10>
indicates that the frame has been truncated due to the
buffer overfiow.

When clear, frames too long for the current receive buffer
are transferred to the next buffer(s) in the receive list.
(continued on next page)

3-58

Hardware Architecture

Table 3-23 (Cont.) CSR6 Bits
Bit

Name

Access

Description

0:8

Operating Mode—Determine the Ethernet coprocessor
main operating mode:
Value

Meaning

Normal operating mode.

Internal Loopback-—The Ethernet coprocessor
will loop back buffers from the transmit list.

The data is passed from the transmit logic back
to the receive logic. The receive logic treats the
looped frame as it would any other frame and
subjects it to the address filtering and validity
check process.

R/W

External Loopback-—The Ethernet coprocessor
transmits normally and enables its receive logic
to its own transmissions. The receive logic
treats the looped frame as it would any other
frame and subjects it to the address filtering
and validity check process.

Reserved for diagnostics.

Start/Stop Reception Command-—When set, the reception
process is placed in the running state, the Ethernet

coprocessor attempts to acquire a descriptor from the

receive list and process incoming frames. Descriptor
acquisition is attempted from the current position in the
list, the address set by CSR3, or the pogition retained when
the Rx process was previously stopped. If no descriptor can
be acquired, the reception process enters the suspend state.

The Start Reception command is honored only when the
Reception process is in the stopped state. The first time
this command is issued, an additicnal requirement is that
CSR3 has already written to; otherwise, the reception
process remains in the stopped state.
When cleared, the reception process is placed in the stopped
state after completing reception of the current frame. The
next descriptor position in the receive list is saved and
becomes the current position after reception is restarted.
The Stop Reception command is honored only when the
reception process is in the running or suspended state.

(continued on next page)

Hardware Architecture

3-59

Table 3-23 (Cont.)

CSRE6 Bits

Bit

Name

Access

Description

R'W

Start/Stop Transmission Command—When set, the
transmission process is placed in the running state, and

the Ethernet coprocessor checks for a frame to transmit at
the transmit list at the current position, the address set by

CSR4, or the position retained when the Tx process was

previously stopped. If it does not find a frame to transmit,

the transmission process enters the suspend state. The
Start Transmission command is honored only when the
transmission process is in the stopped state. The first
time this command is issued, an additional requirement
is that CSR4 has already been written to; otherwise, the
transmission process remains in the stopped state.

When cleared, the transmission process ie placed in the
stopped state after completing transmission of the current
frame. The next descriptor position in the transmit list is

saved and becomes the current position after transmission
is restarted.

The Stop Transmission command is honored only when the
transmission process is in the running or suspended states.
19

Single-Cycle Enable Mode—When set, the Ethernet
coprocessor transfers only a single longword or an octaword
in a single DMA burst on the rtVAX 300 bus.

Boot Message Enable Mode—When set, enables the boot

28:25

message recognition. When the Ethernet coprocessor
recognizes an incoming boot message on the serial line,
CSR5<07> is set, and the external pin BOOT L is asserted
for a duration of 6*T cycles (of the rtVAX 300 clock).
Burst Limit Mode—Specifies the maximum number of
longwords to be transferred in a tingle DMA burst on the
rtVAX 300 bus.

When CSR6<19> is cleared, permissible values are 1, 2, 4,
and 8; when set, the only permissiole values are 1 and 4,
and a value of 2 or 8 is respectively forced to 1 or 4.
After initialization, the burst limit is set to 1.
30

R'W

Interrupt Enable Mode—When set, setting of CSR5<06:01>
generates an interrupt.

(continued on next page)

3~60

Hardware Architecture

Table 3-23 (Cont.)

CSR®6 Bits

BIt

Name

Access

Description

R/W

Reset Command—When set, the Ethernet coprocessor

aborts all processes and starts the reset sequence. After
completing the reset and self-test sequence, the Ethernet
coprocessor sets bit CSR5«<31>. Clearing this bit has no
effect.
Note: CSR5<05> value is unpredigtable on read after
hardware reset.

. 3.6.1.6 System Base Register (CSR7)

This CSR contains the physical starting address of the rtVAX 300 system page
table. This register must be loaded by rtVAX 300 software before any address
translaticn occurs so that memory will not be corrupted.
Figure 3-23 shows the format of CSR7; Table 3-24 describes its bit structure.
Figure 3-23

313029

CSR7 Format

11117 rrrtirryryrvrirrrTT
T rTTrTriand

olo

System Base Address
I

TN DU O

O T U

TS G

00
CSR7

MLO-004421

Table 3-24

Bit

CSR?7 Bits

Name

29:00 SB

Access

R'W

Description

System Base Address—The physical starting address of

the rtVAX 300 System Page Table. Unused if VA (virtual
addressing) is cleared in all descriptors.
Caution: This register should be loaded only once after a
reset. Subsequent modifications of this register may cause
unpredictable results.

Hardware Architecture

3-61

3.6.1.7 Watchdog Timer Register (CSR9)

The Ethernet coprocessor has two timers that restrict the length of time during
which the chip can receive or transmit. These watchdog timers are enabled
by default and assume the default values after hardware or software resets.
Figure 3-24 shows the format of the watchdog timer register; Table 3—25
describes its bit structure.
Figure 3-24 CSR9 Format
31

1615
Frrrrrrreyvroroired

rTr1rrrrvevv1irirrrTd

Receive Watchdog Time~Out- RT | Transmit Watchdog Time-Out
- TT | CSR9
|S

TS N

VO YUY TN N I

O T

A
MLO--004422

Table 3-25

CSR9 Bits

Bit

Name

Access

Description

15:00

R/'W

Transmit Watchdog Time-Out—The transmit watchdog

timer protects the network against Ethernet coprocessor
transmissions of overlength packets. If the transmitter
stays on for T'T * 16 cycles of the serial clock, the Ethernet
coprocessor cuts off the transmitter and sets the CSR5<06>
bit. If the timer is set to zero, it never times out. The value
of TT is an unsigned integer. With a 10 MHz serial clock,
this provides a range of 1.6 ns to 100 ms. The default value
is 1250, corresponding to 2 ms.

31:16

R'W

Receive Watchdog Time-Out—The receive watchdog tinier
protects the rtVAX 300 microprocessor against other
transmitters sending overlength packets on the network. If
the receiver stays on for RT * 16 cycles of the serial clock,
the Ethernet coprocessor cuts off reception and sets the
CSR5<05> bit. If the timer is set to zero, it will never time
out. The value of RT is an unsigned integer. With a 10

MHz serial clock, this provides a range of 1.6 ns to 100 ms.

The default value is 1250, corresponding to 2 ms.

Note: An Rx or Tx watchdog value between 1 and 44 is
forced to the minimum time-out value of 45 (72 ps).

3-62

Hardware Architecture

' 3.6.1.8 Revision Number and Missed Frame Count (CSR10)

This register contains a missed frame counter and Ethernet coprocessor
identification information. Figure 3-25 shows the format of CSR10; Table 326
describes its bit structure.
Figure 3-25
K3 |

CSR10 Format

2827
TTT (T

DIN
1§

24 23
T

HRN

[

Table 3-26

1615

T
T T[T
i T

0
1

2019

00
I

TITiITIrTTIrrr

FRN
|

]

MFC
L

N SN R

CSR10
N

U O O

MLO-006383

CSR10 Bits

Bit

Name

Access

15:00

MFC

Description
Missed Frame Count—Counter for the number of frames
that were discarded and lost because rtVAX 300 receive
buffers were unavailable. The counter is cleared when read

by the rtVAX 300.

19916

FRN

Firmware Revision Number—Stores the internal firmware
revision number for this particular Ethernet coprocessor.

23:20

HRN

27:24
31:28

Hardware Revision Number—Stores the revision number
for this particular Ethernet coprocessor.

Reserved—Read as zeros.
DIN

Chip Identification Number—Determines whether this is
an SGEC or an SGEC-compatible device.

Hardware Architecture

3-63

3.6.1.9 Boot Message Registers (CSR11, CSR12, CSR13)
These registers contain the boot message verification and processor fields;
Table 3-27 describes their bit structure.
Table 3-27 CSR11, CSR12, CSR13 Blts
Register

Bit

Name

Access

Description

CSR11

31:00

VRF<31:00>

R/W

Boot Message Verification field <31:00>

CSR12

31:00

VRF<63:32>

R/W

Boot Message Verification field <63:32>

CSR13

07:00

PRC

R/'W

Boot Message Processor field

3.6.1.10

Breakp»int Address Reglster (CSR14)

This register contains the brea.point address that causes the internal
microprocessor to jump to a patch address. This register, in conjunction with
the diagnostic descriptors, allows software patches. Figure 3-26 shows the
format of CSR14; Table 3-28 describes its bit structure.
Figure 3-26 CSR14 Format
3130
B

1615

rvTtvtry1r

Code Restart Address — CRA
N I

Breakpoint Address ~ BPA
LA U

VU TN O U O (O W

CSR14
A

MLO-004424

Table 3-28
Bit

CSR14 Bits

Name

Access

15:00 BPA R/W

Description

Breakpoint Address—The internal processor address at .

which the program will halt and jump to the RAM-loaded
code.

(continued on next page)

3-64

Hardware Architecture

Table 3-28 (Cont.)

3.6.1.11

CSR14 Bits

Bit

Name

Access

Description

30:16

CRA

R/W

Code Restart Address—The first address in the internal

R/W

When set, breakpoint is enabled.

ROM to which the internal processor jumps after a
breakpoint occurs.

Monitor Command Register (CSR15)

This register is a physical CSR. It contains the bits that select the internal

test block operation mode. Figure 3-27 shows the format of CSR15; Table 3-29
describes its bit structure.
Figure 3-27

CSR15 Format

161514131211
10090807 060504 03 020100
r

1T 1T

71T

17T

Address / Data
|T

(S TS S

(O O

TOADSuuuuuuu ujnjujulul
O

MLO-~004425

Table 3-28

:CSR15

CSR15 Bits

Bit

Name

Access

Description

Bus Select—When set, the monitoring is applied
on the internal address bus. Meaningful only
in test mode (T'SM=1). When reset, the internal
data bus is monitored on the external test pins

BM_L/TEST<03:00>.

(continued on next page)

Hardware Architecture

3-65

Table 3-29 (Cont.)

CSR15 Bits

Bit

Name

Access

Description

14:13

QAD

Quad Select—Meaningful only in test mode
(TSM=1). These bits define the specific four
bits of the internal data bus or address bus
which are monitored on the external test pins

BM_L/TEST<03:00>.

31:16

ADDR/DATA

QAD

Bits

<03:00>

<07:04>

<11:08>

<15:12>

Start Read—When set, starts the Examine
cycle: the data addressed by CSR15<31:16> is
fetched and stored into the same register field.
Reset by hardware at the end of the operation.
R/W

Address/Data—Before the Examine cycle starts,
it points to the location to be read; three cycles
after the assertion of CSR15<153>, it contains
the read data.

3.6.2 Descriptor and Buffer Formats
The Ethernet coprocessor transfers frame data te and from receive and
transmit buffers in rtVAX 300 memory. These buffers are pointed to by
descriptors, also resident in rtVAX 300 memory.
There are two descriptor lists: one for receive and one for transmit. The
starting address of each list is writter into CSRs 3 and 4, respectively.
A descriptor list is a forward-linked (either implicitly or explicitly) list of
descriptors, the last of which may point back to the first entry, thus creating a
ring structure. Explicit chaining of descriptors, through setting xDES1<31> is
called descriptor chaining. The descriptor lists reside in VAX physical memory
address space.
Note

The Ethernet coprocessor first reads the descriptors, ignoring all
unused bits regardless of their state. The only word that the Ethernet
coprocessor writes back is the first word (XDES0) of each descriptor.

3-66

Hardware Architecture

Unused bits in xDES0 are written as 0. Unused bits in xDES1,
xDES2, and xDES3 may be used by the port driver, and the Ethernet
coprocessor will never disturb them.

A data buffer can contain an entire frame or part of a frame, but it cannot
contain more than a single frame. Buffers contain only data; buffer status is
contained in the descriptor. The term data chaining refers to frames spanning
multiple data buffers. Data chaining can be enabled or disabled, in reception,
through CSR6<07>. Data buffers reside in VAX memory space, either physical
or virtual.
Notes

1. The virtual to physical address translation assumes that PTEs are
locked in the rtVAX 300 memory while the Ethernet coprocessor owns
the related buffer.

2. For best performance in virtual addressing mode, PPTE (Processor
Page Table Entry) vectors must not cross a page of the PPTE table.

. 3.6.2.1 Recelve Descriptors

Figure 3~28 shows the format of Receive Descriptors; Table 3—-30 through
Table 3-33 describe the RDESx bit structures. The RDES0O word contains
received frame status, length, and descriptor ownership ir.formation.
Figure 3-28

Receive Descriptor Format

313020282726252423222120191817 1615141312111009

AIALT
u

Frame Length — FL

ElL

08 07 06 0504 03 0201 00

HBFLTCFOTDCO

. Framelengh-FL
= iolg| DT |piols|s|i|s|T]°|n|e|e|F] RDESO
I

1tv 1 &¢t
1 11t1
7 1

I¥ bi

Buffer Size - BS

ity
€
v

ulu

1
7

¢«
L

]

RDE81

O(R
U
oy

u
I

N
L)

TR l SV 14 N 14 S

)

]

0 - SGEC writes as "0"
_
u ~ Ignored by the SGEC on read, never written

]

RDES2

JUE RN VNGSR AN E WA

T 7

Buffer SVAPTE / PAPTE / Physical Address - SV / PV / PA
I

Page Offset — PO

u}
'

RDES3

MLO-006499

Hardware Architecture

3-67

Table 3-30

RDESO Flelds

Bits

Name

Description

CRC Error—When set, indicates that a CRC error has occurred on
the received frame.

Dribbling Bits—When set, indicates that the frame contained a
noninteger multiple of eight bits. This error reported only if the

Overflow—When set, indicates received data in this descriptor’s

buffer was corrupted due to internal FIFO overflow. This will
generally occur if Ethernet coprocessor requests are not granted
before the internal receive FIFO fills up.

number of dribbling bits in the last byte exceeds two. Meaningless if
RDES0<06> or RDES0<11> is set.

The CRC check is performed independent of this error; however, only
whole bytes are run through the CRC logic. Consequently, received
frames with up to six dribbling bits will have this bit set, but if
RDES0<01> (or another error indicator) is not set, these frames
81, ~uld be considered valid:

RDES0<01>

RDES0<02>

Error

None

CRC error

Alignment error

Translation Not Valid—When set, indicates that a translation error

Frame Type—When set, indicates the frame is an Ethernet type
frame (Frame Length Field > 1500). When clear, indicates the frame
is an IEEE 802.3 type frame. Meaningless for Runt frames shorter

occurred when the Ethernet coprocessor was translating a VAX
virtual buffer address. It is set only if RI'-ES1<30> was set. The
reception process remains in the running state and attempts to
acquire the next descriptor.

than 14 bytes.

Collision Seen—When set, indicates the frame was damaged by a

collision that occurred after the 64 bytes following the SFD.

(continued on next page)

3-68

Hardware Architecture

‘

Table 3-30 (Cont.)

RDESO Fields

Bits

Name

Description

Frame Too Long—When set, indicates the frame length exceeds the
maximum Ethernet-specified size of 1518 bytes.

Note: Frame Too Long is only a frame length indication and does
not cause any frame truncation.
LS

Last Segment—When set, indicates that this buffer contains the last

¥S

First Segment—When set, indicates that this buffer contains the
first segment of a frame.

Buffer Overflow—When set, indicates that the frame has been
truncated due to a buffer too small to fit the frame size. This bit may

segment of a frame and status information is valid.

be set only if data chaining is disabled (CSR6<07> = 1).
11

Runt Frame—When set, indicates that this frame was damaged by
a collision or premature termination before the collision window
had passed. Runt frames will only be passed on to the rtVAX 300 if
CSR6<03> is set. Meaningless if RDES0<00> is set.

Data Type—Indicates the type of frame the buffer contains, according

13:12

to the following table:
Value

Meaning

Serial received frame.

Internally looped back frame.

Externally looped back frame or serial received frame.

(The Ethernet coprocessor does not differentiate between
looped back and serial received frames. Therefore, this
information i global and reflects only CSR6<09:08>).

Length Error—When set, indicates a frame truncation caused by one
of the following:

The frame segment does not fit within the currant buffer and
the Ethernet coprocessor does not own the next descriptor. The
frame is truncated.

The Receive Watchdog timer expired. CSR5<05> is also set.

Error Summary—The logical OR of RDESO0 bits 00, 01, 03, 06, 07,
11, 14.

(continued on next page)

Hardware Architecture

3-69

Yable 3-30 (Cont.)

RDESO Fields

Bits

Name

Description

30:16

Frame Length—The length in bytes of the received frame.
Meaningless if RDESO<14> is set.

Own Bit—When set, indicates that the descriptor is owned by the

Ethernet coprocessor. When cleared, indicates that the descriptor
is owned by the rtVAX 300. The Ethernet coprocessor clears this
bit upon completing processing of the descriptor and its associated
buffer.

Table 3-31 RDES1 Fields

Bits

Name

Descriptor

Virtual Type—In case of virtual addressing (RDES1<30> = 1),

Virtual Addressing—When set, RDES3 is interpreted as a virtual

indicates the type of virtual address translation. When clear, the
buffer address RDES3 is interpreted as a SVAPTE (System Virtual
Address of the Page Table Entry). When set, the buffer address is
interpreted as a PAPTE (Physical Address of the Page Table Entry).
Meaningful only if RDES1<30> is set.
address. The type of virtual address translation is determinea by
the RDES1<29> bit. The Ethernet coprocessor uses RDES3 and
RDES2<08:00> to perform a VAX virtual address translation process
to obtain the physical address of the buffer. When clear, RDES3 is
interpreted as the actual physical address of the buffer:
RDESi<30>

RDES1<29>

Addressing Mode

Physical

Virtual —-SVAPTE

Virtual-—PAPTE
(continued on next page)

3-70

Hardware Architecture

Table 3-31 (Cont.)

RDES1 Fields

Bits

Name

Descriptor

Chain Address—When set, RDES3 is interpreted as another
descriptor's VAX physical address. This allows the Ethernet
coprocessor to process multiple, noncontiguous descniptor lists and
explicitly "chain” the lists. Note that contiguous descriptors are
implicitly chained.

In contrast to what is done for an Rx buffer descriptor, the Ethernet
coprocessor clears neither the ownership bit RDES0<31> nor any
other bit of RDESO of the chain descripter after processing.
To protect against infinite loop, a chain descriptor pointing back
to itself is considered owned by the rtVAX 300, regardless of the
ownership bit (RDES0<31>) state.

Table 3-32

RDES2 Fields

Bits

Name

Descriptor

08:00

Page Offset—The byte offset of the buffer within the page.
Meaningful only if RDES1<30> is set.

Note: Receive buffers must be word-aligned.

30:16

Buffer Size—The size, in bytes, of the data buffer.
Note: Receive buffers size must be an even number of bytes, not
shorter than 16 bytes.

Table 3-33

RDES3 Fields

Bits

Name

Descriptor

31:00

SV/PV/PA

SVAPTE/PAPTE/Physical Address—When RDES1<30> is

set, RDES3 is interpreted as the address of the Page Table
Entry and used in the virtual address translation process.
RDES1<29> determines the type of the address: System

Virtual address (SVAPTE) or Physical Address (PAPTE). When
RDES1<30> is clear, RDES3 is interpreted as the physical
address of the buffer; when RDES1<31> is set, RDES3 is

interpreted as the VAX physical address of another descriptor.
Note: Receive buffers must be word-aligned.

Table 3-34 summarizes the validity of the Receive Descriptor status
bits regarding the reception completion status. (V indicates valid; X,
meaningless.)

Hardware Architecture

3-71

Table 3-34

Receive Descriptor Status Validity
Rx Status Report

Reception Status

RF TL

DB CE (ES,LE,BO,DTFS,LSFL,TN,OF)

Overflow

\Y%

Collision a®ter 512 bits

Runt frame

Runt frame < 14 bytes

Watchdog time-out

3.6.2.2

Transmit Descriptors
Figure 3-29 shows the format of Transmit Descriptors; Table 3-35 through

Table 3-38 describe the TDESx bit structures. The TDESO word contains
transmitted frame status and descriptor ownership information.
Figure 3-29

Transmit Descriptor Format

31 3029282726252423 2221 20191817161514131211 10 09 08 07 06 05 04 03 02 01 00

o
W

clv

P
Time Domain Reflect?mlete{ 1T£:)Ro

AlF|L

ulu

E|T]
_[LLINJLIE|H]
" wn [T|ulD
slololelolelelc!e
| clc BNEE TDESO

Buffer Size
— BS

L
i Ao ot vt o a

S IR O

S o

VAN

SRR AR

o o

Page OffsetPO

IOBRI

Buffer SVAPTE
/ PAPTE / Physical Address
- SV / PV / PA

0 - SGEC writes as "0"
u ~ ignored by the SGEC on read, never written

Table 3-35

YWS
T
R

TDES1
| TDES2
TDES3

MLO-006500

TDESO Fields

Blts

Name

Description

Deferred—When set, indicates that the Ethernet coprocessor had to
defer while trying to transmit a frame. This condition occurs if the
channel is busy when the Ethernet coprocessor is ready to transmit.
(continued on next page)

3-72

Hardware Architecture

Table 3-35 (Cont.)

TDESO Fields

Bits

Name

Description

Underflow Error—When set, indicates that the transmitter has
truncated a message due to data late from memory. This bit
indicates that the Ethernet coprocessor encountered an empty
transmit FIFO while in the midst of transmitting a frame. The
transmission process enters the suspended state and sets CSR5<01>.

Translation Not Valid—When set, indicates that a translation error
occurred when the Ethernet coprocessor was translating a VAX
virtual buffer address. It may only set if TDES1<30> was set. The
transmission process enters the suspended state and sets CSR5<01>.

06:03

ccC

Collision Count—A 4-bit counter indicating the number of collisions
that occurred before the transmission attempt succeeded or failed.

Meaningless when TDES0<08> is also set.
07

Heartbeat Fail—When set, indicates Heartbeat Collision Check
failure. (The transceiver failed to return a collision pulse as a check
after the transmission. Some transceivers do not generate heartbeat,
and so will always have this bit set. If the transceiver does support
Heartbeat Fail, <HF>indicates transceiver failure.) Meaningless if
TDES0<01> is set.

Excessive Collisions—When set, indicates that the transmission was
aborted because 16 successive collisions occurred while attempting to
transmit the current frame.

Late Collision—When set, indicates frame transmission was aborted
due to a late collision. Meaningiess if TDES0<01> is set.

No Carrier—When set, indicates the carrier signal from the
transceiver was not present during transmission (possible problem in
the transceiver or transceiver cable).
Meaningless in internal loopback mode (CSR5<18:17>=1).

Loss of Carrier—When set, indicates loss of carrier during
transmission (possible short circuit in the Ethernet cable).
Meaningless in internal loopback mode (CSR5<18:17>=1).
(continued on next page)

Hardware Architecture

3-73

Table 3-35 (Cont.)

TDESO Fields

Bits

Name

Description

Length Error—When set, indicates one of the following:
¢

Descriptor unavailable (owned by the rtVAX 300) in the middle

Zero length buffer in the middle of data-chained descriptors.

*
¢

of data-chained descriptors.

Setup or diagnostic descriptors (data type TDES1<29:28> is not

equal to 0) in the middle of data-chained descriptors.

Incorrect order of first_segment TDES1<26> and last_segment

TDES1<25> descriptors in the descriptor list.

The transmission process enters the susperided state and sets
CSR5<01>.

Transmit Watchdog Time-Out—When set, indicates that the transmit
watchdog timer has timed out, indicating that the Ethernet
coprocessor transmitter was babbling. The interrupt CSR5<06>
is set and the Transmission process is aborted and placed in the
stopped state.

29:16

TDR

Error Summary—The logical OR of bits 01, 02, 08, 09, 10, 11, 12, 14. .
Time Domain Reflectometer—A count of bit time useful for locating
a fault on the cable by using the velocity of propagation on the cable.

Valid only if TDES0<08> is also set. Two excessive collisions in a

row with the same +£20 TDR values indicate a possil.le open cable.

Own Bit—When set, indicates that the descriptor is owned by the
Ethernet coprocessor. When cleared, indicates that the descriptor
is owned by the rtVAX 300. The Ethernet coprocessor clears this
bit upon completing processing of the descriptor and its associated
bufi'er.

Table 3-36 TDES1 Fields
Bits

Name

Descriptor

Virtual Type—In case of virtual addressing (TDES1<30> = 1),
indicates the type of virtual address translation. When clear, the
buffer address TDES3 is interpreted as a SVAPTE (System Virtual
Address of the Page Table Entry). When set, the buffer address is

interpreted as a PAPTE (Physical Address of the Page Table Entry).
Meaningful only if TDES1<30> is set.
(continued on next page)

3-74

Hardware Architecture

Table 3-36 (Cont.)

TDES1 Fields

Bits

Name

Descriptor

Interrupt on Completion—When set, the Ethernet coprocessor sets
CSR5<01> after this frame has been transmitted. To take effect, this
bit must be set in the descriptor where bit 25 is set.

Last Segment—When set, indicates that the buffer contains the last

First Segment—When set, indicates that the buffer contains the first

Add CRC Disable—When set, the Ethernet coprocessor will not
append the CRC to the end of the transmitted frame. To take effect,
this bit must be set in the descriptor where bit 26 is set.

segment of a frame.
segment of a frame.

Note: If the transmitted frame is shorter than 64 bytes, the
Ethernet coprocessor adds the padding field and the CRC, regardless
of the <27> flag.

29:28

Data Type—Indicates the type of data that the buffer contains,
according to the following table:
Value

Meaning

Normal transmit frame data

Setup frame (Refer to Section 3.6.2.3.)

Diagnostic fraine (Refer to Section 3.6.5.)
(continued on next page)

Hardware Architecture

3-75

Table 3-36 (Cont.)

TDES1 Fields

Bits

Name

Descriptor

Virtual Addressing—When set, TDES3 is interpreted as a virtual

address. The type of virtual address translation is determined by
the TDES1<23> bit. The Ethernet coprocessor uses TDES3 and
TDES2<08:00> to perform a VAX virtual address translation process
to obtain the physical address of the buffer. When clear, TDES3 is
interpreted as the actual physical address of the buffer:

TDES1<30>

TDES1«<23>

Addressing Mode

Physical

Virtual—SVAPTE

Virtual—PAPTE

Chain Address—When set, TDES3 is interpreted as another
descriptor’s VAX physical address. This allows the Ethernet
coprocessor to process multiple, noncontiguous descriptor lists and
explicitly "chain” the lists. Note that contiguous descriptors are
implicitly chained.

In contrast to what is done for a Tx buffer descriptor, the Ethernet .
coprocessor clears neither the ownership bit TDES0<31> nor any
other bit of TDESQ of the chain descriptor after processing.

To protect against infinite loop, a chain descriptor pointing back to
itself is considered owned by rtVAX 300, regardiess of the ownership
bit state.

Table 3-37 TDES2 Fields

Bits

Name

08:.00

‘

Descriptor
Page Offset—The byte offset of the buffer within the page.

Meaningful only if TDES1<30> is set.

Note: Transmit buffers may start on arbitrary byte boundaries.

30:16

Buffer Size—The size, in bytes, of the data buffer. If this field is
0, the Ethernet coprocessor ignores this buffer. The frame size is
the sum of all buffer size fields of the frame segments (between and
including the descriptors having TDES1<26> and TDES1<25> set).
(continued on next page)

3-76

Hardware Architecture

Table 3~-37 (Cont.) TDES2 Flelds
Bits

Name

Descriptor

Note: If the port driver wishes to suppress transmission of a frame,

this field must be set to 0 in all descriptors comprising the frame and
prior to the Ethernet coprocessor acquiring them. If this rule is not
adhered to, corrupted frames might be transmitted.

Table 3-38

TDES3 Fields

Bits

Name

Descriptor

31:.00

SV/PV/PA

SVAPTE/PAPTE/Physical Address—When TDES1<30> is

set, TDES3 is interpreted as the address of the Page Table

Entry and used in the virtual address translation process.
TDES1<23> determines the type of address: System Virtual
Address (SVAPTE) or Physical Address (PAPTE). When
TDES1<30> is clear, TDES3 is interpreted as the physical
address of the buffer; when TDES1<315> it is set, TDES3 is
interpreted as the VAX physical address of another descriptor.

Note: Transmit buffers may start on arbitrary byte
boundaries.

Table 3-39 summarizes the validity of the Transmit Descriptor status
bits regarding the transmission completion status. (V indicates valid; M,
meaningless.)

Table 3-39 Transmit Descriptor Status Validity
Tx Status Report
Transmisslon Status

LO NC LC

EC HF CC (ES,TO,LE,TN,UFDE)

Underflow

Excessive collisions

\Y%

Watchdog time-out

Internal loopback

V.V

Hardware Architecture

3-77

3.6.2.3 Setup Frame

A setup frame defines the Ethernet coprocessor destination addresses. These
addresses filter all incoming frames. The setup frame is never transmitted over
the Ethernet nor looped back to the receive list. While the setup frame is being

‘

processed, the receiver logic temporarily disengages from the Ethernet wire.
The setup frame size is always 128 bytes and must be wholly contained in a
single transmit buffer. There are two types of setup frames:

Perfect filtering addresses (16) list

Imperfect filtering hash bucket (512) heads and one physical address

3.6.2.3.1 First Setup Frame A setup frame must be queued, that is, placed
in the transmit list with Ethernet coprocessor ownership, to the Ethernet
coprocessor before the reception process is started, except when the Ethernet
COprocessor is in promiscuous reception mode.

‘

Note

The self-test completes with the Ethernet coprocessor Address filtering
table fully set to 0. A reception process started without loading a
setup frame rejects all incoming frames except those with a destination
physical address of 000000,¢.

‘

3.6.2.3.2 Subsequent Setup Frame
Subsequent setup frames may be queued
to the Ethernet coprocessor regardless of the reception process state. The only
requirement for the setup frame to be processed, is that the transmission
process be in the running state. The setup frame is processed after all
preceding frames have been transmitted and after the current frame reception,
if any, is completed.

The setup frame does not affect the reception process state, but during the
setup frame processing, the Ethernet coprocessor is disengaged from the

Ethernet wire.

3-78

Hardware Architecture

‘
‘

3.6.2.3.3 Setup Frame Descriptor Figure 3-30 shows the format of the setup
frame descriptors; Table 3-40 describes the SDECx bit structure.
Figure 3-30 Setup Frame Descriptor Format
313020282726252423222120191817 161514131211 100908
07 06 05 04 03
02 01 00
0

I A

1
T

ulu

|S T

e eB

0ju| OT|ul clple

L S)

N
¥

Buffer Size - BS
WU R

)

VD WY

]

SN S

)

K S NN
Sl

VR WOVUR I
1

DU SR
1]

Setup Buffer Physical Address- PA
S

WO VAU TS WUV [

€

s|O1e

DOV DR U

0
D

v
W

RSO A

SDESO

LO I

SDESH

NSDStU
T

0 - SGEC writes as "0" (SDESO only)
u - Ignored by the SGEC on read, never written

SO Sy S

L
|

AN e1

Lol

SDES2

emad.

u| SDES3
MLO--006501

Table 3-40

Setup Frame Descriptor Bits

Word

Bits

Name

SDESO

Error Summary—Set when bit 13 is set.

Own Bit—When set, indicates that the descriptor is
owned by the Ethernet coprocessor. When cleared,

Description

Setup Error—When set, indicates that the setup frame
buffer size is not 128 bytes.

indicates that the descriptor is owned by the rtVAX
300. The Ethernet coprocessor clears this bit upon
completing processing of the descriptor and its
associated buffer.
SDES1

Interrupt on Completion—When set, the Ethernet

coprocessor sets CSR5<01> after this setup frame has
been processed.

Hash/Perfect Filtering Mode—When set, the Ethernet
coprocessor interprets the setup frame as a hash table
and does imperfect address filtering. The imperfect
mode is useful when there are more than 16 multicast
addresses to listen to.

When clear, the Ethernet coprocessor does a perfect
address filter of incoming frames according to the
addresses specified in the setup frame.
(continued on next page)

Hardware Architecture

3-79

Table 3-40 (Cont.)
Word

Setup Frame Descriptor Bits

Bits

Name

Description

Inverse Filtering—When set, the Ethernet coprocessor
does inverse filtering: the Ethernet coprocessor
receives incoming frames with destination address
not matching the perfect addresses and rejects frames
with destination address matching one of the perfect
addresses.

Meaningful only for perfect filtering (SDES1<25>=0),
while promiscuous and all multicast modes are not
selected (CSR6<02:01>=0).

29:28

Data Type-—Must be 2 to indicate setup frame.

SDES2

30:16

Buffer Size—Must be 128.

SDES3

29:1

Physical Address—Physical address of setup buffer.
Note: Setup buffers must be word-aligned.

3.6.2.3.4 Perfect Filtering Setup Frame Buffer This section describes how
the Ethernet coprocessor interprets a setup frame buffer when SDES1<25> is

clear.
The Ethernet coprocessor can store sixteen 48-bit Ethernet destination
addresses. It compares the addresses of any incoming frame to these, and
based on the status of Inverse_Filtering flag SDES1<26>, rejects those that
*

Do not match, if SDES1<26> = 0

Match, if SDES1<26> =1

The setup frame must always supply all 16 addresses. Any mix of physical and
multi-

3t addresses can be used. Unused addresses should be duplicates of one

of the valid addresses. Figure 3-31 shows the format of the addresses.

3-80

Hardware Architecture

Figure 3-31

Perfect Filtering Setup Frame Buffer Format
16115

Bytes

PHYSICAL_ ADDRESS 00
<31:16>=Undefined
|

<3:0»
<7:4>

L1 <~ INDIVIDUAL s GROUP bit

PHYSICAL_ ADDRESS 01
|

PHYSICAL_ ADDRESS 02
<31:16>=Undefined
|

PHYSICAL_ ADDRESS 03

PHYSICAL_ADDRESS 15
<31:16>=Undefined
|

Address <31:00>

Address <47:32>

-y

<31:16>=Undefined

<123:120>

<127:124>

MLO--006502

The low-order bit of the low-order byte is the address’s multicast bit.
Example 3-1 illustrates a perfect filtering setup buffer fragment.
Example 3-1

Perfect Filtering Setup Butfer Fragment

Ethernet addresses to be filtered:

28-09-65-12-34-76
09-BC-87-DE=03~15

Setup frame buffer fragment:

1265098

00007634
DE87BC09

00001503

@ Ethernet multicast addresses written according to the IEEE 802
specification for address display

@ Those two addresses as they would appear in the buffer

Hardware Architecture

3-81

3.6.2.3.5 Imperfect Flitering Setup Frame Buffer
This section describes how
the Ethernet coprocessor interprets a setup frame buffer when SDES1<25> is
set.

The Ethernet coprocessor can store 512 bits, serving as hash bucket heads,
and one physical 48-bit Ethernet address. Incoming frames with multicast
destination addresses are subjected to the imperfect filtering. Frames with
physical destination addresses are checked against the single physical address.
For any incoming frame with a multicast destination address, the Ethernet
coprocessor applies the standard Ethernet CRC function to the first six bytes
containing the destination address, and then uses the least significant nine bits

of the result as a bit index into the table. If the indexed bit is set, the frame is ‘
accepted; if it is cleared, the frame is rejected.

This filtering mode is called imperfect, because multicast frames not addressed
to this station may slip through, but it still reduces the number of frames that
the rtVAX 300 must process.
Figure 3-32 shows the format for the hash table and the physical address.
Figure 3-32

Imperfect Filtering Setup Frame Buffer Format

16,15

B<>g%°>>
<7id>

HASH_FILTER 00
HASH_FILTER 01
HASH FILTER 02

HASH_FILTER 03

HASH_FILTER 14

<63:60>
<67:64>
<71:68>]

HASH_FILTER 15
PHYSICAL ADDRESS
<71.70>=Undefined

<75:72>

1<~ INDIVIDUAL / GROUP bit

«127:72>=Undefined

—

<127:124>
MLO-008503

3-B2

Hardware Architecture

Bits are sequentially numbered from right to left and down the table. For
example, if the destination address CRC<8:0> is 33, the Ethernet coprocessor
examines bit 1 in the second longword. Example 3-2 shows an imperfect
filtering setup frame buffer. Appendix E shows a C program to compute the
setup frame buffer for the hashing filtering mode.
Example 3-2

Imperfect Filtering Setup Frame Buffer

Ethernet addresses to be filtered:

25-00-25-00-27-00

A3-C5-62~3F=25-87
D9-C2-C0-99-0B~82
7D-48-4D-FD-CC-02
E7-C1-96~36-89-DD
61-CC-28-55-D3-C7

$B-46-0A-55-2D~TE

1n8-12-34-35-76-08
Setup frame buffer:

©®© 00000000

10000000

00000000
00000000
00000000
40000000
00000080
00100000
000000C0
10000000

00000000
00000000
00000000
00010000
00600000

50400600

35341228

00000876

Ethernet multicast addresses written according to the IEEE 802

specification for address display
An Ethernet physical address

The first part of an imperfect filter setup frame buffer with set bits for the
multicast addresses

The second part of the buffer with the physical address

Hardware Architecture

3-83

3.6.3 Operation
A program in rtVAX 300 memory called the port driver controls the operation
of the Ethernet coprocessor. The Ethernet coprocessor and the port driver
communicate through two data structures:

Command and Status Registers (CSRs)—These registers are located in the
Ethernet coprocessor and mapped in the rtVAX 300 processor’s /O address

space. The CSRs are used for initialization, global pointers, command
transfer, and global error reporting.
¢

Descriptor Lists and Data Buffers—These are collectively called the host

communication area and are located in rtVAX 300 memory. These lists
and buffers handle the actions and status reporting related to buffer
management.

The Ethernet coprocessor can be viewed as two independent, concurrently

executing processes: reception and transmission. These processes are started
after the Ethernet coprocessor completes its initialization sequence. Once
started, these processes alternate between three states: stopped, running, or
suspended. State transitions take place as a result of port driver commands or
the occurrence of selected external events.

A simple programming sequence of the chip can be summarized as follows:
1.

After power-up or reset, verify that self-test completed successfully.

Load CSRs with major parameters, such as the system base register,
interrupt vector, or address filtering mode.

Create transmit and receive lists, and load CSRs to identify them to the
Ethernet coprocessor.

Place a setup frame in the transmit list to load the internal reception
address filtering table.

Start receive and transmit processes by placing them in the running state.
Wait for Ethernet coprocessor interrupts.

Issue a Polling Demand command if either the receive or transmit process
enters the suspended state. This is done after correcting the cause of the
process suspension.
The following sections describe Ethernet coprocessor operation:

3-84

Hardware and software reset (Section 3.6.3.1)

Interrupts (Section 3.6.3.2)

Hardware Architecture

. 3.6.3.1 Hardware and Software Reset

The Ethernet coprocessor responds to two types of reset commands: a
hardware reset through the RESET L pin, and a software reset command
triggered by setting CSR6<31>. In both cases, the Ethernet coprocessor aborts
all ongoing processing and starts the reset sequence. The Ethernet coprocessor
restarts and reinitiahizes all internal states and registers. No internal states

are retained, no descriptors are owned, and all rtVAX 300 visible registers are
set to 0, except where otherwise noted.
Note

The Ethernet coprocessor does not explicitly disown any owned

descriptors; so a descriptor’'s Own bits might be left in a state indicating
Ethernet coprocessor ownershup.

Table 3-41 hists the CSR fields that are not set to 0 after reset.
Table 3-41

Ethernet Coprocessor CSR Nonzero Fields After Reset

Fleld

Value

’

CSR3

Unpredictable

CSR4

Unpredictable

CSRb5<16>

CSR6<28:25>

CSR6<31>

Unpredictable after hardware reset; 1 after software reset

CSR7

Unpredictable

C5R9

RT = TT = 1250

After the reset sequence completes, the Ethernet coprocessor executes the
gelf-test procedure to do basic sanity checking. After the self-test completes,
the Ethernet coprocessor sets the initialization done flag CSR5<31>. The selftest completion status bits CSR5<30> and CSR5<29:26> indicate whether the
self-test failed and the reason for the failure.
Note

self-test takes 25 ms to complete.

Hardware Architecture

3-85

If the self-test completes successfully, the Ethernet coprocessor is ready to

accept further rtVAX 300 commands. Both the reception and transmission
processes are placed in the stopped state.

Successive reset commands (either hardware or software) may be issued. The
only restriction is that Ethernet coprocessor CSRs should not be accessed
during a 1-ps period following the reset. Access during this period will result
in a CP-BUS timeout error. Access to Ethernet coprocessor CSRs during the
self-test are permitted; only CSR5 reads should be performed.
3.6.3.2

Interrupts

Various events generate interrupts. CSR5 contains all the status bits that

may cause an interrupt, provided that CSR6<30> is set. The port driver must
clear the interrupt bits (by writing a 1 to the bit position) to enable further
interrupts from the same source.
Interrupts are not queued, and if the interrupting event recurs before the

port driver has responded to it, no additional interrupts are generated. For
example, CSR5<02> indicates that one or more frames were delivered to rtVAX
300 memory. The port driver should scan all descriptors, from its last recorded
position up to the first description owned by the Ethernet coprocessor.
An interrupt is generated only once for simultaneous, multiple interrupting
events. The port driver must scan CSR5 for the interrupt cause(s). The
interrupt will not be regenerated, unless a new interrupting event occurs after
the rtVAX 300 acknowledged the previous one, and provided that the port
driver cleared the appropriate CSR5 bit(s).
For example, CSR5<01> and CSR5<02> may both be set, the rtVAX 300

acknowledges the interrupt, and the port driver begins executing by reading

CSR5. Now CSR5<03> sets. The port driver writes back its copy of CSR5,
clearing CSR5<01> and CSR5<02>. After the rtVAX 300 IPL is lowered below
the Ethernet coprocessor level, another interrupt will be delivered with the
CSR5<03> bit set.
Should the port driver clear ali CSR5 set interrupt bits before the interrupt
has been acknowledged, the interrupt will be suppressed.

3.6.4 Serial interface
The Ethernet coprocessor supports the full IEEE 802.3 frame encapsulation
and media access control (MAC). The Ethernet coprocessor functions in a send
and receive half-duplex mode and is in either the transmit or receive mode,
except when the Ethernet coprocessor is in one of its loopback modes, which
operate in full duplex.

3-86

Hardware Architecture

. 3.6.4.1 Transmit Mode

In transmit mode, the Ethernet coprocessor initiates a DMA cycle to access

data from the transmit buffer in rtVAX 300 memory to assemble a packet to be
transmitted on the network. It then adds a preamble and start frame delimiter
(SFD) pattern to the beginning of the data, calculates and appends a cyclic
redundancy check (CRC) value, if enabled, to the data to make the packet.
After the packet is assembled, the Ethernet coprocessor waits for MAC to allow
transmission on the network. When transmission is enabled, the Ethernet
coprocessor serializes the data and sends it to the serial interface adapter
(SIA).
3.6.4.2

Receive Mode

In receive mode, the decoded serial data and clock are fed to the Ethernet
coprocessor from the external SIA. The Ethernet coprocessor uses the decoded
clock to read the data into its internal FIFO receive buffer. The data is
desenalized, and the destination address is checked. If the message is for
the Ethernet coprocessor, a CRC value for the received data is calculated and
compared to the CRC checksum at the end of the frame. If there is a CRC
error, an error bit is set in the receive descriptor. The Ethernet coprocessor
notifies the rtVAX 300 processor of all received frames, including those with
CRC errors and framing errors. Frames less than 64 bytes long are not
delivered to the rtVAX 300 processor, unless the Ethernet coprocessor is
programmed to do so.

3.6.5

Diagnostics and Testing
The Ethernet coprocessor supports three levels of testing and diagnostics:
¢

First Level-—Error reporting during normal operation

Second Level—In system software controlled diagnostic features

Third Level—Hardware diagnostic mode, which allows access to the
internal data paths of the Ethernet coprocessor

3.6.5.1

Error Reporting

The Ethernet coprocessor reports error conditions that relate to the network
as a whole or to individual data frames. Network-related errors are recorded
as flags in one or more of the Ethernet coprocessor’'s CSRs and result in an
interrupt being posted to the rtVAX 300 CVAX processor. Frame-related errors
are written to the descriptor entries of the corresponding frame. Table 342
lLists reported errors by class.

Hardware Architecturg

3-87

Table 3-42

Ethernet Coprocessor Summary of Reported Errors

Classification

Error

System Errors

Memory Error

Serial Interface

Errors

Collision Fail

Transmit Watchdog Timeout
Receive Watchdog Timeout

Loss of Carrier

Frame Errors

3.6.5.2

CRC Error
Framing Error
Overflow/Underflow Error
Translation Error
Late Collision Error
Frame less than 64 bytes long

On-Chip Diagnostics

The Ethernet coprocessor contains extensive on-chip diagnostics. These
diagnostics include an internal self-test, loopback modes, and a time domain
reflectometer.

3.6.5.2.1 Internal Self-Test The Ethernet coprocessor’s self-test is run after
a reset of the chip. The internal self-test checks the operation of the following
sections of the Ethernet coprocessor:

3--88

Internal ROM

°*

Internal RAM

Transmit FIFO

Receive FIFO

Address Recognition RAM

Hardware Architecture

3.6.5.2.2 Loopback Modes The self-test performs a local loopback test. The
Ethernet coprocessor supports these loopback modes: internal loopback and

external loopback. Internal loopback mode permits the testing of Ethernet
coprocessor logic that includes frame length checking, CRC generation and
checking, and descriptor management, for example, chaining and virtual
address translation. External loopback mode provides a loopback capability
on an active Ethernet or IEEE 802.3 network. This mode places the Ethernet
coprocessor in full duplex operation in which it receives its own transmissions.
In either loopback mode, the rtVAX 300 software must:
*

Build the data frame that is to be transmitted

Provide a receive buffer for the looped data that is i be returned to the
rtVAX 300 processor

Loopback operation is selected by the operating mode bits (CSR6<09:08>).
3.6.5.2.3

Time Domain Reflectometer

The Ethernet coprocessor has a time

domain reflectometer (TDR) to help find faults on the Ethernet cable. The TDR
detects short and open circuits on the cable that result in reflections on the
cable.

Hardware Architecture

3-89

CARRERRRIEER

VIR
A I ELE

PANSANSEH
SN
bANS 24044
a4 444
b.5.94.6.4
.44
X

XA
XXXXXY
XXXXXXX
KXEXXAXXK
p.0.€.4.9.4.9.0.9,4.4.
XAXAXKXXXKXAX

.0.8.4.6.0.0.8,6.0.
8 804
XAXXXXXEXAXX
KX AXX
P046.0.4.8.0894.0856458464

b8.8.0:0.8629$460.68406444

AKX
KKK XA XXX KK XAX
UKL AAXKEA XK ALAX XA XAXLAAXK
HES 0550806880 8688808464004
P0.0.0.980896044068809
8 8580444044
P 4.0.09066 4400800600698 96049.046648
PO

G0 00040000000009008.0849¢.94.900¢

ji99.0.8.9.0.9.00.06608:66.0¢¢006006900640.999¢1
p8.8.0.060000008060080.0040.600698960840600.
F00.0.9.0.0.¢.8.000.66.98.4.9$00.0.860.46808¢48086684¢01

$ 300000086800094640030
0 8800060 8098:4.6¢8895
p.8.90.0.8.0.00.0.0.0.0.0.80.06000
86068990008 0.8.86.60.64990.8

p4.9:0.9.¢.9.80.60.09.68.000.00864004$68980.6068000008800.
).6.9:9.9.0.80.6.99.900.9.00.60.606.5500800808908008600955045
). 0.9:9.0:4.8.9.9.0.8.6.0.0.0.0.0.0.¢:0.0.00.¢.9009.0.9.099.8.6.8.0.0.0,6:0.0.06900909
b0.0.40.0.9.680:9.9.00009805.6.0,0:0.0.0.690000.960994.90868490966969!

4
Firmware
The rtVAX 300 processor firmware contains the following components:

A subset of the VAX console program

Power-on and Ethernet self-tests

Bootstrap for bootirg from Ethernet, serial lines, or PROM

The rtVAX 300 processor uses the clock interrupt for various timers. Portions
of the code run at IPL 15, to allow clock interrupts. No other interrupts are
used.

The rtVAX 300 system firmware is the software in the system ROM. The
corresponding firmware sections provide these functions:
e

Power-on self-test—Tests the base system and the optional console at
power-on

System configuration—Handles integration of the optional consocle and
memory with the base system by accessing external devices, sizing memory,
and checking for console hardware registers

Dispatcher—Handles entry to the system ROM by booting or entering the
console emulation program

Bootstrap—Loads the next level of software, that is, the VAXELN system
mage

Console emulation program—Emulates a subset of the VAX standard
console program

This chapter discusses the following topics:

®*

System firmware ROM format (Section 4.1)

System firmware entry (Section 4.2)

Console program (Section 4.3)

Entity-based module and Ethernet listener (Section 4.4)

Firmware

4-1

Startup messages (Secticn 4.5)

Diagnostic test list (Section 4.6)

System scratch RAM (Section 4.7)

User-defined board-level boot and diagnostic ROMs (Section 4.8)

Creation and down-lige loading of test programs (Section 4.9)

Serial-line boot directions (Section 4.10)

ROM bootstrap operations (Section 4.11)

4.1 System Firmware ROM Format

‘

The base rtVAX 300 firmware is contained in four 8-bit-wide ROMs; this
provides a full 32-bit memory data path. Figure 4-1 shows the system ROM
format.

Figure 4-1
3

System ROM Format

24
T T

M A

Byte 3
Ll

T T 1T TT

Byte 7
R

Byte 2

L1l

I
O

08
|

Byte 1
I

Byte &
I

15
L

Byte 0

R
A
I

T
Byta 5
R

O O

B SRR
B B BRI

T T
Byte 4

L1l

MLO-004499

System firmware ROMs require two types of information: some information is
required on a per-byte basis for ease of manufacture and development; the bulk
of the information (software and tables) is supplied by the set of ROM parts.

4.1.1

System ROM Part Format
The following features are provided for each ROM part, that is, for each of
the four ROM chips. These features simplify development and manufacture of
ROM parts. The first two bytes (00 and 01) of each chip are reserved for data
used within the context of the full set of chips. The ROM set data start on a
longword boundary. Byte addressing is the address within the isolated chip,
not the address in the system firmware ROM address space nor the address
within the ROM set. The information presented in Figure 4-2 represents the
data within each byte of the system ROM space. The data are replicated for
each byte of the devices associated with the system ROM.

4-2

Firmware

‘

Figure 4-2

System ROM Part
00

Reserved tor ROM Set Data

Byte 0

Reserved for ROM Set Data

Byte 1

Version Low Byte

Byte 2

ROM Byte Number

Byte 3

Manutacturing Check Data (55,;) | Byte 4
Manutfacturing Check Data (AA,,) | Byte 5

Manutacturing Check Data (33,5) | Byte 6

Manutacturing Check Data (00+¢) | Byte 7
AR

Reservedfor ROM SetData

Checksum

~~Byte 8
Last

Byte
MLO-006384

Contents are as follows:
Version (byte 02)—Contains the version number of the console code for the

rtVAX 300 system firmware. The same value appears in each of the four
ROM parts, so that a set of chips may be verified to be compatible with a
high level of confidence.
ROM byte number (byte 03)—~Indicates the position of the byte among the
set of ROMs used to implement the firmware. This is equal to the low two
bits of the physical address of the first byte in this ROM part. This value
ranges from 0 to 3.

Manufacturing check data (bytes 04 through 07)>—~May be used for a quick
verification of the ROM. The data are 555, AAjg, 3316. and 005.

Checksum (last byte)—Fach ROM byte contains a simple additive
checksum in its last word. The system adds all bytes, modulus 256, and
stores the negative value of the sum for each ROM.

Firmware

4-3

4.1.2 System ROM Set Format
The following data are meaningful only within the context of the collated set
of ROMs. All information in the system firmware ROM memory is positionindependent. Figure 4-3 shows the ROM set data.
Figure 4-3

System ROM Set Data

Processor Restart Address

20040000 (Set)

SYS_TYPE

20040004 (Set)

Vers

20040008 (Byte)

0316

0216

0116

0016

2004000C (Byte)

5516

5546

5516

20040010 (Byts)

AhAie

Ahss

Alqe

AAsg

20040014 (Bytes)

3316

3315

334

3346

20040018 (Byte)

0016

001s

0046

0016

2004001C (Byte)

Callable Routines (Memory Test)

;]5 20040020 (Set)

Rest of ROM Set Data and Code

;l:20040080 (Set)

Checksum

l.ast

Longword (Word)
MLO-006385

These physical addresses in the rtVAX 300 base system ROM set are fixed, as
follows:

20040000 {processeor restart address)}—The rtVAX 300 hardware begins
execution at address 20040000 on one of the following conditions:
—

At poveer-on.

—~

On execution of a HALT instruction.

—

On assertion of the EXT HLT line, for example, when a break signal
is received from the user-supplied console device or the
pressed.

Firmware

button is

On processor detection of severe corruption of its operating environment. The processor is forced into kernel mode at IPL 1F4, and

mapping is disabled, so that all addresses are physical.!
e

20040004 (SYS_TYPE)—This is the system type register. The value
representing the rtVAX 300 is 09nn0002, where nn is an 8-bit quantity
representing the major and minor revisions. The high byte is always 09,
representing the rtVAX 300. The next byte contains two 4-bit quantities

identifying the major and minor versions of the resident firmware. The
lowest byte (2) identifies the rtVAX 300 as a single-user system. Figure 44
shows the system type register; Table 4-1 lists its fields.
*

20040008 (reserved for ROM part data)}—24 bytes (6 bytes in each of the 4
system ROMs) are reserved for information contained in each ROM byte.
Section 4.1.1 lists the information contained in each ROM byte.

Figure 44

System Type Register

2423

2019

1615

W R

Type
O

Maj

Min ‘
S

a8 07

Reserved
Y

o8]

Bitmask
T

MLO-006372

Table 4-1

System Type Register Fields

Data Bit

Definition

<31:24>

System processor type of the rtVAX 300. This field is 0946.

<23:20>

Firmware Revision: Version Major ID. This field is 155 for the rtVAX
300 Firmware Version V1.1.

<19:16>

Firmware Revision: Version Minor ID. This field is 1,6 for the rtVAX
300 Firmware Version V1.1

<15:08>

Reserved. This field is all zeros.

<07:00>

Licensing bitmask. Unused. The value of this field is 0246, indicating
a single-user system.

The actual contents at the location 20040000 is a branck instruction.

Firmware

4-5

4.2 System Firmware Entry

The firmware checks for a power-on entry to see if it should execute the
power-on self-test. The firmware then passes control to the dispatch code
shown in Example 4-1, which examines, and dispatches according to, the halt
code set by the hardware at entry, the halt action fields stored internally, and
the restart in progress and bootstrap in progress bits.

Example 4-1

Firmware Dispatch Code

if halt code = power on

then

(CPMBX<hlt act>» = 03

CPMBX<hlt swx> = 03

BOOTDEV<2:0> = BOOT<2:0>
if user_init code present then call user_init code
1f BOOTDEV<2:0> = 0
then halt

else boot according to BOOTDEV<2:0>
endif

}
elseif halt code = external halt
then halt

else

(case CPMBX<hlt act>
0:

(CPMBX<hlt_act>=CPMBX<hlt_swx>
restart

)

(CPMBX<hlt_act>=CPMBX<h1t_swx>

restart

)
(CPMBX(hlt_act>=CPMBX<hlt_swx>
boot

)

(CPMBX(hlt_act>=CPMBX<hlt_swx>

halt

)

endif

(continued on next page)

4-8&

Firmware

‘

Example 4-1 (Cont.)
restart:

if restart

then

Firmware Dispatch Code

in progress

(display ‘restart error’ message

boot

glse

)
(set

restart in progress

do restart

endif

boot !

)

if bootstrap in progress
then (display 'boot error’

message

halt

)
(set bootstrap in progress

else

do boot

)
endif

halt: do halt ©

@ Refer to Section 4.2.1.
@

Refer to Section 4.2.2.

Restart

The restart operation searches system memory for a restart parameter block
(RPB). This data structure is previously allocated by the console program and
filled in by the VAXELN realtime executive and the console program. If a valid
RPB is found, the operating system is restarted at an address specified in the
RPB. An internal flag indicating restart in progress is set to prevent repeated
attempts to restart a failing operating system. A system restart can occur as
the result of a processor halt.

4.2.2

Boot
The system firmware can load and start (bootstrap) an operating system. The
firmware searches for a section of correctly functioning system memory large
enough to hold a primary bootstrap program. If the firmware finds such a
section of memory, it loads and starts the primary bootstrap.

Firmware

4-7

The primary bootstrap then loads and starts the operating system. An internal ‘
flag indicating that a bootstrap is in progress is set to prevent repeated
attempts to boot the operating system when one attempt has already failed.
System bootstrap occurs when the operator enters a BOOT command or when
the processor halts.

4.2.3 Halt
The console (Halt) progra.a interprets commands entered on the console
terminal and controls the processor operation. The following people may use
the console terminal:

An operator to boot the operating system

A customer service engineer to maintain the system

A system user to communicate with running programs

‘

The processor can halt on one of the following conditions:
*

An operator command

A serious system error

A HALT instruction

Assertion of the HLT line

Boot failure

Although users may employ the console program to develop software this
is not a goal of its implementation. The operator may put the system in an
inconsistent state by using console commands. The operation of the processor
in such a state is undefined.

4.3 Console Program

‘

This section discusses the operator interface to the firmware console program.
The console program operates an optional user-supplied terminal through the
Signetics 2681 Serial-Line Unit (SCN 2681 DUART) chip or its equivalent.

4.3.1

Entering the Console Program
The rtVAX 300 operates normally in program /O mode. The mode is set to
console I/O mode by one of the following methods:

Kernel HALT occurs: the rtVAX 300 is running in kernel program mode, a
program executes the HALT instruction, and the default recovery action is
specified to halt.

* Boot operation fails and the default action is set for Boot/Halt,
4-8

Firmware

‘

The boot operation fails, and the default recovery action is set for
Restart/Boot/Halt.
The operating environment is severely corrupted: the processor forces a

processor restart when it detects one of several events indicating severe
corruption of its operating environment. The system firmware treats this
like a processor restart caused by a kernel mode HALT.
The system powers on: the boot register bits 2:0 are specified to be Halt, or
the boot switch is set for a boot option and the boot operation fails.
Boot fails for any reason.

External HALT the external HLT line to the rtVAX 300 is asserted at any
time. This line is typically connected to a user-supplied HALT button.

4.3.2 Compatible Console Interface
The rtVAX 300 ROM code includes console support similar to that supported
by the rest of Digital’'s VAX product line.

4.3.3 Entering and Exiting from Console Mode
Norma! operation of the rtVAX 300 is in program I/O mode. The mode is set to
console I/0 mode by one of the methods de .cribed in Section 4.2.

You issue the BOOT, START, or CONTINUE console command to exit from
console IO mode.
Caution

The operator can put the system in an inconsistent state by issuing

console commands. Processor operation in such a state is undefined.
If power fails, the rtVAX 300 processor enters the power-off state and
loses all context, that is, memory and register contents.

4.3.4 Console Keys
The rtVAX 300 console I/0 program responds to the following keys and signals:
Note

During execution of the XFER console command, data directed to and
from the console are interpreted as binary data and thus may not be
interpreted as described below.

Firmware

4-9

ends a command line. No action is taken on a command until after ‘

it is terminated by a carriage return. A null line terminated by a carriage
return 1s treated as a valid, null command. No action is taken, and the

console reprompts for input. Carriage return is echoed as <CR><LF>.
.

deletes the last character that the operator previously typed. The
previous character is erased from the screen and the cursor is restored to
its previous position.

aborts processing of the current command if control has not been
passed to another program, such as the system-level diagnostics. The
console program echoes this key as "C.

causes the console to ignore transmissions to its terminal until the

next [C/0] is entered. This key is echoed as "0 when it disables output but
is not echoed when it reenables output. Output is reenabled if the console

‘

prints an error message or prompts for a command from the terminal.
Displaying a REPEAT command does not reenable output. When output is
reenabled for reading a command, the console prompt is displayed. Output

is also enabled by entering program I/O mode, and then pressing [Ctr/C].

[CtliQ] resumes output to the console terminal that has been stopped by

[CtIS] stops output to the console terminal until [Cr/Q] is pressed.
ct/Q] are not echoed.

[CtS] Additional

are ignored. [Ci/Q] and [Ctr/S] are not echoed.

‘

and

causes the console to echo “U<CR> and deletes the entire line. If[Ctl/U]
is pressed on an empty line, it is echoed, and the console displays (>>>) to
prompt for another command.

[CulR] causes the console to echo <CR> <LF> followed by the current command
line. This function can be used to improve the readability of a command

line that has been heavily edited. When

is pressed as part of a

command line, the console deletes the line, as it does with [CtiU].

4-10

allows the system to enter console I/O mode upon receipt of the
BREAK signal; you must supply circuitry to assert the EXT HLT line if the
received signal goes into the spacing state for more than 100 ms. The SCN
2681 DUART does not support BREAK processing directly. (Chapter 6
gives a circuit example.)

Firmware

‘

. 4.3.5 Console Command Syntax

The console program prompt is three right angles (>>>) on a new line.l
The following restrictions apply to console commands:

They are limited to 80 characters. Characters entered after the 80th
character replace the last character in the buffer. Though characters so
lost may be displayed on the console display, they will not be included in
the actual command line.

The command interpreter i5 case-insensitive. The lowercase ASCII
characters “a” through “z” are treated as uppercase characters.

* The parser rejects characters with codes greater than 7F.5. These
characters are acceptable in comments.

Type-ahead is not supported. Characters received before the console
prompt is displayed are checked for control characters, such as,
and [Ctr/C], but otherwise discarded.

4.3.6 Console Commands
The rtVAX 300 console program supports the commands described in the
.

following sections.
4.3.6.1

Boot

B[OOT] [1R5:]<DATUM:] [<device-name>[:]]

The console program loads an operating system. If the load is successful, the
operating system is started.
¢

Qualifier

The qualifier is of the form /<DATUM>, where <DATUM> is a hexadecimal
value passed as a longword in register five (R5) to the bootstrap program.

This value is used as boot flags by the loaded code. An equivalent qualifier

takes the form /R5:<DATUM> for backward compatibility. Refer to the
specification of the loaded operating system for a detailed list of other
used flags. The rtVAX 300 system firmware interprets only bit 9 of this
longword. If bit 9 is set, the firmware immediately halts before transferring
control to the booted code. The rtVAX 300 system firmware uses none of
the other bits.

The characber se%
uence is 0D1¢, 0As6, 0D16, 3E15, 3E15, 3E15, 2056 (Which is <crs, aF>,
«CR>, '>>>', «P>); this character string can be used by host software executing a bmary
Joad on the spemal attached terminal port to determine when it may respond.

Firmware

4-11

Device Name

The name of the boot device is passed to the bootstrap routine in register

zero (R0O). The name is of the formn ddcu, where dd is a 2-letter device
mnemonic, ¢ is an optional 1-letter controller designator, and u is a 1-digit
decimal unit number. The console program accepts lowercase letters, but
converts the name to uppercase. A terminating colon on the device name
is acceptable, but not required; this character is not passed to the loaded
code.

Section 4.3.7 lists boot devices and their corresponding mnemonics.
4.3.6.2 Continue

C[ONTINUE]

The console I/O mode is exited. Operation returns to (or begins in) program
mode at the PC value either saved when console /O mode was entered or
entered by the operator using the DEPOSIT command.
Note

The interrupt stack pointer (ISP) must contain a valid virtual or
physical address of RAM memory for this command to work. Two
longwords are pushed on the interrupt stack. If the interrupt stack
contains an invalid address, the following message is displayed:
7?04 ISP ERR

4.3.6.3

Deposit

D[EPOSIT] [/<QUALIFIER>] <ADDRESS> <DATUM>

The specified datum is written to the specified address.
¢

Qualifiers

—

Access (size) qualifiers
/B—byte
/W—word

/L—longword
—

Address qualifiers
N—virtual memory
/P—physical memory
/I—internal register

4.-12

Firmware

/G—general-purpose register

/M-—machine register
~

Miscellaneous qualifiers
/N:<COUNT>—repeat count
/U—unprotect

In the absence of an access or address qualifier, the previous qualifier is

used. Specification of conflicting qualifiers is an error, and an appropriate
error message is displayed; the command is ignored.
The effect of miscellaneous qualifiers /U and /N does not persist beyond the
command in which they are typed.
The /U (unprotect) qualifier allows access to almost any address. Without
the /U switch, a protected deposit or examine can only access memory that
is reflected in the PFN map or physical addresses between 20000000 and

3FFFFFFF.
Address—The address is specified in hexadecimal. A missing address is

treated as a +. Supported symbolic addresses are as follows:
—

*is the location last referenced in an examine or deposit operation.

—

@ is the location addressed by the last location referenced in an
examine or deposit operation. This reference cannot be to a gen ral
register.

—

+ is the location immediately following the last location referenced in
an examine or deposit operation. For references to physical or virtual
memory spaces, the location referenced is the last address, plus the size

of the last reference (1 for byte, 2 for word. 4 for longword).
—

- is the location immediately preceding the last location referenced in
an examine or deposit operation. For references to physical or virtual

memory spaces, the location referenced is the last address, minus the
size of the last reference (1 for byte, 2 for word, 4 for longword).

The following limited set of mnemonic addresses is supported:
ASTLVL

AST level register

CADR

Cache disable register

ESP

Executive mode stack pointer

ICCS

Interval clock control register

IPL

Interrupt priority level register

Firmware

4~13

ISP

Interrupt stack pointer

KSP

Kernel mode stack pointer

MAPEN

Memory management enable register

MSER

Memory system error register

PGBR

PO base register

POLR

PO length register

P1BR

P1 base register

P1LR

P1 length register

PCBB

Process control block base address register

Program counter

PSL

Program status longword

R<n>

General register (n = a decimal number 0 through 15)

SAVPC

Saved PC register—read only, ignored on write

SAVPSL

Saved PSL register—read only, ignored on write

SBR

System base register

SCBB

System control block base register

SiD

System identification register

SIRR

Software interrupt request register

SISR

Software interrupt summary register

SLR

System length register

Stack pointer

Ssp

Supervisor mode stack pointer

TBCHK

Translation buffer check register

TBIA

Translation invalidate all register

TBIS

Translation invalidate single register

USP

User mode stack pointer

The rtVAX 3500 system firmware maintains shadow copies of many
processor registers, because reference to the actual registers would
interfere with the operation of the rtVAX 300 firmware. Data accessible

only through their shadow copies are general registers RO through R15, the
PSL, and internal registers MAPEN, ICCS, SCBB, IPL, MSER, and CADR.
Access of any stack pointer may involve the current stack pointer (R14),
the shadow copy of the stack pointer, and the internal registers.

4-14

Firmware

Notes
1. The shadow copy replaces the actual copy at console exit.

2. Upon entry of the ROM code, the IPR CADR is not correctly saved,
howsever, if the IPR CADR is changed by a DEPOSIT command, the
value added by the DEPOSIT command is restored.

Datum—The datum is specified as a hexadecimal number. A missing
datum is treated as a zero entry.

. 4.3.6.4 Examine
E[XAMINE] [/<QUALIFIER>] [<ADDRESS>]

The contents of the specified address are displayed in hexadecimal.

4.3.6.5

Qualifiers—Supported qualifiers are the same as the DEPOSIT command.

Address—The address specification is the same as the DEPOSIT command

Find

F[IND] [<QUALIFIER LIST>]

The console searches the system memory starting at physical address zero

for a page-aligned 128K-byte section of main memory or a restart parameter

block (RPB). If the segment or block is found, its address plus 512 is left in
the SP; otherwise, an error message is issued, and the contents of the SP are
unpredictable. If no qualifier is specified, /MEM is assumed.
Valid qualifiers are:

/MEM-—Search memory for a page-aligned 128K-byte segment of good
memory.

* /RPB—Search memory for a restart parameter block. The search leaves
memory unchanged. SP contains the address of the RPB+200,¢.

4.3.6.6

Halt

H[ALT]

A halt message is displayed, followed by the console prompt.

Firmware

4-15

4.3.6.7 Help

HE[LP]

Supported console commands are listed along with supported parameters and
available options. Figure 4-5 illustrates the Help screen.
Figure 4-5

Help Display

>>> help

DEPOSIT

EXAMINRE

[{(

[{

<addr>

([{

[{

<addx>

|
|

}]

}
-

/P
|

ETHER

HALT

MEM

[/R5:)[<bflg>]

{EZA0

PRAO

PRBx

<ddcu>

SET

HALT

<0-3>

SET

TRIG

<0=1>

(BOOT

BFLG

{

<bflg>

})

[{

BOOT

[{

BFLG

<sym>

SET

<sym>

SET

SHOW

}]
)

[/V]

[/N:<n>}

[<datum>]]

})

[/U]

[/N:<n>]

}]

TRIG)

INITIALIZE
UNJAM

BOOT

C8Bx}

CONTINUE

START

<addr>

REPEAT

<cmd>

TEST

<n>

FIND

[{

/MEM

/RPB

}]

XFER <addr>» <cnt>
HALT
HELP

>> -

i,
MLO-006357

The Help display is intended to aid the user and does not provide a complete
description of the commands.

4-16

Firmware

. 4.3.6.8 Inltialize

I[NITIALIZE]

A processor initialization is performed. The following registers are set (all
values in hexadecimal):
PSL

041F0000

ASTLVL

SISR

1CCS

MAPEN

CADR

200

ISP

200

All other registers are unpredictable.
4.3.6.9

Repeat

R[EPEAT] <COMMAND>
The console program repeatedly executes the specified command. Repeated

execution of a command stops when the operator types
or when any
abnormal circumstance occurs. Any console command may be specified for the
command.
4.3.6.10

Set
SE[T] <PARAMETER-NAME> <«VALUE>

Note
All saved values are lost on power failure or reset.

Set the console parameter to the indicated value. The following console
parameters and their acceptable values are defined:
o

BOOT—Sets the default boot device. The value must be a valid boot device
name, as specified in Table 4-9 in the device field.

BFLG—Sets the default boot flags. The value must be a hexadecimal

number of up to eight characters. The value that is entered is not checked
for validity.

Firmware

4-17

HALT—Sets the default halt action and halt switch codes. This code
specifies the default action the console should take for all error halts and
halt instructions.

TRIG—Sets remote trigger to be enabled or disabled. This allows a remote
system to request a local boot of the system. If the Ethernet self-test has
failed, then this command is illegal. The power-on condition for this is
determined by BOOT«<3>.
4.3.6.11

Show

SH{OW] <PARAMETER-NAME>

The indicated console parameter is displayed.

BOOT—Displays the default boot device as defined above. If no boot device
has been specified, the field appears as four dots (. ...).

BFLG—Displays the default boot flags. If no default flags have been
specified, then 00000000 is displayed.
ETHER—Displays the hardware Ethernet address. The Ethernet address
ROM is validated and is displayed as ID YY-YY-YY-YY-YY-YY, where YY
is a valid 2-digit hexadecimal number. If the Ethernet address ROM is
invalid, then ID XX-XX-XX-XX-XX~XX is displayed to indicate that the
Ethernet address ROM is invalid.

HALT—Shows the default halt action code.
MEM-—Displays information concerning the rtVAX 300 system memory.
The format of the display is:
>>> SHOW MEM
00400000
00000000

003FD400:003FFFFF

The first 8-character field displays the total amount of memory in the
system, including the console data structures. The second 8-character field
shows the first address of 128K bytes of contiguous memory. The final line
of the display shows the address range of the area of memory that is not
available to the operating system. This includes the area of memory that
is reserved for use by the console program. This fieid will be repeated as
many times as needed to display all address ranges that are not available
to the operating system.

4-18

Firmware

TRIG—Shows the state of r- mote trigger enable. If the returned value is 0,
remote triggers are not allowed, if 1, remote triggers are allowed.
Note

The symbols used in the SET and SHOW commands must be entered
as shown; however, they can be entered in lowercase and uppercase.
The spelling of each symbol is critical.

4.3.6.12

Start
S[TART) <ADDRESS>
The console starts executing instructions at the specified address. The address
is treated within the context of the user’s memory management mode (physical
or virtual).

If no address is given, the current saved PC is used. The START command is
equivalent to a DEPOSIT PC followed by a CONTINUE. No initialization is
performed.
Note

Also note that the ISP is undefined after a power-up or reset.
The INITIALIZE command can be used to initialize the ISP and the
rest of the processor.

4.3.6.13

Test
T{EST] <PARAMETER1> [<PARAMETER2>]
This command invokes extended diagnostics and utilities. Tests 1, through
718 are onboard power-up tests, tests 8;4 through E;g are user-supplied powerup tests. (Refer to Table 4-5 for a list of test numbers and their meanings.)

Firmware

4-19

4.3.6.14

Unjam
UINJAM]

This command provides a system reset. The status of all devices returns to a
known, initial stat~—that is, registers are reset to 0, and logic is reset to state
0.
This operation is implemented on the rtVAX 300 by invoking the hardware
IORESET, and calling UNJAM routines for the Ethernet interface and the
console serial-line unit, if present. The user is responsible for decoding the
IORESET processor register to produce a reset signal and for using this signal
to reset the user’s devices. Any device that may interrupt the rtVAX 300 at

IPL 164¢ or IPL 17,5 must be reset in this fashion. The user cannot reasonably ‘
expect to continue from an UNJAM command.

When you connect the rtVAX 300 to a bus, such as the VME bus, it is useful for
the rtVAX 300 to be able to reset that bus and its peripherals under program
control. The console UNJAM command provides this facility, because it writes
to IPR 37,4, the /O bus reset register. It is not implemented within the rtVAX
300 processor module.
However, if you need an external bus reset signal, external board-level logic
should decode the external-internal processor register write cycle to IPR 374
and assert the I/O bus reset line when any write is performed to that register
location. Any user devices that may interrupt at IPL 16,4 or 17;5 must
implement IORESET, and the device must disable all interrupts upon receiving
IORESET.

There are no bit assignments for the external bus reset I/O register. The /O
bus reset should be performed after any write to IPR 374¢.
4.3.6.15

Transfer

X[FER] <ADDRESS> <COUNT> <CR> <CHECKSUM> <DATA STREAM> <CHECKSUM>

This command transfers binary data to and from physical memory. It is
intended for use only by host software through an attached console terminal,
serial port Channel A. Do not expect to be able to type this command from

a keyboard. Note that XON/XOFF line spacing is disabled during the binary
transfer: these characters are treated as binary data when they occur in the
binary data stream.

4-20

Firmware

address—Specifies the physical address that the binary data are
transferred to or from. It is specified as a hexadecimal number.

count—Specifies the number of bytes to be transferred. The count is
expressed as an 8-bit hexadecimal number. If the high-order bit of the
count longword is 1, the data are transferred (read) from physical memory
to the console terminal; if it is 0, the data are transferred (written) from
the console terminal to physical memory.
CR-—~Carriage return

checksum-—Specifies the two’s complement checksum of the command
string or data stream. The checksum is one byte of data expressed as a
2-digit hexadecimal number.

data stream—"Count" bytes of binary data.
4.3.6.16

! (Comment)
! <COMMENT>

<COMMAND> ! (comment)

The exclamation point prefixes a comment, wherever it appears on the line; the
remainder of the line is ignored.

4.3.7 Supported Boot Devices
The boot device names that you can use to boot the rtVAX 300 processor are as
follows:
1.

EZA(0—Ethernet

PRAO—ROM in memory space, starting at physical address 10000000

PRBO—ROM in /O space, starting at physical address 20200000

PRB1—ROM in /O space, copied to system memory

CSB0—Channel B on SCN 2681 DUART at 1200 bps

CSB1—Channel B on SCN 2681 DUART at 2400 bps

CSB2—Channel B on SCN 2681 DUART at 9600 bps

If no device name and/or qualifiers are given on the BOOT command, the
console uses the value determined by BOOT<2:0>.

Firmware

4-21

4.3.8 Console Program Messages
Error messages consist of a 2-digit hexadecimal number prefaced by a question
mark and an abbreviated text message. Error message numbers are in the
range 00,5 through 7F;¢.
Section 4.5 discusses and illustrates startup messages that can be displayed
during power-on initialization. Table 4-2 lists and describes firmware error
messages.

Table 4-2

Firmware Error Messages

Codes

Message Text

Description

702 EXT HLT

The external HLT line was asserted.

704 ISP ERR

The interrupt stack was inaccessible or invalid
during the processing of an interrupt or exception.

705 DBL ERR1

A machine check occurred while the processor was
processing a normal exception.

706 HLT INST

A kernel mode HALT instruction was executed.

707 SCB ERR3

SCB interrupt vector bits <1:0> equaled 3.

708 SCB ERR2

SCB interrupt vector bits <1:0> equaled 2.

76A CHM FR ISTK

A change mode instruction was executed when
PSL<IS> was set.

?70B CHM TO ISTK

The exception vector for the change mode had bit 0
set.

70C SCB RD ERR

A hard memory error occurred while the processor
was trying to read an exception or interrupt vector.

710 MCHK AV

An access violation or invalid translation occurred

during the processing of a machine check.
11

711 KSP AV

An access violation or invalid translation occurred
during the processing of an invalid kernel stack
pointer exception.

?12 DBL ERR2

A machine check occurrad while the processor was
trying to report a machine check.

713 DBL ERR3

A machine check occurred while the processor was
trying to report an invalid kernel stack pointer
exception.

719 PSL EXC5

PSL<26:24> = 5 on an interrupt or exception.
(continued on next page)

4-22

Firmware

Table 4-2 (Cont.)

Firmware Error Messages

Codey;

Message Text

Description

?1B PSL EXCé

PS1.<26:24> = 6 on an interrupt or exception.

?1B PSL EXC7

PS1.<26:24> = 7 on an interrupt or exception.

71D PSL EXC7

PSL<26:24> = 5 on an REL

?1E PSL EXC7

PS1.<26:24> = 6 on an REL

?1F PSL EXC7

PSL<26:24> = 7 on an REL

721 CORRPTN

Console memory corrupted.

722 ILL REF

The requested reference would violate virtual

memory protection. the addres- is not mapped, the

reference is invalid in the specified address space, or
the value is invalid in the specified destination.

?23 ILL CMD

The command string cannot be parsed.

724 INV DGT

The number has an 1nvalid digit.

725 LTL

The command was too large for the console to buffer.
The message is issued only after the receipt of the
terminating carriage return.

726 ILL ADR

The specified address falls outside the limits of the
addressing space.

727 VAL TOO LRG

The specified value does not fit in the destination.

728 SW CONF

Switches conflict.

729 UNK SW

The switch is unrecognized.

72A UNK SYM

The symbolic address in the EXAMINE or DEFOSIT
command is unrecognized.

72B CHKSM

The command or data checksum on the XFER
command is invalid.

72C HLTED

The operator entered a HALT command.

72D FND ERR

The FIND command failed to find the RPB or 64K
bytes of good memory.

722E TMOUT

During an XFER command, data failed to arrive in
the expected time.

72F MEM ERR

A parity or other memory error occurred.
(continued on next page)

Firmware

4-23

Table 4-2 (Cont.)

Firmware Error Messages

Codeys

Message Text

Description

730 UNXINT

Unexpected interrupt or exception. For some

interrupts, this message is followed by the PC,
PSL, and interrupt vector.

BOOT SYS

This is the bootstrapping message.

FAIL

This is the general failure message.

RESTART SYS

This is the restarting system software message.

RMT TRGGR

This is the remote trigger request message.

4.3.9 Console Device
The console program operates an optional attached terminal connected through
a serial port. The attached terminal may be an ASCII video terminal, for
example, a VT220 or VT320, or a host computer sunning special software.

The existence of a console is determined by the Mllowing test performed at
power-on:

Check the physical address 20100000 frr a nonexistent memory errar
(NXM) timeout. If a timeout occurs, 7.0 cons~!: i~ ~vailable for use.

The SCN 2681 DUART device .s .nitialized, and the console port (Channel
A) is initialized to 9600 bps, no varity, 8 bits/character, and 1 stop bit.

Channel B is not initialized at this time.

No check is made to determine wi. *L.r ¢ device is on the other end of the
cable.

4.3.10 Capabilities of Console Terminals
Console terminals for the rtVAX 300 must support at least USASCH
graphic character encoding. The terminal may optionally support the DEC
Multinational Character Set, which is a superset of USASCII. National
replacement character sets are not supported.
Characters normally transmitted by the console program are the USASCII
graphic characters 21,5 ('} through 7E;¢ (-}, the space character 2044, and
control characters 0D;5 (CR), 0Ag (LF}, and 08,4 {BS, a backspace character}.

4-24

Firmware

. 4.3.11 Console Entry and Exit

The system firmware must do several things when it enters and exits from
console mode to ensure that the console window is displayed correctly.

Attached Termina's When present, the attached terminal on serial port
Channel A is expected to be operable at all times. Console firmware does not
attempt to alter the state of these terminals or the serial port through which
they are connected. At entry to the console mode, firmware calls the operating
system’s SAVE routine (SCR$A_SAVE_CONSOLE), if supplied, and the console
prompt is displayed; at exit, firmware calls the operating system’s RESTORE
routine (SCR$A_RESTORE_CONSOLE), if supplied.
Resident irmware sends several characters to the attached console terminal at
entry to console mode. These attempt to place the terminal in a known mode
and include:
*

XON (11;4) enables terminal.

ESC\ (1Byg, 5Cyg) turns off special text modes (ReGIS, SIXEL, etc).

ESC\4i (1Byg, 5Cy¢, 3416, 6916) directs output to screen.

. 4.4 Entity-Based Module and Ethernet Listener
The Ethernet maintenance operation protocol (MOP) module supports MOP
Version 3 and Version 4 functions. The hardware device type of the rtVAX 300
in the MOP SYSID hardware code field is 105.

The Ethernet listener polls the Ethernet subsystem for receipt of packets.
Once a packet has been received, the listener code inspects the packet protocol
in order to determine the actions to take. Important protocols are as follows:
e

MOP loopback packet (protocol 90-00) for Ethernet connectivity testing.
The listener forwards or loops back a MOP loopback packet.

DECnet SYSID request packet (protocol 60—02, type 5) for sizing the
network. The listener generates a DECnet SYSID.

Ethernet counters request packet (protocol 60-02, type 9) for checking the
performance of the system on the Ethernet. The listener generates an
Ethernet counters packet.

DECnet bootstrap trigger packet (protocol 6001, type 6) for forcing the
rtVAX 300 system to enter its bootstrap sequence. Remote trigger must be
enabled, in order to initiate the bootstrap process. The listener processes a
down-line loaded system image.

Firmware

4-25

DECnet assistance volunteer packet (protocol 60—01, type 3) for the case
where the console program has failed an attempt at booting over the
Ethernet.

The listener is established when an initialization routine sets up a pointer
in the scratch RAM area to the listener’s starting address. The initialization
routine is established when the Ethernet subsystem self-test passes and sets
up the pointer in scratch RAM to the initialization routine’s starting address.
The initialization routine is called by the UNJAM routine, or at power-up
time prior to the console program startup, unless the MOP flag is set to 0.
This routine establishes the Ethernet controller data structures (transmit and

receive descriptor rings, data buffers) and some scratch area for the listener to .

maintain pointers and counters.

If the protocol is one of those described above, the listener code takes the
appropriate action. If the protocol is unsupported, for example, DECnet
routing updates, the packet is disregarded.

4.5 Startup Messages
The console displays messages and menus, some during power-up and others
when the operator issues commands at the console terminal. The latter depend
on entries in the console memory.

4.5.1

Power-On Display
This display is intended to give a complete, but abbreviated, account of the
results of the power-on initialization. The display includes the board name and
firmware version, a hexadecimal countdown list of test modules (F through 1)
with a quick summary of the status of each, and an expanded status report
of those test modules for which error or status information is available. The
following example shows a sample power-on display:

rtVaX 300 Vn.m
>>>

where:

n is the major version number
m is the minor version number

4-26

Firmware

In the countdown line, each test number is followed by a status character and
two periods. Table 4-3 lists the status codes and their meanings.
Table 4-3
Code

Countdown Status Codes

Meaning

Test completed without fatal error
?

Fatal error detected in test

Test determined option is missing

The return status of a user-supplied test was not 1 (test passes), O (test failed),
or -1 (option not present)

4.5.2 Boot Countdown Description
When the rtVAX 300 is loading an operating system, the LED display and
the console display, if they exist, indicate the progress of the boot. Table 44
explains the meanings of the LED displays and console messages.
Table 44

Boot Countdown Indications

LED

Console

Message

Meaning

The bootstrap code has started; no valid load host or ROM

For ROM boots, the ROM boot block has been located, and
if the ROM is to be copied to memory, this procedure has

Display,s

boot block has been located yet.

started.

For Ethernet and serial line boots, a host system has offered
to down-line load an operating system to the rtVAX 300 and
load of the operating system has started.

0...

The load of the operating system from the host or copying
and verifying of ROM ie complete, and control is being
transferred to the loaded operating system.

When the system is booted, a positive indication of boot status is returned in
the processor LED display and on the console terminal, as follows:
¢

The name of the boot device appears on the console terminal.

The value 2 appears on the console terminal and th
. processor LEDs to
indicate that the bootstrap device is about to be accessed.

Firmware

4-27

The value 1 appears on the console terminal and the processor LEDs to
indicate that the rtVAX 300 firmware has found the secondary bootstrap
image on the boot device, and is now reading the image into physical
memory

—
—

For ..OM boots, the ROM boot block has been located and copied to

memory, if the boot device was PRB1.

For Ethernet and serial-line boots, a host system has volunteered and
is down-line loading the rtVAX 300 system.

The value 0 appears on the console terminal and the processor LEDs to
indicate that the rtVAX 300 resident firmware is now transferring control
to the operating system or secondary bootstrap.

A typical console display during the boot process is:
-EZAD

2..1..0..

This illustrates a boot from the Ethernet. Other boot devices would be
displayed, depending on the setting of the user boot register.

4.5.3 Hait Action
The operator may inspect and possibly modify the console fields used during
processor restarts by using the console SET/SHOW HALT command, for
example:
>>>

SET HALT

75>
3

>>>

See Section 4.2.1 for more information.

4.5.4 Boot Device
The operator may inspect the console field used for the default boot device and
modify it by using the console SET/SHOW BOOT command, for example:
>>> SET BOOT

EZAQ 7

>>>

See Section 4.2.2 for more information. This field is initialized from the boot
register upon reset or power-up. When there is no default for the boot device,
it is displayed as four periods. To clear the field, enter a period at the prompt.

428

Firmware

. 4.5.5 Boot Flags

The operator may inspect and possibly modify the console field used as default
boot flags for system image boot by using the console SET/SHOW BFLG
command, for example:
>>>

SET BFLG

00000000 2 »>> 10
>>>

See Section 4.3.6.1 for information on the BOOT command. This field is zeroed
upon power-up or reset.

4.6 Diagnostic Test List
Tests are listed in the order they are executed upon restart. Tests are executed
implicitly by a power-up/restart condition or explicitly by a console TEST
nn command, where nn is the hexadecimal test number. Table 4-5 lists
LED-displayed test numbers and their meanings.
Each test has the following features:

When called from the conscle, it supports loop-on-test, loop-on-error,
halt-on-error, and continue-on-error.

It has two levels of subtests:

—

The functional unit of the device under test

—

The particular function of the subunit being tested

Table 4-5

LED Test Number Code List

Test

LED

No.

Code,s

Description

Initialization test. This test is not user-selectable.

Power-up value; this value is set on power-up. It indicates that there

is power on the module. If the display remains at this value, the
rtVAX 300 is unable to execute the first few instructions correctly.

The first few instructions have completed. The rtVAX 300 can write

Special value u. -'d for the tVAX 300 HALT test in the tester box.
This value is used only when the rtVAX 300 test box is used.

to the display register.

(continued on next page)

Firmware

4-29

Table 4-5 (Cont.) LED Test Number Code List
Test

LED

No.

Codeys

Description

Special value used for the tVAX 300 HALT test in the tester box.
This value is used only when the rtVAX 300 tester box is used.

The actual presence of the LED display is verified.

Value set when user initialization ROM entry point is called.

F7-F1

Reserved for use by the user’s initialization ROM.,

FoO

The preliminary initialization is completed. Basic rtVAX 300
instructions work, and it is possible t¢ communicate off the chip.

rtVAX 300 ROM verification, LED tests, and checksum. Verify the

ROM checksum, that the high and low bytes of ROM are the same
version, and that ROM test patterns are correct. The LED registers
are verified. This may be the only means to display errors.

The ROM high and low byte identification words are incorrect.

ROM version numbers do not match.

ROM test patterns are incorrect.

ROM checksum is incorrect.

ROM tests exited successfully.

Memory test codes DF, DE, DD, and D1 are displayed by the scratch

memory tests that find and verify RAM used by ROM code and tests
that locate, verify, and initialize RAM for use by the console data
structures. The RAM is tested with . bit pattern test and an address
test and cleared to 0.

No memory present.

Memory could not be cleared.

Sizing memory.

Full memory test—clearing memory.

Full memory test—memory addressing test.

Full memory test—test each page of memory.

Full memory test—test page boundaries.

Sizing memory completed.

Scratch memory initialized and is usable.
(continued on next page)

4-30

Firmware

Table 4-5 (Cont.)
Test

LED

No.

Codeg

LED Test Number Code List
Description

Console channel routine, channel existence, and verification. Check
to see if a console device responds to the console address. The consovle
will be used after this point if it exists and is functional.

Console not found. All output directed to the console is discarded

Console detected.

Initialization of Ethernet coprocessor after self-tests.

UNJAM function after self-tests.

(not necessarily a failure).

Performing automatic restart/boot/halt action according to boot
register.

Not implemented.

Floating-Point Accelerator test. The different groups of floating-point
instructions, including F.. D-, G-float adds, subtracts, multiplies,
comparisons and divides are tested and verified with known results.
This verifies the operation of the CFPA.

MOVTF instructions.

MNEGF instructions.

ACBEF instructions.

ADDF2/ADDF3 instructions.

CMPF instructions.

CVTFD/CVTFG instructions.

CVTFB/CVTFW/CVTFL/CVTRFL instructions.

CVTBF/CVIW /CVTLF instructions.

DIVF2/DIVF3 instructions.

EMODF instructions.

MULF2/MULFS3 instructions.

POLYF instructions.

SUBF2/SUBF3 instructions.

TSTF instructions.

CFPA tests passed.

(continued on next page)

Firmware

4-31

Table 4-5 (Cont.)
Test

LED

No.

Codey

LED Test Number Code List
Description

Interval timer test. Verify the on-board interval timer interrupt
signal exists, does generate interrupts when enabled, and is accurate.
9F

Interval timer interrupts when disabled via IPL.

Interval timer does not interrupt.

Time between interrupts is too short or is not consistent.

Interval timer interrupts when disabled via ICCS IPR.

Interval timer tests passed.

‘

Ethernet test. Tests that the Ethernet interface is functional and
that the Ethernet network ID ROM contains a valid network address
and correct checksum. Ethernet tests consist of the Ethernet selftest, an Ethernet sanity test, internal and external loopback testing
of the Ethernet, address filter testing and several others. This test
determines if the Ethernet can be used for booting. This is the final
self-test.

Ethernet sanity test failed.

Ethernet internal loopback failed.

Ethernet collision test failed.

Multicast addressing test failed.

CRC test failed.

Frame type test failed.

Virtual mode test failed.

Ethernet tests passed.

‘

ROM network ID address test failed.

‘

The remaining tests are reserved for the user-application-specific test ROMs and are
not part of the rtVAX 300.

7F-70

User-supplied Test 8.

6F-60

User-supplied Test 9.

5F-50

User-supplied Test A.
{continued on next page)

4-32

Firmware

Table 4-5 (Cont.)

LED Test Number Code List

Description

Test

LED

No.

Codey;

4F-40

User-supplied Test B.

3F-30

User-supplied Test C.

2F-20

User-supplied Test D.

1F-10

User-supplied Test E.

The following routines are in the rtVAX 300:
-

System boot. This is not a test. If other tests pass, the system either
boots or enters console mode, as determined by the boot register
setting.

System is awaiting or executing a console command.

Console Restore Procedure, called before control is transferred to
user’s code, by CONTINUE command.

Attempting boot.

Boot host found, or ROM boot block located.

Control passed to down-line loaded code or external ROM code.

Once control is passed to the loaded code, the state LEDs will have meaning only as
defined by that code.

Caution

User code may modify the LED display without affecting the system
ROM code; however, such modifications may cause confusion, if the
user believes that the system ROM code caused the status.

Firmware

4-33

4.7 System Scratch RAM
The rtVAX 300 system firmware acquires a numi-er of pages of RAM memory at
power-on initialization. These pages are marked “bad” in the memory bitmap
to prevent higher-level software from modifying their data indiscriminately.
Table 4-6 lists the offsets in the scratch RAM to parameters and variables of
interest to operating system or option ROM developers.
Table 4-6

Scratch RAM Ofiset Definitions

Oftsetys

Name

Console program mailbox

Console program flags

Default boot device register

Reserved

SCR$A_RESTORE_CONSOLE

SCR$A_SAVE_CONSOLE

Figure 4-6 shows the layout of the console mailbox register; Table 4~7
describes its fields. Figure 4-7 shows the layout of the console program flags;
Table 4-8 describes its fields. Figure 4-8 shows the layout of the default boot
device register; Table 4-9 describes its fields.
Figure 4-6 Console Mailbox Register (CPMBX) Offset 004¢
07

TRIG | RSV

04
B

HLT_SWX
§

RP | BP

00
i

HLT_ACT
1

MLO-G06517

4-24

Firmware

Table 4-7 Console Mailbox Register Fields
Fleld

Description

TRIG

A 1-bit field that indicates that remote triggers are allowed. If this bit is
get, remote trigger is allowed.

This field is initialized upon power-up/reset to the value of the remote
trigger bit of the boot flags byte after the user’s initialization routine (if
any) is called.

RSV

Reserved.

HLT_SWX

A 2-bit halt switch field used to encode permanently the desired console
action when a processor halt occurs (except externally generated halts
brought about by the assertion of the HLT L line). The action taken is
indicated below:

0 — Restart; if that fails, boot; if that fails, halt.
1 — Restart; if that fails, boot; if that fails, halt.
2 — Boot; if that fails, halt.
3 — Halt.

This field is initialized upon power-up/reset to the value 2 (BOOT)
before the user’s initialization routine (if any) is called. This field
may be inspected and modified by using the SET/SHOW HALT console
cornmands.

At entry to the console, this value is moved to the HLT_ACT field, except
for externally generated halts.

RIP

A 1-bit field that serves as the restart in progress flag. The bit is set
when the console attempts a restart. If it is already set, the restart
attempt is abandoned, an error message is displayed, and a boot is
attempted.

This field is cleared at power-up. It is also cleared at entry to the console

(halt) program, after any attempts at restart and/or boot.

The user application must clear this bit when the Ethernet coprocessor’s
Boot Message Enable mode is to be used.
(continued on next page)

Firmware

4-35

Table 4-7 (Cont.) Console Mallbox Register Fields
Fleld

Description

BIP

A 1-bit field that serves as the bootstrap in progress flag. The bit is set
when the console attempts a cold restart. If the bit is already set, the
bootstrap attempt is abandoned, an error message is displayed, and the
Console (halt) program is executed.

This field is cleared at power-up. It is also cleared at entry to the console
(halt) program, after any attempt to boot.
The user application must clear this bit when the Ethernet coprocessor’s
Boot Message Enable mode is to be used.
A 2-bit field that temporarily encodes the action that the console is to
take when the next processor halt occurs (except for externally generated
halts, such as BREAK and assertion of the HLT L signal). The action
taken is as described for HLT_SWX above.

HLT_ACT

This field is copied from the HLT_SWX field at power-up, upon execution
of the SET/SHOW HALT console commands, and at entry to the console.

Flgure 4-7 Console Program Flags
T

Reserved to Console Code
|

DisP | sLU

MLO-004504

Table 4-8

Console Program Flags Fields

Field

Description

DISP

A 1-bit field used by the console code to determine if the hexadecimal display

at address 201FFFFE is present. If the bit is set, that address responded,
and the display is assumed to exist. If the bit is clear, there was no hardware
response to that address.

User-supplied tests and booted images may test this bit to determine if the
display register exists.

This field is initialized at every entry to the console program.
(continued on next page)

4-36

Firmware

Table 4-8 (Cont.)

Console Program Flags Fields

Field

Description

SLU

A 1-bit field used by the console code to determine if the SCN 2681 console
DUART at address 20100000 is present. If the bit is set, the address
responded and preliminary tests determin.~d that the console DUART was
usable. If the bit is clear, there was no harlware response to that address.
User-supplied tests and booted images may test this bit to determine if the
console DUART is present.
This field is initialized at every entry to the console program.

Figure 4-8 Default Boot Device Register (EOOTDEV)
07

06
|

Reserved
1

I
1

MEMTST | Res.

BOOT
4

MLO-004505

Firmware

437

Table 4-9 Detault Boot Device Register Fields
Fleld

Description

«2:0>

A 3-bit field used to determine the default boot action of the rtVAX 300 when
it executes a boot sequence. This field is temporarily overridden by a BOOT
command with an explicit device specified. This field is initialized from the
boot register at power-up or reset and may be modified by software control.
Posgsible field meanings are as follows:
BOOTDEV

Device

000

001

Boot Action
No boot performed; system enters or remains in

HALT mode.

PRAO

Boot from ROM in system memory space. The

firmware searches for a boot block starting at
physical address 10000000 every 16K bytes until
it finds the boot block or has reached the address
1FDFC000.

010

PRBO

Boot from ROM in /O space. The firmware
searches for a boot block starting at physical
address 20200000 at each 512 byte boundary, until
it finds the boot block or has made 256 attempts.

011

PRB1

Boot from ROM in I/O space after copy. The same
action as the PRBO boot is taken, except the
contents of ROM are copied into RAM memory
address before control is transferred, and then
control is transferred to the RAM copy.

<3>

100

CSBO

DECnet DDCMP boot. Channel B on the SCN 2681
is initialized to 1200 bps, and a DDCMP MOP load
function is executed. See the DDCMP specification
for more details. The SCN 2681 console DUART
must be supplied by the user.

101

CSB1

DECnet I:DCMP boot. Same as CSBO, except that

110

CSB2

DECnet DDCMP boot. Same as CSB0, except that

111

EZAO

Channel B is initialized to 2400 bps.

Channel B is initialized to 9600 bps.

Boot from Ethernet. The standard MOP protocol

for Ethernet loads is used.

Reserved.
(continued on next page)

4-38

Firmware

Table 4-9 (Cont.)
Fleld

<4>

Default Boot Device Register Fields

Description

Set if memory test is to be performed on power-up; cleared when test is not to
be performed.

<7:5>

4,71

Reserved.

SCR$A_SAVE_CONSOLE
Scratch RAM contains the longword physical address of a save routine supplied
by the operating system. This routine is called as the console program enters
console mode. The routine gives the operating system the opportunity to save
the current state of hardware that may be obliterated by the console device and
to ensure that the console device hardware is in an operable state (as discussed
in Section 4.3.11 and shown in Table 4-6). This routine is called with a JSB
instruction at IPL 1F;4 in kernel mode with memory management disabled. A
value of 0 in this field implies that no routine has been provided, and no call
is made in this case. The console program does not wait for the hardware that
is used by the console device to complete its current operation (become stable)
befare calling this routine. This field is zeroed at power-up.

4.7.2 SCR$A_RESTORE_CONSOLE
This is the longword physical address of a restore routine supplied by the

operating system. This routine is called as the console program exits from
console mode. The routine gives the operating system the opportunity to
restore the original hardware state when the console program no longer needs
to use the console device. This routine is called with a JSB instruction at IPL
1F15 in kernel mode with memory management disabled. A value of 0 in this
field implies that nc routine has been provided; no call is made in this case.
This field is zeroed at power-up.

4.8 User-Defined Board-Level Boot and Diagnostic ROMs
An optional, user-defined initialization routine and up to seven user-defined
self-test routines can be located in user ROM. This 32-bit-wide user ROM is
located at a starting address of 20080000 of physical /O space. This ROM
is optional and is not necessary for the normal operation of the firmware

initialization and self-test routines.

Firmware

4-39

On power-up, the firmware runs preliminary self-tests and then checks to see '

if a ROM exists at location 20080000. If a ROM responds to that address,

the console program checks for a user-supplied ROM initialization routine in
user ROM before executing the full self-tests. If the routine is found, the ROM
initialization routine is called.
Once the rtVAX 300 firmware regains control from the user ROM initialization

routine, the rtVAX 300 completes its self-test.
If the ROM exists at location 20080000, it is checked again for user-supplied

self-test routines; these routines are executed, and the system attempts to boot
or to enter console mode, depending on the setting of the BOOT<2:0> lines.

The longword at ROM address 2008001C contains the address of the user’s
initialization procedure. The seven longwords starting at ROM address
20080020 contain the physical addresses of the seven test routines. The
physical address of these routines must be in the range of 20080040 to
200FFFFC, or be 0. A value of 0 for the physical address indicates that this
routine does not exist. Figure 4-9 shows the layout of this ROM. Refer to
Appendix D for a template of these routines.
The CALLG/CALLS instruction is used to call the initialization and test

routines, and the RET instruction to return from them. You must follow the
VAX calling standard and therefore save registers R2 to R11. If you use R2 to

R11 in the routine, specify them in the procedure entry mask. Registers R12 to
R15 are specially handled by CALLX/RET and need not concern users writing
code according to the standard. The procedures are called at IPL 1F;¢ with
memory mapping disabled.

4.8.1

Optional User Initialization Routine
Routines in the initialization ROM can initialize any of the user-supplied
devices to a known state and use the interrupt stack for variable storage. The

only requirement is that the processor context be restored as described in the ‘

VAX calling standard after these routines exit.!
*

The user’s devices are optionally placed in a known state before the
self-test is run.

The console mailbox can optionally be modified.

! Registers R2 to R15, the interrupt stack, and all IPRs must be preserved. The VAX ‘
Architecture Reference Manual describes this standard.

4-40

Firmware

Figure 4-9

User Boot/Diagnostic ROM
16,15

LED Display

200FFFFF

Board Level Initialization Code and

Range

Diagnostics Testing Code.
20080040

2008003C

Reserved, Mustbe O

20080038

Ptiysical Address of Test # E

(1F-10)

20080034

Physical Address of Test# D

(2F-20)

20080030

Physical Address of Test#C

(3F-30)

2008002C

Physical Address of Test #B

(4F-40)

20080028

Physical Address of Test# A

(5F-50)

20080024

Physical Address of Test#9

(6F-60)

20080020

Physical Address of Test # 8

(7F-70)

2008001C

Physical Address of Init Code

(F8-FO)

20080018

Reserved, Mustbe O

20080014

Reserved, Mustbe O

20080010

Any Value

2008000C

Any Value

20080008

Must be 20202020,

20080004

ROM Byte Nuimber (03020100,)

20080000

Any Value
31

4.8.2

Must be 3101,
1€ 15

MLO-006375

Input Parameters
The user-defined initialization routine is called with three parameters:
¢

Parameter 1 (AP+4) is the address of the console mailbox.

Parameter 2 (AP+8) is the address of the memory bitmap descriptor.

Section 4.8.3 defines this descriptor.
¢

Parameter 3 (AP+12) is the address of a scratch memory area.

Firmware

4-41

4.8.3 Memory Bitmap Descriptor Format
Figure 4-10 shows the layout of the memory bitmap descriptor.
Figure 4-10

Memory Bitmap Descriptor

00
Bitmap Length (in Bytes)

+00

Bitmap Starting Address

+04
MLO-006374

Each bit corresponds to a page of memory; bit 0 corresponds to physical page 0, .
bit 1 corresponds to physical page 1, and so on. If a bit is 1, the corresponding
page is considered good and available for use by the operating system. A page
whose bit is 0 is considered “bad” or reserved by the console program, and is
not to be used as general-purpose memory.

The initialization routine may change any bit from a 1 to a 0 to indicate that
a page is reserved for any reason or is not to be passed to the loaded operating
system as a normal memory page.

Bits set to 0 when the user initialization routine is called should not be set to 1
by user firmware.

The memory self-test that executes later will change the bit that corresponds
to any defective page of memory to a 0. Pages whose bit is 0 when the memory
self-test starts will not be tested.

4.8.4 Optional User-Supplied Diagnhostic Routines
User-supplied ROM test routines can test any of the user-supplied devices.
The seven longwords at 20080020 through 20080038 are checked for addresses
of user-supplied tests. If these longwords contain a number in the range
20080040 through 200FFFFC, it is considered the address of a user test, and
the test at this location is called with a CALLG/CALLS instruction. Any tests
not used should have a 0 as the test address. The processor context must be

restored according to the VAX calling standard after these ROMs exit.

The LED status display values between 10,6 and 7F;¢ are reservec for use by
these external self-test routines. When control is passed to the test in ROM,
the high-order byte of the LED status register is set to a value in the range
of 1 through 7 to indicate the test number, and the low-order byte is set to
Fi6. The user’s test routine must change the value from the starting vaiue to

4-42

Registers RZ to R15, the interrupt stack, and all IPRs must be preserved.

Firmware

indicate progress through the user’s subtests. Normally. the subtests count the
lowest digit down from F;g to 0;5. The high-order byte should always indicate
the same value to make failure codes unique.
4.8.4.1

Self-Test Routine input Parameters

The user-defined initialization routine is called with five parameters:
Parameter 1 (AP+4) is the address of a scratch memory area. The first 4K

bytes may be used as a scratch memory area.
Parameter 2 (AP+8) is the address of a longword that the test may use to
store the PC if the test fails.
Parameter 3 (AP+12) is the address of a quadword that the test may use to
store "expected data" if the test fails.
Parameter 4 (AP+16) is the address of a quadword that the test may use to
store "actual data” if the test fails.
Parameter 5 (AP+20) is a longword containing flags:

Bit 0: 1 if explicitly called with a TEST x command. Informational
messages should be suppressed if this bit is 0.

—

Bit 1: 1 if test is called by the power-up sequence.

—

Bit 2: 1 if test should return immediately upon failure; if 0, test may
continue to completion and return an error if there is a failure.

4.8.4.2

—

Bit 3: 1 if console DUART exists; otherwise, 0.

Bit 4: 1 if LED test display exists; otherwise, 0.

Self-Test Routine Output

The return status of each test is placed in register R0. Return status meanings
are as follows:
1—Test passed successfully. During self-test, the hexadecimal digit
corresponding to the test number followed by 3 periods (...) is displayed to
indicate that the test passed.
0—Device under test failed the test. During self-test, the hexadecimal digit
corresponding to the test number followed by a "?7" and 2 periods (?..) is
displayed to indicate that the test failed.
—-1—Device being tested is not present. During self-test, the hexadecimal

digit corresponding to the test number followed by a "_" and 2 periods (_..)
is displayed to indicate that the tested option is not present; however, this
is not considered a failure.

Firmware

4-43

4.8.5 Linking User Initialization/User Test ROM

To link the ROM containing the user initialization/user test routines, use the
following LINK command to generate a ROM image in file ROM_IMAGE.SYS:
$

LINK/SYSTEM=3X20080000/NOHEADER/EXE=ROM
IMAGE.SYS roml.obj,rom2.obj, ...

4.9 Creation and Down-Line Loading of Test Programs
You can write simple test routines, down-line load their executable files (.EXE)
to the rtVAX 300, and run them.

4.9.1 Writing Test Programs

‘

Test routines can be written in VAX MACRO or in any other programming
language that does not call the runtime library (RTL). When compiled and
linked with the /SYSTEM and /HEADER qualifiers, they create an executable
(.EXE) file, as in the following VAX MACRO code sample:
§
$

MACRO/LIST TEST.MAR
LINK/SYSTEM/HEADER TEST.QOBJ

The /HEADER information, which contains the starting address of the
executable code, is automatically attached to the beginning of the .EXE

file. The rtVAX 300’s built-in maintenance operation protocol (MOP) loads the ‘
executable file into memory and jumps to the starting address.

The program is defined as a load file when the network data base is set up. Do
not begin the program’s code with the VAX MACRO .ENTRY statement or its
equivalent in other languages.

The following example shows a VAX MACRO self-looping test program that
allows verification of correct down-line loading:
START:

.end START

brb START

When you power up the rtVAX 300, issue the BOOT EZAQ command to boot
it; the processor loads the test program into memory and runs it. When the
processor halts, it displays the current program counter address, which you
can verify. The address should be 00001800, but it can vary according to the
firmware revision.

Use the HALT instruction to end a test program. The processor halts and
displays the program counter address.

4-44

Firmware

. 4.9.2 Using MOP to Run Test Programs

To set up your network data base for an rtVAX 300 target node, use the
network control program (NCP), defining the target node name, address,
hardware address, and load file, as shown in the example below.
The network data base consists of the following:
*

A permanent data base, which is stored en the system disk. You need
BYPASS privileges to modify the permanent data base; you use the
DEFINE command to make modifications.

A volatile working data base, which is loaded at network startup time from
the permanent data base. You need OPER privileges to modify the volatile
data base; you use the SET command to make modifications.

NCP>
NCP>
NCP>

set node rtv300 hard address 08-00-2B~12-BC-36
set node rtv300
service circuit gna-0
set node rtv300 load file user:|[day]test.exe

If network service is disabled, you must enable it, for example:
NCP>

set

circuit

gna-0

service enable

When you boot from Ethernet, MOP loads and starts the test program.

4.10 Serial-Line Boot Directions
The following directions show how to set up a VMS system for serial down-line
loading of VAXELN system images to an rtVAX 300 target through Channel B
on the DUART.
1.

To load the asynchronous DDCMP driver, execute the following statements

each time the system is booted:
$

RUN SYS$SYSTEM:SYSGEN

SYSGEN>

CONNECT NOA(:/NOADAPTOR

SYSGEN>

“Z

Configure the asynchronous terminal port as a DDCMP port as follows:
§

SET TERM ddcu:

/PROTOCOL=DDCMP

where dd is the device code, ¢ is the controller designation, and u is the
unit number.
Note

To ensure that these procedures are performed on each system startup,

enter the commands in steps 1 and 2 in the system startup file.

Firmware

4-45

3. Determine the DECnet name for the terminal port used to boot the rtVAX ‘
300. To do so, change the third character of the VMS device name (the ¢
in the ddcu: format) from a letter to the number that corresponds to the
letter’s position in the alphabet; then, subtract one from that number.

For example, if the port you are using is TXB4:, convert the third character
(B) to 2 (since B is the second letter of the alphabet), and subtract 1, which
leaves 1.

Take the following steps to build the new device name:
a.

Append a dash (~) to the first two characters of the VMS device name

(the "dd" in the ddcu: format).

Append the digit obtained in step 3 to the resulting string.

Append another dash (-) to the resulting string.

Append the unit number, which is the fourth and following digits of the
VMS device name (the u in the ddcu: format).

‘

For example, the device name TXB4: becomes TX-1-4. The device name
TTA1: becomes TT-0-1. Do not append the colon character (:) to the new
device name.

5. Run the Network Control Program (NCP), as follows:
$

‘

RUN SYSSSYSTEM:NCP

NCP>

Use the NCP SET command to identify the rtVAX 300 node name and
address and to specify the new device name (derived in step 4) and the file
that DECnet must down-line load to the rtVAX 300 when it makes a load
request.

NCP>

name

SET NODE name ADDRESS a.n SERVICE CIRCUIT tt-m-n LOAD FILE file.ext

The DECnet name assigned to the rtVAX 300

a.n

The DECnet address of the rtVAX 300

tt-m~n

The terminal name derived in step 3

file.ext

The name of the system image to be loaded to the rtVAX 300

For an tVAX 300 named RTVAX1 connected to TXB4: to which you need
to down-line load the file MOMS$LOAD:RTVAX300.SYS, you would enter
the following NCP SET command:
NCP>

SET NODE RTVAX1 ADDRESS 1.1 SERVICE CIRCUIT TX~1-4 LOAD -

FILE MOMSLOAD:RTVAX300.SYS

446

Firmware

‘

7. Start the DECnet line using the terminal name derived in step 4, as

follows:

tt-m-n

The terminal name derived in step 3

The line speed to be used (one of 1200, 2400, or 9600 bps for the
rtVAX 300

For example, you use the following NCP SET LINE command to set the

line for device TXB4: at 9600 baud:
NCP>

SET LINE TX-1-4 STATE ON LINE SPEED 9600

Start the DECnet virtual circuit, and instruct DECnet to service load
requests, as follows:
NCP>

SET CIRC tt-m-n STATE ON SERVICE ENABLED

For example, you use the following NCP SET CIRCUIT command to start
the virtual circuit for device TXB4: specified in the previous step:
NCP>

SET CIRC TX-1-4 STATE ON SERVICE ENABLED

Note
Use NCP DEFINE rather than NCP SET commands to save the
information in the nonvolatile data base, where it can be automatically
used whenever DECnet is started or restarted.

4.11

ROM Bootstrap Operations
The ROM bootstrap allows an rtVAX 300 system to execute either out of ROM

or out of RAM, after the system image has been copied from ROM to RAM.

You can specify which RAM bootstrap to use in any of the following ways:
*

By selecting a boot action in the boot register at power up

By using the BOOT command and explicitly specifying any of the ROM
boot devices

By overriding the default boot action in the BOOTDEV register through
software

Firmware

4-47

The ROM bootstrap uses a boot block mechanism that allows flexible placement ‘
of the ROM in either of the two ROM address spaces. To locate a ROM
bootstrap, the rtVAX 300’s resident firmware searches a ROM address space,
looking for a valid page-aligned ROM boot block. When the first six longwords
of any such page contain a valid ROM boot block, the rtVAX 300’s firmware
copies the ROM contents (if selected) and starts execution. Otherwise, the
search continues until the resident firmware has either searched all of the
ROM address space or has found a ROM boot block.
Figure 4-11 shows the format of the ROM boot block.
Figure 4-11
31

ROM Boot Block

24 23
Check

16 15

Any Value

00 gg.
0018 ¢

+00:

Must Be Zero

+04:

Size of ROM in Pages

+08;

Must Be Zero

+12:

Offset into ROM to Start Exacution

+16:

Sum of Previous Three Longwords

+20:
MLO--006373

BB+0:

This word must be 0018;¢.

BB+2:

This byte may be any value.

BB+3:

This byte must be the one’s complement of the sum of the previous three

BB+4:

bytes.

This longword must be 0.

BB+8:

This longword contains the size (in pages) of the ROM.

BB+12:

This longword must be 0.

BB+16:

This longword contains the byte offset into the ROM “vhere execution is

BB+20:

This longword contains the sum of the previous three longwords.

to begin.

The rtVAX 300 supports two ROM address spaces:

4-48

(Cached ROM address space

ROM I/O address space

Firmware

‘

. 4.11.1

Booting from Cached ROM Address Space
Cached ROM address space 1s located in memory space to permit the caching of
any data and instruction references to it. Cached ROM address space provides
254M bytes of addressing. It begins at address 10000000 and ends at address
1FDFFFFF.

Booting from cached ROM address space is selected by the device PRAO. To
speed the search for the ROM boot block, only pages on 16K-byte boundaries
are checked for a ROM boot block.

4.11.2

Booting from ROM I/O Address Space
ROM I/0O address space is located in user I/O space. Any data and instruction
references to ROM located here are not cached.

ROM 1/O address space starts at the base of user I/O space starting at address
20200000. Booting from ROM I/0 address space is selected by the devices
PRBO or PRB1. There is no restriction on the upper bound of ROM 1I/O address
space; however, the search for a ROM boot block is limited to 255 pages and is
done on a page-by-page basis. Bootstrap operations for the two devices PRBO
and PRB1 are identical, except that, for PRB1, the ROM is copied to the first
contiguous piece of good RAM in memory space large enough to hold the ROM
image.

Firmware

449

PS040 4444460490 04854.444
P086.6568.008458448.4449.004
fA 04909004004 060404¢

p4.9.6.6.4.8.0.0.9.660446.6064
).4.49.6.0.6.5.5.8.0.¢4.644
).9.9.5.4.4.4.4.4.9.6.0.64
.9.9.0.9.6.0.0.4.4.64

p.6.9.0.9.4.0.0.4.9
$.0.9.0.6,0.¢.4
XXXXX

XXX
X

XXX}

XXXHXD
EXXXKAXAD
b8.0.0.4.0.6.69
¢
XXX KAXK KA XD
$9.9.9.4.50.06.00060

1$.9.6.80.0.68.86064.94
KXXHXAXX
YA XK XK AKX

XX XK AKX XA XL XA KAXKKX
K

$0.0.0.9.6.0.9.6.9.0.4.098460.64¢.6¢
P 0900008 0.8.09.8064840.98806¢
b0 0000.050.60608.606008088000¢0

B000.00.0.4.00000.4090.9490.48484640.90
$.9.0.0.0.0.6.0.80.08900.0.¢.65.46 806869044

$$.0,:9.8.0.0.0.6.6.900.090069.99085090864é40¢

0000.0000000.0060000009
089044494

§0.0..:.6.0.9:9.0.06.969.80409090.999908¢658099
09.9.8.0.9605.0.0.0.0.08.006000890.0.80690¢8¢8880¢4¢0
F0.0.8.094.90.4.6.0.0.6.06.009.9
0000008 0068080688600¢0
D0.9.0.0.00.0.0.0660.0.060069.80866906998098069.94694
[10.610.6.8.9.¢.0¢.0.¢.0.00.90.0.0.080.6606490088008298684849

00.9.0.9.6.9:0.08806.09009960006809096069.0889109069
064594
$9.0.4.0.9.8.9.0.68.0.986006.090985.0.400.009650.990
650964 EW 89
19,48 688 4340499089006 8.08.89:¢8¢50990 0400680509086

S
Memory System Interface
This chapter provides the technical information necessary to design a RAM
memory system for the rtVAX 300 processor. A 4M-byte DRAM memory array
and controller design is presented as an example. Design illustrations are
included at the end of this chapter.

This chapter discusses the following topics:

Memory speed and performance (Section 5.1)

Static and dynamic RAMs (Section 5.2)

Basic memory interface (Section 5.3)

(Cycle status codes (Section 5.4)

Byte mask lines (Section 5.5)

Data parity checking (Section 5.6)

Internal cache control (Section 5.7)

Memory management unit (Section 5.8)

Memory system design example (Section 5.9)

Memory timing considerations (Section 5.10)

Memory system illustrations and programmable array logic (Section 5.11)

Memory System Interface

5-1

5.1 Memory Speed and Performance
The system performance of the rtVAX 300 system is linked to the performance

of the memory system. Most bus cycles are used to access memory, because
memory contains both the application instructions and data that the rtVAX
300 is processing.
In turn, the rtVAX 300 memory system performance depends on the speed or
access time of the RAM memory devices used. In general, the cost of memory

devices is directly proportional to their speed and size. Static RAMs generally
provide the fastest access time; however, they are more costly and less dense

than dynamic RAMs (DRAMs). The memory system speed must be weighed
against the cost of the memory elements to determine the type of memory
devices which are used.
To improve its performance, the rtVAX 300 processor contains a 1K-byte cache.
This cache has a very high hit rate (greater than 70% for some applications)
and allows the rtVAX 300 to read a longword in one microcycle. This cache
helps to provide very high performance with relatively slow external memory,
by satisfying many of the required processor read operations in one microcycle.
The best processor performance is still realized with the fastest memory
system, so the memory system should be designed to be as fast as practicable.

5.2 Static and Dynamic RAMs
The memory system can be constructed from either static or dynamic RAMs.

Dynamic RAMs provide more storage at a lower cost per bit than static RAMs,
and they also require less PC board space for the same density. Static RAMs
store data more reliably than dynamic RAMs, because the data is stored in
a latch and not as a charge on a capacitor. Static RAMs have faster access
time than dynamic RAMs. Dynamic RAMs require refresh cycles to retain the
stored data and also require address multiplexing and precise strobe timing.
Thece requirements complicate the design of a memory controller for DRAMs.
Once the size of the external memory system has been determined, the type

and speed of the memory elements must be defined after weighing all of the
factors mentioned above. If performance is the only issue and cost and size are
less important, fast static RAMs are the better choice. If cost, size, and power
consumption are big concerns, dynamic RAMs are the better choice. For most
applications, the slower, less expensive DRAMs are a good choice, because the
rtVAX 300 performance is greatly enhanced by its internal cache.

5-2

Memory System Interface

. 5.3 Basic Memory Interface
The rtVAX 300 can access up to 256M bytes of physical memory and up to
510M bytes of memory-mapped 1/O. The physical memory addresses are in the
range of 00000000 to OFFFFFFF. Appendix C lists rtVAX 300 addresses.
The device address is first multiplexed onto the DAL<31:00> bus, and the

data is then transferred through that same bus. This reduces the number of
external pins on the rtVAX 300 processor module; however, it requires the
addition of external latches to store the device address for the duration of the
bus cycle. Other bus cycle information must also be latched, such as the WR L,

CSDP<«4:0> L, and sometimes the BM<3:0> L lines. The latches must hold the

bus cycle and address information while AS L is asserted.

When the rtVAX 300 attempts reading from or writing to memory, it first
places the memory’s physical address on DAL<29:02> H. DAL<01:00> H are

unused at this time, and DAL<31:30> H indicate the number of longwords that
are to be transferred. Table 54 shows the codes for DAL<31:30> H and the
number of longwords that are to be transferred.
The 28-bit address provided by the rtVAX 300 on DAL<«29:02> H is a longword

address that uniquely identifies one of 268,435,456 32-bit-wide memory

locations. The rtVAX 300 provides four byte masks, BM<3:0> L, to facilitate
byte accesses within 32-bit memory locations. The rtVAX 300 imposes no

restrictions on data alignment. Any data item, regardless of size, may start at
any memory address, except the aligned operands of ADAWI and interlocked
gueue instructions.

Any rtVAX 300 read or write falls into one of the following categories: byte
access, word access within a longword, word access across longwords, aligned
longword acress. or unaligned longword access. Quadword and octaword

accesses a

within a 1

accesses th.

~cur on longword boundaries. Byte accesses, word accesses

'nd aligned longword accesses require one bus cycle. Word

uss a longword boundary and unaligned longword accesses

require two bus cycles. Table 51 lists each transfer and the type and number
of bus cycles required for the transfer.

Memory System Interface

5-~3

Table 5~1

rtVAX 300 Data Transter and Bus Cycle Types

Type

Number
of Bytes

Transferred

Number of

Bus Cycles

Type

Byte

Longword

Aligned word

Longword

Unaligned word

Longword

Aligned longword

Longword

Unaligned longword

Longword

Aligned quadword

Quadword

Aligned octaword

Octaword

Data Transfer

Bus Cycle

5.4 Cycle Status Codes
The CSDP<4:0> L lines indicate the type of transfer cycle that is taking
place. Note that the address decoder for memory must include the CSDP<4:0>
L cycle status information to prevent accidental memory access during an
interrupt acknowledge cycle, an IPR access cycle, or an rtVAX 300 internal

access cycle. Interrupt acknowledge cycles are performed in the same way as
a memory read cycle; however, CSDP<4:0> L reads 1X0115. In addition, IPR
access cycles are performed in the same way as a memory read cycle; however,
CSDP<4:0> L reads 1X010y. Lastly, during rtVAX 300 internal access cycles,
CSDP<4:0> L reads 0XXXX,. Thus, if CSDP<4:0> L indicates an interrupt
acknowledge cycle, an IPR access cycle, or an rtVAX 300 internal access cycle,
do not allow the memory controller to perform a memory access cycle, although

the longword address on DAL<29:02> H is within the system RAM space.
The remaining codes are useful for implementing a multiple processor system

(to lock and unlock dual-ported memory); however, most simple applications
need to decode these lines only to determine when the rtVAX 300 is running an
interrupt acknowledge cycle or an IPR access cycle. If an IPR (accessed with
MTPR and MFPR instructions) is implemented externally—such as IPR 37,
the I/O reset registers—the IPR read and write codes must be decoded to select
the IPR. The read lock code could be used to set a flop that locks the memory
subsystem to prevent auxiliary processors from accessing it with interlocked
instructions. The write unlock code could then be used to unlock memory by
resetting that flop. If the rtVAX 300 is the only device that can access system
memory, the lock and unlock cycles can be ignored.
Table 2-5 lists the cycle status symbols.

5-4

Memory System Interface

. 5.5 Byte Mask Lines

The data path of the rtVAX 300 is 32 bits wide. Byte mask lines indicate which
byte(s) the processor is accessing.

Memory is viewed as four parallel 8-bit banks, each of which receives the
longword address in parallel on DAL<29:02> H. The address placed on
DAL<29:02> H is a longword address, and the byte masks are used to select
the bytes within that longword that are being accessed. Each bank reads or
writes one byte of the data bus DAL<31:00> H when that byte’s byte mask
signal is asserted, as shown in Figure 5-1. Byte mask lines BM<3:0> L must
be latched on longword and quadword cycles and flow through on octaword

cycles; they need be used only during write cycles. During write cycles, the

byte masks must be used to select only the byte(s) in memory indicated by
asserted byte masks. If a byte with an unasserted byte mask is written to, the
data in that location will be corrupted.
Figure 5-1

Memory Organization
DAL<07:00>

DAL<29:02>
:

DAL<15:08>
DAL<23:16>

_B_M..<°_>__.

DAL<31:00>

Bank0
DAL<31:24>

._B_M.flz_....

Bank 1

BM<2>
.1

Bank2

BM<3> —wf
"
Bank3

MLO-0" 1426
Note

Valid parity must be placed on each CSDP<3:0> L line during a read
cycle, regardless of the assertion of BM<3:0> L, if DPE L is asserted.
Therefore, use the by te masks only for write cycles and select all 4

Memory System Interface

5-5

bytes during read cycles. This parity information is required for proper
functioning of the Ethernet controller.

The rtVAX 300’s Ethernet controller can use octaword transfer cycles when
transferring to nonoctaword-aligned buffers in memory. This forces the byte
mask lines to change state during octaword transfers. The Digital-supplied
VAXELN device driver always sets up transmit and receive buffers on page
boundaries, so that all octaword transfers occur on octaword boundaries. Thus,

the byte mask lines will not change during octaword transfers when using the
Digital-supplied Ethernet device driver.
Although Digital does not recommend this, users can write their own Ethernet
device driver and use nonoctaword-aligned buffers. Digital has tested

device drivers that use nonaligned buffers and has found they have poorer
performance than those that use aligned buffers. Nonaligned buffers require
that memory controllers connected to the rtVAX 300 write only to bytes whose
byte mask lines are asserted for each longword that is transferred.

To handle octaword transfers to nonaligned buffers correctly, you must not
latch the byte mask lines. They must be able to enable CAS line assertion of
the DRAMs during each longword that is transferred directly. Longword and

quadword transfer cycles require that the byte mask lines be latched during
the address transfer portion of the memory access cycle.
The BM<3:0> L lines of the rtVAX 300 must be connected to a separate 74F373
latch. The HOLD L line of this latch cannot be connected directly to the AS
L signal of the rtVAX 300. Decoding logic which decodes LADDR<31:30> is
used to gate the HOLD L input of the address latches with the AS L line of the

rtVAX 300.1 Figure 5-11 schematically represents this logic.
Note

Modules that have been designed to latch the byte mask lines under

all conditions work correctly with current Digital-supplied VAXELN
Ethernet device drivers. Digital recommends that all future designs
implement the selective byte mask latch, as described above. Selective

byte mask latching is required by users who write Ethernet device

drivers that place buffers on nonoctaword-aligned boundaries or
support continuous address buffer chaining without a 16-byte buffer at
the end of each buffer.

5-6

LADDR<31:30> are asserted during octaword transfer cycles.

Memory System Interface

. 5.6 Data Parity Checking

To monitor the data integrity of the DAL«31:00> H bus, parity bits are

provided with each byte. The parity bits are driven onto CSDP<3:0> L during
write cycles while the data is driven onto the DAL<31:00> H bus. During
read cycles, the CSDP<3:0> L lines must be driven with valid parity while
the DAL<31:00> H bus is driven with the data. The odd bytes (DAL<31:24>,
<15:08> H) are driven with odd parity, and the even bytes (DAL<23:16>,
<07:00> H) are driven with even parity. If the CSDP<3:0> L lines are not

driven with valid parity during a read cycle when DPE L is asserted, the
rtVAX 300 performs a DAL parity error machine check, as described in

Table 3-11. If the Ethernet controller was bus master at the time of the error,
the CPU will be interrupted and will not performm a machine check.

To accommodate peripherals that do not generate or check parity, the DPE L
line is provided to cause the rtVAX 300 to ignore DAL parity. DPE L must be
driven along with the data during a read cycle; if it is driven low, the rtVAX
300 checks the parity on all 4 bytes, regardless of the assertion of BM«3:0>
L; if it is driven high, the rtVAX 300 ignores the data parity information.
Table 5-2 lists the parity bits and byte mask lines associated with the 4 bytes
of the DAL<31:00> H bus. Proper parity is required only when the DPE line

is being asserted. Read cycles from devices residing in the 1/O space do not
require parity generation.

Table 5-2

rHVAX 300 DAL Parity and Byte Masks

DAL

Byte
Mask

CSDP

Parity
Type

07:00

Even

15:08

Odd

23:16

31:24

Even
Note

The CSDP<4> L signal is used only to indicate an internal cycle and
not as a parity bit.

Memory System Interface

5-7

5.7 Internal Cache Control

The rtVAX 300 provides the CCTL L signal to allow external control of the 1K

internal cache. If this line is asserted (driven low) during the data transfer of

a quadword read cycle, the data read is not stored in the internal cache. In
addition, the rtVAX 300 aborts the quadword read cycle after the first longword
has been read when the CCTL L line is asserted. If this line is unasserted
(driven high) during the data transfer of a quadword read cycle, the data read
is stored in the internal cache. To improve processor performance, this line
should be driven high during a memory read cycle to allow read references
to be internally cached. I/O devices generally drive this line low during read

cycles to prevent internal caching of volatile I/0 data. Reads from the I/O

space (20000000 to 3FFFFFFF) are not cached internally, regardless of the

‘

state of CCTL L.
In applications containing multiple processors or a secondary cache, the CCTL

L line is manipulated to maintain internal cache consistency. The designer
may want to segment system RAM into cacheable and noncacheable address
ranges. This can be accomplished through the manipulation of the CCTL L
line after the address is decoded.

memory, the internal cache entries corresponding to modified memory locations .
When external devices perform DMA to the rtVAX 300 private external

must be invalidated. This is accomplished by running a conditional cache

invalidation DMA cycle. This cycle begins by asserting the CCTL L line before
the DMA address during the DMA write cycle. (See Figure 8-19.)
Each conditional invalidate cycle causes the rtVAX 300 to detect a collision on
a quadword cache entry. Two consecutive conditional invalidate cycles can be

used to detect a collision on a naturally aligned octaword. To maintain cache
coherency, a detected collision invalidates that entire quadword within the

rtVAX 300 internal cache.

The Ethernet controller can issue longword write cycles. To maintain CPU
cache consistency, the Ethernet controller asserts CCTL L at the beginning of

the write cycle to start a quadword cache invalidation cycle. Cache invalidation
cycles require at least 4 microcycles; therefore, if CCTL L is asserted at the
beginning of the write cycle, the memory system must add two wait states
(a total cycle time of 400 ns) to the cycle by holding off the assertion of RDY
L. If CCTL L is not asserted at the beginning of the write cycle, this is a
CPU longword write cycle, and zero or one wait state (200 or 300 ns) memory
access can be applied. All DMA devices that use cache invalidation cycles to
maintain internal cache consistency must adhere to the cache control timing
specifications shown in Figure 2-17.

5-8

Memory System Interface

. 5.8 Memory Management Unit
To facilitate multitasking and to ease program development, the rtVAX 300
supports virtual memory. The internal memory management unit (MMU) of
the rtVAX 300 processor translates virtual addresses to physical addresses.
Since the MMU resides within the rtVAX 300, only physical addresses appear
on the DAL<29:02> H bus. Thus, the memory system design is simplified,

and the memory subsystem is directly addressed by the rtVAX 300 processor.!
The VAX Architecture Reference Manual provides more information on
virtual-to-physical address translation of the MMU.

. 5.9 Memory System Design Example
The remainder of this chapter discusses the design of a 4M-byte DRAM
memory system for the rtVAX 300. This memory system consists of the
following elements:

Address and cycle status decoders

Address latches

Refresh request timer

Thirty-six 1M-bit DRAMs (32 for data and 4 for parity bits)

DRAM row and column address multiplexer

DRAM data latches

Meniory controller state machine

Figure 5-2 shows a simplified diagram of the memory controller logic. Read,

write, and refresh memory operations are sequenced by the memory controller.

5.9.1

Address Decoder
The rtVAX 300 places a 28-bit longword address on the DAL<29:02> H bus
at the beginning of a memory access cycle. This address must be decoded by

an address decoder to provide a select signal for the memory controlier. All
physical memory must be mapped at the lowest possible memory addresses.
Physical memory must also be contiguous and 32 bits wide. Therefore, if a IMbyte memory array was constructed, it must be mapped to locations 00000000
through 000FFFFF.

Memory system design is similar to that of a nonvirtual-addressed processor.

Memory System Imerface

5-8

[*zez=vaWvai3s
EoHeOnVaANiI[l.\D
<ZHA¥0V:A1N2)>HA V1 <0:6>HAaVXN

s<s0yY'v>340SD|BZIgesUyqaDoiIoepY.]OsyUASLE>HAsqQY<QE J8joNuo] ,EHAVY aB9usdiwBeagy “<0:6>HQAYNVHG

<0E'LE>IWVQ| 85aip y

<zZ12>Wwo

e—

1sd ojelS-d vded

sexeiduny

LRUNOJ/MOY

2{6oy
WvHa 832.10pY

<c:e>svonva ~
—————— 3119340 §s1pue0auq 1 02

jwLsz:aeiujoe—bsndiowABusgbaneqipjns4yqg
cHaavi

3UHMWYHGT

i-sS|YfHNlV.HA 30°*LY)

W210iALmQ

eleig

5-10 Memory System Interface

numoi———

ouIYoBY

AGYIHAVEG- SVOEN3

EysLesEjeoynLjo]swenyb)eay !119

f———

|soro2sn8g043

Full memory address decoding must be implemented to prevent multiple

mapping of memory. This is necessary because the firmware begins at location
00000000 and uses a binary search algorithm to ascertain the configuration of
memory for sizing and initialization. Nonexistent memory is detected when
the memory controller does not assert the RDY L line. The rtVAX 300 internal
timer times out, and the memory sizing finishes with the highest responsive
location marked as the top of memory. The stacks are set up, and the rtVAX
300 is able to boot.
If full memory address decoding was not implemented, the initialization
firmware would find an invalid top of memory. This would cause the stack to

write over free process pages and the rtVAX 300 to fail when it tries to boot.

The decoder can be implemented in a registered PAL, as shown in Figure 5-9.
In this configuration, DAL<29:22> H are fed into the inputs of the PAL. For
memory access, all of these bits must be zero. The PAL'’s internal flip-flop
latches the output of this decoder, SELRAM, at the rising edge of AS H. The
SELRAM signal will remain valid throughout the entire bus cycle, until AS H
deasserts.

The CSDP<4:0> L bits must be decoded to prevent them from enabling
memory when the rtVAX 300 is executing an interrupt acknowledge cycle or

an externally implemented internal processor register access cycle. Disable
memory during these two cycles; Table 5-3 lists their bit assertions.
Table 5-3

rVAX 300 CSDP<4:0> IPR and IACK Codes

CSDP«<4> CSDP<2>

CSDP<1> CSDP<0>

Bus Cycle Type

External IPR read or write

External interrupt acknowledge

rtVAX 300 internal cycle

5.9.2 Address Latches
The rtVAX 300 uses a time-multiplexed data and address (DAL) bus. Address
latches, such as the 74F373, must be connected to the DAL lines, and the
HOLD line of these latches must be connected to the AS line. This latched
address can then be fed into the address inputs of the memory elements. Also,
the WR L and BM<3:0> L lines must be latched. (Figure 5~11 shows the
connections of these latches.)

Memory System Interface

5-11

5.9.3 DRAM Memory Refresh

Each bit of data stored in a DRAM memory element is stored as a charge in a
very small capacitor. Through time, this charge is bled from these capacitors,
so each bit must constantly be refreshed to retain the stored data. Special
access cycles are defined for the DRAMs that refresh an entire row of data
bits. The 1M-bit DRAMs used in this example contain 1,048,576 bits divided
into 512 rows, each containing 2048 data bits. Thus, it takes only 512 refresh
cycles (one for each row) to refresh every bit within the DRAM.

The specifications for the 80 ns page mode DRAMs require that every row
of the entire DRAM array be refreshed every 8.0 ms. The rows can all be
refreshed in sequence every 8.0 ms, or one row can be refreshed every 15.6 ns
(8.0 ms/512 rows). The 8-bit counter shown in Figure 5-15 sets the refresh
request SR latch every 12.8 ps, and the memory controller then refreshes a row
of the DRAMs and resets the SR latch. In this scheme, a new row is refreshed
every 12.8 ps, so the entire DRAM is refreshed every 6.6 ms (512 x 12.8 ps),
and the refresh requirements are met.
Before a refresh cycle can occur, a refresh row address must be generated. This

address is latched into the DRAMs, and each bit cell in that row is refreshed
during the refresh cycle. The DRAMs that were used generate their own

refresh address internally, simplifying the external logic by eliminating the

strobe (CAS) before row address strobe (RAS) refresh internaily generate their
own refresh row address. When the DRAM CAS line is asserted before the
RAS line, the internal refresh row address counter is incremented, and the
next row is selected. When the RAS line is then asserted, the selected row
of bit cells are refreshed. RAS and CAS are then deasserted, and the refresh
cycle is complete. An external refresh address counter, whose outputs are
multiplexed to the DRAMs address lines, must be added if the chosen DRAMs
do not support CAS before RAS refresh.

‘

need for a refresh row address counter. DRAMs that support column address

5.9.4 DRAM Row and Column Address Multiplexer
All DRAMs have a multiplexed row and column address bus. This means that
half of the address of any bit is driven onto the DRAM address bus at one

time. For example, to read one cell within the DRAM, half of the address of

that bit is driven onto the DRAM address bus.! Next, the RAS is asserted, and
the second half of the address (10 bits) is driven onto the DRAM address bus.
Next, the CAS is asserted, and the output driver is turned on. After the DRAM

access time delay, data that is stored in the addressed cell is driven at the
DRAM’s data output pin. Once the data has been transferred to the processor,
!

5-12

Half the address equals 10 bits, because the 1M-bit DRAMs require 20 bits of
addressing.

Memory System Interface

the RAS and CAS lines are deasserted, and the DRAM'’s output is tri-stated.
RAS must remain deasserted briefly to allow for internal DRAM precharging.
A multiplexer, such as the 74F711 shown in Figure 5-3, is needed to multiplex
the row and column address onto the DRAM address bus. Because the address
bus of each DRAM is connected to the output of this multiplexer, high current
output drivers are needed to drive the high-capacitive inputs of the DRAMs.
This will prevent excessive propagation delay. The 74F711 multiplexers
provide sufficient drive current to drive the address bus of the DRAMs directly.
If the 74F258 multiplexer is chosen, high current drivers, such as the 74F244,
are needed to drive the high capacitance of the DRAM address bus.
The rtVAX 300 supports multiple longword memory access cycles. During
quadword and octaword transfer cycles, the rtVAX 300 places only one
longword address on the DAL bus at the beginning of the transfer cycle.
The memory system must generate the correct number of longwords in the
correct order. The subsequent longword addresses are generated by adding
the F86 XOR gates between the two lowest order column address inputs of the

74F711 multiplexer. The assertion of the other input of the two F86 gates will
cause the associated column address bit to invert.

DAL<31:30> H indicate the number of longwords to be transferred. Table 54
lists the codes for DAL<31:30> H and the number of longwords that are to be
transferred.

Memory System Interface

5-13

eoepelu| weisAg Alowepy pL~§

Figure 5-3 Sample Design: DRAM Address Path
RAS, WRITE and CAS DRAM Array Drivers

Row/Column DRAM MUX
5X%2 MUX

74F7T11

LADDR<21> H
LADDR<11>H

MUXADDR<«9> H

MUXADDR<8> H

DRAMADDR<8> H

MUXADDR<7> H

DRAMADDR<7> H

MUXADDR<6> H

ORAMADDR<6> H

MUXADDR<S> H

DRAMADDR<5> H

LADDR<20> H

1D-D FD

{ADDR<c10>H

18 0D-D

LAODR<198> H

1D-C FC

Octal
Bufler

ORAMADDR<9> H

$2
1D-E FE
3lop.E

74F244

LADDR<18> H

1D-B FB

2
1D-A FA
opA

LADDR<17> H
LADDR«7> H

—JOE

LADDR<¢16> H
LADDR<E> H

12
ID-E FE
(] P

LADDR<15> H
LADDR<S> H

14
10-D FD
(L] Py

MUXADDR<3> H

DRAMADDR<3> H

MUXADDR<2> H

ORAMADDR<2> H

L] Py

LADDR<13> H
LADDR<3> H 4y 72

INVADDR3I H

8)]F86

LACDRe«2> H

INVADDR2H 2j/F86
SELCOL L

1D-C FC

[
\o

19
1D-B FB
ELT s

MUXADDOR<1> H

ORAMADDR<1> H

2HDA EA

MUXADDR<0> H

DRAMADDR<0> H

Yoo-a

{70

Selact

7] Invert

vV
A

DRAMWRITE L

DRAMCAS L

4BF

DRAMADDR<4> H

MUXADDR<4> H

LADDR<4> H

ORAMRAS L

Jen

T4F711

LADDR<i4> H

| oslg

5X2 MUX

2K 0

Octal
Butfer

wereL

———|—1CI invert

A8V — AN

—Y

74F244

Select

EL] P

LADDR<8> H

LADDR<12> H

1 deN

Blon.c

LADDR<O> H

sls

RAS L

Octal
Driver
74F244

VYV

CAS<3> L

olas

CAS<2> L

[

CAS<1> L

CAS<0> L

2 AD

YOO ———VWW
2

Y2 f———— A
hA

——

Z>tL
DRAMCAS<——

DRAMCAS L

]

DRAMCAS<O> L

r—'—C EN

- OE

R31!

100

MLO-004428

Table 5-4

Memory Read Cycle Selection

DAL

Longwords

Cycle Type

Longword read or write

Quadword read cycle (CPU)

Octaword read or write
cycle (Ethernet)

Transferred

The memory controller looks at LADDR«31:30> to see the transfer cycle type
and subsequently asserts INVADDR<3:2> to generate the necessary longword
addresses during muitiple longword transfer cycles.

5.9.5 4M-Byte DRAM Array
The memory system for the rtVAX 300 must be 32 bits wide. If parity memory
is desired, 4 bits must be added, so that each hyte has 1 panty bit. Most
DRAMs are a single bit wide, so 36 DRAMs are needed to implement parity

memory. DRAM packs, which are 8 or 9 bits wide, could also be used.
Note

During Ethernet controller read cycles, proper parity must be generated
in CSDP«3:0> L for each longword read, if DPE L is asserted.

The scheme that is used to satisfy multiple word transfers requires that the
DRAMSs support page mode access. For example, when a quadword read

cycle is performed, the address of the preferred longword is first placed on
the DAL<29:02> H bus, and DAL<31:30> H read 105. The rtVAX 300 then
asserts AS, and the address is latched by the address latches. The row address
ripples through the F711 MUX and appears on the DRAM address bus. The
decoder is asserting the SELRAM and deasserting the IACKIPR signal. The
memory controller now asserts RAS, and the row address is latched into the
DRAMSs. The address MUX select latch then asserts the SELCOL signal,
driving the column address onto the DRAM address bus. Now, the memory
controller asserts ENBCAS, waits for the access time of the DRAMs, and
asserts DRAMREADY. The first longword is now latched into the data latches
shown in Figure 5-14, and the ENBCAS line is deasserted. The INVADDR2
line is now asserted, driving the next longword address onto the DRAM
address bus. Now, the ENBCAS line of the DRAM is reasserted, and the next
longword appears at the data latches. DRAMREADY is reasserted, the second
longword is transferred, and the access cycle is complete.

Memory System Interface

5-15

If page mode access is not supported by the DRAMs, the row address would

have to be restrobed into the DRAMs for the second longword and the memory
performance would suffer.

5.9.6 DRAM Terminaiing Resistors
The very fast rise and fall times of the DRAM’s address, RAS, CAS, and
WE lines have some very high frequency components associated with them.
When one of these signals changes state, the voltage change has to travel
down the PC board trace. The trace acts like a transmission line to very high
frequencies, and the impedance of this line may not be uniform. A reflection
occurs when a signal encounters a change in impedance. These reflections
cause signal overshoot and undershoot, where the line voltage bounces above
5.0V or below 0.0V. Signal reflections deteriorate the signal transition edges; in
a clock signal, this could affect which time data is strobed; in the case of data,
this could affect when the signal can be sampled.
Most TTL gates can handle a small amount of overshoot and undershoot,
DRAMs are easily damaged by excessive overshoot and undershoot. These
memory elements have a specification for the amount of undershoot that can
safely be tolerated. If this value is exceeded, the DRAM can corrupt its stored

data or can be damaged permanently.

Many techniques can be used to reduce the amount of overshoot and
undershoot that the DRAM experiences. The RAS, CAS, WE, and address
lines connecting to the DRAMs must be made as short as possible to reduce
the lines’ inductance and capacitance. These lines should be daisy-chained to
all of the connection points. Series-dampening resistors should be added to all
of these lines as close to the MUX outputs as possible, as shown in Figure 5-3.
The DAL and strobe signal lines of the rtVAX 300 are driven by an ACTQ
244 or ACTQ 245. Thrse CMOS drivers can also generate a fair amount

of overshoot and undershoot. Therefore, it is good practice to add series

termination resistors for these lines on the application module to improve
signal integrity. These resistors slow the rise and fall times of the DRAMs,

reducing the reflections. The value of these resistors is determined by

measuring the overshoot and rise time of these signal lines on the actual
PC be=rd prototype. The resistor value should be the lowest that gives an
undershoot voltage below that tolerated by the DRAMs that are used. Shunt
resistors can also be used at the end of these lines as terminators.

5-16

Memory System Interface

' 5.9.7 DRAM Data Latches

The latches shown in Figure 5-14 store data for processor reading, while
the next longword is accessed in the DRAMs. This overlapping improves the
performance of the memory system for multiple longword transfer cycles.

When the data for the first longword is valid, the memory controller asserts
DRAMREADY. This sets the ready hold latch (see Figure 5-15) and asserts
the RDY L line of the rtVAX 300. This latch is cleared when the rtVAX 300
deasserts the data strobe (DS) line. When the RDY L line is asserted, the
data that was present at the DRAM outputs is latched and driven onto the
DAL bus. Once the data has been latched, the CAS hold latch can deassert
the CAS<3:0> lines of the DRAMs, and the memory controller can assert the
INVADDR?Z line to generate the next longword address. The memory controller
reasserts the ENBCAS line, asserting the CAS<3:0> lines and driving the next
longword data into the inputs of the RAM data latches. When the processor
finishes transferring the first longword, the second longword is latched into the
data latches.
Caution

The RDY L, ERR L, and CCTL L lines are tri-stateable lines. These
lines are pulled up by resistors in the rtVAX 300 and must be driven by
a tri-stateable driver, such as the 74F125. If tl ese lines are driven by
a standard TTL totem pole output, the rtVAX 300 will not function.

These latches can be eliminated; however, the memory controller state machine
must be redesigned and quadword read cycles take one more microcycle,
with the consequent reduction of memory system performance. The rtVAX
300 octaword access cycle always requires at least two microcycles for each
longword that is transferred; memory performance and longword read cycles
are not improved by these latches.

5.9.8 Memory Controller State Machine
The memory controller state machine diagram has the following responsibilities:

Arbitrate between refresh requests and memory access (refresh requests
have priority)

Execute refresh requests by cyvcling the REFCYC, ENBCAS, and RAS lines

Memory System Interface

5~17

e Ezxecute memory access cycles by cycling RAS, ENBCAS, DRAMREADY, ‘
and INVADDR<3:2>

Provide the precise timing that is required on the DRAM RAS and CAS

lines
Refer to Figure 54 for the following discussion.
Every 12.8 ps the refresh counter asserts its TC L output. This sets the refresh
request latch shown in Figure 5-15. The latch asserts the REFREQ input of

the memory controller. The controller now jumps to the STARTREFRESH state

and asserts ENBCAS and REFCYC, asserting every DRAM CAS line. The

assertion of REFCYC

clears the refresh request latch, deasserting REFREQ.

‘

Next, the memory controller asserts RAS, waits one clock tick, and deasserts
ENBCAS and REFCYC. The state machine now jumps into the FINISHUP
state and deasserts RAS, so the refresh cycle is now finished.
The AS signal of the rtVAX 300 is synchronized by the address strobe
synchronizer latch, as shown in Figure 5-15. This is necessary, because AS
deasserts just before the rising edge of CLKA, possibly causing the state
machine to missequence. By synchronizing AS with CLKB, SYNCHAS

deasserts after the rising edge of CLKA.
Note

The setup time of the state machine must be met on all unmasked
inputs to prevent missequencing.

During a memory access cycle, SYNCHAS and SELRAM are asserted, while

IACKIPR is deasserted. When these conditions are true and REFREQ is
unasserted, the memory controller state machine jumps to the STARTACCESS

state and asserts RAS. The row address has been latched by the DRAMs, and

the SELCOL line is asserted by the address MUX select latch when CLKA

deasserts. The column address of the first longword is placed on the DRAM
address bus. Next, the controller ensures that the DS line is asserted and
then asserts the ENBCAS signal. If this is a write cycle, ENBCAS is then

deasserted and DRAMREADY is asserted. The state of INVADDR<3:2> is
incremented, creating the DRAM column address for the next longword. Next,

the state of INVADDR<3:2> is compared to LADDR<31:30> to determine if the
last longword has been transferred. If that was the last longword, the state

machine jumps to the FINISHUP state, deasserts all outputs, and waits the
RAS precharge time before it allows another memory access.

5-18

Memory System Interface

. Figure 5-4 Sample Design: Memory Controller Sequence
]

DRAMREADY-

ENBCAS+

WRITECYCIL]

IDLE

REFCYC-

READ

ENBCAS-

FhT.A(ES+D +
DR AMREADY

ACCESS

INVADDRI1.

LAG

INVADDR2.

REFREQ
# RST

READGVYGT L]

MEMORY

DRAMRCEASDY+

ENBCAS-

ACCESS

FLAG+

r-—-——-—--Yos

¥
|

]

STARTREFRESHL]
i

ENBCAS+

;

REFCYGy

FINISHUP

STARTACCESH.]

INVADDR2-

RAS+

INVADDR3-

ENBCAS.

MEMORY

RAS-

ACCESS

DRAMREADYREFCYC-

T
'

»Yes

REFRESHCYC
L] |

WRITECYC2L]

RAS+
ACCESS

ENDREFRESHL]

ENBCAS-

hfi:ct&sg

[Yes

READCYC2

]

{

DRAMREADY.

DRAMREADY-

MEMORY

ENBCAS+

oS
—»|No

{

WRITECYC3
L]

1
3

Yes

\
Y

Yes

MEMORY ACCESS = SYNCHAS & IACK & SELRAM

ATEEvETT

WRITE ACCESS = P4 & LWRITE

DRAMREADY
s |—

READ ACCESS = !P4 & ILWRITE & (!FLAG # IDS)

ENBCAS+

EQU1 = lINVADDRR2 & INVADDR3 & LADDR<30> & ILADDR<31>
EQU2 = INVADDR2 & !INVADDR3 & L ADDR<30> & LADDR<31>
EQU3 = INVADDR2 & INVADDRS3 & !LADDR<30> & ILADDR<31>
EQU4 = INVADDR2 & INVADDR? & LADDR<30> & LADDR<31>
* INVADDR2 = INVADDR2

** INVADDRS3 = (INVADDR2 & INVADDR3) # ({NVADDR2 & lINVADDR3)
MLO-008387

If another longword is required and it is a write cycle (LWRITE is asserted),

the state machine jumps toc WRITECYC2 and deasserts DRAMREADY. The

state machine then waits for DS to deassert and jumps to WRITECYC3. Once

DS asserts, the state machine jumps to WRITECYC4 and asserts ENBCAS

Memory System Interface

5-19

and DRAMREADY. The machine then increments INVADDR<3:2>, driving

the address of the next longword onto the DRAM address bus. The state
of INVADDR<3:2> is compared to LADDR<31:30>, and the cycle repeats if

another longword is needed.

If another longword is required and it is a read cycle (LWRITE is deasserted),
the state machine jumps to READCYC2, deasserts DRAMREADY, and asserts
ENBCAS, driving the next longword into the inputs of the RAM latches. When
DS deasserts and the rtVAX 300 processor has latched the previous longword,
the state machine jumps into the READCYC1 state, and the process repeats
itself until the last longword is read.

Table 5-5 lists all transfer cycles along with the order of the longwords that
are transferred.

Table 5-5

Quadword and Octaword Read Cycle Transters

rtVAX 300

Memory Address

Latched Address
LADDR

‘

DRAMADDR

Longword

Transferred

Quadword

First

Second

First

Second

First

Second

Third

‘

Octaword

Fourth

After AS and DS have been asserted, the rtVAX 300 processor waits for the
assertion of RDY L, indicating that the memory or device has transferred the
data. Wait states of one microcycle are added to the I/0 or memory access cycle
until the memory controller asserts RDY L. If RDY L is not asserted 16 to 32
ps after the assertion of AS, the rtVAX 300 completes the access cycle, indicates
an error condition, and transfers operation to an error-handler routine. This
action prevents the rtVAX 300 processor from stalling when a read or write
request is directed to a nonexistent I/O device or memory location.

5-20

Memory System Interface

‘

. 5.10 Memory Timing Considerations
The memory subsystem of the rtVAX 300 must satisfy some special timing
requirements. (Table A-3 lists these requirements.)
Note

The rtVAX 300 read and write timing specifications must be followed

explicitly. Any timing parameter that is not within specification can
cause intermittent or complete memory system failure.

The PLUS405—45 logic sequencer controls the timing of all the memory control
signals. This sequencer is clocked on the rising edge of CLKA; therefore, all
outputs of the state machine will change 12 ns after the rising edge of CLKA.

5.10.1

Calculating Memory Access Time
The rtVAX 300 accommodates slower memory and peripherals by providing the

RDY L input. The accessed peripheral can add any number of wait states into
the access cycle by holding off the assertion of RDY L. Each wait state is one
microcycle long; the processor will wait up to 32 ps until it times out. When
calculating the speed of the memory elements, first determine the number of
wait <tates.

If you are operating with one wait state, data must be valid 28 ns before the
second rising P1 edge. The access time of the DRAMs is specified from the

time that the RAS line is asserted. The sample memory controller will assert
the RAS line 12 ns after the rising edge of P3. The RAS driver delay must also
be added along with the 74F374 latch delay; thus, the access time from RAS is

as follows:
+ 3.0 x CLKA period
— Data setup time
— Memory controller delay

— RAS driver delay
- Latch delay
Access time
In this case, access time =3 x50 ns -~ 28 ns - 12 ns - 5 ns — 7 ns = 98 ns.

Therefore, during a read cycle with one wait state, data must become valid 98
ns after the assertion of RAS. Thus, 98 ns or faster DRAMs, used with this

scheme, allow the memory subsystem to operate with one wait state.

Memory System Interface

5-21

5.10.2 State Machine Input Setup Time
In Figure 5-15, the PLUS40545 state machine used as the memory controller
requires 12 ns of setup time at each of its inputs. The actual setup time on
any of these inputs is calculated by adding the maximum propagation delay of
each gate located between the source and the state machine input. This sum
18 added to the delay of the source from the rising edge of CLKA. For example,
the AS signal is asserted by the rtVAX 300 23 ns after the rising edge of CLKA
when the processor is in the P1 state. The delay of the F00 gate in the address
strobe synchronizer (5 ns) is added to 23 ns to yield 28 ns total delay from the
rising edge of CLKA. Because the cycle time of CLKA 1s 50 ns, the setup time
of SYNCHAS is 22 ns, meeting the 12 ns requirement.
The IACKIPR and SELRAM outputs of the 22V10 PAL in Figure 5-9 are both
stable 10 ns after the rising edge of AS H. The 4 ns delay of the AS inverter in
Figure 5-15 must be added; therefore, IACK and SELMEM are delayed 14 ns
after the falling edge of AS. Since AS falls 23 ns after the CLKA rising edge,
IACKIPR and SELMEM assert 37 ns (23 ns + 14 ns) after the CLKA edge.
Thus, the setup time for these two signals is 13 ns

30 ns — 37 ns), which is

greater than the 12 ns requirement.

Similar analysis was done to the rest of the memory controller sequencer setup
times, and Table 5-6 lists the setup times of all the signals.
Table 5-6

5-22

Memory Controller Setup Times

Signal Name

Minirnum
Setup (ns)

Actual
Setup (ns)

IACKIPR

SELRAM

LWRITE

P3P4

SYNCHAS

REFREQ

RST

LADDR30

LADDR31

INVADDR2

INVADDR3

Memory System Interface

. 5.10.3 Memory Subsystem Longword and Quadword Read Cycle
Timing

Section 2.6 specifies the memory system longword, quadword, and octaword
read and write cycle timing. The rtVAX 300 bus timing is synchronous with
CLKA and CLKB. This timing is used to derive the states required by the
memory controller state machine. The state machine, shown in Figure 54,
illustrates sample operation of the memory controller. Figure 5-5 shows the
sample longword and quadword read cycle timing.

The critical timing parameters for the rtVAX 300 memory system must be
satisfied along with the timing parameters for the DRAMs. Section 2.6

discusses the values of these parameters. In addition, the DRAMs have some

critical timing parameters that must be met. Table 5~7 lists these parameters.
The memory system must be able to transfer four successive longwords at a

time during an octaword read cycle. Sample timing for the octaword read cycle
i1s shown in Figure 5-6. The timing relationships are similar to those of the
longword read timing.

Memory System Interface

5-23

Figure 5-5 Sample Design: Memory Controller Longword Timing

‘

Note. LWRITE L IS DEASSERTED AND LADDR<31:30>s01 FOR THE LONGWORD CYCLE AND 10 FOR QUADWORDS
P1

P3 P4

P2 P3 P4

P2 Pa P4

P3 P4

P2 P3 P4

CLKAH

P1 P2iP3 Pa:P1 P2:P3 P4 P1 P2iP3 PaiP1 P2iP3 Pa'P1 P2:P3 P4iP1 P21P3 P4!P1 P2:P3 Pa:P1 P2.P3 PA'
;

AL@10> H

DAL<31.0>

ADDHESS

;

LONGWGRD 0

Y
:
{
)
\ADURESS

‘

Ldnewokoo LONGWORD 1 :
:
‘
j___:
)-—-(
N

'
i
'

;

]

)

}
'

SELCOLL

DRAMREADY L

\___J

INVADDR2 H

I'—\

P3P4 H

‘

j—'—"'\
l-—L

INVADDR3 H
'

DRAMADOR<8:0> H

{ADDRECOL

XADDRO quXAdDao cdu.x

‘

ADDR2COL__

XfibDRO no%noao cqj Amam coL

‘

IDLE

" IDLE

ACCESSCYC

~ STARTACCESS

anSHU'P

READCYC

IDLE

DLE |

ACCESSCYC ACCESSCYC

STARTACCESS

READCYC

FINISHUP

READCYC

IDLE

MLO-006388

5-24

Memory System Interface

;

I T B B

;

DWWWOO( 0>0mmw00< 0>mew00wawoo<

;

\N . Y

$17<0€ 1E>HGAYT GNY G3LHISSY LON SI UM -8IoN

7<CFE>SYO

TAGH

Hvdtd

180

HWYD

Memory System Interface 525

Table 5-7

5-26

DRAM Timing Parameters for 80 ns Page Mode 1M Bit x 1

Parameter Name

Minimum Time
(ns)

Maximum
Time (ns)

Row address setup time

Row address hold time

Column address setup time

Column address hold time

RAS precharge time

RAS width

10,000

Access time from RAS

Access time from CAS

Output disable time after CAS

RAS to CAS lead time

Data in setup time before CAS

Data in hold time after CAS

Memory System Interface

. 5.10.3.1

Calculating DRAM Row Address Setup Time

When the rtVAX 300 is accessing memory, the memory controller asserts RAS
on the rising edge of P3. The address is placed on the DAL<29:02> H bus
20 ns before the rising edge of P1. This address has to propagate through
the 74F373 latches, the 74F86 XOR gate, and the 74F711 MUX. The total
propagation delay is as follows:
+ 1 CLKA period
+ Address to P1 edge

— Propagation of 74F373
— Propagation of 74F86

— Propagation of 74F711

+ Minimum memory controller delay
+ Minimum RAS driver delay
DRAM row address setup time
In this case, DRAM row address setup time =50 ns + 23 ns — 7ns — 5ns — 6
ns + 0 ns + 2 ns = 57 ns.
5.10.3.2

Calculating DRAM Row Address Hold Time
Once RAS has been asserted, the SELCOL input to the 74F711 is asserted on
the following CLKA falling edge. When the worst-case row address hold time
is calculated, the minimum propagation delay of the two 74F00 gates of the
address MUX select flop must be added to the RAS to SELCOL time. The row
address hold time is calculated as follows:
+ RAS to CLKA rising edge
~ Memory controller output delay
— 2 x minimum propagation of 74F00
+ Minimum 74F711 delay
—~ Minimum 74F04 delay

DRAM row address hold time

In this case, DRAM row address hold time =50 ns — 12 ns - (2x 2)ns + 8 ns
— 4 ns = 38 ns.

Memory System Interface

5-27

5.10.3.3 Calculating DRAM Column Address Setup Time

The memory controller asserts ENBCAS on the P1 edge following the assertion
of RAS. The CAS lines of the DRAMs assert after two minimum 74F0Q delays.
The SELCOL line, which drives the column address onto the DRAM address
bus, does this two maximum 74F00 gate delays after the falling edge of CLKB.
The column address setup time is calculated as follows:
+ SELCOL to CLEKA rising edge

— 2 x maximum propagation of 74F00 (address MUX latch)
~ Maximum propagation of 74F711
+ 2 x minimum propagation of 74¥00 (CAS decode latch)
+ Minimum CAS driver delay
DRAM column address setup {ime

In this case, DRAM column address setup time = 25 ns - (2x5)ns — 15 ns +
(2% 2)ns + 2 ns = 6 ns.

5.10.3.4 Calculating DRAM Column Address Hold Time

The INVADDR<3:2> lines assert on the P3 edge that follows the assertion of
ENBCAS. The column address hold time is calculated as follows:
+ CAS assertion to INVADDR<3:2> assertion

~ ENBCAS memory controller output propagation delay
— 2 x maximum propagation or 74F00
—~ CAS driver delay
+ Minimum INVADDR<3:2> memory controller delay
+ Minimum 74F86 delay
+ Minimum 74F711 delay
DRAM column address hold time

In this case, DRAM column address hold time =50 ns — 12ns ~(2x5)ns - 5
ns +0ns+2ns+ 5ns=30nmns.

5.10.4 Memory Subsystem Octaword Write Cycle Timing
Like the access time for read cycles, DRAMs also have setup and hold times
that must be met for write cycles. The data on the DALSs is strobed into
the DRAMs on the falling edge of CAS. The rtVAX 300 can write up to four
longwords in one access cycle. Refer to All multiple word write cycles ship one
microcycle for each longword transferred to satisfy the data in setup and hold
times. Figure 5-7 for the octaword write cycle sample timing.

5-28

Memory System Interface

H¥¥ID

Ha0

ZHQAvANI H

TAQYIEAYEQ

V<0-6>8VYD

1700138
8VO8N3 7

ISYH

¥dtd H

1sa

18v

QA5SS390V

)

20403LEM

TAQY

<0'8>"OQYNVHG H e Ep . i elS A.VOVIHV. LS 10AD341dM ESADILIOM JADILIUM

20A03L OADS300Y JNHSINIZ
§ EIADIUEM 1OAD3LINM EDA03LIUM LM EOAD

‘80NJLIHMT51LONG3LU3SYONY1€>HAV]1=<0E

31Q

SEFPO0-OTN

ainbHi<04'17e>—v¢aWIs1idomjA€zdd¢1i!VwwZbTwd3eoAsivsmda.7ida:v1vd9u]gb€2oddAi'u‘'Ai:)a2s£dpdiavtvg)ddm“i[].QAdr1HdudOlMYE2oOddoBN;i]]wO26Td3e]1¥l0SddvT:I!s+‘'ia1JJd9u—9aiEZcjdde]yI:iK:—]2©t{oddw(nYi¥dndu'¢“iVh:Qov1oUd9)OA€ZMpddOX1Dm(;V]NiZBOddoSYAY(mbz|ddg]e“|i1]]sv1ladawdaC2Qdd](!iv“Z£addNWRiI¥rdd+ui'ii:[ovm1dE28ddX1]‘1vi1Y]Z€2dd4/1vN2ddAw]!i!tiPB1jdluo£ZjddI_ieTw]2€$yd2salI¥ddd1a'[i:adv1udvdoE2mddi[ei.:Zn£ddok¥£dd'Ii|11bi{dd€2dd]!1i}:2£ddI¥dd:]|miP]vi1dd£2dd][!i1:: Z€dd¥¥dd
¢ ' | 1 1OAhDS3IiOV20IlAD3LIH'MDA.DS30|VHM' ' ‘ + ' ) ¢
FWd

£HAavANI

Memory System Interface

5-29

5.10.4.1

Caiculating Data In Setup Time
The Data In setup and hold time must be calculated to ensure that valid data
is strobed into the DRAMs. The DALSs are driven with valid data 23 ns
(2P — 27 ns) before the rising edge of P1. The DRAMs CAS line is driven 17
ns after the rising edge of P1; thus, the worst-case DRAM data in setup time is

calculated as follows:
+ 2 (74F00 minimum propagation delay)
+ 23 ns
+ 0 ns (state machine minimum propagation delay)
Data in setup time
In this case, data in setup time = 23 ns + 4 ns + 0 ns = 27 ns.
5.10.4.2

Calculating Data In Hold Time
The rtVAX 300 continues to drive the DAL bus with valid data until 31 ns (P +
6 ns) after the rising edge of the following P1. Thus, the minimum data in hold

time can be calculated as follows:

- 2 (74F00 maximum propagation delay)

~ Memory controller delay
+ 31 ns
+ 100 ns

Data in hold time
In this case, data in hold time = 131 ns - 12 ns — 12 ns = 107 ns.

5.10.5 Memory Subsystem Refresh Timing
Figure 5-8 shows the memory controller refresh timing. The DRAMs that
are used support CAS before RAS refresh, page mode, and thLey have an
access time of 80 ns. These DRAMs require that CAS be asserted at least

20 ns before RAS, and RAS must be asserted for at least 80 ns. If CLKA is
operating at 20 MHz, the cycle time is 50 ns. The timing diagram also shows

that ENBCAS and REFCYC assert 50 ns after REFREQ asserts. REFCYC
clears REFREQ, and all of the DRAMs’ CAS lines are asserted. RAS asserts
50 ns after ENBCAS asserts, and all three signals remain asserted for 100
ns. Table 5-8 lists all of the timing parameters needed for CAS before RAS

refresh.

5-30

Memory System Interface

. Figure 5-8 Sample Design: Memory Controlier Refresh Timing
Pi

P3 i P4 P1

P3iPaiP1i P2.P3 P4iPIip2iP3ip4

CLKAH

REFCYCL !

ENBCASL |

;

—\— :

;

:[ é

\ A/ I

RASL§‘;§§E:§%§\
]

IDLE

‘

IDLE

+
v

REFRESHCYC
STARTREFRESH

"»

FINISHUP

IDLE

ENDREFRESH
MLO-004430

Memory System Interface

5-31

Table 5-8

DRAM CAS Before RAS Refresh Timing Parameters
Minimum

Maximum

Actual

Parameter Description

Time (ns)

CAS low while RAS high

RAS low time

10,000

100

RAS precharge time

100

5.10.6 RAS Precharge Time
RAS precharge time is defined as the amount of time that the DRAM needs
to be unselected (RAS and CAS are deasserted) after any access cycle. This is
needed because internal voltages of the DRAMs must settle after each access.
The RAS precharge time for the DRAMs is maintained, because the memory
controller enters the FINISHUP state followed by the IDLE state after every
memory access or refresh cycle. During these two states, all the memory
controller’s outputs are unasserted, and the controller stays in each state for
50 ns. This deasserts the RAS and CAS lines for at least 100 ns after each
memory access, satisfying the RAS and CAS precharge requirements.

5.10.7 DAL Bus Turnoff Time
The DAL bus turnoff time must also be preserved to prevent bus contention.
This time is 35 ns (P + 10) after the P1 edge, when DS has deasserted. After
that time, the rtVAX 300 begins to drive the DAL bus with the next address.
The DRIVERAM signal, which turns off the DRAM latches, deasserts one
74F20 gate delay after DS. Thus, the turnoff time is as follows:
+ DS deassertion delay
+ 74F20 propagation delay

+ 74F373 turnoff time
Turnoff time

In this case, turnoff time = 25 ns + 5 ns + 7 ns = 37 ns after P1 edge.
Because the memory system is deactivated in 37 ns, transceivers are not
required between the rtVAX 300 and the memory system. This time is less
than the 53 ns maximum time required by the rtVAX 300. If the turnoff time
for any peripheral is greater than 53 ns, transceivers are needed to isolate that
peripheral from the DAL bus after the peripheral has been accessed.

5-32

Memory System Interface

5.11 Memory System lllustrations and Programmable Array
L.ogic
The following sections show memory system illustrations and programmable
array logic.
Figure 5-9 shows the sample design for the address decoder and powe.-up
reset.

Figure 5~10 shows the RAM memory map.
Figure 5~11 shows the sample design for the address latches.
Figure 5-12 shows the sample design for DRAM memory array 1.
Figure 5-13 shows the sample design for DRAM memory array 2.

Figure 5-14 shows the sample design for the RAM data latches.
Figure 5-15 shows the sample design for the memory controller.

5.11.1

Application Module Address Decoder PAL
Table 5-9 lists the programmable array logic (PAL) that decodes the rtVAX 300
address and cycle status lines. This PAL does the following:

Selects the memory and decodes rtVAX 300 interrupt acknowledge cycles
Asserts the SELRAM, IACKIPR, and ENBCCTLDPE lines, which control
the data parity enable and cache control drivers, select system RAM, and
signal when the rtVAX 300 is running an interrupt acknowledge or IPR
cycle

The SELRAM and IACKIPR select lines are internally latched on the rising
edge of AS H. This PAL eliminates the need for external device select latches
by using the D flip-flops built into the 22V10 PAL.

Memory System Interface

5-33

Table 5-9
Pin

Application Module Address Decoder PAL

Description

input

DAL22

DAL23

DAL24

DAL25

DAL26

DAL27

DAL28

DAL29

CSDPO

CSDP1

CsDhP2

CSDP4

'WR

Output

5-34

'SELRAM

TACKIFR

!IENBCCTLDPE

CYCRES

Memory System Interface

Figure 5-9 Sample Design: Address Decoder and Power-Up Reset
Power-On and Powar Glitch Reset
+BV

Address Decoder PAL (includes laich)
Note: Socket used here

1NM§42S

PAL

‘

Deonde PAL

22vi0

I 23

Fbu—

RESE TVAX L

SELRAM L

{ACKIPR L

ENBCCTLDPE L

{CYCRES)

A6 DR

RE [
R4 DTé

Ra
R2

1§

CSDP<2> L__lwl‘-‘-1—5—-2(-LE_—1
CSDPeia L
CSDP<0> L

+8V

DAL2O> H

AAA

DAL<28>H
DAL27>H
DAL<R6>H
DAL<B5y H_
HLT L

11] oo

10| 0o

DALc2d> H

| 02

DAL<23s H

3 D1

DAL"2>H

2 DO

AS H

Yok

CSDPcéd> L
DS L

WRL

AAA

+8v

L RESETVAX L

Note: The nVAX 300 uses CMOS ACTQ245 drivers for
the DAL lines and ACTQ244 drivers for the control lines.
These drivers have very fast rise and fall imes which can
generate a fair amount of undershoot and overshoot. Some
PAL devices and RAM chips may malfunction when exposed
to excessive overshoot and undershoot. It may be necessary

to isalate these devices from the tVAX 300 signal lines with
TTL butfers or provide series termination resistors for these
lines.

MLO-006389

Memory System Interface

635

Figure 5-10 shows the RAM memory map; Table 5-10 lists the corresponding
equations.

Figure 5-10

RAM Memory Map
Memory Locations

Device

Selected

RAM

00000000 - 003FFFFF

DAL<29:2x

24283

16 15

0807

000000 | 00XXXXXX | XXXXXXXX | XXXXXX

Table 5-10

MLO-004435

Application Module Address Decoder Equations

Line

Equals

SELRAM.D

g)%fiz% 'DAL28 & 'DAL27 & 'DAL26 & 'DAL25 & 'DAL24 & 'DAL23

SELRAM.AR

CYCRES

IACKIPRD

!WR & (/CSDP2 & CSDP1 & CSDPO) # ({CSDP2 & CSDP1 & !CSDP0)

IACKIPRAR

CYCRES

!AS & (IACKIPR # SELRAM)

ENBCCTLDPE DS & SELRAM

5-36

Memory System Interface

. Figure 5-11 Sample Design: Address Latches

Address Latches

8BF

8-Bit

Latch
74F373

DAL<17> H

DAL<16> H

DAL<15> H

DAL<14> H

DAL<13> H

DAL<12> H

D6
D5

D4
D3

D2
D1

DAL<10> H

Latch

LADDR<17> H

Re w6

H
1
LADDR<16>

asos

LADDR<15> H

74F373

Bip7 B7
7

Tpe AEST
Hlps

Replz_ LADDR<14>H
R3 ki

H
1
LADDR<13>

R2odS

H
1
LADDR<12>

rord2

LADDR<10> H

—C] ENO

los P

BM<3

BBF

8-Bit

LADDR<30>
H_|
ASL

LBM<3s L

LBM<2> L

BM L

LBM<is L

BM<O> L

3 00 RO

0 L
LBM<O>

_HO_. LD

111

LADDR<31>H

B39

RS D+

2lpa P47

——HOLD

—

974

~—J ENO

8BF

—~dF32

8-Bit

Latch

Laich

74F373

74F373
19

DAL <8> H

DAL<7> H

DAL<6> H

. DAL<5> H

DAL<d> H

DAL<3> H

DAL<2> H

ASL

D4
D3
D2

Blo7 R7—

R6 16

LtADDR«<8> H

LADDR<7> H

R4 12

LADDR<6> H

Rapt?

LADDR<5> H

R2 6

LADDR<4s> H

RIS

LADDR<3>H

DAL<19> H

aopl2

LADDR<2> H

DAL<18> H

“JHoLD
{IENO

R
WRL

e b6 R 6!

‘

LWRITE L

DAL<30> H

Ii‘ 13

DAL<21> H

DAL<20> H

3
11

R4: 12

30> H
LADDR«
Re30>

LADDR<219 > H

R24-8

LADDR<200>> H

LADDR<19> H

RO 2

18> H
R<18
LADDR<

)

T HOLD

~—C ENO

MLO-004436

Memory System Interface

5-37

eospew| weishs Loweyw ge—S

Figure 5-12 Sample Design: DRAM Memory Array (1)
Note: Pinout of DRAM depends on peckage typs Used.

RAM<13> H

fvw-—'—
100

ORAMADDR<S> H

DDR<8>H 20|

]
1!

DRAMADDR«S>H 17 ::
DRAMADDR«4> H_18
DRAMADDR«<3>H 14 n

DRAMADDR«<Z>H
DRAMADDR<1>H
DRAMADDR«<O>H

13 | 4o
12 § o4
11 ] 40

DRAMCASL

2dcas

DEAMWRITEL.
¢ A wg

—
=

100

VB ZIP

' D‘DQD

DORAM

17 ::
[T
14 z

17 ::
10
14 :
138
AL

13 ] a2
L

s D‘DOD

VD 2P|
DRAM

' D'WD' e

[
1A

[]
[

17 ::
18
14 z

17 :
"
14 :;

17 :
[
14 ::

17 :
18
14 ::

tr :
)
14 ::

17 :
I
14 :

18} a2
12 1 a9
11 ¥ a0

131
12 { a4
1140

[

13 ) a2
L
11 P

[]
[

s DOED.

131,
i3 PV
11 { a0

[
1t

131 a2
L1 8
11 ] a0

13§ 4
12 § a1
11} a0

|—2dcas

|—dcas

|—qcas

|[—dcas

—2dcas

[—Iccas

2dcas

RAM<7> H

RAM<8> H

RAM<S> H

RAM<A> H

RAM H

RAM<2> H

RAM H

RAM<O> H

|—dwe

—dwe

DAL H

DAL<d> H

DAL<3>» H

DAL<2> H

DAL«<1> H

DAL <0> H

1% A7
18 | o0
17 A8
10 | 5,

iMB 1P
DRAM

.s Di 0ot

1917
181 48
17 AS
18 ] a4

[}A

1MB 1P

1MB 7P

DOt~

(sL 00

DRAM .

L
nla.e
17 AS
8}

b 1
(T
17
LH

DRAMADDR<2>H 13| 40
CRAMADDRH 12 | 54

“las

193]
12§

a2
a4

14}

18§

DRAMADDR<O> H

iAo

1§

11 ] 45

19|
40
12 1 44

LEH AP
12 ¥ a9

1MB 2P

)+ 12 oot

|¢ D ooty

|s1% ood

L. 1 P
18| aa
17 AS
s

L
181
17
18]

19
LTI
17
18

1.7
PP

L
18 | a8
17 AS
T3

DRAM

[

DRAM .

A5
a4

DRAM .

(L
TR
17
TR

A8
v

113
194
128

a2
a1

14 ] 45

13
a0
121

[—IqRAs

|—IQRAS

DBAMWRITEL...
& 3 we

|—dwe

|—Etdqwe

|—ggoas

[—Idms

|—gcas

1MB 2P

—Iqms

+qcAs

CSDP<O> L

1MB 2P

ras

L_.__.59.>____CRAM‘ CAS

|—Ldcas

DRAM s

—rq

DRAM

| (CAs

g RAS

:g CAS

wWE

»

C80P
L
18

TM8 0P

DRAMADDR<®>H _ 1 | 49

unmg::

RAMcE> M

DAL M

|L;W’

_9
ae

RAM<d> H

DAL<10> H

1MB ZIP

DRAMADDR<3> H 14

Fid

RAM<11>

DAL<11> H

DAL<7> H

+s 12

DRAMADDR<7>
H
DRAMADODRGS>H
DRAMADORC<S> H
ORAMADDRcA>H

- DAL<I2>»H

ORAM

AAM<12» H

DAL <13>» H

1315
12 a5

DRAM

AS
10

1MB ZIP
ORAM

.. Dl [y 9

14 1 a3

1940
12§ ay

13 4 50
12 { a1
a0

qmms

|—Iqms

|—dnras

I—idwe

}+—dwe

'_TC CAS

—_-.-g CAS

|——Ccas

DP<O>L

Figure 5-13 Sample Design: DRAM Memory Array (2)

Mote: Pinout of DRAM depends on package type used.

RAM<31> H
DAL<31> H

!
pran

100

DAL<30> H

2
[

DRAMADDR<S> H

DRAM .

DRAM R

ORAM

)

VB 2P

DRAM s

DAL <26> H

MB ZIP

Doy

DRAM

Doy

RAM<26> H

’

DAL<25> H

DRAM

DOy

= ::

21 as

2 )28

2 148

-1

DRAMADDR<6» H 12 A8
=

[T]7

DRAMADDR<2> H
DRAMADDRc1> H
DRAMADDR<O>H

13 | oo
12 | 4y
11 | 44

pnmA:Tm:»v 1 :
¢.

ORAMRASL
7 pas
Di

<3»

tdcas

14 :‘3

" :‘3

|—Ldaas

*gdwe

tdwe

100

[TMB ZiP|
8

DRAM
o DOy

DRAM
3
i DOK

(N
»

DRAMADDRH_

1 § 40

DRAMADDR<8>
H

20} 40

® ] a8

ORAMAODR<7>H 18 | oy
ORAMADOR<O>H 18 | 40
DRAMADODR<S>H 17 | 45

DRAM .
o DODY

DRAM .
o DO

[

(1B ZiP |

DRAWM .
P DON

)

DAL<16> H
18

TM8 ZIP

M8 ZIP

DRAM .
8 { o DO

DRAM s
51 DO

[

2 | an

2 | op

2 | ap

2 | an

o
{7
191
a8
17 1 ag

LN
L PV
17 ] as

LN
L
17 ] a5

LN
9 { 28
T ] a5

LN
g
(T8
7 3 as

19 { a7
TH ¥
17 ) a5

19§ a7
18 | 40
17§
a5

] a
LN JPr
v 1 as

DRAMADDRcA> H_18 | 44
DRAMADDR«3>
H 14 | 0o
DRAMADOR<E>H 13 | oo
DRAMADDR<1>H t2 § o4
DRAMADDR<O>H 11 } 49

LN
LI

L1
P
14§
s
12
a0
2 1 a4
a0

wlae
141
an
13§ a0
12 } a1
1 { a0

AL
W
14§
aa
134
a2
12 1 a4
1y
a0

LI
PV
LU
15§
a2
12 ) a1
LI
Y

18 4 as
14 { an
13 § 40
12 ) 4y
LR
Y

(LI
9P
AL
13§
a2
12 ) a9
"
a0

18 | aa
14 [ a3
13 1 a2
12}
a9
1t
{40

DRAMRASL
__
Tomas

|—Idmas

DRAMWRITEL
¢ 3 we

:g cAS

—dRas
+q

cAs

DRAM s
o DO

2§

jg CAS

ras

j RAS

—_—:E ras

L—1dras

|—2dwe

—*dwe

[—*dwe

$ g CAs

cAs

cgcas

OP<2> L

CSDP<2>L

® | an

|—Iqmas |—I1qmas

RAM<16> H

d we

CAS

‘i

RAM<17> H

ME 2IP

|—Tdnas

|—2dcas

DAL<17> K

[1MB ZIP

—:—C cas

RAM 18> H

DAL<18> H

12 § 4y
1]
a0

RAM<19> H

VA
N
13 § 40
120
a1
LA
AP

|—dwe

DAL<19> H

DRAMOAS<2>L
1A cag

dwe

__.T’c CAS

1 :‘3

13 8 a0
12§
a1
11
a0

|—dwe

_%C CAS

14 :

13 | an
12 | a4
L
PP

|—"dwe

B Z1P
gl

- \L3 :‘3

a2
a¢
a0

|(—Idmas

RAM<20> H

DRAM .
' Doq

131
12§
1

DRAM

2 A

{—Idms

DAL<20> H

B ZIP

14 :‘3

19 { a7

|—Idqmras

RAM<21> H

B ZIP

e oT

MB 2IP

|—Iqms

}—Ldcas

DAL<21> H

e o

19 ] a2
12
a4
Y}
a0

::!g cAs

RAM<22> H

DAL<22> H

1" :;

3 { 40
12
{ay
11 ] a0

_——_—'_S CAS

2 I

L} :43

12l
.0
12 ] a4
114
a0

RAM<23> H

s o

|—Iqms

t A cas

[|—Zdras

wliay

e L

131
a
12 { a4
18
Y

DAL<23> H

DOy

2 ::

DRAM _’j

20 ::

19 ] .o

1MB ZiF

_DPA>L

CSDP<3> L

1MB ZIP

’

DOy

RAM<24> H

DAL<24> H

VB 2IP

RAM<25> H

DRAMADDR«<8> H 2 ::
DORAMADDRH

68— oorpeluj weisig Aiowepy

RAM<27> H

DAL<27> H

B ZIP
.

AAM<28> H

DAL<28> H

1MB ZIP,

RAM<29> H

DAL<28> H

1MB ZIP

RAM<30> H

——dcas
MLO-D0801

eoepelu| weisAg Alowsy oS

Figure 5-14 Sample Design: RAM Data Latches
BBF

8BF

88F

B-Bit

8-Bit

5>
RAM<iS>HD187 H?DL._-_[—J&"
——

AAM<i4>H 17 mepl e BAL<14>H
DAL<135> H

RAM<13>HDP5 RS 16
—I
<1Z2H
RAM<i2>H 1o map|2DAL
——— D4

RAMciI>H

-1 D3

H
11>>_DAL<.<_
* ____.—
R3l>'_

1 >H
ReppS—OAL<10
7]
AAM<10>H {p
2

————

RAMo, H | int DALO2H
ve>3] Root? DAL<8> H
rams

MRDY L

— (|HOLD
=
foc
1 0|WL
DRVERA

RAM<31>H

18 o7 R7 4

RAM<30> H

<28> H
RAM<28>

M<27> H
> ___.J D3 R3 5
E_A_f______.2

HAM<1> H
RAM<O> H

MRDY L

7
s
1"

D3
D2

DAL<26> H

DP<2> L

DAL<25> H

A2 [}

;

CSDPe2> L

—

DPet> L

mig)s CSOPcirt

DP<O> L

. GSPP<O-L
mopl?

———q 01

Pt Do

MROY L

= — (JHOLD

DRIVERAML

ENO

Latch
74F373

<4> H

DAL<4>

—

18 o7 R7 =

RAM<22> 4

<21> H
RAM<21>

1 DS RS B

RAM<20> H

K
13 TM R4 12 __DAL20>

4
RE

R20 ki

DAL

<2> H

Mc18> H
RAMc18>

7 D2 R2 =

RAMc17> H

01 R14

RAM<16> H

DAL<ci> H
DAL<G> H

DAL<23> H

AAM<23>
<23> H

[] D3 R3 DA

HOLD

R3D"°'*E§9F_—‘.
8
DP<3> L{03

Mc19s 19> H
RAMc

MO ENO

DAL<27>H

DAL<3> H

RO 2

rapt'?

DALc24>H
P Ro2

RIS °
A1 s

RAM<24> H

8BF

R4 12

RS it

4 o1 R1

B-Bit

H
DAL<28>

RAM<25> H

8BF

] o PO

7 D2 R

MRDY L

R7Ex—

DAL<29> H

RAM<26> H'

DAL<30> H

D
oD
DRIVERAM L
ENO

RAM<T> H 1| D7 7oytDALM
DAL<E> ~H
77 R6 e
RAMcE> H
06
1
—
DAL<S> H
RAM<S> H 4 rs 16

RAM<3> H
AAM<2> H

13 D4 R4 =

Latch

DAL<31>H

1} ,¢ RSHH
Ram<29>H

74F373

RAM<4> H

74F373

8-Bit

Latch

Latch
74F373

MRDY L
RiV
DRIVERAML

DAL<22> H

DAL<21> H

DAL<19> H

SYNCHAS H
LWRITEL
18

L
_DRIVERAM

ENABLERAM L

__DpALE>
DAL<17> H

CLKA H

DAL<16> H

1 diaio
ENO
ML O-090£440

Figure 5-15

Sample Design: Memory Controller

CAS Decode Logic

Address MUX Select

Fig-Flop

LBM> L

oMz L

et L

g0 A
|]

st
B

RN S

R B

18
7

30)
-

s _|FOO b"'——‘—m"

o0 0+

SYNCHAS H

CCTL and DPE Orivers

REFCYC L

45V ]
RESETVAX
L
RESETV Xk

SV a3
CLKA

-5
N L2 s AT ‘fl

% 545532 | ssag0azs

MRDY L

Memory System Interface

5-41

PAGE

5-42

INTENTIONALLY

LEFT

BLANK

. 5.11.2 Memory Subsystem Sequencer State Machine PAL

The memory subsystem sequencer performs the following functions:
e

Sequences the RAS, CAS, and address enable control lines for memory
access and refresh on the rtVAX 300 application example

Arbitrates between refresh requests and memory accesses

Controls the RDY L signal to the rtVAX 300 to mark the end of a memory
access cycle

Table 5-11 lists pins, signals, and comments.
Table 5~11

Memory Subsystem Sequencer State Machine PAL

Pins

Signal

Comment

Input Signals

CLKA

The rtVAX 300 A phase of the CVAX clock used to

SYNCHAS

This synchronized version of AS L from the rtVAX 300

trigger all state transitions.

indicates that the address cycle status information is
valid and that the rtVAX 300 is starting a memory
access. The signal remains asserted until the end of the
memory access cycle and is synchronized to deassert on
the CLKA positive edge.

'DS

This rtVAX 300 data strobe signal output is assertzd
when the DAL bus is ready to transfer data.

CLKB

This rtVAX 300 B phase of the processor clock is added
here in case extra states need to be clocked off its edge.

P3P4

This signal is asserted when the rtVAX 300 is in the P3
or P4 state and deasserted when the rtVAX 300 is in
the P1 or P2 state. This state machine uses the signal
to determine when to assert the DRAMREADY line.

'LWRITE

This latched write signal output from the rtVAX 300 is
asserted during a write cycle and unasserted for reads.
It affects the operation of this state machine.

SELRAM

This signal is asserted by decode logic when the rtVAX
300 is trying to access the DRAM.

(continued on next page)

Memory System Interface

5-43

Table 5-11 (Cont.)
Pins

Memory Subsystem Sequencer State Machine PAL

Signal

Comment

input Signals

'IACKIPR

This pin is controlled by external decode logic connected
to the CSDP lines of the rtVAX 300. The signal
asserts when the rtVAX 300 is running an interrupt
acknowledge cycle but is not asserted for a memory
read cycle and must be checked to prevent this state
machine from starting a memory access cycle when the
rtVAX 300 is running an IACK cycle.

This is the output enable of the sequencer.

FINVADDR2

This is tied to the INVADDRZ2 output of this state
machine and used as an input for determining the
address of the last longword transferred during

multiple-longword transfer cycles.

FINVADDR3

This is connected to the INVADDRS output of this
state machine and used as an input for determining

the address of the last longword transferred during
multiple-longword transfer cycles.

LADDR30

This signal is the secend most significant bit of the
latched address of the rtVAX 300. When it is deasserted
and LADDR<31> is asserted, a quadword read cycle is
taking place.

LADDR31

This signal is the most significant bit of the latched
address of the rtVAX 300. When it is asserted and
LADDR<30> is deasserted, a quadword read cycle is
taking place.

IRST

This signal asserts during power-up and system reset.

It causes the state machine to run refresh cycles
continually to warm up the DRAM upon power-up.

'RESETVAX

This signal is asserted to start a svstem reset; its
assertion forces the IDLE state and deasserts all
outputs.

'REFREQ

This signal is asserted by an external refresh request
counter every 3.28 ms. This request is reset when this
state machine asserts the ENBREFRESH signal.
(continued on next page)

5-44

Memory System Interface

Table 5-11 (Cont.)

Memory Subsystem Sequencer State Machine PAL
Comment

Signal

Pins

Output Signals
12

'RAS

The assertion of this signal strobes the row address into
the selected DRAMs for refresh or memory access.

'ENBCAS

The assertion of this signal strobes the column address
into the selected DRAMs, writes data into them during
a write cycle, and turns on the output drivers during a
read cycle to drive output data.

'REFCYC

The assertion of this signal turns on the refresh
address counter output drivers, driving the next refresh
address onto the address lines of the DRAMs. This line
clears the refresh request latch, and its deassertion
increments the refresh address counter.

INVADDRS3

The assertion of this signal inverts the LADDR<3>
bit of the column address, which is then driven onto
the address lines of the DRAM. This line is asserted
only during the quadword, hexword, and octaword read
cycles.

INVADDR2

The assertion of this signal inverts the LADDR<2>
Lit of the column address, which is then driven onto
cne address lines of the DRAM. This line is asserted

only during the quadword, hexword, and octaword read

cycles.
'DRAMREADY

This output controls assertion of the RDY L line to
signal that valid data is on the DAL lines and that the
cycle should end.

You define the internal state bits and assign a state name for each bit pattern
as follows. In addition, all illegal states are defined to prevent the machine
from accidentally hanging. All illegal states next-state to the idle state.
NODE

[STATE(Q, STATEl, STATEZ, STATE3,FLAG);

STATEQ . CKMUX
STATEL .CKMUX
STATEZ2 . CKMUX
STATE3 .CKMUX
FLAG.CKMUX

= CLKA;
= CLKA;
= CLKA;
= CLKA;
= CLXA;

/* REFCYC.CKMUX

= CLKA;

DRAMREADY.CKMUX

= CLKA;

INVADDR2 .CKMUX
INVADDR3 .CKMUX

= CLKA;

RAS.CKMUX

= CLKA;

ENBCAS.CKMUX

= CLKA;

Memory System Interface

5-45

FIELD MEMORY =

[STATE3,STATEZ,
STATEL, STATEO];

SDEFINE IDLE
SDEFINE STARTACCESS
$DEFINE ACCESSCYC

‘B’ 0000
‘'B’0100
'B'0110
"B’ 0010
‘B'1110
B’ 1100

$DEFINE READCYC
$DEFINE WRITECYC1 ~

$DEFINE WRITECYC2

'B‘0111
$DEFINE WRITECYC3
$DEFINE STARTREFRESH 'B‘1000

$DEFINE FINISHUP
$DEFINE POWERUP

'B’1001
'B’1011
"B’ 0001
‘B’1111

SDEFINE ILLEGALl ~

‘B’001l

$DEFINE ILLEGAL2

"B 0101

$DEFINE ILLEGAL4 ~

'B’1101

S$DEFINE REFRESHCYC
SDEFINE ENDREFRESH

'B’1010

$DEFINE ILLEGAL3_ ~

You now define equations to ease the state transition conditions. Memory
access can start only if SYNCHAS and SELRAM are asserted and if IACK
and REFREQ are not asserted to give refresh priority over memory access
and to prevent memory access during an rtVAX 300 interrupt acknowledge
cycle. EQU 1 through 4 determine when multiple longword transfer cycles are
complete by looking at the cycle type LADDR<31:30> and the address of the
last longword INVADDR<3:2> that was transferred.
MEMACCESS = SYNCHAS & SELRAM &

!IACKIPR;

EQUl = !LADDR31 &
LADDR30_ &
/* END LONGWORD XFR */
EQU2 = LADDR31_ & 'LADDR30_ &

FINVADDR2_ &

!FINVADDR3
;

'FINVADDRZ &

FINVADDR3
;

'LADDR30_ &

FINVADDRZ_ &

FINVADDR3
;

HEXWORD XFR */
LADDR31
&
LADDR30_ &

!'FINVADDRZ &

!FINVADDR3
;

/* END QUADWORD XFR */

EQU3 = !'LADDR31_ &
/* END

EQU4 =

/* END OCTAWORD XFR */

The state machine listing is as follows:
SEQUENCE MEMORY {
PRESENT IDLE

IF (REFREQ # RST) NEXT STARTREFRESH OUT REFCYC OUT ENBCAS;
IF MEMACCESS & ! (REFREQ # RST) NEXT STARTACCESS OUT RAS;
DEFAULT NEXT IDLE OUT
OUT !RAS

546

OUT

!ENBCAS

OUT

!INVADDR2

OUT

!INVADDR3

OUT

!DRAMREADY

OUT

!FLAG;

Memory System Interface

!REFCYC

PRESENT STARTACCESS
IF MEMACCESS & DS NEXT ACCESSCYC OUT ENBCAS,

'MEMACCESS NEXT ENDREFRESH,

DEFAULT NEXT STARTACCESS;
PRESENT ACCESSCYC

IF 'P4

'LWRITE &

'FINVADDR2 &

NEXT READCYC
OUT

OUT INVADDR2

'FINVADDR3 &

OUT DRAMREADY

(!FLAG # !'DS)

!'ENBCAS

;

IF 'P4_ & 'LWRITE & FINVADDRZ & 'FINVADDR3_ & (!FLAG # !DS)
NEXT READCYC

OUT
OUT

OUT DRAMREADY
!'ENBCAS

!INVADDR2

OUT INVADDR3
;
'P4_
& 'LWRITE & !'FINVADDR2 & FINVADDR3_ &

OUT !'ENBCAS
OUT INVADDR2
;
'P4_
& 'LWRITE & FINVADDR2 & FINVADDR3_ &

NEXT READCYC

OUT DRAMREADY

NEXT READCYC

OUT
!INVADDR2_

OUT
OUT

OUT DRAMREADY

(!FLAG #

'DS)

!DS)

!'ENBCAS

!INVADDR3_;

IF !'P4_ &

LWRITE & 'FINVADDR2 & !FINVADDR3
NEXT WRITECYC1

OUT DRAMREADY

OUT !ENBCAS

OUT INVADDR2
;
'P4_ &
LWRITE &
FINVADDRZ &
NEXT WRITECYCl

!FINVADDR3_

OUT DRAMREADY

OUT !ENBCAS

OUT

!INVADDR2

OUT INVADDR3
;

'P4_

LWRITE &

'FINVADDR2 & FINVADDR3_

NEXT WRITECYC1 OUT DRAMREADY
OUT

OUT

!'P4_

!'ENBCAS

INVADDR2
;

LWRITE & FINVADDR2

& FINVADDR3

NEXT WRITECYC1 OQUT DRAMREADY

OUT

OUT
!INVADDRZ

OUT

!INVADDR3
;

!ENBCAS

DEFAULT NEXT ACCESSCYC;
PRESENT READCYC

IF MEMACCESS &

!(EQU1 4 EQU2 # EQU3 # EQU4)

NEXT ACCESSCYC

OUT

OUT ENBCAS

!DRAMREADY

OUT FLAG;

IF EQU4 NEXT REFRESHCYC OUT
OUT

!ENBCAS

OUT

!INVADDR2

OUT

!INVADDR3_

!RAS

Memory System Interface

5-47

OUT

!DRAMREADY

OUT

!FLAG;

DEFAULT NEXT FINISHUP OUT

OUT

!ENBCAS

OUT

!INVADDR2

!RAS

OUT !INVADDR3_
OUT

!DRAMREADY

OUT

!FLAG;

PRESENT WRITECYC1
IF MEMACCESS &

!(EQU1 # EQU2 # EQU3

NEXT WRITECYC2 OUT

DEFAULT NEXT FINISHUP OUT

OUT

!ENBCAS

OUT

!INVADDR2

OUT

!INVADDR3

OUT

!DRAMREADY;

!RAS

PRESENT WRITECYC2

IF !DS NEXT WRITECYC3
;
IF DS NEXT WRITECYC2

PRESENT WRITECYC3 — ~
IF DS NEXT ACCESSCYC

;
OUT ENBCAS

OUT FLAG;

!'DS NEXT WRITECYC3
;

PRESENT STARTREFRESH

NEXT REFRESHCYC OUT RAS;:
PRESENT REFRESHCYC
NEXT ENDREFRESH OUT

!ENBCAS;

PRESENT ENDREFRESH

NEXT FINISHUP OUT

OUT

!RAS;

PRESENT FINISHUP
NEXT

IDLE OUT

!RAS

OUT

!ENBCAS

OUT

!INVADDR2

OUT !INVADDR3_
OUT

!REFCYC

OUT

!DRAMREADY

OUT !FLAG;
PRESENT POWERUP
NEXT FINISHUP;
PRESENT

ILLEGAL]

NEXT FINISHUP;

PRESENT

ILLEGAL2

NEXT FINISHUP;
PRESENT ILLEGAL3
MEXT FINISHUP;
PRESENT

ILLEGAL4

NEXT FINISHUP;

}

5-48

Memory System Interface

'REFCYC

§ EQU4)

!DRAMREADY;

XXKXX

XXXXXXX

XAXXXXXXX
).9.4.0.0.9.9.0.6.08

PO00904404004
0 9.6.6,0404646606464
XEXX XXX A KXXXKKAKK
10.8.9.4.5,0.856.444606060464
. 90.0.4.6.0.6.0.0.0.6.6086.406¢6444

P 9000006500056 8444.9294.44
P54400.06000.800.6004¢448806¢

P09 8008 0646080.60090.04.69054644
P00 989.0.406809008600¢8850.4000464
P9 0.0 0.089.900.008049.8.60098800444¢4

J.0.0.9.0.8.69408¢0.0009060.006865608049
44
$. 0,608 8000084088.00000048.64043044888094
).0.8.0.0.0.0.8.898 0846960900 0600096690 8644044
$:6.0.0.0.6.00.8.0.0.6.8:96.08¢6.9¢090,6.9.90.06.99609¢4964

$90.8.0.0.0000.66.000900668.48000.6460490$0969100¢44
p0 6,090.000.00.5.9.0.00.80.898¢888045000083890
5349444
p0.9.0.9.90.90.00.0609.0.998.00080999090908600.90096608094

1. 9.9:9,9,0.9.4:09.9.69.6.6.98.9.0.0.0.999$6800085509689.8.005669.9060
p.0.4.8.09.9.¢.0.9.99.0.¢8.00.9.9.9.9.09.909.608$898460.000690¢6086634
19088.9.6.90.6.0.9.09.4.0009.080.909800800.¢.64900.0669.088000805.46904

6
Console and Boot ROM Interface
This chapter provides information and examples for interfacing a processor

status LED register and an external boot ROM to the rtVAX 300 processor.

The console is used for hardware and software debugging, and the optional boot
ROM is used to store the VAXELN image and user apj.ication permanently, so
that the rtVAX 300 processor can boot without an operational network or host
system. This ROM could also be used for board-level testing and initialization.
The processor status LEDs are used to indicate the progress of rtVAX 300
self-test and processor operating mode.

This chapter discusses the following topics:

* (Console system interface (Section 6.1)
*

Booting from external ROM (Section 6.2)

rtVAX 300 processor status LED register (Section 6.3)

Console and boot ROM illustrations and programmable array logic
(Section 6.4)

6.1

Console System Interface

The rtVAX 300 processor module does not contain an internal console serial-

line unit (SLU); however, 16 console registers are reserved in the rtVAX 300

processor reserved space to select and program an external Signetics 2681
console dual universal asynchronous receiver/transmitter (SCN 2681 DUART).
These registers occupy physical locations 20100000 to 2010003F. The built-in
firmware of the rtVAX 300 programs and communicates with the external SCN
2681 DUART, which implements these console registers. The firmware detects
the absence of an external console DUART and will stop communication with
the console and continue to boot if the console 1s inoperable or nonexistent.

(Table 3-13 lists console register addresses and their read and write functions.)

Console and Boot ROM Interface

Note

Digital recommends that the console DUART be implemented in every
application module that uses the rtVAX 300 processor. The console
provides a tool for debugging the application hardware and software.
Without the consnle terminal, you cannot use the console emulation
program and the local debugger.
I/0 registers implemented in the application hardware can be debugged
by using the EXAMINE and DEPOSIT commands of the console
emulation program through the console terminal. The built-in console
emulation routines provide other commands for performing self-test
and external memory testing. The VAXELN kernel also provides a
local debugger that is used through the console. User-written VAX
assembly language programs for debugging hardware and VAXELN
system images can easily be loaded through Channel B of the DUART.

A console terminal interface for the rtVAX 300 processor must contain the
following elements:

Full address decoder to select the console DUART

Cycle status decoder to detect console interrupt acknowledge cycles
Address latches to hold the console register address

SCN 2681 DUART to implement the console registers and interface
Line receivers and drivers

DAL transceiver to prevent bus contention
Interrupt vector generator

Optional 160 ms break detector

Console state machine

Figure 6~1 shows the console terminal interface block diagram. The interface
contains the address and cycle status decoder, the DUART, DAL bus
transceivers, address latches, an interrupt vector generator, and a console
state machine. The console terminal connects to Channel A of the DUART,; a
serial-line output of a VMS host can be connected to Channel B to down-line
load hardware debugging assembly language programs and VAXELN system
images. Other general-purpose RS—232 peripheral devices can also connect to
Channel B.

6-2

Console and Boot ROM Interface

. Figure 6-1 Sample Design: Console Terminal intertace Block Diagram
Dl;l.<29 1 35,‘ Address

RXA

AS _ _ _ »l Decoder

UPCONE

; LOWCONE

CONE

oot and IACK f oy aue oToR

i
WR
Deceder ==
AS

RST

LWRITE

CLKA

TXDB

Driver

TXB

RXB

Interface

D<7:0

<7:.0>
<
IRQ<0> Transceiver

DAL<7:0>

———

ENBCONDATA

IOREADY

{>° !

3.6864 MHz
Oscillator

Conscle

SYNCHAS. Controlier

RXA

DUART

ENBCONRD

CONIACK B

»|

", Console

i
|
ENBCONWR

ENBROM |
>

RXDB

RST

CONE

TXA
Line

LADDR<5:22> LlscN2681
LADUR<S

P3P4

TXDA

Receiver

B
BXB_JConsole
Receiver

! pydress B24040
DAL<122>
CONIAC
.
CSDP<4:0>
1 La 2K SN

LBM<0O>

Console A RXDA

CONE

ENBCONWR

ENBCONRD

LWRITE |

= DIR
]

Intorrupt

Generator

Vector

nerrup

Drivers
Bits (15-10, 8, 5-0)

|
J

DAL<15:0>»

ENBVECTOR_|=—
————=——»EN
MLO-006522

6.1.1

Console Access
When the rtVAX 300 processor accesses any of the 16 console registers, the
rtVAX 300 first places the register address on the DAL<29:02> H bus. This

address is in the range of 20100000 through 2010003F. The address decoder
(see Figure 6—6) asserts the console enable (CONE L) signal when a valid
console address is latched. CONE L asserts on the rising edge of AS H and
remains asserted throughout the entire console access cycle. The 4 low-order

address bits DAL<05:02> H are latched (see Figure 6-7) and fed into A<3:0>
of the DUART to select one of the 16 internal registers. The DUART is only 8
bits wide; therefore, DAL<31:08> H are ignored when acce:sing the console.

Console and Boot ROM Interface

6-3

6.1.2 Console State Machine
When the address decoder has asserted CONE L, the DUART is selected, and
the console state machine jumps to the WRITECYC1 state, if it is a console
write cycle, or to the READCYC1 state, if it is a read cycle. ENBCONDATA
and either the DUART RD or the WR input are asserted. The state machine
waits the appropriate number of wait states for the console read or write
cycle, synchronizes with the P3P4 signal, and asserts IOREADY. This sets the
ready hold latch (see Figure 6-11), and the RDY L input to the rtVAX 300 is
asserted until the end of the access cycle. The state machine then jumps to the
FINISHUP1 to FINISHUPS3 states. These states are necessary to satisfy the
200 ns of deselect time required by the SCN 2681 DUART. Refer to Figure 6-2
to see the console state machine sequences.

Caution

The RDY L, ERR L, and CCTL L lines are tri-stateable, bidirectional
lines. These lines are pulled up by resistors inside the rtVAX 300
processor and must be driven by a tri-stateable driver, such as the
74F125. If these lines are driven by a standard TTL totem pole output,
the rtVAX 300 processor will not function.

6.1.3 Console interrupt Acknowledge Cycles
Interrupt requests to the rtVAX 300 processor from the DUART are generated
on the IRQ<0> L line when the receive buffer is full or the transmitter buffer
is empty. The rtVAX 300 processor responds to interrupt requests by initiating

an interrupt acknowledge cycle, shown in Figure 6-3; the sequence is shown in
Figure 6-2.

The INT output of the DUART asserts the IRQ<0> L input of the rtVAX 300
processor. The rtVAX 300 processor executes an interrupt acknowledge cycle,
during which it expects to read a vector from the interrupting device. The
interrupt vector generator (see Figure 6-11) drives a vector of 02C0;4 onto the
DAL bus when the ENBVECTOR signal is asserted.
The cycle status decoder (see Figure 6—6) monitors the CSDP<4:0> L and
DAL<06:02> H lines to determine if the rtVAX 300 processor is performing
an interrupt acknowledge cycle. The interrupt priority level (IPL) is detected
when DAL<06:02> H is read. If the IPL correlates to an interrupt generated
by the console, the cycle status decoder asserts the CONIACK signal.

6-4

Console and Boot ROM interface

Sample Design: Console Cycle Sequence

|
i
‘
.

DLE

'
AITECYCIL,
WRITECYC

CYCLE

RAEAD

JENBCONDATAS

WRITECYC2

ENBCONDATA.

READCYC L]

ENBCONDATAS

IOREADY-

ENBCONDATA+

WRITE

ACCESS

Yes

thads

WRITECYC3L]

READCYC2 L.
ENBCONDATA.

Y
4

;

INo

WRITECYCSL]

ENBCONDATAs|

ENBCONDATA+
.

FINISHIACK L]

ROMCYC4a

[et

READCYC4

ENBCONDATA+

IOREADY+

]

ROMCYCS

!
i
i

|
i

i
i

[Pl

pIng

ROMCYCE U

Yos
4

tND

FINISHWRAITE L]

FINISHAEAD 1]

ENBCONDATA.
IOREADY

ENBCONDATA.
IOREADY+

La'2%

START

ENBCONDATA.

IOREADY.

FINISHUP3

ROM ACCESS = LWRITE & SELROM & SYNCHAS

Q.,

WRITE ACCESS = LWRITE & LBM<c<0Oc> & CONE & SYNCHAS
READ ACCESS = ILWRITE & LBM<«<0<> & CONE & SYNCHAS

FINISHUPY
[

FINISHAOM L

IACK CYCLE = (CONIACK # CPUST) & SYNCHAS

Yos

READCYC3 L

ENBCONDATAS

IAGKCYC2

ROMCYG2

¥
ROMCYG3
U]

WRITECYCd

INo

ENBCONDATAS

IACKC VYL Y

CYCLE

ROMCYC1

READ

l} ®

off DO

Figure 6-2

The ENBVECTOR signal is asserted when DS asserts, driving the vector

onto the DAL bus. When in the IDLE state and CONIACK is asserted, the
console state machine jumps to the IACKCYC1 state and to IACKCYC2. The
state machine checks the state of P3P4 to synchronize with the rtVAX 300

and asserts IOREADY, ending the cycle. The rtVAX 300 reads the vector that
was driven onto the DAL bus and uses it as an offset into the system control

block (SCB) to determine the location of the interrupt service routine for the

console.

Console and Boot ROM interface

6-5

Figure 6-3

Sample Design: interrupt Acknowledge Cycle Timing
P1

CLKA H
{P1:P21P3 P4 P1.P2 P3 P4:P1:P2:P3 P4 P1 P2:P3 P4 P1:P2 P3:P4 P1 P2 P3|

DAL<31:0> H :)-——-( ubL HNT%ER#UP*VSCTQE)-E——%—-(ADD{RE#SH wélré evfi
ASL
.

)

WRTEL

;

——

CONIACK L

OREADYL T\
NvECTORL —————\
IDLE

IDLE

| "
s

IACKCYC2

IDLE

IACKCYC1 FINISHIACK

IDLE

MLO-004443

6.1.4 Console Timing Parameters
To ensure reliable console operation, all timing parameters of the SCN 2681
DUART and the rtVAX 300 must be satisfied. Table 6-1 lists important timing

parameters of the SCN 2681 DUART.

6-6

Console and Boot ROM Interface

‘

Table 6-1

SCN 2681 DUART Timing Parameters

Parameter Name

Minimum Time
(ns)

Maximum Time (ns)

Address getup time to RD, WR assertion

Address hold time to RD,WR assertion

WR,RD pulse width

225

Data valid after RD low

175

Data float after RD high

100

Data in setup before WR deasserts

100

Data in hold after WR deasserts

High time between WR and RD

200

Figure 6—4 shows a timing diagram of the console read and write cycle. This
state machine is clocked on CLKA; therefore, all state transitions occur on the
positive edge of CLKA. The setup times for each of these inputs were calculated

like those of the memory controller and meet the requirements of the 15 ns
22V10 PAL that was used.
6.1.4.1

Console Address Setup and Hold Times
When the rtVAX 300 is accessing the console, the address is placed on the
DAL<29:02> H bus 23 ns before the rising edge of P1. ENBCONDATA is
asserted on the rising edge of P3. The address information has to propagate

through the 74F373 latches (see Figure 6-7).
The calculation for the address setup time is as follows:
+ 74F244 turn-off time (5 ns)
+ 50 ns

+ 23 ns

— Propagation of F373
DUART address setup time

In this case, the DUART address setup time =5 ns + 50 ns + 23 ns —

Tns =71

ns.

The address on A<3:0> of the DUART will be valid during the entire console

access cycle, so the DUART address hold time is easily satisfied.

Console and Boot ROM Interface

6~7

T T i@ aumm3joshiod |

stz | Y | vivdaivale | $—{ssasaad)——r{

T13NOD
il

Console and Boot ROM Interface

6-8

Hrdtd

3y 3

Fryo0OIN

184

HYX10

. 6.1.4.2 Console Data Turn-Off Time

The turn-off time of any device connected to the rtVAX 300 DAL bus must be
less than 35 ns after the rising edge of CLKA during the last P1 cycle. Since

the turn-off time of the DUART is 100 ns, a transceiver is needed between the
DUART data bus and the DAL<07:00> H bus. This 74F245 transceiver (see
Figure 6-11) turns off with the deassertion of DS, satisfying the required bus

turn-off time. The transceiver also adds delay to the read access time and the
write setup time.

The calculation for the timing analysis for the console turn-off time is as
follows:.
+ DS deassertion delay
+ 74F32 propagation delay
+ 74F245 turn-off time
Turn-off time
In this case, turn-off time = 25 ns + 5 ns + 5 ns = 35 ns after P1 edge.
Note

The time required to deactivate memory and peripheral devices must be
considered in the application design to prevent bus contention conflicts.

6.1.4.3

Console Read Cycle Timing Analysis
Since the read access time of the DUART is 175 ns, two wait states are needed
to satisfy the rtVAX 300 read-timing. These wait states are added by delaying
the assertion of the rtVAX 300 RDY L signal.

During a console read cycle, the console state machine asserts the ENBCONDATA
signal, which enables the ENBCONRD, to the DUART, and the ENBCONDAL

signal is asserted when DS asserts. The assertion of ENBCONDAL and
ENBCONRD turns on the bus transceivers and asserts the RD input of the
DUART. The console controller state machine waits 200 ns and then asserts
the IOREADY signal within the rtVAX 300 RDY L window, adding two wait
states. The console controller completes the console read cycle by deasserting
ENBCONDATA and IOREADY for 150 ns and then waits for another console

access cycle to begin.

Console and Boot ROM Interface

6-9

Console read cycle access time is calculated as follows:
+ 5 x CLKA period
— rtVAX 300 data setup time

— CLKA edge to ENBCONDATA assertion
— 74F00 propagation delay
— 74F245 propagation delay
Access time from RD

In this case, access time from RD = (6 x50)ns - 28 ns — 12ns - 5 ns — 6 ns
= 199 ns.

The FINISHUP1 to FINISHUP3 and IDLE states deassert the ENBCONDATA
signal for at least 200 ns after each console read or write cycle. This satisfies
the 200 ns RD and WR deassertion time after each console read or write cycle.

6.1.4.4 Console Write Cycle and Data in Setup and Hold Timing Analysis
During console write cycles, the WR line of the DUART must be asserted for
at least 225 ns. The data is latched in the DUART internal register upon the
deassertion of this line. Figure 64 shows the console write cycle timing. The
ENBCONWR line is deasserted when the console state machine deasserts the
ENBCONDATA line. The console state machine asserts the ENBCONDATA
line on the P3 edge after AS asserts. ENBCONDATA remains asserted for five
CLKA cycles and deasserts on the P3 edge of CLKA before the cycle ends. At
this time, the console state machine asserts IOREADY, asserting the rtVAX
300 RDY L line and ending the console write cycle.
Memory system write cycle data in setup time is calculated as follows:
+5x 50 ns

+ DAL write data setup
+ 7T4F00 minimum propagation delay
— 74F245 propagation delay
Memory system write cycle data in setup time

In this case, data in setup time = 250 ns + 23 ns + 2 ns — 6 ns = 269 ns.

6-10

Console and Boot ROM Interface

The input data is valid on the DALs until after the P1 edge of CLKA. The
ENBCONDATA line deasserts on the P3 edge of CLKA. Thus, the data in hold
time is calculated as follows:
+ 1 CLKA period

— State machine output delay
-~ T4F00 propagation delay
Data in hold time

In this case, data in hold time = 50 ns — 12 ns — 5 ns = 33 ns.

. 6.1.5 Console Oscillator
A 3.6864 MHz crystal oscillator provides the clock signals and internal timing
to the DUART. The baud rate and other serial line configuration information
is software-programmable by writing to the appropriate console register. The
built-in firmware of the rtVAX 300 sets the baud rate to 9600 with 8 data bits
and 1 stop bit.

6.1.6 Line Drivers and Receivers
The voltages of RS-232 and DEC—423 are not directly TTL-compatible. Line
drivers and receivers must convert the TTL voltages of the DUART to the
standard voltage levels that are used for RS-232 and DEC—423 applications.
The 9636 and 9639 line drivers and receivers (see Figure 6-11) serve as the
DEC—423 interface drivers.

6.1.7 Console Break Key Support
You can set up the console terminal break key to halt the rtVAX 300 program

execution. This is accomplished by adding a break detection circuit connected
to the HLT L line of the rtVAX 300. When the break key of the console
terminal is depressed, the RXD line receiver output is asserted low for more
than 160 ms. The counter (see Figure 6—11) begins counting as soon as the
RXD line is low; it will reset as soon as the RXD line returns to the high
state. This counter is clocked by the 10 ms interval timer, and once it counts

to 16 (after 160 ms), it asserts the HLT L line of the rtVAX 300 processor and
stops counting. The assertion of the HLT L line on the rtVAX 300 processor
breaks the program execution and drops the program into console emulation.
This break detection circuit can be eliminated if a separate halt switch is
implemented or if the console break key is not needed.

Console and Boot ROM Interface

6-11

6.2 Booting from External ROM

The default booting device for the rtVAX 300 is the network. In this
configuration, the BOOT<3:0> L pins are tied to Vcc or left unconnected. (The
BOOT«3:0> L pins are tied high through pull-up resistors.) When the rtVAX
300 initializes after a power-on reset, it sends the maintenance operation
protocol (MOP) message over the network. The host system responsible for
booting the rtVAX 300 receives these MOP requests and begins to down-line
load the ELN system file to the rtVAX 300. Once this file is loaded into the
rtVAX 300's memory, the rtVAX 300 begins executing the application software

from its RAM.

Many applications require the rtVAX 300 to boot internally, independently of ‘
the state of the network or host. This is accomplished by connecting a ROM

in the rtVAX 300’s 1/O space or memory space and fixing the VAXELN system

image in this ROM. The rtVAX 300 can now boot the intended application if
the host node is not available or the network segment fails. This feature is
important if controller down time is unacceptable.

6.2.1

Base Address of External ROM
The external user ROM’s base address (first and lowest physical location) may

be at 20200000 or 16000000. To boot from this ROM, you must connect the

BOOT<3:0> L pins, as shown in Table 3-12. When the rtVAX 300 finishes
initializing after a reset operation, it begins to copy the VAXELN system image
from the ROMs to its external system RAM or runs from the ROMs. The
rtVAX 300 does not send the MOP requests over the network; instead, the
rtVAX 300 boots from the ROMs. Table 3-12 lists boot options.

6.2.2 Programming the Bost ROMs
The system file generated by EBUILD must first be down-line loaded to the

rtVAX 300 target by means of the network as the booting device. You can then ‘
use the remote and local debuggers to debug the application software. Once the
application software is running correctly, EBUILD should be used to generate
a new system file, selecting the ROM as the boot method. The resulting
.SYS file should then be run through the PROMLINK program, for example,
which creates a loadable file for the EPROM programmer. The programmed
ROMs are then inserted into the EPROM programmer, programmed, and then
inserted into their correct sockets on the user’s application module.
You can now connect the BOOT<3:0> L pins, as shown in Figure 2-7; the
rtVAX 300 boots from these ROMs.

6—12

Console and Boot ROM Interface

Note

The ROMs must be plugged into their correct sockets; otherwise, the
rtVAX 300 will not boot.

6.2.3 Boot ROM Interface Design
Figure 6-5 shows the design of a 1M-byte boot ROM connected to the rtVAX
300’s DAL lines. This ROM is constructed from eight 128K x 8 bit 27010 1Mbit ROMs. Eight ROMs are needed to construct a memory size of 1M bytes and
each ROM is connected to one of the four bytes of the rtVAX 300 DAL lines by
means of F244 drivers. During a read cycle, it is not necessary to qualify each
byte with the BM<3:0> L lines. The rtVAX 300 reads only the byte(s) in the
longword that correlate to an asserted BM<3:0> L and ignores the other bytes.
However, during write cycles you must write only to the byte(s) selected by an
asserted BM<3:0> L line. Since ROMs are read-only and cannot be written to,
the select logic need not include the BM<«3:0> L signals.
Figure 6-5 Sample Design: Boot ROM Functional Block Diagram
YT

=02

DAL<29:19
ser

WR_ ]

Latches

SELROM<O>

el HOLD

AS ) andLatch |SELROM<1>

SELROM<0>
—_—

LWRITE

ROMDATA

128Kk X 8 L

ROMDATA

| Privers DAL<31 :0>
"Rompata.
M
02K |Ho——
Address [TAnDRa823) 4 ROMs
="

>
—
AS
Address

Decoder

SELROM<O> |

———»1CS
—
|JwRITE

ROMDATA

—

ROM READ |
Bank2
o2

128K X 8

o]
e
2 EN

MLO-004445

Console and Boot ROM Interface

6-13

6.2.4 Boot ROM Address Decoder
The address decoder, shown in Figure 6-6, decodes the address placed on the
DALs by the rtVAX 300. When a valid address for ROM bank 0 (between
20200000 and 2027FFFF) is placed on the DAL bus, the address decoder
asserts the SELROMO signal. In addition, when a valid address for ROM bank
1 (between 20280000 and 202FFFFF) is placed on the DAL bus, the address
decoder asserts the SELROM1 signal. These two signals are latched by the
assertion of AS H and select the appropriate ROM bank; when the DS L output
signal of the rtVAX 300 is asserted, the ROM outputs and drivers are enabled.

6.2.5 ROM Address Latch
Since the address is valid on the DAL<29:02> H bus only at the beginning of
any rtVAX 300 access cycle, latches are needed to preserve this address for the
duration of the access cycle. The 74F373 latches shown in Figure 6-7 serve
to latch the ROM longword address upon the assertion of AS L. This latched
address, LADDR<18:02>, is fed directly into the address inputs of the ROMs.

6.2.6 ROM Read Cycle Timing
Figure 6-8 shows the read cycle timing for the ROM system. Valid data must
be placed on the DALs 28 ns before the rising edge of P1; D3 L asserts 27
ns after the rising edge of P3. To operate without any wait states, data must

be available at the same time as the assertion of DS L.1 Access time of the

ROMs used is 250 ns; therefore, you must insert three wait states. ROMREAD
asserts 5 ns after DS; thus, ROM read cycle access time is calculated as follows:
+ (number of wait states x 100)
+ P3 to P1 time
— DS assertion delay
-- Data in setup time
-- 74F244 propagation delay
- 74F20 propagation delay
ROM read cycle access time

6~14

100—72—28 = 0 ns, according to the rtVAX 300 specifications.

Console and Boot ROM Interface

. Figure 66 Sample Design: Address Decoder

Address Decoder PAL {Inciudes aich)
Note: Socke! used here

I )

UPCPUST L

RE >21

SELROM H

Re
Ra

}

118
D7

‘

Jre2

CPUST L

CONEL

IACK PAL

22V10

AT
Ro 22

R8 2

LOWCONE L
LOWCPUST L

CONIACK L

R7D% NC - Cycte Reset

DAL<235 H 1.3;—.3—10—-51—2_'1
Do

PAL

R2T :i

DAL<22> H 11

R7 D?g NC - Cycle Reset
Re D‘lQ

F32

UPCONE L

PAL
22V10

ectde PAL

r — 74

|
|

‘

DAL<21> H 10 D8

DAL<20> H

DAL<18> H

B 06

DAL<IB> H
DAL<17> H
DAL<16> H
DAL<1S> H
DAL<I4s H
DAL<13> H_

asH

7] 05
6 D
5 D3
4 D2
3 D1
2§ Do

CLK

. DAL<Z5> H

DAL<24> H

;

2‘

DAL<Z6> H

DAL<27> H

o
Lo

DAL<28> H

DAL<E> H
DAL<S> H
DAL<4> H
DAL<3> H
DAL<Z> H
CSDPeds> L

CSDP L
CSDP<0> L

st 2
WRL

———

AS H

DAL<7> H

DAL H

DAL<E> H

Lo
i

DAL<10> H

;

DAL<115 H
DAL<12> H

Note: The tVAX 300 uses CMOS ACTQ245 drivers for the DAL lines and ACTQ244 drivers for the tontrol lines.
These drivers have very fast rise and fall times which can generate a tair amount of undershoot and overshoot.

. It may be necessary to isolate these devices trom the fVAX 300 signal lines with TTL buffers or provide series
Some PAL devices and RAM chips may matfunction when exposed to excessive overshoot and undershoot.
termination resistors for these lines.

MLO-004447

In this case, ROM access timie = 300 ns + 50 ns — 27 ns - 28 ns - 6 ns - 5 ns
= 284 ns.

Table 6-2 shows a list of ROM access times and the number of required wait
states. The delay of the drivers, if placed between the ROM ocutputs and the
DAL lines, must be added to the ROM access time.

Console and Boot ROM Interface

6-—15

Figure 6~7 Sample Design: Address Latches
CTL and DPE Dnivers

AdCress Latches

8BF
8.BHt
Latch
74F373

DAL<17>H

DDR<17>T> B
1a]__ D7£eRyplt HADDR<I

DAL<16s H

17|

DAL<i8sH

14|

DAL<14> H

. b4 RaD] 12 LADDR<¢14> H

1
H
R1E>
e
RepLRADD

H
Foplts bADDRc15>

DAL<I3>H

pAL<tzs M

. R3D

» LADDR<13>H

Rop|o LADDR<12> H
1

DAL<11>H |
DAL<10> H

2 Do RoTM

¢ LADDR<11s H
2

LADDR<10> H

_
LW

bS L

—4
"

125

CONEL

ENBROM L w:'

SELCONROM L

Note' Parity checking not enabled bacause caching

P-State Flip-Flop

RST
L

A4 1B

Address Latches

B-Bit

8-Bit

> H
<9>
£ 19 LADDR<§
bttty
8 ., RTD S

£137
w|, R

Ao D} S ADDR<E> H

o RE DA

E18

CLR op

DAL<Os H | | o] D1 miplstARDRSH

sl o moplltADDR<2aH
DDRe2>

[

AS L

LBM<O> L

N
gyt
A

o oa

ASL

—] ENO

6-16 Console and Boot ROM Inteiface

Oy ENO

SYNCHAS H

DAL<2> H

P3P4 P,

)

s LWRT| EL
Re
W 5 heolb
DALeTs H | | ra] D5. Roppe FARDR<T2H gy
<18> B
LADDRAci8s
8> H 3 R‘D‘z
R<6>
_K DAL<1
13 D4 mp_‘z_i*;@_ie_’
e
DAL B> H
DAL<18>H 'l
LBMeasL
e
DAL<Ss H | | o] Rapl —HADDR<S>H gy,
LBM<a L
T Renls
oL
[ moplt ADDRedz M
DAL<#> H
ReS>

418

CLAA

Latch
74F5T3

Latch
74F373

iy
ZD PR

8BF

DAL<BsW | | 17|

not aliowed on console reads

r-—‘—C HOLD
—C] ENO

DAL<8> H

22q

;

CLKB

7N
3les

Figure 6-8

Sample Design: ROM Read Cycle Timing

CLKA H ]
h
f

!P1IP2IP3 P4 P1P2IP3 P4IP1IP2IP3
P4 PY ‘P2 P3!P4 P1.P2 'P3 P4 P1 P2.P3.P4 P1:P2:P3 P4 P1IP2IP

CLKB H \

]

)

‘

DAL<31:0> H D-:—-‘-(Aoo;ness):——(;

' OLE

IDLE

‘

INVALID DATA
!

ROMCYC2

ROMCYC1

LoflawbnbnSAog
YT

ROMCYC4 ' ROMCYC6

ROMCYC3

ROMCYCS

IDLE

FINISHROM

;

IRE

ADDREgS}=—{
WRITE BYTE |

1IDLE

IDLE

IDLE '

IDLE

MLO-004446

Console and Boot ROM Interface

6-17

Table 6-2 Typical ROM Access Time
Maximum ROM Access
Time (ns)

Wait States
Needed

Total Read
Cycle Time (ns)

300

184

400

284

500

384

600

These wait states are inserted by holding off the assertion of the RDY L signal
input of the rtVAX 300. This RDY L signal is controlled by the console state
machine. The machine jumps to the ROMCYC state when the ENBROM and
AS signals are asserted. The state machine then counts seven CLKA ticks
and asserts the IOREADY signal, which in turn asserts the RDY L line of the

rtVAX 300. Additional wait states can easily be added for slower ROMs by
increasing the number of CLKA counts (ROMCYC states) needed before the
assertion of the RDY L line.

6.2.7 ROM Turn-Off Time
The rtVAX 300 uses ROMs that have a data turn-off time of 60 ns. This time

exceeds the 35 ns specified by the rtVAX 300 processor. Data drivers are added
between the ROM data outputs and the DAL bus to stop driving the DAL
bus after DS L deasserts to prevent bus contention. The calculation of ROM
turn-off time is as follows:
+ DS deassertion delay
+ T4F20 propagation delay
+ 74F244 turn-off time

ROM turn-off time from CLKA to Pl edge

In this case, ROM turn-off time from CLKA to Pl edge =27 ns + 5 ns + 6 ns =
38 ns.
To determine if drivers are needed, add the DS assertion delay to the ROM

CS select delay and subtract the total from 35 ns. The resulting value is the
maximum turn-off delay that can be tolerated without the addition of drivers.
In this example, the maximum turn-off delay of the ROMs was as follows:

Sample maximum turn-off delay = 35 ns - 28 ns —~ 5 ns = 12 ns.

6-18

Console and Boot ROM Interface

If the ROMs take longer than 12 ns from CS deassertion to HI-Z, a set of

drivers must be added between the ROMs' data bus and the DAL bus to

prevent bus contention;! they are enabled by the ROMREAD L signal.

6.2.8 ROM Speed Versus rtVAX 300 Performance
If the ROMs are copied to RAM, the speed of these ROMs affects only the time
required to boot the VAXELN system on the rtVAX 300. Once the rtVAX 300
has finished booting, it runs out of system RAM and no longer accesses the
ROMs: The entire system image has been copied from the ROMs to system
RAM before the VAXELN kernel begins executing. If a loi =r boot period can
be tolerated, slower ROMs can be used. If the rtVAX 300 is designed to run

out of the ROMs, the access time of the ROMs directly affects the runtime
performance.

6.3 rtVAX 300 Processor Status LED Register
Many applications must have a visual indication of the rtVAX 300 processor
status. Two 7-segment LED displays and a status register can be implemented
on the user’s application module to use as a processor status display. When
the rtVAX 300 firmware is performing its self-test, it writes to that register

to show the progress of the self-test. This register is at physical address

201FFFFE and is implemented as shown in Figure 6-9. The implementation

of this register is optional; if it is deleted, the rtVAX 300 continues to perform

its self-tests correctly.

6.4 Console Interface and Boot ROM lllustrations and
Programmable Array Logic
This section shows console interface and boot ROM illustrations and describes
the programmable array logic (PALSs) used.
*

Figure 6-10 shows the memory map for all the RAM and ROM registers;
Table 6-3 lists the corresponding equations.

Figure 6-11 illustrates a sample design of a console interface.

Figure 6-12 and Figure 6-13 illustrate sample designs of user boot ROM
banks 1 and 2, respectively.

! The ROMs used in the example were specified at 60 ns from CS deassertion to HI-Z.
Console and Boot ROM interface

6-19

Figure 6-9

Sample Design: Processor Status Display
4BE

—

DAL<23> H

18 ‘m

HEX

a1
QB

oE
Lo

DAL<22> H

2 _ina Mb‘""‘“‘"‘““’ ; |

DAL<21> H

5 o

DAL H

Aige.
P

]

w%‘a

ag“"“““““"!

—=-i

g HOLD
—
7
J

vie

+8V

4BF
4D Fip;
748175

DAL<18> H

[

" Rabe

ing

DAL<18> H

2 _jp

DAL<17> H

Aie.

DAL<162 H

4 oo

‘

|
]

11y

)
104F32 b

12 O

] —Tegh

‘g‘a

4
s

98
——gHaD
by

L&!m“_‘—‘fi
4
CPUSY |

o
HEX

|
i

g !
,;\,gcm“‘
4BF

4 Fp

74L5175
16

DAL<25> H

18 _ing

DAL<24> H

12
.

RST L

CPUST L

6-20

532
-

1B
DS L

R15a

£ \

ins

RATX

078

2 F32

Console and Boot ROM Interface

\.s

F!DS:

w— 1Y)
MLODOAED

. 6. 4 1 Application Module Address Decoder PAL

The application module address decoder PAL selects the memory and I/0

devices. It asserts the UPCPUST, SELROM, and CONE signals for the system
console and the external boot ROM. The ROM and console select lines are
internally latched on the rising edge of AS H. This eliminates the need for
external device select latches by using the D flip-flops that are built into the
22V10 PAL. Table 6-4 lists pin settings.
Figure 6-10

Application Module Address Decoder Memory Map

Memory Locations

Device

Selected

2423

DAL<29:2>
16 15

0807

CONE

20100000 - 2010003F

|100000]

ROM
CPUST|

20200000 - 202FFFFF
201FFFFE
- 201FFFFF

100000 ] 0010 XXXX | XXXXXXXX | XXXXXX
[100000 | 00011111 ] 14111111}
111111

00010000 | 00000000 ] 00 XXXX

M1.O-004453

Table 6-3

Line

Decoder Equations

UPCONE.D

Equals

DAL29 & 'DAL28 & 'DAL27 & !DAL.26 & 'DAL25 & 'DAL24 & 'DAL23
& 'DAL22 & 'DAL21 & DAL20 & 'DAL19 & !DALIS & 'DAL17 &
'DAL16 & 'DAL15 & 'DAL14 & 'DAL13

UPCONE.AR

CYCRES

SELROM.D

DAL29 & 'DAL28 & 'DAL27 & 'DAL26 & 'DAL25 & 'DAL24 & !DAL23
& 'DAL22 & DAL21 & 'DAL20

SELROMAR

CYCRES

UPCPUST.D

DAL29 & 'DAL28 & 'DAL27 & 'DAL26 & 'DAL25 & 'DAL24 & 'DAL23
& 'DAL22 & 'DAL21 & DALZ0 & DAL19 & DALI18 & DAL17 & DAL16

& DAL15 & DAL14 & DAL13
UPCPUST.AR

CYCRES

AS & (UPCPUST # SELROM # UPCONE)

Console and Boot ROM Interface

6-21

Table 64

Application Module Address Decoder

Setting

Input Signals
1

DAL13

DAL14

DAL15

DAL16

DAL17

DAL18

DAL19

DAL20

DAL21

DAL.22

DAL23

DAL24

DAL25

DAL26

DAL27

DAL28

DAL29

Output Signals

6-22

'UPCONE

'UPCPUST

SELROM

CYCRES

Console and Boot ROM Interface

Figure 6-11

Sample Design: Console Interface

IMerrupt Vecior Genersor

4BF

Consols imemrupt Vector = 02C0

Driver

57%&“

Tlins

Y2D1—!——

13 iy

Yooy

Al <14» H

DAL<13> H

]

AL<12> H

DAL<S> H

4BF

n‘%m

2 o3
tlpe

os
2-po

<11>

<10> MW

17}

M o8
Yoo

DAL<2

DAL<1> H
<0> H

DALS> H
AL<8> H
oI

1den

e
4BF

<d>
H

OAL<3>

“

Ootal w

ved

qen

X8
L

TXAL

LWRITE \
w)

Octal
Driver

T4LS244

[

Var-d—
_ DAL<T> H

Ve s

AL H

Y141

DAL<S> H

yoo-2

DAL<é> H

311
11

5
ggs'iu

ENBVECTOR L

RXDA H

gia H
12

CAL<3>

O
1
DAL<2> H

slp
0o

Yoo 18

DAL<0> H

5 1805
E46

;!
:

10 Ig b"— !
|

INTM L

HLT L

Note: Socket ussd here
~ —F—"“m&
10

Eios

TR
fl

W:—Jflrr"
2—
L

;

—

SYRCHAE W

SLGA H

Br® sta

;

55_

;

+5V

Concale, ROM and IACK Stste Machine

Conmle PAL

den

160 me Braak Detection

aile

tICiK

Console and Boot ROM Interface

6-23

PAGE

6-24

INTENTIONALLY

LEFT

BLANK

Figure 6-12
"'“mfi a

(UY 1
2L
AV

4BF

T TUVPHOM] ]

Octal
ol

3ROMDATAGts H

lUE:ITl N

TaF2es

2 ROMDATA<30> H

E4D

19 ROMDATA<29> H

77 AOMOATAQRT>
B

| | ———

14 ROMDATA<2S> H

18_ROMDATA<28> H

< ?} H

128KX8
e

1AD

;

—

> H

CABOFCS =R

74F204

20 ROMDATA<14> H

E37

17 [pa

Y30

18 ROMDATA«12> H

15_ROMDATA<10> H

DAL28y
H

14 FOMDATA<O» H

LADDR<185 H

CIDORSTBS

TADD!

17> H

=
]

13 faq

|
i

‘

DAL<145 H

)

DAL<12> H

48F

1rzu

Driver
e

;

voole

OAL<1Ss M

" AQ

13 AOMDATA<8> H | |

15 ROMOATA<13> H

17_ROMDATA<11> H

48F

Ovtal
Sl

31 ROMDATA<1§> H

H—L—jm—u

oo e

13 ROMDATA<24> H
Rc18»

AL1a M

48F

AL<30> M

15 ROMDATA<26> H

fi"f‘; 1

Sample Design: User Boot ROM Bank 1 with Drivers

Yapi-14_

DAL<10> H

vooi-le

DALH

T BD

DAL<9» H

A1
f

—W‘

48F

21 ROMDATA3» H

. %‘

|20 BOMDATAR2> H

. B39

19 ROMDATA<21> H

17 ROMDATA<19> H

14 ROMDATA<17> H

7 UVPROM |

TAs16

19 a4

;

15 ROMDATA<18> H
'

1%~

1
|

vzo 8

DAL<23>

DAL<2 W

Vil

DALZI> H

| 20 BOMDATA W

19 ROMDATA<E> H

DAL<20> H

aBr

L,
|

ROMREAD L

%&;> —

vaS 12
Y2r

145y

15_ROMDATA<2> H

12
DAL<7>
H
8 fpy YTt

—_—

DAL<1> H

—
|
o

% g—=w—1
>¥

TM UVPRAOM |

|g\1BKE

DOoRETYS

DAL<18> H

DAan

«i
>Ag
i

BEbRE T
>

Y2pi

tiyg

14 ROMDATA H

Ootal

17 ROMDATA<3> H

%‘.

DRALsg2

OAL<ES

M ppt8
. DAL<E> R

|13 ROMDATA<0> H__

4BF

7]t ROMDATAST:

| Driver

pdjd

;

" vomt

OthoPs T

TUVPROM

m% %’WM

1y YD

18 ROMDATA<Z0> M

R10

Vool

DAL<d> H

A9
lldeN

(

48F

o [

V35 1

DAL<3>

1rp

Y2oi-it

DAL<2> H

Vil

<1> H

|
:

Oriver

ROMREAD L

OLLIPe

T4 50N

PONBRRTs L2

g@"m"‘”"

ROMREAD
L
|
1dmy
UV PROM 27010 128KXBUV EP
Address Rangs 20200000 o 2027FFFF
MLO-Co4481

Console and Boot ROM Interface

6-25

PAGE

6-26

INTENTIONALLY

LEFT

BLANK

Figure 6-13

Sample Design: User Boot ROM Bank 2

Address Range 20280000 to 202FFFFF

oFT I

" UVPROM |

\128Kx8
18

ROMDATA<23> H
MDAT.

%:f"

.21

ROMDATA<15» H
le)

14> H

ROMDATA<7> H

ROMDATA<€> H

ROMDATA<21> H

AOMDATA<13> H

ROMDATA<5>
H

ROMDATA<28> H

)

ROMDATA<20> H

ROMDATA<12> H

ROMDATA<4> H

__ROMDATA<26> H

ROMDATA«<2> H

ROMDATA<2T> H

AT,

| 17

ROMDATA<II> H

ATA<18>

‘

ROMDATA<10> H

AOMDAT <25> H

ROMDATA<17> H

ROMDATA<#> H

ROMDATA<1> H

ROMDATA<24> H

ROMRATA<16> H

ROMDATA H

ROMDAT A<0> H

LADDR<18>
H
<175

UVPROM |

[ UVPRCM 4

L1 28Kx8
18

J—

}A 1

CADDH<14> X
PR
DA

—

FADDR<E H

mq__

</> P

TS
TR . —

DADDRSAs H—— 10

ROMREAD L

> H

LAOM<1> L

SELROM<O> L

7 UVPROM 1

16)

128KX3

[, 1

fil_‘.’um

ENICUTP!

AOMREAD L

;

WYl
m——
T
24

ENIOU
|

12BKXBUVEP

.
48V

ROMDATA<3>
H

> M

Uv PROM 27010

LADDR<18>
H
g‘%flfl‘b

EXODRTT

LADOR«18> H
2
J128Kx8
W18 i

S
A5
<105

—E—

ROMDATA<3U> H

_.DDR<18>
H
[ADDR<T 7>

ROMDATA<31> H

H s

DEH

107

—Lw 2
K

TWHITE T 17 ]

ROMREAD L
MLO-004452

Console and Boot ROM Interface

6-27

PAGE

6-28

INTENTIONALLY

LEFT

BLANK

Table 6-5 (Cont.)
Pin

Console Sequencer State Machine PAL

Signal

Comment

Output Signals
16

TOREADY

This output asserts the tVAX 300 READY line to
signal that valid data is on the DAL lines and the cycle
should end.

STATEA

This output correlates to a state bit for this machine.

STATEB

This output correlates to a state bit for this machine.

STATEC

This output correlates to a state bit for this machine.

STATED

This output correlates to a state bit for this machine.

STATEE

This output correlates to a state bit for this machine.

ENBCONDATA

The assertion of this signal enables a DUART read or
write cycle.

You define a state name for each bit pattern as follows:
FIELD

CONSOLE =

[STATEE, STATED, STATEC, STATEB, STATEA],

SDEFINE IDLE

'B’00000
SDEFINE WRITECYC1 'B’00001
SDEFINE WRITECYCZ "B’00010
$DEFINE WRITECYC3 "B’ 00011
$DEFINE WRITECYC4 B’ 00100
SDEFINE WRITECYCS

‘B’00101

$DEFINE FINISHWRITE
SDEFINE READCYC1

'B’00110

'B’10001

SDEFINE READCYCZ

"B’ 10010
READCYC3
'B’10011
SDEFINE
READCYC4
'B’10100
NE
$DEFI
FINISHKEAD
'B’10101
NE
SDEFI
FINISHUP1
'B’'10110
NE
SDEFI

$DEFINE FINISHUPZ

'B’10111

SDEFINE FINISHUP3 'B’11000
'B'00111
SDEFINE I0CY¥CL
‘B’01000
SDEFINE IOCYC2
$DEFINE FINISHIO 'B’'01001
’B’01010
SDEFINE ROMCYC1
’'B’01011
SDEFINE ROMCYC2
'B’01100
$DEFINE ROMCYC3
'B'01101
$DEFINE ROMCYC4
'B’01110
$DEFINE ROMCYCS

6-38

Console and Boot ROM Interface

SDEFINE ROMCYCE

'RB’01111

SDEFINE FINISHROM 'B’110(1

SCEFINE ILLEGALI

'B’11010

SLEFINE ILLEGAL2

'B’11(11

SDEFINE ILLEGAL3

’B’11100

SDEFINE ILLEGRL4

'B’111C1

SDEFINC ILLEGALS
SCEFINE ILLEGALS

'B’11110

SDEFINE ILLEGRL?

'B’'10000

'B’71111

You set access and cycle information as follows:
LWRITE

'LWRITE

ROMACCESS

LWRITE

ZACKCYCLE

(CONIACK # CPUST)

WRITEACCESS
READACCESS

LBMC

&
&

CONE

IBMO

ENBROM

CONE
&

SYNCHAS;

SYNCHAS,

SYWCHAS;

You force the idle state during power-up and reset assertion, as follows:
ENBCONDATA
.AR =

RST;

ENBCONDATA.SP

"B’
{;

IOREADY
. AR =

RST;

IOREADY.SP

'R’ (;

STATEA.AR

= RST;

STATEA.SP

'R’ (;

STATER.AR = RST;
STATEB.SP

'B’'(;

STATEC.AR = RST;
STATEC.SP

'B’'(;

STATED .AR = RST;

STATED.SP =

'B’'(;

STATEE .AR = RST;

STATEE.SP

'B'(;

The state machine listing is as follows:
SEQUENCE

PRESENT

CONSQOLE

{

IDLE

WRITEACCESS NEXT

READACCESS

IACKCYCLE NEXT

WRITEC7/C1

NEXT READCYC1

OUT ENBCONDATY;

O T

ENRCONDATA;

IOCYC1;

IF ROMACCESS NEXT ROMCYC1;
DEFAULT NEXT

IDLE;

PRESENT WRITECYC1
NEXT WRITECYCZ

OUT ENBCONDATA;

PRESENT WRITECYC2
NEXT WRITECYC3

OUT ENBCONDATA;

PRESENT WRITECYC3
NEXT WRITECYC4

OUT ENBCONDATA;

Console and Boot ROM interface

6-31

PRESENT WRITECYCY
NEXT WRITECYC5

OUT ENBCONDATA;

PRESENT WRITECYCS
IF

'P4 NEXT FINISHWRITE OUT ENBCONDATA
OUT IOREADY;

DEFRULT NEXT WRITECYCS

OUT ENBCONDATA;

PRESENT FINISHWRITE

NEXT FINISHUP1:
PRESENT READCYC1

NEXT READCYC2 OUT ENBCONDATA;
PRESENT READCYC2

NEXT READCYC3 OUT ENBCONDATA;
PRESENT READCYC3
NEXT READCYC4

OUT ENBCONDATA,

PRESENT READCYCY

'P4 NEXT FINISHREAL OUT INBCONLATA
OUT

DEFAULT

IOREADY;

NEXT READCYC4

QUT ENBCONDATA;

PRESENT FINISHREAD
NEXT FINISHUPL;

PRESENT FINISHUP1
NEXT FINISHUPZ;

PRESENT FINISHUPZ
NEXT FINISHUP3;

PRESENT FINISHUP3
NEXT

IDLE;

PRESENT

IOCYC1

NEXT IOCYCZ;
PRESENT IOCYC2
IF

'P4 NEXT ¥INISHIC OUT IOREADY;

DEFAULT

10CYCZ;

PRESENT FINISHIO
NEXT

IDLE;

PRESENT ROMCYC1
NEXT ROMCYCZ;

PRESENT ROMCYC2
NEXT ROMCYC3;

PRESENT ROMCYC3
NEXT ROMCYC4;

FRESENT ROMCYC4
NEXT RO:CYCS:

PRESENT ROMCYCS

NEXT ROMCYCE;

PRESENT ROMCYCH

'P4 NEXT FINISHROM OUT

CEFARULT

NEXT ROMCYCE;

PRESENT FINISHROM
NEXT IDLE;
PRESENT

PRESENT
NEXT

6~32

ILLEGAL1

IDLE;

ILLEGALZ

IDLE;

Console and Boot ROM interface

ICREADY;

PRESENT ILLEGAL3
NEXT

IDLE;

PRESENT
NEXT

ILLEGAL4

IDLE,

PRESENT ILLEGALS
NEXT

IDLE;

PRESENT ILLEGALG
NEXT

IDLE;

PRESENT ILLEGAL7
NEXT

IDLE;

}

6.4.3

Interrupt Decoder PAL
The interrupt decoder PAL decodes the CSDP<2:0> L, CSDP<4> L, and
DAL<06:02> H lines to determine when the rtVAX 300 is running an interrupt
acknowledge cycle. The CONIACK signal is asserted when the rt VAX 300 is
running a console interrupt acknowledge cycle for a console interrupt (IPL
1414). The console is connected to the rtVAX 300 IRQ<0> L line. DAL<12:06>

H lines are decoded to produce the LOWCONE signal to enable the console.
The CONIACK and LOWCONE outputs are internally latched by the rising
edge of AS This is accomplished by using the internal D flops to store the

output information. The ENBVECTOR output asserts to drive the interrupt

vector onto the DAL bus during an interrupt acknowledge cycle.

Table 66 lists the pins, signals, and comments; Table 6-7 lists the
corresponding equations.
Table 6-6
Pin

Interrupt Decoder

Signal

Comment

Input Signals

This is the active high (inverted) rtVAX 300 address strobe signal,

AS L. It is used to ciock the internal latches on the rising edge
while WR L, DAL, and CSDP L information is valid.

'DS

This data strobe line, DS L, of the rtVAX 300 is asserted when
the processor is expecting to receive the interrupt acknowledge
vector from the DALs.

'WR

WR L signal from the rtVAX 300 is high during an interrupt

acknowledge cycle.
4

CSDPO

The cycle status bit 0 1s asserted during an rtVAX 300 external

interrupt acknowledge cycle.
(continued on next page)

Conscle and Boot ROM Interface

6-33

Table 6-6 (Cont.)
Pin

Signal

Interrupt Decoder
Comment

Input Signals

CSDP1

The cycle status bit 1 1s asserted during an rtVAX 300 external
interrupt acknowledge cycle.

CSDP2

The cycle status bit 0 18 deasserted during an rtVAX 300 external
interrupt acknowledge cycle.

CSDP4

The cycle status bit 4 18 deasserted during an rtVAX 300 external
interrupt acknowledge cycle.

DAL2

DAL line 2 from the rtVAX 300 contains information about the
IPL of the rtVAX 300 By decoding the DAL and CSDP lines,
this PAL can determine when the rt VAX 300 is running a console
interrupt acknowledge cycle.

DAL3

DAL line 3 from the rtVAX 300 contains information about the

IPL of the rtVAX 300. By decoding the DAL and CSDP lines,
this PAL can determine when the rtVAX 300 is running a console
interrupt acknowledge cycle.

DAl4

DALS5

DALS

DAL line 4 contains information about the IPL of the rtVAX 300.

By decoding the DAL and CSDP lines, this PAL determines when
the rtVAX 300 is running a console interrupt acknowledge cycle.

DAL line 5 contains information about the IPL of the rtVAX 300.
By decoding the DAL and CSDP lines, this PAL can determine
when the rtVAX 300 is running a console interrupt acknowledge
cycle.

DAL line 6 contains information about the IPL of the rtVAX 300.

By decoding the DAL and CSDP lines, this PAL determines when

the rtVAX 300 is running a console interript acknowledge cycle.

DAL7

DAL line 7 is used as one of the console address decoder inputs.

DALS

DAL line 8 is used as one of the console address decoder inputs.

DALY

DAL line 9 is used as one of the console address decoder inputs.

DAL10

DAL line 10 is used as one of the console address decoder inputs.

DAL11

DAL line 11 is used as one of the console address decoder inputs.

DAL12

DAL line 12 is used as one of the console address decoder inputs.
(continued on next page)

6-34

Console and Boot ROM Interface

Table 6-6 (Cont.)

Interrupt Decoder

Comment

Signal

Output Signals

LOWCONE

'LOWCPUST This signal selects the processor status LED register and the
UPCPUST of the address decoder.

ICONIACK

This signal is asserted when the rtVAX 300 is running an
interrupt cycle for the console.

ICYCRES

This signal resets all the select outputs asynchronously once AS
deasserts.

Table 6-7

This signal and the UPCONE of the address decoder select the
console.

Interrupt Decoder PAL Equations

Line

Equals

CONIACKD

'WR & CSDP4 & !CSDP2 & CSDP1 & CSDPO & DALG6 & !DALS &
DAl4 & 'DAL3 & 'DAL2

CONIACK.AR

CYCRES

LOWCONE.D

'DAL12 & 'DAL11 & 'DAL10 & !DALY & !DALS & 'DAL7 & !DAL6

LOWCONE.AR

CYCRES

LOWCPUST.D

DAL12 & DAL11 & DAL10 & DALY & DALS8 & DAL7 & DALS &
DAL5 & DAIL4 & DAL3 & DAL2

LOWCPUST
AR

CYCRES

'AS & (CONIACK # LOWCONE # LOWCPUST)

Console and Boot ROM Interface

6-35

X
XXX
XAAKL
A

p.o9.0.0:080
p850805084

KAXAXAXAKNIL

AL
LA LLKA A
KXA

0048¢
60096944848
$9.9.4.9.9.8.406.3.0499044

KAXAXKAK
LK KK KKLLKLK

).0.0,0.0:0.6.0.9.8.6.9.0.60908¢480
p8.6.0.0.0.6.6. 6049604440508
PA.00.00.0.00.080.¢8.404404844404

KEXEK AKX UK U HE UKL XL KK KLLKA,
80
PO.0.0008600.0.00.08060040648804

P OGS GO0 0000600400680 6408680040¢
P O8O0 0066008606000 00098886888405460¢

PO 00 069600000.000008068§8860808004908

04
08000804
PIRIN O SO OO OGP0.0.000064900
99068004840¢
PO908.06:0.0.0.0.0.0006.0009084896686

6
00400
0000
48 06 000804¢800
PRGOS 000.0609000000

600N DO 0$0080.00480866.999608060889600,
)9.9:6:90.0:0.9.9:0.0.09.8.0.040.9440.80.09.65660.60680649¢0¢9094¢
04,
0009
00 P 0PV GGG I SIS IVEIVIES0000005000004
P o000 P

XA XK KK AKX XK XK A KKK

XK LK AR KL KA KA KL AL LU LA AL XL LA KA

7
Network Interconnect Interface
The rtVAX 300 processor connects easily to Digital’s Ethernet network. The

VAXELN kernel can include DECnet communication through the built-in
Ethernet interface.

This chapter discusses the following topics:

DECnet communications (Section 7.1)

Ethernet interface (Section 7.2)

Thickwire network interconnect (Section 7.3)

ThinWire support (Section 7.4)

Ethernet coproessor registers (Section 7.5)

Hardware implementation example (Section 7.6)

7.1 DECnet Communications
The rtVAX 300 processor allows the transfer of information and programs
among Digital’s systems, and among Digital's and other manufacturer’s
systems. Network communications between Digital’s systems is facilitated by

DECnet hardware and software.

VAXELN programs developed on a host VAX processor can be loaded into
the target rtVAX 300 based application through the network. The rtVAX 300
communicates with other VAX processors through the Ethernet local area
network. Systems and devices can easily be connected to the network; network
expansion is possible without interrupting network operations. Programs and
data can be transferred between realtime applications and VAX processors in
the network.

Network Interconnect Interface

7-1

Ethernet provides the following features:

Simplified network design allows installation of new devices without
interrupting communication.

(Cable segments can be added to expand networks.

Remote locations have fast access to data.

High-speed communication can take place between nodes.

7.2 Ethernet Interface
The Ethernet coprocessor and serial-interface adapter (SIA) built into the
rtVAX 300 provide the basis of an interface to an Ethernet network. The
coprocessor has these features:
e

It supports virtual DMA and buffer management.

It contains one 120-byte FIFO queue for data reception, and another for
data transmission, with loopback capability.

It complies with IEEE Standard 802.3.

It provides collision handling, transmission deferral and retransmission,

and automatic jam and backoff.
¢

It has a continuous packet rate of up to 14,000 frames per second.

The Ethernet interface can perform DMA transfers directly to the 256M bytes
of system RAM. The coprocessor is programmed by reading from and writing
to a set of registers on the rtVAX 300. Figure 7-1 shows a block diagram of an
interface which supports AUI connection to thickwire and ThinWire or direct
connection to ThinWire.

Proper operation of an Ethernet/IEEE 802.3 interface requires precise and
specific physical design of the power and ground arrangements Briefly,
components connected to the trunk network cable must be dc and low
frequency-isolated from system ground. This isolation is provided by the
isolation transformer and dc-to-dc converter. Figure 7-3 illustrates this
isolation.

7-2

Network Interconnect Interface

‘

Figure 7-1 Network Interconnect: Controller Block Diagram
AVAX 300

Application

‘

' C!::ip

ansceiver

*‘[[

]

ThinWire

isolation

Transformer

;

Switching

Unit

“

‘_ v

AUl Cable

15-Pin

b o e e

D-Sub

e e e e

‘

e e

Media
MLO-004456

7.3 Thickwire Network Interconnect

Thickwire Ethernet interconnect requires addition of an external isolation
transformer and a 15-pin D-sub connector to the rtVAX 300. Figure 7-2
shows the wiring requirements for the collision detect, receive, and transmit
signals for this connector. (Figure 7-2 shows a jumper array, to allow alternate
support of a ThinWire interconnect. Figure 7-5 shows the AUI connector and
pinning.)

7.4 ThinWire Support
The rtVAX 300 connects to a ThinWire Ethernet network through the DP8392
transceiver and a few other components. An isolated —9V power source is
needed to support the ThinWire connection.

The user’s application can incorporate the design shown in Figure 7-5, which
allows selection of either the thickwire or the ThinWire configurations.

Network Interconnect interface

7-3

Figure 7-2 Network Interconnect: Isolation Transformer and Jumpers

XMIT+

‘QE

AUI_XMIT+ ~——ot2]

XMIT-

lfl ws

G
!

}{

16 XMT+

XMT

13 RCV +

RCV -

COL+

rntVAX 300

AUL_XMIT- ——-130]

1
-{]

RX+

20
3

hl]

RX-

AUI_RCV:

2[;

Note:

o All etch to and from T1 to be of

———]

minimum length, with each differential
:

COLL+

AUI_COLL+

COLL-

—{

pair having identical lengths and

paired runs.

20
)

AUl_coLt- ——130

MLO-006302

7.5 Ethernet Coprocessor Registers
The rtVAX 300 Ethernet coprocessor is programmed by reading from and
writing to a set of 16 registers at locations 20008000 through 2000803F. Refer
to Section 3.6.1 and Table 3-17 for a full description.

The Network ID ROM provides a unique physical network address for the
rtVAX 300, readable at locations 20008040 through 200080BF. This address
is predetermined by Digital and cannot be changed. This network address is
marked on the rtVAX 300 body.

7-4

Network Interconnect Interface

' 7.6 Hardware Implementation Example

A dual-purpose ThinWire/Attachment Unit Interface (AUI) design was chosen

as the sample design, because many designs now incorporate IEEE 802.3
network interfaces through either ThinWire or AUI. The terms ThinWire and
AUIT should be understood.
Many aspects of these two interfaces are similar; however, detailed

implementation of the two differs significantly. The main difference lies
in the connection of the network controller to the media: ThinWire adapters
are designed specifically to attach directly to the ThinWire (RG58-like) cable,

that is, they employ an internal MAU.
In contrast, AUI interconnects never attach directly to the media. Instead, they
employ an IEEE 802.3 standard interface to a Media Attachment Unit (MAU),
which will attach to the media. Figure 7-1 shows a block diagram of the
sample design. The broken lines indicate the design’s functional boundaries.

7.6.1

Overview of Ethernet Interface
Figure 7-3 shows an Ethernet interface block diagram. This interface supports

both direct ThinWire and AUI interfaces.

. 7.6.1.1 Ethernet Interface Functions

At the heart of all Ethernet interconnect systems are three basic components:
¢

The MAU

The Manchester data encoder-decoder, sometimes called an EnDec)

The local area network controller

The MAU is incorporated in the user module if direct media attachment to
TuinWire is required; the other two components are implemented within the

rtVAX 300.

The MAU allows access to the medium and handles certain critical timing

and amplitude level conversions. The DP8392 CTI chip performs the MAU
functions for the ThinWire medium.

Network Interconnect Interface

7-5

Figure 7-3 Network Interconnect: Ethernet Interface Block Diagram

/_};—— Bypa:ssing _37

+12V et BC.t0-DC

+12V RTN — Converter

|
|

rtVAX 300

DP8932

\V/

XMIT 2
RX 2

coLL2l

XMT -

TXO

XMT +
RCV +

RXI
anp j— OO

—%

Isoléltion | Jumpers (!

Isolation

RCV - | Transformer E

e T Boundary

COL +

coL -

—

AUI_XMIT ")

Saidatint y

AUI_COLL ] AUI

)

+12V

AUI_RCV ’,
7

‘

1Conn

+12V RTN

—_L__ S—
-

/77

MLO-008370

Table 7-1

MAU Signals Description

Signal

Description

inputs from MAU Interface

Collision+, Collision—

These are signals of + 1V on a 78 (2 differential
pair.

Receive+, Receive—

These are signals of + 1V on a 78 §? differential
pair.

Outputs to MAU Interface

Transmit+, Transmit—

7-6

Network Interconnect [nterface

Differential Manchester-encoded, drive 78 ?
differential. No pulldown resistors.

‘

. 7.6.1.2 DP8392 Transcelver Chip

This section describes the transceiver chip and its interface functions.
Figure 7-2 shows the rtVAX 300 isolation transformer and jumpers.
The major transceiver functions are as follows:
Transmit—The DP8392 chip takes a differential input (output of the
rtVAX 300) and drives a single-ended ac signal onto the ThinWire Ethernet

coaxial cable.
Receive—A signal is received from the coaxial cable, corrected for
frequency distortion, and driven to the rtVAX 300 on the receive differential
pair. The receiver has high input impedance, and low input capacitance,
to minimize reflections and loading of the ThinWire coaxial cable. The
receiver squelch prevents nois: on the coaxial cable from triggering the
receiver. At the end of reception, the squelch also serves to prevent dribble

bits.
Collision Detect—A low-pass filter extracts the average dc level on the
coaxial cable and compares it to the collision threshold. The collision
threshold is met if more than one transmitter is simultaneously active on

the coaxial cable. The DP8392 chip signals the collision to the rtVAX 300

by a 10 MHz signal on the collision differential pair.
Heartbeat Generator—After each transmission, the DP8392 chip sends a
10 MHz signal to the rtVAX 300 on the collision differential pair. This tests

the collision detection circuitry. The heartbeat (also called the SQE test)
may be disabled with the HE pin.

Jabber Monitor—The DP8392 chip monitors each transmission with a

watchdog timer. If the transmitter is active for an illegal length of time,
the transmitter is disabled. Thus, jabbering (broken) nodes are not allowed
to interfere with the operation of the network.

Figure 7—4 shows an DP8392 chip block diagram. On the coaxial cable side, the
DP8392 chip connects to the 50 12 Ethernet coaxial cable by a BNC connector.
On the rtVAX 300 side, the DP8392 chip differential signals connect to the

rtVAX 300 differential signals through isolation transformers.

Network Interconnect Interface

7~7

Figure 7-4 Network Interconnect: DP8392 Chip Block Diagram

Data

RXI

Receivers

Receive
Squeich

pE——
g

CD+

10 MMz

Line

CD-

Oscillator

Driver

Collision

Detection

HBE

Transmit

Squelch

Heartbeai

TX+

X-

Generator

1 Data

»| Transmitter

Jabber

Monitor

Transceiver
Interface

TX:
Medium
Intertace
MLO-004461

7.6.2 Iimplementation of Design
The following sections discuss implementation considerations:

7-8

Section 7.6.2.1 discusses the transceiver.

Section 7.6.2.2 discusses layout requirements.

Section 7.6.2.3 lists Ethernet board parts.

Section 7.6.2.4 discusses the dc-to-dc converter.

Network Interconnect Interface

' 7.6.2.1 ThinWire Transcelver

Figure 7-5 shows the ThinWire interface (BNC connector) and the AUI
connector (15-pin D-sub). Included in this figure are the BNC connector for
direct ThinWire connection and the required capacitive bypassing between
reference planes. The DP8392 transceiver chip must be connected directly to
the coaxial BNC connector by an etch run of less than 4 cm.
The 15-pin D-sub connector is the AUI interface to an external MAU, if one

is employed. Note that either the direct ThinWire connect or the external
MAU can be employed, never both. W8 is the Heartbeat enable jumper for the
DP8392 chip; W9 is the Ethernet/IEEE 802.3 isolation jumper. W9 should be

installed for standard product shipment.

Note

The isolation transformer is not shown in Figure 7-5.

7.6.2.2

Layout Requirements

® The shell of the AUI connector must be attached to the chassis ground.
¢

Etch running from pin 6 of the AUl connector to the 12V return, and

from pin 13 of the AUI connector to the 12V source, must be capable of
maintaining a steady-state current of 5 A.
¢

It is recommended that the 12V return line (pin 6) be taken from the AUI

connector and returned to the power supply directly. The return for the
12V supply should not be connected through logic ground due to possible
noise problems caused by ground loops.

.
e

Pins 4, 5, and 13 of the DP8392 chip require thermal relief. This can be

accomplished by connecting these pins to the —9V plane by an etch pad

with a surface area greater than 6.45 cm? (1 inch?).
¢

Placement of the BNC connector is critical. In order to reduce stray

capacitance, place the BNC connector as close as possible to the DP8392
chip, no farther than 4 cm etch length away, and void all planes beneath
the connecting etch.

Network Interconnect Interface

7-9

Figure 7-5 Network Interconnect: Transcelver, BNC Connector, and AUl Connector ‘
-9V

R11 ¢ R24 $R22

1499 ¢499

—n

COLL+—

201

R16

7499 ¢ 499

COLL-

-oV—_2
ov—30

COAX

_@_

RX+

R20

XCVR]

1
AY’7_[£ cD CD- P&

¥oDGG“

CD+ T

XMIT-

— RX-

lgP8392

XMIT+

TRANZORB

¥
4700PF
AN

8RX )
RX. b8

1000V
/77

)
+12V

OAVe,
2A

014
X012

AUI_RCV- —--—~'-—O_l
o 1

AUI_XMIT- ————010
AUI_COLL- ————Og

e The shell of the D-Sub connector J2 to be

attached to chassis ground.

e The etch for ground B and +12V to J2 must
be capable of handling a current of 5A.

e Ground B to be connected to logic ground
at the power supply only.

e Pins 4, 5, and 13 of E4 tc be connected to
the VEE plane with a surface area >1 sq in

for heat dissipation purposes.

O6
O

AUI_RCV+ — 1 °

C}4

AUI_XMIT+ _"""02
AUI_COLLy ——0O

Notes:

» Place E4 within 2 cm of J1. Void all planes
as near to J1 as possible.
® A indicates the -9V return.
¢ B indicates the 12V return.
MLO-006383

7-10

Network interconnect interface

. 7.6.2.3 Typical Ethernet Board Parts List

Table 7-2 shows a list of parts used in this design example.
Ethernet Board Parts List

CAP

.1 uF

RES

100

40.2

RES

Total in Design

Discrete Value

DP8392

COAXXCVR

BIZENER

400V

FUSE

CONN15

15 P D-SUB

4700 pF

RES

1K 1%

RES

499

DIODE

D664

CAP

.01 uF

CAP

820 pF

CAP

47 uF

CAP

i50 pF

CAP

68 uF

ZENER

8.2V 1%

TRANSISTOR,NPN

SWITCHING

DIODE

UES1302

DIODE

1N4004

TRANS

POWER XFORM

INDUCTOR

2.2 uH

ek pd

bbbk

CAP

JUMPER

hed

75 uH

ENETXFMR

JUMPER

Generic Name

Table 7-2

(continued on next page)

Network fnterconnect Interface

7-11

Table 7-2 (Cont.)

7.6.2.4

Ethernet Board Parts List

Generic Name

Discrete Value

Total In Design

4N38

OPTO IS "LATOR

555

TIMER

NMOS

NMOS POWER FET

RES

39.2

RES

14.7K 1%

RES

16.5K 1%

DC/DC Converter

Figure 7-6 shows a discrete dc-to-de converter that produces the voltage
required by the DP8392 chip while maintaining the isolation requirements
of Ethernet. Note that some modular dc-to-de converters perform the same
functions as the discrete converter.

7.6.3 Detailed Design Considerations
This section presents detailed information regarding use of the standard
Ethernet devices. The data presented here are more detailed than those found
in the device specifications and form the basis for the layout requirements
presented in Section 7.6.
7.6.3.1

Difterential Signals

The transmit (XMITz), receive (RX+), and collision (COL=) signals are
differential pairs. Run etch to these pins as parallel pairs, maintaining equal
etch length.
7.6.3.2

DP8392 Transceiver

This section discusses:

7-12

External components (Section 7.6.3.2.1)

Layout considerations (Section 7.6.3.2.2)

Network Interconnect Interface

Figure 7-6 Network Interconnect: dc-to-dc Converter
T

+12v

(W7

s12v_sw ——4]
3D

Notes:
* Ground B 1o be connected to logic ground
at power supply only.

e Ground A 1o be isclated from all other grounds.

1N4004 2.2UH
D4
+12V SW—{HA— IYTYTY T
~

.
.

Cc19
c22 _l. c21 lZOV
47UF

AUF

gl~L ©oeMelu| J08uUodIell] YIOMIBN

oUTPUT

| nos

" 30.2

L
- ssuF

Q2 .

DEC30098

§7

N/ IN756A

8.2V 1%

vee

GND

ci8
150PF

‘L R21

3s.2

2{CONTROL

LD |
®ITHRSH
DISCHG

R18
::/.7!(

R14

c20

2ITRIGGER

€

MR
al=

R23

AN38

s1* R17
100

TJUF]‘

2["E3

-V —

D3
T2, UES1302

_L C16

4 C14

T 820PF

i AUF

I
MLC-004458

7.6.3.2.1 External Components The following paragraphs list and discuss ‘

external components.

Pull-Down Resistors—The ThinWire receive and collision balanced
differential line drivers from the transceiver chip need four pull-down
resistors to VEE. Being external to the chip, they allow setting of the
voltage swings required to drive the differential lines and dissipate power

outside the chip, which adds to long-term reliability. In addition, they are
used with the transformer to control the differential undershoot which
occurs when the drivers reset.

In ThinWire designs with integrated transceivers, the transceiver is

directly connected to isolation transformers. In this case, higher value

pull-down resistances (up to 1.5K (2) may be used to save power and still
provide the necessary ac voltage swing. The use of resistances greater than
1.5K 12 is not justified by the amount of power saved and results in too low
a signal for proper operation of the SIA receiver squelch.
e

Diode—The requirements for the capacitance added by the transceiver
chip to the ThinWire coaxial cable are strict. The transceiver along with
the media-dependent interface is allotted 10 pF in a ThinWire network.
The DP8392 transceiver chip introduces about 4.5 pF when it is not

transmitting. To decrease this capacitance, the "off" state capacitance
of a diode is placed in ¢

s with the transmitter output (TXO) pin of the

chip.

A general-purpose diode, like the D664 of 25V and 135 mA, provides a
maximum 2 pF of capacitance when it is reverse-biased and has a reverse
recovery time of a maximum 10 ns. This means that the capacitance

introduced by the DP8392 is reduced from 4.5 pF to 1.4 pF (maximum) and
that 10 ns are added to the transmitter startup delay (the time required
for transmitted data to validly appear on the coaxial medium).
¢

Precision Resistor—The transceiver chip uses a 1K, 1% resistor between

pins 11 (RR+) and 12 (RR-) to set ThinWire coaxial drive levels, output
rise and fall times, 10 MHz collision oscillator frequency, jabber timing and
receiver ac squelch timing. A 1K, 0.25 W, 1% resistor is recommended.

Decoupling Capacitor—A 0.1 to 0.47 uF capacitor is needed between
the GND and VEE pins (10 and 4, 5, 13). This decrupling capacitor helps
reduce impulse and ripple noise on the transceiver chip power supply

below limits of 75 mV and +100 mV peak-to-peak, respectively. A ceramic

capacitor should be used for its good high-frequency characteristics. A 0.47
uF, 25V capacitor is recommended. If impulse noise and ripple limits are
exceeded, packet loss results.

7-14

Network Interconnect Interface

Pulse Transformer—MAUSs, either internal or external, need three

isolation pulse transformers to isolate the differential signals (COL =, RX
+, and XMIT =) of the transceiver chip from the SIA. ThinWire products
with integrated transceivers use 75 uH pulse transformers.
Power Supply—The DP8932 transceiver chip cperates over a supply
voltage range of —8.46V to —9.54V. The chip draws from 50 to 200 mA. The
transceiver chip has a power supply noise immunity of 100 mV peak-topeak.
7.6.3.2.2

Layout Considerativrn
s

To minimize the capacitance introduced to the ThinWire coaxial cable by

the transceiver chip, follow these guidelines:
—

Mount the transceiver chip as close to the center pin of the BNC
connector as possible, no more than 4 cm away.

—

Align the RXI pin, 14, and the anode of the isolation diode with the
center pin of the BNC connector.

—

Keep the length of traces from the RXI and TXO pins (14 and 15) to
the BNC connector to a minimum, not greater than 4 ¢cm.

—

Keep all metal traces, especially GND and VEEZ traces and planes, as
far as possible from the RXI and TXO traces.

—

In a multilayered PC board, void the area of GND and VEE planes
beneath the RXI and TXO lines.

—

Solder the DP8392 chip directly onto the PC board. Do not use a
socket; the DP8392 has a special lead frame designed to conduct heat
out of the chip.

Connect VEE pins (4, 5, and 13) to large metal traces or planes. Good heat

conduction is required for long-term reliability. A minimum total trace or

plane area of 6.45 cm? (1 inch?) is recommended to take advantage of the
3.5 W power dissipation rating of the chip package at 25°C. Do not use

heat-relieved mounting holes for these pins.

Connect the collision detect sense (CDS) pin independently to the coaxial
shield. The CDS pin is provided for accurate detection of collision levels
on the coaxial cable. To avoid altering the coli ion tureshold due to
intermediate ground drops from pin 16 to the coaxial shield, attach pin
16 independently to the coaxial shield by a short, heavy conductor. During
ESD testing, any potential differences between power ground (pin 10) and

the CDS pin (pin 16) can cause some internal functions to latch up.

Network Interconnect interface

7-15

e Place the decoupling capacitor, connected across GND and VEE, as close to .
the transceiver chip as possible to minimize the trace induciance.

Etch run: from the pins of the differential pairs (COL =, pins 1 and 2;
RX =, pins 3 and 6; and XMIT =, pins 7 and 8) must be parallel pairs of
minimum, equal lengths. The possibility of one side of the differential
pair picking up more noise than the other is minimized when the lines are
balanced.

For ThinWire designs maintain a voltage isolation barrier of 500V RMS
between input and output circuits

Figure 7-7 shows the typical layout of a ThinWire interface.
Figure 7-7 Network Interconnect: Layout of ThinWire Medium Intertace
Pulidown

ThinWire

Resistors

Grounding

U U |:I D

Network

)

o
8

0
8

[

o
g

Tra:ns;o:mer

Diode

Connector

—

ThinWire

Q —pd————— Precision
Q

Bypass

Resistor

Capacitor

0;3—3-92 Heartbeat
Enable
Switchk
MLO-004462

7.6.3.3 ThinWire Application Hints

The following application hints may be useful:
¢

PCB layout considerations

Figure 7-8 shows a heat spreader, implemented in side one (component
side) PCB etch, connected to pins 4, 5, and 13 of the transceiver chip. This
heat spreader works in conjunction with the special copper leadframe used
in the DP8392 chip to conduct heat out of the VEE pins. Since this large
area of side one etch is under the chip, it does not require extra PCB space

7-16

Network Interconnect interface

‘

to implement. You need not route signals under the chip on side one, if the
layout is done as indicated above.

-~ O O O[O0
0 0---

Figure 7-8

Network Interconnect: Heat Spreader

0
¢
5
Q
6

EMC compliance

ThinWire Ethernet interfaces can be difficult to certify for FCC Class B;
Class A requirements are less difficult. The best approach is to use very
low ESR capacitors between the isolated ThinWire cable shield and the
system chassis earth ground. The best type of device is a multilayered
ceramic-surface mount capacitor. These devices have very low ESR,
insignificant lead length, and are available in a 1000 VDC rating that
meets the 500 VAC (RMS) isolation requirement of Standards IEEE 802.3
and ECMA 97.

In general, more than one value may be required, and two to six parts may
have to be connected in parallel to achieve a low enough impedance at all
frequencies of interest. The total capacitance must not exceed the limit
imposed by IEEE 802.3, 0.01 xF. This requires some experimentation and
testing at the EMC test sites. The etch used to connect the BNC shield
contact and the chassis ground to these capacitors must be very thick and
very short for the capacitors to be effective.

Network Interconnect Interface

7-17

The 1M 12 resistor required by the IEEE 802.3 10Base-2 (ThinWire)

Standard between isolated ground and chassis earth ground removes static
electricity buildup, but does not protect from ESD effects. The best solution
for ESD protection is two 400 VDC bidirectional transorbs (similar to
back-to-back zener diodes) in series. This retains the required 500 VAC
(RMS) isolation, but protects against ESD voltages above 800 VDC. The
connection requirements for the transorbs are similar to those for the
capacitors, that is, very short and very thick etch.

7.6.3.4

‘

Power

The Ethernet interface requires two supply voltages, +12V and -9V. The

following are the specific requirements for each supply.
e

‘

12V

The +12V supply must be between 11.28V and 15.75V. This supply is
referenced to AUI voltage return. This +12V is used to supply power to
the MAU. The MAU may be the DP8392 chip (and associated circuitry) or
may be an external MAU connected to the station by an AUI cable. It is
not permissible to supply power to both MAU’s simultaneously to prevent
transmission on two networks.

When the MAU is the on-board DP8392 chip, the current drawn from

the +12V supply is approximately 220 mA. When power is supplied to
an external MAU through the AUI connector, the current draw can be as
much as 0.5 A steady state. The voltage that appears at the AUI connector
must be at least 11.28V (12V—6%) when the external MAU is drawing the
maximum current of 0.5 A. It is therefore important to minimize the dc
resistance of the path between the power supply of the station and the AUI

‘

connector.

In addition to the steady-state current requirements, there are consid-

erations for surge current. The +12V supply must be able to handle the
surge current drawn by an external MAU, when it is hot-swapped. The
connection of an external MAU should not crash the station, or otherwise
affect normal operation of the station. The +12V supply (as seen at the
AUI connector) is allowed to go out of tolerance during MAU hot-swap.
Transceivers draw currents of up to 25 A lasting 500 us.
A significant amount of noise can be coupled into the voltage return line
for the +12V supply. Most of this is switching noise from the dec-to-dc
converter (either on-board or in the external MAU). It is recommended that
a dedicated path be used for voltage return between the AUI connector and
the power supply. Avoid coupling this noise inte the logic ground of the
board.

7-18

Network Interconnect Interface

~9V

A dc-to-dc converter is used to create a -9V supply that is necessary to run
the DP8392 chip, when used. The ground reference for the -9V supply is
the ThinWire coaxial cable ground. This supply and its ground must be
dc-isolated from the other grounds in the design.
7.6.3.5

Grounding

Four different ground references must be considered in the Ethernet interface:
®

Logic ground

This is the reference for the system +5V supply.
Chassis ground

This is the lowest available impedance path to earth, usually provided by
the ac power line.
Voltage return

This is the reference for the +12V supply. Keep the voltage drop over the
path to the power supply small to ensure that a minimum requirement of
11.28V is delivered to the AUT cuonnector when 0.5 A are being drawn from
the +12V supply.
Ultimately, the logic, chassis, and voltage return grounds may all be
common. However, it is recommended that these three grounds be tied
together only at one location: at the power supply.
Connector grounding
=

ThinWire BNC connector grounding requirements (if used):

The shell of the BNC connector must be common with the ground of
the DI'8392 chip and the return of the ~9V supply. This ground must
be dc-isolated from the remaining three grounds.
-~

AUI connector grounding requirements:

Two variants of the AUI cable exist: old, Ethernet-compliant cables and
IEEE 802.3-compliant cables.
The old Ethernet cable has a protective outer shield which is connected
to the connector shell and pin 1 of the cable. It may have shields on
the individual twisted pairs, which are also connected to pin 1.

The IEEE 802.3 cable has a protective outer shield which is connected
to the connector shell only. It also has inner shields on the twisted
pairs. If the shields have a common drain wire, the cable is connected
to pin 4. If the shields have individual drain wires they are connected
to pins 1, 4, 8, 11, and 14.

Network Interconnect Interface

7-19

It is the goal of the sample design to meet the functional requirements
of both cable types. This is accomplished by connecting the connector
shell to the chassis ground with a dc resistance not to exceed 20 mf?
and connecting pins 4, 8, 11, and 14 to logic ground at the station’s
AUI connector. A jumper is used to configure the connection of pin
1 in the station. When the jumper is installed, pin 1 is connected to
logic ground. When the jumper is removed, pin 1 is left floating. The
jumper must be installed when IEEE 802.3 AUI cables are used with
the station. The jumper must be removed if the station has an old
Ethernet cable.

Stations should ship with the jumper installed. This ensures that
the implementation of the interface complies with the IEEE 802.3
grounding specification. All cables shipped by Digital Equipment
Corporation comply with the IEEE 302.3 ground design requirements.
7.6.3.6

Isolation Boundary

An isolation boundary must exist between the coaxial cable medium and the
circuitry within the station. This boundary has two characteristics:
e

It presents a high impedance to low frequency signals.

This is required in order to limit currents in ground loops. These ground
loops are set up by multiple stations connecting to their local earth grounds
and to the coaxial cable ground that is the network media. The impedance
between either coaxial cable conductor (center conductor or shield) and any
of the conductors in the AUI must be a. least 250 kf? at 60 Hz.
¢

It presents a low impedance to high frequency signals.

This creates a low impedance path for noise to be shunted to earth ground.
The magnitude of the impedance between the shield of the coaxial cable
and the protective ground of the AUI must be at most 15 12 in the frequency
range of 3 MHz to 30 MHz.

This isolation boundary is implemented within the MAU. When a station
has only an AUI connector, the design need not implement these isolation

requirements, because they are implemented in the external MAU.
The isolation boundary must be implemented in internal MAUs and is provided
by the isclation transformer between the SIA and the MAU. The requirement
for a high impedance at 60 Hz is met by the use of two blocks: a de-to-dc
converter and a signal isolation transformer. The layout must maintain
a sufficient spacing between any two conductors on opposite sides of the
boundary.

7-20

Network Interconnect Interface

The requirement for a low impedance at 3 MHz is met by the use of the
bypassing block. Note that the design uses a capacitance of 4700 pF to provide
the RF shunt. At 3 MHz, this capacitance has an impedance of 11.3 2. This
leaves a budget of 3.7 12 (15—11.3) for connection between the chassis ground

on the PC board and the earth ground of the station.

Hetwork Interconnect Interface

7-21%

PSR 0000000000000
0000000000 00006.0904¢:09.889089.0.4694
P89 4 40008 4900800000000 0003084890840 00009¢40.¢948404

19000000900 6040000000800
80880000000 000¢84040!

fES 00000808068 48.04880 9200060080000
800.80.508.894
h00.0. 8000000900684 0969.0.06.6000005690069.940.68¢
[3.4:4.4609. 80043040089004040830809400043459.009.4

P00 0400090.000804008¢08088094900¢95907¢

bR 008099 9.8.09 5909 808460080806+808808443
PO FN S5 9098 $4480.9.948:088009¢94896991

HEXRK KA KR EY

ARKERURAR KK KK AKX AR HEKAKK

HXXAARA XK EX KA KA KA XK AR KA KK AKX
}9.4:9.9:0.0.9.0.8:9.0.6.4.9.9.8.0.8.6.0.¢04.893991
EO 030 000700 88.9.6980094.09.0909.0¢4

ERUX AR KA KA AL KKK

KA LA KK KL K

09.9.3.80.99.8.0.9.9449949.9490.93
f 2040.¢4.0.0.8.0.9.3.9.0.46.4¢¢4.4
XXX KEXH X AKX KR KR KX
P8569.0.9.4.9.5.5.9.5.8.4.4.04
59,68 9.0.9.69.0.9.99.9.94

24.3.9.4.9.0.8.9.4.0.¢.44
1.0.9.9.6.9.9.6..9.9.4
ARERREAKK

EXKXEXX
KXXXH

XXX

$.9.6.9.90.4.4.4
£ 8. 4.6.8.9.9.4.94

b3.8.0.0.5.44.44484
f280089444451

KXEXEXERYLAKEXX
EX XA LA A

KA RK KL LR

200688086589 8865943 1
TEXARA
XK AL AH LR EALARARK
XXKA AR KUK KL KRR

XA KKK

LS00 900 808030000960
0840589

KEXKEX KL AR AR LA KT
XX

KA KKK

X R R AR KA Y

EXEARE XA R IR AU E R KA A AL AU KRR REY,

IP D OIS G000
EUN AR EX KRR R

PO BRI I PRI LN

FU RGOS OI DI

KE XX
KRR
EX

ELHK AR KL LH YA KL

R
LR

ALK LKA K

I 6000000884008

D IE PP DG800589504000

W
OO X

R AR R KA RN

PSSO IIINEGOIORIC IO INTI NI

R R KA A

R XU EA XK L K XU AR LR AR
O

P000095000004989

AR XK KA A XA AR

U KA KK KA K

H AN R WL H AR KA
KR X

NSGIIEREI

K KA RS

R AN AL AR KEN XA
IR RIS

16 80640089880 RRIVESIFEIINIPCIENINIDIDES
D IEP0800]

8
I/0O Device Interfacing
This chapter discusses the following topics:
¢

]/O device mapping (Section 8.1)

Interrupt structure (Section 8.2)

Bus interfacing techniques (Section 8.3)

DMA device mapping registers (Section 8.4)

rtVAX 300 to digital signal processor application example (Section 8.5)

Reset/power-up (Section 8.6)

Halting the processor (Section 8.7)

/0O system illustrations (Section 8.8)

8.1 /0 Device Mapping
The rtVAX 300 processor supports 8-bit, 16-bit, ar.1 32-bit I/O devices that are
located in the rtVAX 300 processor’s 510M bytes of I/O space. This space is
accessed with the same read and write cycles used for memory access; however,
address bit 29 is set for /O access and clzared for memory access. The I/O
space of the rtVAX 300 is at physical locations 20000000 to 3FFFFFFF.

8.1.1

Address Latch
The rtVAX 300 uses time-multiplexed data and address lines to transfer
memory and device addresses and data. Since the address is valid only on this
bus at the beginning of a device read or write cycle, address latches are needed
to latch the address. These latches can be connected, as shown in Figure 8-1,
by using the AS signal to latch the address. In addition, the byte mask signals
BM«<3:0>, write line WR L, and cycle status signals CSDP<4:0> L must all
be latched along with the address. The outputs of these latches are used as
inputs to address decoders and other application-specific logic. The outputs of
these latches maintain valid address and cycle status information throughout
the access cycle.

I/O Device Interfacing

8-1

Figure 8-1

VO Device Interfacing: Address Latches

BM<3:0>

74F373

DAL<21:18>

(
DAL<17:10>

(’

LADDR<31:30>, LADDR<2'I:2>’

Hold

From

rVAX 300

LBM<3:0>

74F373

’
N

Hold
?

To
Application

Logic

DAL <31:30>,
L21:
DAL<212>

74F373

D,
9:2
NDAL<92>

/
Hold

\, DAL <31:30>

CSDP<4.0>

7aFa73

LCS«4:0>

erfiind

~#4

/
-

Hold

LWRITE

MLO -004464

8.1.2 Address Decoding
Address decoding to generate chip select signals must be performed for each
memory-mapped 1/O peripheral. Programmable logic, such as the PAL 22V10,

can be used to decode the rtVAX 300 addresses and generate the chip select
signals for the memory subsystem and I/O peripherals. To implement full

address decoding for a byte-, word-, or longword-wide peripheral, 28 address
bits must be decoded. However, most PAL programmable devices do not offer
enough input pins, and you can cascad. «wo PAL devices to decode the memory
address, as shown in Figure 8-2.

The first PAL decodes the upper address bits DAL<29:13>, and the outputs
of this PAL are all latched by the device select latch. ROM and RAM are
selected by the first PAL. Two other outputs of this PAL are latched and fed
into a second PAL with the low-order latched address bits LADDR<12:02>.

The output of this PAL asserts the CONE (console enable), SELBADDR (DMA

base address register), and SELCSR (I/O CSR register). The data strobe (DS)
line enables these three select signals.

8-2

/O Device Interfacing

‘

Figure 8-2 1/O Device Interfacing: Address Decoding Block Dlagram
Davice

First
Decoder
DAL<29:13> 17

PAL

Select
Latch

SELRAM
SELROM

SELDSPRAM

Address

s
e

[

LSELCONIO

LSELREGIO

Latches

CONE

DAL<12:2>

LADDR<12:2>

PAL

.
ol

SELBADDR

SELCSR

Decoder
Second

MLO-004465

. 8.1.3 /O Access: Cache Control, Data Parity, and I/0 Cycle Types

The rtVAX 300 performs only longword transfers from I/O space; it does
not cache any data read from there. This allows for a simple design of /O
peripherals, because they need not respond to quadword or octaword ac. 2ss
cycles.

I/0 devices can be constructed to generate and check DAL bus parity, although
proper parity is not required for I/O space reads if the DPE L line is deasserted.

If DAL parity generation and detection are not needed for the I/O device,

drive the DPE L line high during that device’s read cycle. A 74F657 parity

transceiver can be used to generate and detect parity for an I/O device. Note
that the odd bytes (DAL<15:08> and DAL<31:24>) have odd parity and that
the even bytes (DAL<07:00> and DAL<23:16>) have even parity. If the /O
device is capable of DMA operations to the rtVAX 300 processor’s external
RAM memory, the DMA I/O device must generate the correct parity when
writing to memory; otherwise, the rtVAX 300 detects a DAL parity error when
reading those modified memory locations.

/0O Device Interfacing

8-3

8.2 rtVAX 300 Interrupt Structure

‘

Most simple peripherals, such as A/D, D/A, parallel, and serial I/O devices,

can be directly mapped to a valid location of the rtVAX 300 processor’s I/O
space. When the device requests service, it asserts one of the four IRQ<3:0> L
lines and waits for the rtVAX 300 to run an interrupt acknowledge cycle. This
interrupt acknowledge cycle looks like a normal memory read cycle; however,
the CSDP«<4:0> L reads 1X011, indicating an external interrupt acknowledge
cycle.
The IPL of the device interrupt being serviced is placed on DAL<06:02>, and
AS L is asserted. This IPL must then be decoded, and the interrupting device

must place a vector on DAL<15:02> and assert RDY L. DAL«31:16> and

DAL<01> are ignored; however, DAL<0>L can be used to force the processor
IPL to 17, when asserted. Thus, if a device interrupts the rtVAX 300 by
asserting IRQ<0> L, the processor raises its IPL to 144¢. If the vector that is
driven onto DAL<15:00> is odd (DAL<00> is set to 1), the rtVAX 300 raises its
priority level to IPL 17, when executing
the interrupt service routine. It is
now up to the interrupt service routine to lower the IPL of the rtVAX 300 so
that other interrupt requests are nct blocked.

‘

Lines IRQ<3:0> L are level-sensitive, and the interrupting device can continue

to assert the IRQ<0> L line until the interrupt service routine lowers the
rtVAX 300 IPL level below the interrupt request IPL. The rtVAX 300 does not
service interrupt requests of the same or lower IPL than the IPL at which
the processor is now operating. Therefore, if a device requests an interrupt
by asserting IRQ<1> L and the processor runs an interrupt acknowiedge cycle
for that device, the processor’s IPL is raised to 15;6. If the device continues
to assert the IRQ<1> L line, the processor does not acknowledge the second
interrupt until the interrupt service routine iowers the processor’s. IPL below
15;6; thas prevents interrupt stacking and allows multiple devices to interrupt
the processor by using the same interrupt request line. It is good practice to
have the I/0O device clear the interrupt request after the rtVAX 300 runs an
interrupt acknowledge cycle for that device.

Typically, a CSR register associated with the I/O device contains the interrupt
control bit(s). When a device has requested an interrupt, a bit is set in that
register. This bit can automatically reset after the CSR is read, or the ISR
can clear this bit by writing back to the CSR. The ISR branches to the correct
servicing code, which depends on the nature of the interrupt, after reading this
CSR. The ISR exzecutes the service code, which cannot be preempted. After
executing the code, the ISR lowers the processor’s IPL, and other interrupts
can be serviced. See the rtVAX 300 Programmer’s Guide for a discussion of
ISRs.
‘

8—4

/O Device Interfacing

b 8.2.1 interrupt Daisy-Chaining

In many applications, more than four devices need to request interrupts from
the rtVAX 300. To accommodate multiple devices, the interrupt requests are
logically ORed, and the interrupt acknowledge is daisy-chained between the
devices, as shown in Figure 8-3.

Figure 8—3 1/O Device interfacing: Interrupt Daisy-Chain Block Diagram

CSDP<4.,2:0>

. DAL<62> | Dgzfier Latch| {

)

AS
DS

__.__\

‘

Device 1
IACKIN

“\iackouT | | IACKIN .

)

Device Interrupt
Request

)IACKOUT .

Device Interrupt
v

vce

IRQ<0>

‘

Device 2

Request

Open-Collector
Driver

MLO-004466

For example, if two devices need to interrupt at IPL 1444, the interrupt request
line of both devices can connect to IRQ<0> through open-collector drivers. A
decoder that decodes interrupt acknowledgments at IPL 14,5 asserts the device
interrupt acknowledge signal. After being latched, this signal is then ANDed
with DS and fed into the interrupt acknowledge input of the first device. This
device drives a vector onto the DAL bus and drives RDY L, if it was the device
that was asserting IRQ<0> L. However, if the first device did not assert the
IRQ<0> L signal, it passes the interrupt acknowledge to the second device
by asserting an interrupt acknowledge output signal. This IACKOUT signal
is then fed into the interrupt acknowledge input of the second device. The
second device can now drive the vector onto the DAL bus and assert RDY L.
If the second device did not assert the IRQ<0> L signal and it receives the
interrupt acknowledge input, it should not drive the vector onto DAL<15:00>
or assert RDY L. The rtVAX 300 times out after 32 ps and aborts the interrupt
acknowledge cycle. Aborted interrupt acknowledge cycles result in a passive
release without a machine check.

I/O Device Interfacing

8-5

8.2.2 Interrupt Vector
The interrupt vector generated by the interrupting device is used as an offset
to locate an entry in the system control block (SCB). This entry is then read
from the SCB to determine the virtual starting address of the interrupt service
routine for that interrupting device. Each interrupting device must generate
a unique vector, so that a different ISR is invoked for each device. (Table 3—4
lists the relationship between interrupts and the SCB.)

8.3 General Bus Interfacing Techniques
In some applications, the rtVAX 300 interfaces with a general-purpose I/0O bus, ‘
such as the VME bus or the IBM PC/AT bus. The design of this interface can
vary. The rtVAX 300 application module can function either as a bus master or

a slave processor. Communication between the rtVAX 300 application module
and other modules on the bus is carried out through either shared memory or
dual-ported data registers.

8.3.1

Bus Errors
When a bus error occurs, external logic notifies the CPU by asserting ERR L

during a bus cycle. The CPU responds, as shown in Table 8-1. External logic
can assert both ERR L and RDY L to request a retry of bus cycles.
Caution

The RDY L, ERR L , and CCTL L lines are tri-stateable bidirectional
lines. These lines are also internally pulled up by a resistor, and they

must be driven by tristateable drivers. If these lines are driven by a
standard TTL totem pole output, the rtVAX 300 does not function.

8.3.2 Using the rtVAX 300 as a Bus Master
In most bus interfacing applications, the rtVAX 300 functions as a bus master.
The address space of the bus should be mapped to the rtVAX 300’s I/O space.
An interrupt controller is needed to handle and control interrupts that are

generated on the bus; this controller must interrupt the rtVAX 300 and provide
an interrupt vector when the rtVAX 300 acknowledges the interrupt. A bus
cycle controller is also needed to control the bus protocol of the 1/0 bus and
correctly service bus access cycles from the rtVAX 300. This controller becomes
fairly complex if multiple bus masters are allowed on the I/O bus.

8-6

/O Device Interfacing

‘

Table 8-1

Response to Bus Errors and DAL Parity Errors

Cycle Type

Prefetch

Demand D-stream

Write

Request D-stream

Request I-stream
(read)

Halted

(read)

Cache'

Error Status?®

Machine Flows

Entry

Logged in MSER bits

Machine check abort

invalidated
Entry

06:05

invalidated

Logged in MSER bit

Entry
invalidated

Logged in MSER bit
06

!The entire row in cache memory selected by the faulting address is invalidated whether or not the reference

is cacheable. The entries from both sets are invalidated.

20nly DAL parity errors log status.

8.3.3 Using the rtVAX 300 as a Bus Slave
In certain applications, rtVAX 300 functions as a slave processor on a system

bus. To do this, a bus interface must be designed to interface the bus to dualported memory on the rtVAX 300. This memory must map to the rtVAX 300’s
1/0 space and to some address space of the system bus. It is useful to construct
a few CSRs that allow the master processor on the system bus to interrupt the
rtVAX 300 and give status information. In addition, the rtVAX 300 should be
able to interrupt the master processor.

8.3.4 Building a DMA Engine for the rtVAX 300
The rtVAX 300 allows the peripherals to request the DAL bus and become DAL
bus master. When the rtVAX 300 has given bus mastership to the external
DMA device, the rtVAX 300 tri-states its DAL<31:00>, AS L, DS L, WR L,
BM<3:0>, and CSDP<4:0> L lines. The DMA peripheral must now drive each
of these lines with the same protocol as the rtVAX 300. All control signals
must be pulled up to prevent accidental assertion when their lines are first
tri-stated. It is also good practice to pull up the DAL<31:00>, BM<3:0>, and
CSDP<4:0> L lines to prevent oscillation when these lines are not driven.
The DMA peripheral transfers information in the following sequence:

The DMA device asserts the DMR L signal, requesting to become DAL bus
master, and waits for the assertion of DMG L.

The rtVAX 300 finishes the present transfer cycle, tri-states all signal li~es,
and asserts DMG L.

1’0 Device Interfacing

8-7

3. The DMA device drives the DMA address on the DAL bus, the cycle status ‘
onto CSDP<4:0> L, and the BM«3:0> lines, which are the byte access
information, along with the WR L and DPE L lines.

The DMA device asserts AS L. This is the P1 clock phase.
The DAL<31:00>, CSDP<4:0> L, DPE L, and WR L lines are tri-stated by
the DMA device. This is the P2 phase.

During a DMA write cycle, the DAL bus is driven with the data and

CSDP «3:0> L is driven with the byte parity by the bus master. During
a read cycle, the DMA peripheral listens to the DAL and CSDP lines to

read the data. During either cycle, the DS L line is asserted. This is the
P3 phase. DMA write cycles must maintain rtVAX 300 internal cache
coherency; therefore, a DMA write to an address whose data has been
previously cached invalidates that cache entry. The DMA bus master
accomplishes this by first asserting the CCTL L line and then driving
the DMA addresses onto the DAL bus and asserting AS L. This cache
invalidation cycle prevents stale data from existing in the rtVAX 300
internal cache.
7.

The DMA device waits for the assertion of RDY L durirg the P1 phase.

During a read cycle, the memory subsystem asserts RDY L, and the DMA
device must latch the data; during a write cycle, the DMA device must
tri-state the DAL<31:00> and CSDP<4:0> L lines during the P2 phase.

If another DMA transfer is required, the DMA device goes to step 3.
Only eight successive DMA transfers are allowed; the DMA device must
relinquish the bus to the rtVAX 300 by deasserting DMR L. In addition,

Until RDY L is asserted, all signals stay in the same state.

‘

DMA devices cannot remain bus master for longer than 6 ys. If more DMA
transfers are required, the DMA device can reassert DMR L and go back to

step 1. The deassertion of DMR L allows the rtVAX 300 to access memory
between DMA requests.
10. The DMA device deasserts the DMR L signal, the rtVAX 300 deasserts the
DMG L signal, and the DMA transfer is complete.

The DMA timing diagrams, Figure 8—4 and Figure 8-19, show more details
of the read and write cycles. In Figure 84, all data and strobe signals are
controlled on rising edges of both CLKA and CLKB. For example, the AS L
signal asserts on the rising edge of CLKA (P1 state) and deasserts on the rising
edge of CLKB (P2 state). To emulate the proper timing of these strobe signals,
a state machine must be clocked on CLKA, and some output latches must be

clocked on CLKB. (See Figure 8-29 for an example of this.)

8-8

/O Device Interfacing

;

maw

Heyi

SRLBM:isEtE:'N:YEt::: SNTVAUDROI7|PQiYR3Y4da

L9¥00-OTIN

I/0 Device Interfacing

8-9

8.4 DMA Device Mapping Registers
When /O devices or 2 bus interface must support DMA to the rtVAX 300
systern memory, a scatter/gather ($'G) map is useful. This map translates the
DMA addresses generated by the I/O device into the physical addresses of the
rtVAX 300 system memory.
The VAX architecture defines a page to contain 512 bytes. To access any byte
within any page, 9 bits of addressing are required for the byte offset within a
page, anrd 21 bits are needed (the page frame number) to locate the page within
the 30 bits of addressing accommodated by the VAX. To map the 1/0 device
DMA address to the rtVAX 300 system memory correctly, the S/G map provides

the page frams number (PFN) for the address that the I/0O device generates.
For example, the Q22-bus supports 22 bits of addressing and multiple bus
masters. The bottom 9 bits of the Q22-bus are directly multiplexed onto the
rtVAX 300 system memory address. Bus address bits <08:02> are multiplexed
onto DAL<08:02>, and bus address bits <01:00> control BM<3:0> to access
the correct byte of VAX memory. The upper 13 bits of the Q22-bus address
are used o select one entry in the S/G map. That entry in the S/G map then
contains the 20 bits of possible pages in memory space to define the PFN. In
addition, a Valid bit (bit 31) for each entry ensures that the operating system
has correctly updated each map entry. Thus, the S/G map consists of 8192
Q22-bus mapping registers (QMRs), each being 21 bits wide.

The operating system dynamically updates each entry in the S/G map as pages
of the I/O bus are mapped into physical pages of the rtVAX 300 svstem RAM.
The rtVAX 300 views the S5/G map as 8192 longword registers; each register
maps one page of Q22-bus memory to a page in the rtVAX 300 system RAM.
Figure 8-5 shows the translation from Q22-bus addresses to physical memory
addresses.
Implementing these mapping registers allows Q22-bus DMA devices to perform
DMA to and from contiguous Q22-bus addresses; the S/G map maps each page
of Q22-bus memory to a page in system RAM ii the Valid bit is set. These

mapping registers must be readable and writable only from the rtVAX 300
and directly mapped to I/O space locations. When the rtVAX 300 is writing to
or reading from the Q22-bus, the mapping registers are not used to address
the Q22-bus. The Q22-bus address space is directly mapped to locations in
the rtVAX 300 I/O space. The S/G map is used only when Q22-bus devices
are performing DMA to the rtVAX 300 system memory. The rtVAX 300 can
access its memory space through the Q22-bus interface by accessing a Q22-bus
address that is validly mapped to its own system RAM.

8-10

/O Device Interfacing

’ Figure 3-5 Q22-bus to Main Meimory Address Translation
Q22 bus Address
21

Map Register Number|
-

Byte Ofiset

_—

~——

_J
—

Extract f.eg:star Numbes
to Select Map Register

[

—

Q22-bus Map Hagister

32-B.t Map Register
3130

Sealactad Map Ruyister F—»1 V
(valid)

2019

Page Frame Number

Main Memory Addrees
29

r Page Frame Number

\t}

Byte Oftset

29-Bit Physital Memory Address
MLO-004468

These mapping registers are not a requircinen’, and some low-cost rtVAX 300

bus interfaces may not implement them. In addition, larger buffer areas that
span many Kbytes can be used to reduce the number of mapping registers. In
these applications, sections of the rtVAX 300 system RAM are directly mapped
to an address space withir the bus. This methed requires rontiguous allocation

of DMA catz buffers and reduces the flexability of the VAXELN device drivers.

Refer to the riVAX 300 Piogrammer’s Guide for information un rtVAX 300
device dnivers.

Digital recommends implementing error registers for bus interfaces. These
regisiers log events, such as DMA tiineout znd bus protocol and parity errors.
Trror conditions should interrupt the processor or assert the ERR L line. The
ERR L line is asserted only if the preseni processor bus cycle caused the error
condition. The system software can access these error registers to acknowledge
the errcr condition and take the appropriate action.

I/O Device interfacing

8-11

8.4.1

Q22-bus to Main Memory Address Translation
On DMA references to main memory, the 22-bit Q22-bus address must be
translated into a 29-bit physical memory address. This translatior process
is performed by the Q22-bus interface by using the Q22-bus map. This map
contains 8192 mapping registers (one for each page in the Q22-bus memory
space), each of which can map a page (512 bytes) of the Q22-bus memory
address space into any of the 1M pages in main memory. Figure 8-5 shows
how Q22-bus adJdrr.ses are translated to main memory addresses. At system
power-up, the Q22-bus map registers, including the Valid bits, are undefined.
The system software must initialize these registers and enabie the S/G map.

8.4.2 Q22-bus Map Registers
The Q22-bus map contains 8192 registers that control the mapping of Q22bus addresses into main memory. Each register maps a page of the Q22-bus
memory space into a page of main memory. These registers are implemented
in a 32K-byte block of 1/0 space.

The local I/O space address of each register was chosen so that register address
bits <14:02> are identical to Q22-bus address bits <21:09> of the Q22-bus page
that the register maps.

Figure 8-6 shows the format of the Q22-bus map registers (QMRs); Tabie 8-2
lists the register bits and their meanings.
Figure 8-6

Q22-bus Map Register

3130

2019
T

ITTTfirTTTriTyrrqrvrd

0
O

A28
- A9
N

MLO-004469

8-12

VO Device Interfacing

Table 8-2
Data

Q22-bus Map Register Bits

Bit

Meaning

Valid bit (V). Read/write. When a Q22-bus map register is s-lected by bits
<21:09> of the Q22-bus address, the Valid bit determines whether mapping is
valid for that Q22-bus page. If the Valid bit is set, Q22-bus addresses within
the page controlled by the register are mapped into the main memory page

determined by bits <28:09>. If the Valid bit is clear, \he Q22-bus interface
does not respond to addresses within that page.

8.4.3

20:20

Unused. These bits must always read and be written as zero.

19:00

Address bits <28:09>. Read/write. When a Q22-bus map register is selected
by a Q22-bus address, and if that register’s Valid bit is set. then these 20 bits
are used as 1 iin memory address bits <28:09>. Q22-bus aadress bits <08:00>
are used as main memory address bits <08:00>. These bits are undefined on
power-up and the negation of DCOK when the processor is halted.

Dual-Port2d Memory
Another communication method that can be used is the design of dual-ported
memory Either the system RAM can be dual-ported or some dual-ported RAM

can be placed in the /O space. In addition, dual-ported RAM in the I/O space

does not require the implementation of cache invalidation cycles, because I/0
references are not stored in the cache. Dual-ported RAM in the I/O space has
the advantage that the processor can still read from and write to system RAM
while the IO device is reading from and writing to the dual-ported VO RAM.
This method does not require the design of a DMA engine; therefore, the logic
may be simpler.

8.5 rtVAX 300 to Digital Signal Processor (DSP) Application

Example

A 2-processer system v s designed and constructed as an application example
for the rtVAX 300. This application module has the following features:
e

4M bytes of parity DRAM system memory that operates with one wait
state

A 1LI-byte user boot ROM for permanent storage of application sottware

Two DEC—423 serial lines for the console and down-line loading

DECnet Ethernet network interface for both ThinWire and thickwire

A Texas Instrument TMS320C25 DSP with 4K words of private memory

/O Device Interfacing

8-13

4K words cf initialization and loader ROM for the DSP

A D/A and A/D converter that (s privately coupled to the DSP

A DMA engine that allows the DSP wo write to and read from rtVAX 300
system memory

An interprocessor communication CSR
Figure 87 shows the rtVAX 300 and DSP processor interface.

8-14

VC Device Interfacing

Flgure 87 /O Device Interfacing: DSP and rtVAX 300 Processor interface Block Diagram

1508
TWS320028
Digha!
Signal | DSPDATAC <15:08>

cPU

0>
* DSPDATACI

ZK¥%e
SsPETRE

SRAM
Data |

WERAM>, | o

»{ ADDR
< 100>
e

WERAM<D | =

CsRAM<D> ) o

~»] ADDR
<10:0>
118

ADDR
<100>

OF B->A

[

EP ROM
Data } —

SRAM
Date J

SAAM
Data e

SRAM
Data be—

CsRAM |o

ET3 )

118

csmom |

OEROM_)

Oclal
Drivor

F’J ENABLE

a8i

Octal

Driver

N OUT

WRo

+5V

OUT

ouT

DAL<82> DSPADDR<O> H
DSPADDR<O> L

Is
ENBADDR

ENABLE

C5DP<10>
i

OAL29

ENABLE

oArso:g)

Octal

Driver

w outh BM<1:0>

N out|. PAL3>
DAL<1 0>

IN OUT——2 T

113P

e ‘M&’

OEB A

++_~ OF A>B

Octal
Flop

csoé 2
X2 loat<zetes

N oUT

CLK
e ENABLE

5 | DAL<23:18

DEV ENB

]

LATCHBADOR iH ouYp————
M2

112p

_
OE B->A
OF A->B
L:: LB->A

—»] ADDR
<110>
128

DMA Base

DAL
N OUT CSDP<4:3>

N ouT

—>iL B->A
=} DEV ENB

EF ROM
Deta H

Addraese Rogister

our]_E50P<®>

[———-Dl N

OE A->B

KKS

4K Word Loadar ROM

Octal
Driver

out|DALIBIC>| DSPWRITE

pspwRITE | & o

Ed%

DMA Addtess Drivers

—»] ADDR
<110
128

ADDR
<100>

4K Word Private Progiam and Data Static RA

g= he

DAL<31:24

| B iBre

ENBDMARD<> |
ENBOMARD<0>

Lol B.5A

| 0EV ENE P
LA

114

DAL<7
0>
——
8 {e——

N PR

ENBOMAWR

wloE a0

ENBDMADAL

> DEV ENB
»]

EHBDOMARDY

|| ENABLE
DAL Rogistersd Dava T

Si—g Buepeiul edineq O/l

MR_O00804

8.5.1

DSP Private Memory
The DSP executes programs in 4K words of private RAM memory; 4K words of

ROM for initialization and program loading are privately coupled to the DSP.
Table 8-3 shows the memory map of the DSP.
Table 8-3

TMS320C25 Digital Signal Processor Memory Map
Program

Data

Physical
Location

Space
Device

Global Memory
Space Device

0000—OFFF

ROM

RAM

None

1000—1FFF

ROM

RAM

None

2000—2FFF

ROM

RAM

None

3000—3FFF

ROM

RAM

None

4000—4FFF

RAM

None

5000—5FFF

RAM

None

6000—6FFF

RAM

None

7000—7FFF

RAM

None

8000—FFFF

None

rtVAX 300 memory accessed by DMA cycles

The DSP is a word-oriented device, expecting to transfer 16 bits of data at a
time. The rtVAX 300 can transfer either bytes, words, or longwords during
each bus cycle. When the DSP is reset, it begins to execute code from program
space location 0000. The loader ROM is at that location. The code in that ROM
first initializes some registers and vectors of the DSP; then, the code causes
the DSP to load a program from the rtVAX 300 memory by using DMA cycles.
Once the program has been loaded into the DSP’s RAM, the DSP executes the

‘

loaded program from this program RAM at location 4000,g. Since full address ‘
decoding was not implemented, the ROM maps four times in the program
space, and the RAM maps eight times in the data space and four times in the
program space.

8.5.2 4K Words of DSP Private RAM
When the DSP reads data from external memory, it first places the address
on the DSPADDR address bus. Either the program strobe (PS) signal for
access to program memory or the data strobe (DS) signal for access to data
memory is asserted. The DSPWRITE signal is not asserted (read cycle).

The DSP_MEMORY PAL (see Figure 8-29) looks at the SRAMADDR<0>
line to determine if bank 0 or bank 1 is selected. If bank 0 is selected,
the CSRAMO line is asserted and the two SRAMs in bank 0 are selected.

8-16

VO Device Interfacing

Both WRITERAM<1:0> signals remain unasserted. Next, the DSP asserts
the DSPSTRB signal, enabling all SRAM outputs. The DSPREADY signal
is asserted by the DSP_MEMORY PAL, and the DSP reads the data and

ends the cycle. Write cycles operate in the same manner; however, the
WRITERAM<1:0> signals assert with DSPSTRB for the selected bank.
The DSP requires the use of 40 ns static RAMs to operate without any wait

states. The propagation delay of the DSP_MEMORY PAL must be added to the
access time; therefore, 25 ns SRAMs were used.

8.5.3 DSP 4K-Word Private Initialization ROM
The DSP can read from only the initialization ROM. The DSP_MEMORY PAL

asserts the CSROM output when a valid ROM program space address is placed
on the DSPADDR bus. The OEROM signal is later asserted, and the DSP
asserts the DSPSTRB line with DSPWRITE unasserted. Since the ROMs are
very slow, the DMA_CONTROL PAL adds three wait states to the access cycle.
Aiter those wait states have occurred, the DMA_CONTROL PAL asserts the
DMAREADY line, which in turn asserts the DSPREADY line, ending the cycle.

8.5.4 DSP DMA Cycles
Certain portions of the DSP’s memory can be mapped globally. This global
memory is mapped between locations 8000 and FFFF. Access to these locations
causes the DSP DMA controller to assert the rtVAX 300’s DMR L line. Then
the rtVAX 300 tri-states the DAL bus and all of the control signals and asserts
the DMG L line; now, the DMA controller must start a DMA access cycle.
Once the DMA controller state machine receives the DMG L signal from
the rtVAX 300, the DRIVEADDR signal is asserted to drive the DSP’s DMA

address onto the rtVAX 300’s DAL bus through the 74F244 drivers, shown
in Figure 8-26. The assertion of DRIVEADDR asserts the ENBADDR signal

through the CSR_REG PAL, driving DAL<31:02> H, CSDP<4,2:0> L, and
BM<3:0> L with the appropriate address and control information. Next,

the AS L signal is asserted and later, the DRIVEADDR signal deasserts.
Nnw, the DS signal and the ENBDMADAL are asserted; the DMA controller
waits for the assertion of RDY L in the RDY/ERR window. The assertion of
ENBDMADAL turns on the 74F543 transceivers (see Figure 8-25). Once RDY
L is received, the DMAREADY signal is asserted, asserting the DSPREADY
signal through the DSP_MEMORY PAL. If this is a DMA read cycle, the
DSPDMARDY signal causes the 74¥543 transceivers to latch the data on the
DAL bus and continue to drive the DSP data bus with that data until the DSP
finishes the read cycle. The DSP global memory access cycle now completes,
and the DMA controller deasserts AS L, DS L, DMR L, and ENBDMADAL. See
the state machine diagram described by Figure 88 and the timing diagram in
Figure 84 for details.

I/O Device Interfacing

8-17

Figure 8-8 1O Device Interfacing: DMA State Machine Sequence
ASSERTAS L
AS+

MDRIVEADDR!ot

IDLE

DMACYC1 U
DS+

FINISHUP1
L]
DSPREADY+

REQDALBUSL

DMACYC2

[ FINISHUP2
L

DMR+

DSPREADY-

Yes

DMG

_—

DRIVEADDR ]
MDRIVEADDR+

MLO-004471

8-18

VO Device Interfacing

8.5.5 Control and Status Register
A control and status register (CSR) is implemented between the r'vAX 300
and the DSP. This register has an 8-bit 1-way mirror for interv.rocesso.
communication. It also contains interrupt, reset, and hold mts for each
processor.

8.5.5.1

1-Way Mirror Register
The bottom 8 bits of the CSR register form a 1-way mirror register (see

Figure 8-27). When the DSP reads from I/0 space, the DSPIS signal is
asserted, indicating that the DSP is accessing the CSR. The DSR_BADDR

PAL then asserts the ENBDSPCSR line once DSPSTRB asserts, driving the

contents of the mailbox onto the DSPDATA bus. These contents are the value
that was last written to by the rtVAX 300 and not the contents last written to
by the DSP.
When the DSFP writes to I/O space, the DSPIS signal is also asserted. The

DSR_BADDR PAL then asserts the LATCHDSPCSR line when DSPSTRB
asserts. When LATCHDSPCSR deasserts, the data on the DSP data bus is
latched intc the DSP mirror register. The data on DSP data bit <08> is used
to set the VAX interrupt request flop, as shown in Figure 8-28. When this bit

is set, an interrupt at IPL 16,4 is, posted by asserting the IRQ<2> L line of the
rtVAX 300.

When the rtVAX 300 reads this mirror register, it reads the most recent value
written to it by the DSP. When the rtVAX 300 writes to this register, the DSP
reads that value the next time it reads from that register.

8.5.5.2

Interrupt, Reset, and Hold Bits
When the system is first reset, the CSR register clears all of its bits except

the HOLD DSP and RESET DSP bits. Once the rtVAX 300 boots, it writes the
DSP program into a reserved block of rtVAX 300 system memory and sets the
DMA base address register. The 1tVAX 300 can now reset these 2 bits, and the

DSP copies the program to its own private memory and begins to execute it.
The base address register (see Figure 8-28) drives through the bus drivers (see
Figure 8-27) to the rtVAX 300 DAL bus. The DSP cannot read any of these
bits; however, it can wri‘e to the interrupt VAX bit, as described above.
When set, the interrupt bit for the rtVAX 300 requests an interrupt by

asserting IRQ<2> L. When the rtVAX 300 runs an interrupt acknowledge
cycle, this request is cleared; however, the bit in the CSR remains set. When
this register is read, this bit is cleared at the end of the read cycle. The
interrupt bit for the DSP operates in the same manner; however, it asserts
the DSPIR <0> bit. This bit is cleared when the DSP runs an interrupt

acknowledge cycle.

I/0 Device Interfacing

8-19

8.5.6 DMA Base Address Register

The rtVAX 300 can perform DMA to up to 64K bytes of memory. The DMA
base address register selects the 64K-byte block of memory which can be seen
by the DSP. The DSP CSR, whose implementation is shown in Figure 8-286, is
readable and writable only from the rtVAX 300 and cannot be accessed by the
DSP.

‘

8.6 Reset/Power-Up
The rtVAX 300 processor must have its RST L line asserted for at least 750

ns when it is first powered up to ensure the stability of all on-chip voltages

‘

before beginning operation. Assertion of this line resets all rtVAX 300 internal
registers and sets the program counter to 20040000. Once the RST L line is

deasserted, the rtVAX 300 begins booting by fetching instructions that start at
physical location 20040000, the starting location of the rtVAX 300 internal boot
and diagnostics ROMs.
The power-on reset circuit, shown in Figure 8-9, asserts the RESETVAX line
when power is first applied to the board. The 4.7 ki? and 470 {2 resistors on

the (~) input of the LM211 comparator set that input voltage to 4.5V. The 10

uF capacitor on this input charges more quickly than the 10 pF capacitor,

which is charged to 5V through a 100K resistor to Vee. Thus, when power is

‘

first applied, the (-) input of the LM211 comparator quickly reaches 4.5V. The
(+) input of the comparator is at a lower voltage than the (-) input until the
10 pF capacitor charges over 4.5V. This takes slightly longer than the RC time
constant of 100,000 x 0.00001 = 1 second. While the (+) input is at a lower

potential than the (=) input, the open-collector output of the LM211 comparator
is turned on, and the RESETVAX signal is asserted.
When the reset switch is pressed, the BUTTRST signal also asserts through

the 74F32 gate of the ENBRST switch, shown in Figure 8-31. When either
BUTTRST or RESETVAX is asserted, the 74F579 counter is reset, and the

reset hold latch is cleared. After 12.8 ns, the counter overflows, and the TC
output toggles. The reset hold flop stores a 1, and the RST L line is deasserted
by the reset latch.
Caution
The reset assertion time and deassertion timing in the specifications

must be followed exactly. RST L can deassert only 10 ns after or 20 ns
before any CLKA edge. If this timing is violated, the rtVAX 300 does
not initialize properly. The RST L line can be asserted at any time.

8-20

I/O Device Interfacing

‘

Figure 8-9
+5V

/O Device Interfacing: Reset Timer Logic

l 1

\ R3

470

100K

— 1

ped

1 ggepF

T oo

LM211

E47

—~

RESETVAXL

2
1

, 25V

1 :

§Z
1

4
c3

1
1

?225\/
MLO-004473

8.7 Halting the Processor
The rtVAX 300 is a dynamic device and cannot be halted by disabling its clock
input (CLKIN). The CPU is halted either by executing the HALT instruction in

kernel mode or by asserting the HLT L signal.
When in the HALT position, the RUN/HALT switch (S1) sets a flip-flop which
asserts the HLT L output to the rtVAX 300 processor, as shown in Figure 8-10.

This causes the rtVAX 300 to enter a halt routine and to store the content
of certain rtVAX 300 registers. This is a momentary contact switch that is
normally in the RUN position.

YO Device Interfacing

8-21

Figure 8-11;

1/O Devi_e Interfacing: HALT Logic
T2

72K

S22 Run

lne
2

{2K

SR §R34

T
74
LSO01

1k E25

13 ,

ToK

HLTREQL

Halt

—

-9

84
MLO-006395

8-22

VO Device Interfacing

8.8 1/0 System lllustrations
The following pages show I/O system illustrations and programmable array
logic.

Figure 8-11 shows the address decoder and power-on reset.
Figure 8-12 shows the address latches.
Figure 813 shows the DRAM address path.
Figure 8-14 shows DRAM memory array (1).
Figure 8-15 shows DRAM memory array (2).
Figure 8-16 shows the RAM data latches.
Figure 8-17 shows the DSP PGM loader ROM.

Figure 8-18 shows rtVAX 300 ThinWire/thickwire network connections.
Figure 8-20 shows the memory controlier.
Figure 8-21 shows the console interface.
Figure 8-22 shows the user boot ROM bank 1 with drivers.

Figure 8-23 shows the user boot ROM bank 2.
Figure 8-24 shows the DSP and private RAM.
Figure 8-25 shows the DSP DMA transceiver and parity generator.
Figure 8-26 shows the DMA address drivers.
Figure 8-27 shows the VAX-to-DSP 1-way mirror register.

Figure 8-28 shows the rtVAX 300 and DSP CSR.
Figure 8-29 shows the DSP DMA controller.

Figure 8-30 shows the D/A and A/D interface.
Figure 8-31 shows rtVAX 300 I/O pin connectors.

Figure 8-32 shows the decoupling c: ps.

I/O Device interfacing

8-23

Figure 8-11

1/O Device Interfacing: Address Decoder and Power-On Reset

Power On and Power Gllich Reset
+5V

[ 1|2
R3

2
SRS

220pF

T~ 5oV
|2

;2R7

3;4‘”(

E47

-1 >J§L

R4
ol

SELCSRL

NC - Cycle Reset

PLT

R1J14.

32Kk

SR11

11 je2s

Han 0—‘_‘!

Jaor

E25

DAL<21>H
7] | DS

fR34

2 {son
74

R?
Re (18

RAL<24>
H 104 g

SELRAM
H

TAIK

B0}

RESETVAXL

—

2Res R4

DAL<25>H 1Y Ds

1|2

10UF —

225

22v10

:Ezsv _h

PAL1e
22V

Decode PAL

21K

LM211

Teq

4 A8

cla

i-:$ ‘10(”( 2< 1470

== 10UF

Address Decoder PAL (inciudes latch)
Note: Socket used here

DAL<20>H
8}

HLTREQ
2
HLTREOL

J! evevaure
Naol|

sTREQL

|2 £

|7a

D2
b

HTL

sos

Rél<te2
2 po
ASH

S08

oLk

| DAL<275 H

Mzg
DAL<2>
H

+5V

gR1e Ri

) 12K' 12
2

$R18

Interrupt Decoder PAL (Includes latch)

Note: Sccket used hers

fRi3

LR
2

{2 RSTREQL 1 |

—1He

ENBRST L

IACK PAL

22v10

E131

=TT

BUTTRSTL

NC - Cycie Reset

Re 42

Rra &l

——t

A7 A0
rRe 18
RS [

Note: The tVAX 300 uses CMOS ACTG245 drivers for

‘;fi 1 14

the DAL lines and ACTQ244 drivers tor the contro! lines,

Dsi

a fair amount of undershoot. Some PAL devices and RAM chips

WRBL
1l ps
DAL<6>H
10 ng

These drivers have very tast rise and fall times which can generate
may mallunction when expased to excessive ovarshoot and undershoot. It may be necessary to isolate these devices from the HVAX

Ra {17 ENBVECTOR
|,
raffle _JOIACKL
CONIACK L

IACK]

13875

*74
be

300 signal itnes with TTL buters or provide series termination

rasistors for these lines,

CSOP<>
L 4 o
CS0P
ASH

L2l po
CLK

MLO-006396

8-24

/O Device Intertacing

. Figure 8-12

/O Device Intertacing: Address Latches
Address Latches

Addrest L.alcnes

8BF

B-Bit

Latch
74F373

DAL<16> H

&
LADDR<16>H
1) g RED] ————e

QAL<15> H

14 05 RS

DAL<14> H

13} D4 R4

DAL<13> H

DAL<12> H

DAL<1 1> H

DAL<10> H

E13

DFi<17> H

1 D7 R?

]

Latch
74F373

LADDH<17>

DAL<17> H

8BF

8-Bit

18] L7 R7 Y

16
g RSB

LADCR<15> M

15
14 D5 RS DY—

LADDR<14> H

12
13 N4 R4p—

Rapj2

ADDR<13»
H
LADDR<I®

BM3> L

1
LADDR<12>H

BM<2s L

aipl

LADDR<it>H

BM<is L

LADDR<10> K

BM<0> L

_-L“-O HOLD

LADDR<31> H

—C ENO

LADDR<30> H

-EJ—BJ——-»-C 7a

8BF

LBM<S>L

LBM<e2> L

Ropb
e

LBM<1> L

L
1 EM<O>
LY

},_._.'_:.c HoLD

]——c

—C ENO

F32

BBF

atch

w10

. Ract

atcl

E27

LADDR<«9> H
<3>

DAL<9> H

19 07 R7

DAL<8> H

DAL<7> H

w| _ mspje

DAL<6> H

DAL<S> H

s{_

RapjlLADDRS H

DAL<21» H

DAL<d> H

R<d> H
A Rz} S LADDR<d>H

DAL<20> H

710 B2 &

LADDR<20>

DAL<3> H

|, PO

DAL<19> H

o, Riot

LADDR<19H

AS L

Reppt—_LADDR<E>H

D4
D3

sG
LdEeno

18 D7 R7 04—

WRL

RephS

LWRITE L

LADDRTT>H

DAL<31> H

w| _ Rsplt

HADDR<31>H

LADDR«6> H

DAL <305 H

LADDR<30> H

Thanl__

R<21
H
LADDR<21>

-7

LADDR<3> H

D4
D3

DDR<20> H

B ot
ENO
=

Mo 00ue7

I/O Device Interfacing

8-25

Buepsiu} eoineq O/ 92-8

Figure 8-13 I/O Device Interfacing: DRAM Address Path
FAS, WRITE and CAS DRAM Array Drivers

Row/Column BRAM MUX

5X2 MUX I
74F711

LADDR<R1> H

LADDR<11> H

12 1D-

MUXADDR<S>H

1 R4t 3

DRAMADDR<O> H

wloop FO

prey

MUXADDRH

;

R4 ;

DRAMANDR H

13 OS_E FE

LADDR<20> H

CADDR<10> W

Sota

LADDR<9> H

wliDC Fe

MUXADDR<7>H

| RB¥I o

DRAMADDR<7>H

LADDR<8> H

LADDR<185 H

1D-B
FB
2|10

MUXADDR<6>H

1 R¥# 5,

DRAMADDR<S> H

LADDR<7> H

25 oA papl> MUXADDR<S>H 4 mz
oo

DRAMADDR<S> H

LADDR<19> H

LADDR<17> H

VYV

VYW
hA

00-A

DRAMADDR<4> H

MUXADDR<3>H

¢ P38 ,
VAAA

DRAMADDR<3> H

Ul 0c ponlt_MUXADDR<2>H

4 R252

DRAMADDR<2>
H

8op.c

1 B2t 3

DRAMADDRH

2 DA
A FA

MUXADDR<O>H

¢ AR
R17 5

DRAMADDR<O> H

Hop-a

INVADDR2 H

FB6

SELCOL L

IEL

[oalect

10
olec
)—rfiO Invert
|

+5Y —MN—————

2K Q

' oE
|,

MUXADDRH

LADDR<12> W

LADDR<2> H

PAY

[

10 10-B

H 4‘)F
LADDR<3>
1o

12
¢ TM2,
Yo r—W

DRAMWRITE L

-—CEN

1 me

LADDR<4> H

'NVADDR2H &
W

LWRITEL | s ]
‘

tMUXADDR<4>H

10-D
wloop
C

1ADDR<13> H

Butter

74F244

4ABF

LADDR<5> H

LADDR<14> H

1B
—

“

LADDR<15> H

74F711

T E Fen)

DRAMRAS L

—C|EN

5X2 MUX

YOr—g

of,

AAS L

E3p

Sele-t
Pfinven
Lls (o]

LADDR<16> H

Butler

745'::;2:4

A
2

Driver

casanr | o),

2
2
YOIV

CAS<2> L

Yap—— A

o]ap

casai>t | af,
casort | 2,
.

1 %

VIV

RIB

oy R32 2

YOV

ODORAMCASC3> L

oRAmMcAs<yL

<12

DRAMCASc

.
DRAMCAS<O>
L

-—CIEN
.

R31

. 100

100

MLO-006307

Figure 8-14 /O Device Interfacing: DRAM Memory Array (1)
RAMc 15> H

18
M8 2P

18
1MB ZiP

1B
MB ZIP

1B
1iMB ZIP

1B
1MB 2IP

8 Iy 998

s |, DO

1o OOE

1o 29

®°

8o 0©

s [or O

DRAMADDR<S> H 17| 4¢

DRAM

8
\
A9

201
ap
LI
[

IELT

16 | 44
14 A3
13 A2
12| 44

L W
LN Y
13 an
121

18 1 aa
ol ag
131 a2
2 1 Ay

L
DRAMRAS L
DRAMRAS

aas

7
—'dras

}—-1dras

ORAMWRITEL8

dwe

|--2dwe

L-2dwe

CRAMeASL
g cas

(XN

—-‘é CAS

RAM<7> H
DAL<7> H

iMB ZIP

DRAM

5 ol DO

)
1

GRAMADDR>H 20| o>
Al

H 18| 47
DRAMADOR<7>
DRAMADDR<E> H 18 | 46

DRAMADDR<S>H 17 | 5g

DRAMADDR<d>
H 18 | 5,
DRAMADDR<3> H 14 | 4n
DRAMADDR<2>
H

DRAMADDR<1>H 12 § 44
DRAMADDR<O> H _11 | AD

ORAMRAS L
Iqras
DRAMCAS<0=-L 22gcas
A
REMMWRITEL
S we

DRAM

)

1
AQ
-]

2 | aq
P
XN

|-—-2qdwe

f|(—-%qwe

|—2qwe

_RAMc<d> H

RAM<3» H

RAM<2> H

DRAM

s | ol DOY
[

)

DRAM

3 o DY

]

"o AD

wlaz
LU PP

12} A5

7} as

'8 3 ag
LI B
EN B

LN W
14 { an
1]

121
At
LI
PP

12AN 1 Ay
PN

RAS

CAs

DAL<3> H

| —d; RAS
|-——cd cAs
d we

DRAM

[

]

A9
T2l

WAz
LI P

171
as
L1
W

1MB ZIP

s o [eleds

5 {p DO

DRAM )

o]
]

19 a7
LI IV

17 1 A5

DRAM

[N
1

1MB ZiP

1MB ZIP

DRAM

s | Dl DO 3 ,i_ DI Do
[
1

a7
IV

18 | ag

BN
v
14 } aa

171 as
13}

12" § Ay
a0

L
Tdmas
—~~:~d cas
|—%dwe

17 1 as

131

1211 1 a1
ap

—Idras
b--2dcas
|—2dwe

[]

13 ) A2

LT RAs
|--2dcas
p—dwe

CSDP<0s L

13 1 a2

———d; RAS
fqcas
dwe

DAL<O> H

DP<O> L

RAM<0> H

18 | ap
18 1 a4
41 aa

A1
BFY

7 I

18 | a4
15 { aa

121LU

A
7 I

AD
—2]as

12A 1 SN
Ay

I Ras

RAMci> H

1MB 21P

A9
[T 2]a

13 ¥V ap
2 4 aq
a0
114

Jgras

DAL«<1> H

o~
[ o DoH

16 { a4
1 a3

|f—2dcas L—fdcas (—2dcas

DAL<2> H

|1MB 2IP

8 | g

17 | as

]

~ RAM<S5> H

1MB 2IP

RAS

AAM<E> H

]

1 ) a2

|—2dcas

1MB ZIP

18}

|12] A
L

|--2dcas

DALcd> H

|20
:g
W | a7

18 | aq
LN P
13 ) Az

[

DRAM ’

], 90Y

-2
::
9 ) a7

[

16 | ag
L IV

tMB ZIP

[

181 aa
LN P

121

—A--:ffl cas

Az
PP

| mas
p—Idcas
|—2dwe

|--2qwe

TN v

BLE Y
Y
LA

DRAM ’

LY PP

_____)1_1 Az

131 Az
12 ) Ay
PN
LI

{(—2qwe

20)ag
9]}
a7

2d cas

| ] o
19
LI

18 | a4
LI Y

}—Ldras

idas

DAL<S> H

s DI Doy 1.2

171 a5

|—I dras

1B ZIP

L. 20
4 Ap
10}
az

]

1B
- S———

1MB ZIP

DPL

CSDP<1> L

1B
ety

B
::
WAy

Ad
1a3
A2
Al

AAM<8> H

DAL«B>H

DRAM

|—IdRas

DAL <6> H

H
DAAMADDR:«O>

Lz~g Buwepslu) edineq O/l

A:
A7

DRAM .

[

AB
A7

.18 ag

)

s [

)
S—

'8 1 a6

M) a5

DRAM )

DRAMADDR<4>H
DRAMADORc3> H
DRAMADDR«2> H
DRAMADDR<1>
H

DRAM ‘.!J

RAM<9> H

DAL<O> H

DAL<10> H

H 18 [ o
DRAMADDRc6>

100

FAM<10> H

~ DALcit> o

DRAMADDR<8>
H
DRAMADDRc7> H

RAM<11> H

~ DAL<iZ> H

R
DRAMADDR<9> H

RAM<i2> H

DAL<13> H

DRAM s

DRAMADDR<O> H

RAM<13> H

DAL<14> H

EAVAV A

100

RAM< 14> H

DAL<15> H

17
1 as
i3
PV

14 | A

12| | a0
ay

b—ZdnRas
|—2dcas
}—2qjwe
MLO- 004479

Buioe Heju; eoineq O/ 82-8

Figure 8—15 1/O Device Interfacing: DRAM Memory Array (2)
AAM<31>H
DAL<31> H

!
=

100

DRAMADDR<9> H

DAL <30> H

2
]
1

DRAM
3
o DOt

]
1

5
[
1

]

20 :B

2| an

" | a7
W)
a6
17}
as

ORAMADDR<d> H 18
Ad
ORAMADDRc3> H 14 | 2q
DRAMADDR<2>H 13 | »,

DRAMADDR<1I> H 12

6 | ag
14 § aa
134,

121

DRAMADDR<O> H

DRAMADDR<7>H 10 | 5+
DRAMADDR<6>H :8| ¢
DRAMADDR<S> H_17 | 4¢

DRAMRAS L

19 | a7
18 | ag
17
a5

RAS

Tqms

DRAMGAS<3>L
2 cpg
DRAMWRITEL
8 4 we

[
1

DRAMADDR<8> H 20 A:

DRAM
3
o DO

DPRAM s
oI DOt

s
[
1

DALc24> H

1MB ZiP

°
1

[
1

)
1

1MB ZIP

DRAM a
S | ol DO

1MB ZIP

DARAAM 3}
PRAM
.
B
o DOD
el
ooy
[
1

W1iaz
18}
a6
|
7] a5

19§
A7
18 ] a8
LE

2 | a8

20 | ap

2§ an
"1
18}
7

a7
a6
§ag

2 { ag

® [ ag
L3
I
3] ap

1€ | ag
14 | aa
31 a0

LN
'
LI
P
13 ] a5

8 | a4
L
PO
131 a0

L3
W
14 | 42
13 | a2

16§
LI
13}

'8 | aq
18 | a3
3}
a2

1 o Ap

1 | a0

(1N

v | a0

" § a0

A‘i-

12] Ay

|—2dcas
|—2dwe

L—Idms

| —Idnas

_—_’g ms

RAM<23> H

RAM<22> H

RAM<2i> H

RAM<20> H

}—2iqoas
|—.dwe

2goas
we

|—Iqras

9§
A7
LIS
PP
17 4 as

a5
12 ] aq

2 | Ay

|—1dras

1 cas
|—2dwe

|—Ldras

2 8 A

11 1 a0

|—_dras

idcas
we

|—Edcas
|—2dwe

—fdcas
|—Sdwe

|—idcas
|-fdwe

RAM<19> H

RAM<18> H

RAM<17> H

AAM<16> H

me ZIP

1MB ZIP

TMB ZIP

1MB ZIP

1MB ZiP

1MB ZIP

1MB ZiP

1MB ZIP

DRAM

|- ——

AP
DRAMADDR<8> H gn_j A
DAAMADDR<7>H 138 | 47

A9
2 | an
19}
a7

.
)

DRAMADDR<6>H 18 ) 56

18 § a6

DRAMADDR<d> H 18 | 5,

o1 [ole]>

DAAM

DRAMADDi3<9> H

ol [ ety

DAL <20> H

L
P
8| a6
17 | as

DAL<22>H

DRAM

DAL<21> H

]
a7
'8 1 a6
1]
as

DRAM

oI DODy

DAL<18> H

DRAM

oi DO

DAL<18> H

DRAM)

8o DO

DAL<17>» H

DAL<16> H

AD
Y
Ay

A8
VY
12 ) a7

AD
2 | .8
" | Ay

A9
2 { aa
9]
a7

AB
20 | pn
% ) a7

.
T

17 1 as

!5 1 A6

9 1 46

18 | as

18 | g

14|

14§

¥
{as

[}

171

]

DRAM

ol DO

174

18 | g

14|

16 { a4

14 | aa

DRAMADDR<2>H

13 § ,»

13 1 a2

13 1 A2

13 ) a2

LEH

13 § 22

13§

DRAMADDR«<1>
H

2 ) A

12}

12 } Ay

12 | Ay

12§

DRAMADDR<O>H

1 § .4

1.3

7
DRAMRAS
=
=]
e L
RAS

7
——-(]
RAS

p— -

DBAMWRITEL
6 Jwe

[—tdwe

[—°dw:

|—qoas

RAS

| —i<3cAs

(1 RAS

———(C] RAS

[ —S°dwe

|—*dwe

-—2dcas |—Edcas

DRAM

DI DO

AD
e

17 | as

]

8 5 A6

17 | ag
18 | aa

14]

13 | a2

a4y

2 | A

12 | Ay

1 | Ao

——C] RAS

|—2dwe

|—2dcas

]

}———1 A9
® | g

14 | a3

RAS

:g: cas

18 | a2

DP<2> L

CSDP<2> L

]

DRAMADDR<3>H 14

DAAMCAS<2>L2dcas

DRAM

o DOK

DP<3>L

CSDP«3> L

1MB ZiP

DRAM J
—
1
&-‘ DI DOD
A9

RAM<24> H

2§ g

20 | ag

DAL<25> H

TM8 ZIP

RAM<25> H

DAL<23>H |

o DO

DRAMADDR<S> H 17

[

RAM<26> H

DAL <26> H

1MB ZIP

DRAM 4
Kl
oI DO

RAM<27> H

DAL<27> H

1MB ZIP

DRAM s
ot Do

RAM<28> H

DAL<28> H

1MB ZiP
&

RAM<29> H

DAL <29> H

1MB 2IP
&

RAM<20s H

———C] RAS

t—2dcas
—2dwe

————C] RAS

|—idcas
[—°*dwe

LO 004480

Figure 8-16

1/0 Device Interfacing: RAM Data Latches
8BF

BBF

8BF

8-Bit

8-8it
Latch
74F373
E15

8-Bit
Lateh
74F373
€12

Latch

74F373
E6

RAM<15> H

| _ R7plt DAL<1S>H

RAM<31> M

RAMcI4> H

RGD.____‘G E_>AL<14_LH

RAM<30> H

17|

neplt DAL<30>H

RAM< 13> R

RS D_‘f___w_f_fi

RAM<29> H

14|

RAMc<12a H

13|

Rasl2.DAL<i2-H

RAM<28> H

mp.:.z—_gé&.‘_z.?—)_f

RAM<27> H

R3 p-_g__p._A_.'Liz.'l H

RAM<26> H

OM
o
1| _ Rapl DAL<Z

RAM255 H

RAM<24> H

— D7
i D6

et DS
e—— 0

RAM<1i_>H &in, 5. PAL<1I> M
M
1
c10>H 7| D2 Repf®PAL<10>F
RAM
T
H
A
Rweosn o[ oS DAL
i AL<ExM
RAM M 3| Ropj D
<113

e —— D0
1
MRADY L
————C HOLD

—{D7

17l e
0>
H
RAM<3

1 06

s
e

—_—l Do

MRDY L

DRIVERAML 0t

R1 ;;.S_D_A_kfis’_H
RO aL_[lA_Lf_?i)_:l

Jm—

——-CAHOLD

DRIVERAM L

1 ] o

88F

8BF

8-8it
Latch
74F373

8-8i

E17

18| _ R7DHSDAL<23>H

HGD—‘G
'?
RAMcE> H
—106
I RS 15
RAM<S> H

DAL<6> H
DAL<S>H

RAM<22>eH

Rep.‘f‘_w

RAM<21> H

RS D;‘_S_DAL‘E‘._::‘

RAMcd>

R4 12

DALi‘_?_H

RAMc3> H

A3 b-—“—

DAL<3> M

103

R2 DAL<2> H
3
RAM<2> H
S
— D2

of mipt DAbsiaH
RAM<t> W1
D
RAM<O» H

>H
i
mop}DAL<O

e DO

T
'
fo=r
| __ L
MRDY
MADY

, RAML 1400
o
ORIVE

A\l

7
06 R6 [ S
7]

Mps P
1

lt
. CSDOP<3>L
map

DPc3a L

DP<2» L

D__(?_:_L
RZDE‘.-——E._&SDP

DP<1s L

R1 gLfiffi:fi

DP<O> L

D2
—
— D

MRDY L

L '
DRIVERAM

RQD«E—».-.QEEE:P:.E

5558

Jpno

E14

RAM<23> H

— D7

R7RES

Lateh

DA_L_<7> H

74F373

RY D—W

RAM<7> H

Bipy

29>
HH
DAL<29>

errnser] D3

——{D2
—

RTDMA_L__d" H

——D7
— D6

——DS

13|

RAM<20> H

—_— e

RAM<195

Rap] 2-DAL<20>H
DAL<I1B> H
9
H
RappS_DAL<1O>

RAM<18> W

Roppe-DAL<18>H

RAM<17>H

H
s
Ryp DAL<17>

RAMc16>H

1
z
KH
<16>
Rog)i-DAL

e D2
o bASLALNILE F,7'

— Do

MRDY |

DRIVERAM L
E

SYNCHAS H

SELRAM H

=t 74

e i
CLKA H

F20

774

LWRITE L

MslE3
b
P

DRIVERAML

AR
mE
=
;‘1’0
2

=
.

O: ERG

MiLO-0D448"

VO Device Interfacing

8-29

Buoepeju| soneq 0/ 08-8

Figure 8-17 /O Device Interfacing: DSP PGM Loader ROM
4BF

4BF

Octal
Driver

74F 244

74F244

E52

ES2

A3
.

A3
vaol
5 _DSPDATA<14>H

A2
Al

vip| OSPDATA<13> H

LS I

4BF

48F

Octal

Drivar

74F244

D7 Dp=-

8laz

DS D

D34S

]

4KX8

E48

slas

{

1._2iap

DSPDATA<11> H
V9 12

ROM
2742

E68

vao}

4 DSPDATA<10> H

o1
00 [ L

22| ,0
2] 4o
a7

22| oo

DSPADDR<S>H

DSPADDR3>H
DSPADDR<2>H

DSPADDRH

7],

CSROM L

CE]
']

)

DSPDATA<2> H

T10}'6_DSPDATA<1>H

voo}'®_DSPDATA<0>H

I
a;

2| a6
W

8|\

4l ad

ao
1y

t an

ENO
nd cs

12 DSPDATA<3> H
Y

B Ay

21 ag

D2 m

H
DSFADDR<D>
DSPADDA H
DSPADDR<7> H

HSPADDR<10>H 1) a1

DSPADDR<0O> H

D34

vopi " BSPDATA H

€48

vao)
4

—t—Ela2

papd

OEROM L

.‘_'J

D6
[
R4

v1pl 5. DSPDATA<G> H

DSPADDR<11>H

DSPADDR«d>» H

4% I

DSPADDR<6> H

H
DSPDATA<d>

e e ——4 AQ

Octal
Drivar
4Kx8

DSPDATA<S> H

y1p]/_DSPDATAS:H
Yool

DSP
12>
H
H
vop} »o -OSPDATA<12>

~2den

ES9

v2ol5

s LY

ROM
2732

vao)) DSPDATA<7> H

H
vap)? DSPDATA<1S>

L1
|

s ENO
dcs

MLO- 004486

Figure 8-18 /O Device Interfacing: rtVAX 300 ThinWire/Thickwire Network
Connections

Thickwire

15-Pin Female
‘D’ Connector

-ORETURN 2

560

0.5W

ThinWira

\k\‘ NXXXX

1,2

\¢2

/1.1

ne|

T
.5

[

-8V ——-——-——-—0//.0;
O
Thickwire

ThinWire

5 0/0““

180L

RCV+

Rev-

XMT+

XFMR

%7 GND for «12V Supply

O—1— (?

o2
16

”

" C

]
——
GND for +5V Supply
—

*.___fi.EO’"

——Q

75 mM

ISI Ethemet/802.3 Jumper

-V

/77

498
3 499
S 490
< 490
L
L/
L7
o,

XMT -

coL+

M—E { ‘
coL-

20—

23
30—o4

Ormrenmad

‘1

]

A|{

1
401

< 40.1

> 1%

< 1%

L
_LOJUF
4

0.0047uF
21000V

5V and 12V

Common Ground

Chassls Ground

{izolated from SV and 12V GND)

Jeps

14g P)i*oy,
I

2
——

CD+L

cD-

RX+

50V

DPB382
16

{

-SRETURN

XCVR

]

)

1C01UFL_2oHBE
P
50V

L—‘-sz

10K |

| 1

Afin

Foeen

s D664

&@cou1

12 IrR

TM% | L2 lvees

Foor

o] VEE!
N

100V

Decoupling cap - pisce closest to pins 10 and 13,
MLO-004455

I/O Device Interfacing

8-31

PAGE

8-32

INTENTIONALLY

LEFT BLANK

Figure 8-19

]

P P4

(]

]

(]

)

P3 P4

[

(]

/O Cevice Interfacing: DMA Write Cycle Timing

P3 Ba

]

k2 P3 P4

[]

[}

P2 P3

[}

EP1EP2EP3}P4§P1EP'&EPG{PAEMEP2§P35P4§P1§P2§PSEP&§P1EP2§P3§P4EP1':P2§P3§P4§P1§P22P3§P4§P13P2§P3§P4;P1§P2§P3§P4§P1EPZ';PBEPA;NEPZEPSEF’AEFHEP2§P3§P4§P1§P2§P3§P4E
CLKB A

[}

]
SDSPBR

)

]

(]

PIPA H

{

()

[

(]

]

[}

]
s
+
[}

1
p—
"
1]

+
ng
"
1

]
—
A
]

+
.
.

]

[}
.

+
1}

]
'

o
v
[}
L]

(]
v
il
.

]

‘

1]
’
*

[]
(]
.

i
.
1

'
i
'

+
»

.
]

'
]

+
[}

]
1

Al
.

]

[]

]

[}

]

[

[}

.amaa

3
1)
]

[

(]

'
]
i

.
v

]

)
[}

)

[]

]

[
]

v
\

[}

Ll
+
il

+
1
.

1
-y
+
1]

+
)

k)
1

]

1
.

1
+

‘

]

1
'

]

]
'

[}

[}
1

A
v
1
1

v
.

(]
T
1
[]

‘

[]

1
+

.
[}

+
+

1
.

]

‘

)

—p—————

(]

[

]
v
t
+

I
1]

]
1

-t

)

’

[}

]

]
i

[}

(]

+
+

(]

]

’

]

‘

[l
]

3
1]

)

[}

v
’
.

]

[]
1]

)

13
1]

1
p—
.
1]

v
3
1}

.
]
L)
.

L)
1}
1]
1}

1
’
L
v

1
+

1
(]

[}
[}

1
1

1)
(]

1
1

*
.

’

]

v
v
)
.

’

e
]
.

0
il
'

L]
3
1]
1]

BR)

T
’

1
.
¥
1}

1]
1
i
]

T
1}
1
+

1
1
i
1]

.
1]
1]
1]

F -

]

‘

]

’

)

1
.
.

1
.
1]

+
.
.

'
(]
1

(]
[}
i

]

‘

)

.
+
.

[]

————

1]
,
£l
]

.
t
[}
(]

.
[}
1}
[}

13
+
13

)

[}

[

)

Trorp——

1
E]
1]

1
1
»

{]

[}

1}
1
1
1

.
1]
1
i

[}
[]
1]
1

¥
1
.
1}

1
[}
[}

1
»
1}

]

[}

[]

[}

1
.
'
1}

’

1
.
'
1

)

1
1

)

i
]
.

(]

[
.
1
1

()

)

]

1
(]
[l

]

‘

1
»
1

Prasseperamap

'
T
+

'
t
3

1
L}
.

[]
1
1]

]

[]

[}

[

v
1]
+

)

]

)

[

’

‘

’

(]

[

——

——.

’

]

[}

]

.
1

’
*

'
t

'
.

.
.

[

4
1]

]

ASL

‘

(]

Voo

]

)

.‘

]

[

)

‘

:
T

.
.

'
]

.
1]

'
]

'
1}

'
]

'
+

'
.

'
[}

.
+

HER

(]

.
'

[}

]

[}

[]

]

t
’

]

+
N

‘

]

)

]

irponpionpard

/H
0

]

‘ \x)

]

:
1

;

)

1
\

'
S

(]

[

‘

A'
v

[}

]

[}

]

(]

L g

0
.
[

.
s

v
L]

.
1

s
+

N
.

C
*

*
‘

[

]

v
.

.
[

‘

.
1]

T———

)

]

(]

]

[}

]

‘

13
'

]

VNS

———

’

[

’

)

(]

N
1}
"
1}
.

;

Voo

v
'

.
1

’

[

Y 2 T

L—

]

[}

—r

Pyt

[]

’

)

Senae b

.
1

'
+

'
[]

H
+

'
]

.
?

dovrarrbomaens

.
'

’

[

‘

.
1

)

[

'
+

'
]

H
1]

v
.

.
1

H
13

'
1]

'
1

'
13

¢
1

.
L]

H
+

[
1
t

.
1}

rE—

—

'
1

)

‘

’

]

[]

(]

[}

]

[}

)

[}

1
1}

’

]

[}

4
'

[}

]

[}

’

]

’

[}

’

‘

[

[}

’

]

Semsdheacad,

e——
'

.
(]

’

]

Prmnarafaama

'
[}

n amann

v
'

)

[

T
.
i
t
'
.
‘

)

‘

)

[]

‘

)

]

’

TN SRST

’

'
.

’

]

-y

Senan:
same

Mame

Sas

]
'

]

'
1}

]

[}

’

L SR

frarmenpsmay

(]

[}

]

.
v

‘

.
’

h
.

]

'
’

]

LATCHRM L

]

L}
ag
1}
]

DSt

)

]

ENBADDR L

OMG
L

(]

DMpRL

[}
—
'
.

(]

!
v
+
]

'
+
.

()

SDSPSTRAB
L

)

L]
i}
.
.

[]

1
'
N
.

v
»
'

ENBSRAMDALL::::;::5::::33::::::::t:

DSPREADY

State Machine

CLKA

State Machine

[

—

‘

)

‘

p—y

1
)

‘

p—p——p—————

[

’

)

’

]

’

[

‘

’

‘

)

[

‘

’

)

]

[

‘

[

’

[

)

]

)

’
'

()

‘

)

[

]

‘

DAL<31:03 H

)

RODY L

]

}

)

.
L)

’
1]

C ;m; w;.fl;
ml fi

iouh AbOR

:L;:

'
]

IDLE

REQDALBUSA REQDALBUSA REQDALBUSA ASSERTAS ~READCYCZA

~READCYGZA FINISHREAD2A FINISHUPRA FINISMUPZA

iDLE

IDLE

REQDALBUSE REQDALBUSB REQDALBUSB ASSERTDBE READCYC2B READCYC2B FINISHREAD2B FINISHUP28 F!N!SHUPZB

IDLE

1I0LE

REQDALBUSA

REQDALBUSB

HEGDALBUAA

REQDALBUSB

REGDALB
A

EA DR

RERDCY
e S Lt

REQDALBUSB STARTACCESS READCYC1B

crEnk

READCYC1B

READCYC1A

READCYC1B

FINISHUPTA

FINISHUP1B

[}

‘

«««««««««(««(««

IDLE__

IDLE

FINISHUPZA

FINISHUP28

1OLE

DLE

IDLE

10LE

IDLE

IOLE

IDLE

GLKB

MLO-004472

/O Device Interfacing

8-33

PAGE

8-34

INTENTIONALLY

LEFT

BLANK

Figure 8-20

PULE

EEE—F
<

CAS Decode Logic

Address MUX Select
Flip-Flop

Address Strobe Synchronizer

AS L

|s ]fe

Stats

Machine

REFCYC L

Note: Socket uged here
P-State Flip-Flop
RAST L

o l‘.
FA 18LS

~ 74

CLKA H
{
AS L

I
| Fos

AS H |

|l E4L

E DS:?

35
—ENBEAS ¢
gg%'r“~—“’fim
3R

INVADDR W

{

REFRECL

EICHXS
B
CWRER

12.8 uS Rsfresh Request Timer

571 1

Refresh Request

Lateh

CLKA H

DPEDAIVE
L
Wip
e U NN
LS128

g [}

ENBCCTLOPE L
Ready Hold Lakch

DRAMREADY L

IOREADY L

BUT

—

//J

+5V ~Lera
Bl——{CP
L EEND

CLKA H

{

cqis

10:::;'“% Y

8 _ g2

.3_.,' AST
H

—

se DPEL

)

L 7
~lo
W=
PR-OE

45V

TCD

o and DPF Drivers
COTL

RESETVAX
L

CAScO> = L

—

MROY L

H
RVADDRZ

DRAMFEXDY L

L®amR

0 IER

REFCYC L

Reset Hoid Latch

RESETVAX LTM

<1> L

CAS<1>

7718

LWRITE T
BCK L~

g’ig

CADORLAT> B34 13

RST U

SYNCHAS L

TRVADDHRI H

RVADDRI H————

_;q@“—
QqE2
s [EP

ENBCAS L

obs

]

N,
2 |0

CAS<2> L

agflgs

;

cLR2P

cAsdbL

Memory PAL

1
L

LWRITE 13'Efi
H

PRONELE

18N,

2 EP /
2qez

LBM<O> L

MunorLCommuor

LI T

1
O

LBMci>
L

CLKB H

ERTILE
ufié@*‘jfi}u

LBM<2> L

-2

(

WMaL

SYNCHAS H

/O Device interfacing: Memory Controller

n iRSTL

DS L

SELRAM H

PP o lweoy 74LT,
3

E£21

move

1 [74
12 SELRAM L
‘F“ Dot SRR

MLO-OG4ATE

VO Device Interfacing

8-35

PAGE

8-36

INTENTIONALLY

LEFT

BLANK

Figure 8-21

/O Device Interfacing: Console Interface

Interrupt Vector Genenstor

4BF

Console interrupt Veosor « 02C0

OSP imerupt Vetor « 02E0

oer

W&n

;mcgn

Driver

EmAFZA

'misw
o

vaEl-2

DAL<1%> H

Yzof- 3

DALcias H

DAL<13> H

wa_'YOD

<12 H

D3
AL D2

13 1p
"

.
I

19 +EN
48F

RXDA oa

|18

DAL<?> H

B8 -2

KI> AS

BS <A 13

Lt Ad

DAL ot> i

B3 ol-t2

‘.22 18

DAl<> H

Aa',

DAL <> H

BO <

]

T4LS244
L -8 103
.

nes

<it> H

Yz b

<10» H

Y1 ot

ot
el

YOOI

)

ENBCONDATA H

@!—

Octal

Oriver

\
x
oL
W

é:bsz“

v -2

DAL<7> H

Y205

DAL<E> H

Y1 04

DAL«<S> H

voo2

DAL<t» H

EBY )

D8 H

’

tlos 7 ‘
Y2

DAL<2> H

viDl18

DAL«<l> H

ENBVECTOR L

2 n,

\den

ol-14

T°H

DAL<O> H

'.E

P
.

o
oL

Rl |
)
5
27K
Y —g—a12

Sy 2ghd

- 10

-y

g
vo2
o

asT L

W5V

A L

égg
4

Nois: Socka: uped here

WLT

Conscle PAL

PAL

guo

INEES

9636
mb

“,‘.".g:f
e
i‘-“ma
.
A
B
® srare
¢

RSTR s

RS D14

vos g—:

é:tésw

Uprn
Counter

Octal W
Oriver

180 m Braak Detection

g -

)

—

Conscie. ROM and IACK Ste Machine

COMIACK L

Une

RaY
BV el
pn B

36084 MHx

T ,-Dla

—gp— &
|
Et9
e

—GEN

—CQ EN

Al
gm

L M

& H

LWRITE L

Hene
ENT
gg

-4
—;

TA H

D—i—

D10
o9

§
D8

SYNG

g")

ENO

sRess

R4 I

Tcp

cLK

VO Device Interfacing

8-37

PAGE

8-38

INTENTIONALLY

LEFT

BLANK

Figure 8-22

/O Device Interfacing: User Boot ROM Bank 1 with Drivers

_N_—_ym-—-—48F
|‘U1V5R)k.fl

L ___EQ! m...i-eq

4BF

21 ROMDATA<31>» M

20 ROMDATACH H

N r4en

eR>

| PM

'_"_'—‘M"RG

oALsta H

21 _ROMDATA<15> H

T
e

13 ROMDATA<26> H

14 ROMDATA<28» M
ACOMDATAcZdn

‘sjzsxxs

:
§

[(RODH T

[AODA<TS

_x::m: 81? :
AR ORoTE
ADBHG
(ADCH<SS
03

mnq% L

PUCLOPK
H 31

—

‘

AOMREAD,

DAL<Zos M
DAL <28 H
"

aeN

[

48F

PUT]

EqCHiP?

[ADOR<YA>

siblien

Y1 DpLm

""‘"‘“"‘WD ]

DAL<2S> H

~CJBN

17_ROMDATA<I%> H

ROMDATA<ZO H
1

15 ROMDATA<18y H

CADDRETSS

ACBns

—2——]

FODR<YT>H ~ 7 %F

AUDRT
CADD

OB R

(A
He > W
CADDH<E> N~
AL

CADDE <45 R

ADOREH

R
T

oLe

DAL<12> H

12
B
7olie

DAL<11> H

;

)]

—q&N

2‘3';“‘

;
:

DAL M

—L
L
E
N

Yo o8

DAL W

ENICHIP

1
—1den

(UYPR:»&!]

<23

DALzt

H
>

YIDRTooo SEER
l

‘

DAL<20s H

Tapoaa

‘
EE—
)
R

s
L]

B
N "‘a 12
A3
A

Y2l
Y1

e
ROMREAD

)
2

ODR

DAL<18> H

CADDH<B

18,

DAL<i?> H

DALctesH

CAD R<T0

__18 _ROMDATA<d> H

17_ROMDATA<IH> H

98 ROMDATAC2s H

4y,

}

CADDR<Z

ENIOUTP
POME
T2
RNK
<
ENMOLTRUT)

POCEOPE A4 - 3 oy

DAL W

=
DAL<é> H

DAL<3> H

DAL<> H

DaL H

voolte

DAL<O> H

48F
Octal

E®

ot
ROMREAD L

DAL<E> H

b _,._.,._9_#,‘2

14
.

[

DALTs H

) A0

K 26

DDA

AOMREAD L

12_ROMDATA<O» H

163

CAUDR<h B %

LA
<7i_. \UDHES R

%;nx%“

£32

19_ROMDATA<S> H

CADDRSTS
W3]
LADDR=1T> H
27

Yot

AoRar

AL mgW*

DAL<19> H

ROMDATASB W

| 20 ROMDATA<E> H

14_ROMDATA<!»
H
il Satlaly

LADDR<18> H

4BF

B -o

AVl

..E_P_‘._...____

]

4BF

o A0

7
"8

B
—

Octal

A Ek

DAL<22s W
,

2
CABDRSTH

13,

|13 ROMDATA<16» H _

— 8

:
:

ROMDATA<E

48F

E76

ity

14 _ROMDATA<!7> H

Bsiei

14_ROMDATA<O> H
13

.
ROWMHARK 05
E‘.E:g::%‘%j’“"”"

1 Ja

Srow

18 _ROMDATA<21> M

FTUVPROM

Rkt

A
rA Tk

Ociai

20 ROMDATA<22> H

’

DALt H

" Dl

/10

% ROMDATMAZB

Az ,

DAL<14> H

wl,

AOMREAD

oL2

WOR
W~ <E
70—
1,

—
DAL<iS>

DDR<E

DAL<24> H

;

18 ROMDATA<10> H

OvPRGH

:g_

“ |

4BF

Jl':ggi“% H

CRAEN: M 14
Ui —
CRODR
R

| 19

‘

fat

.17 ROMDATA<!I> H

PP
—rld
[ADDR<YE R %

"“‘2—""-___3DAL
H
1w . ®Y
TNl
e .DAn

uymgl

ADDR<'i>

18_ROMDATA<IZ> H

: E«wz«

‘

> A gk

voole

DAL<30s H

]

A POR W

14 2as

1.3

g
=
%

B,y

T
UVRRGM -

ol-3

.17 ROMDATAQT>
M
|| A2

Driver

20_ROMDATA<lds H

1{en

VO Device Interfacing

8-39

PAGE

B8-40

INTENTIONALLY

LEFT

BLANK

Figure 8-23

1/O Device interfacing: User Boot ROM Bank 2

User External Boot EPROM Bank 2
Address Range 20280000 to 202FFFFF

ROMDATA<31> H

ROMOATA<30> H

ROMDATA<29> H

AOMDATA<28> H

ROMDATA<20> H

AOMDATA<27> H

e N 1/

ROMDATA<19> H

ROMDATA<26> H

‘

ROMDATA<18> H

ROMDATA<25> H

ROMDATA<24» H

ROMDATA<17> H

pe e
]

LADOR<18> H

CRODR<T7> R~

CAGDRLTES
LADDR<13>
y

5
)

CAUDR<TT>

OVPROM

"t
3

|'6

Jaxxa

CADUH<TZS

CADDR 9o
FADDRL7>
AT OREET
L KADDR<5S

CAODH TRE
o
CXDOHS7>
OUR 6>

<Z>

FULLUPR H

PULLUPE H—

[ADDH<d> H
CAUDH<35

R
—1

10"~

(ADDOR<Z>

OUTPUT]

(ask

ROMDATA<16> H

LADDR<18> H

LA
1

ROMDATA<11> H

E—

ROMDATA<G> H

ROMDATA<8> H

ROMDATA<1> H

ROMDATA<O> H

LADDR<18> H

XODRST7>
H

.~T —

.3
=

sk
!

T
CADORSSs H

‘

CADDR<7>
DR F

</>

CADDH< <>

CADDF<4>

R<3>

CADDH<2>

0 J

28%%%&%—,.———%—@ ENfOUTRUT]

ROMREAL L

ENOUTPUT]

POLLUPA
H 31—~

PULLUPA H 31—

POLCOPE H—— —

ROMDATA<4> H

[ADDR<T3>
RDUR<1Z>

ROMDATA<3> H

L
L
CADDR<145

H<2>

ROMDATA«<S> H

ROMDATA<2> H

ROMDATA<6> H

[ADDH<3>

ROMDATA<7> H

ROMDATA<10> H

<Th>

21
20

</>

ROMDATA<12> H

CADDR<SS

ADDRrS
CAUOR 62

ROMDATA<13> H

P<14> H R

TRt
CAUDR
TS

Gewoureun

[AUUH<TZs H

——

[ADDR<13> H

<1b>

UV PROM 27010

LADDR=<19> H

ROMDATA<15> Y

ROMDATA<14> H

e =

CADDR<d>
H

AQG

ROMDATA<21> M

PULLUPK
R
17~ & EN[CHIP]

ROMDATA<22> H

ROMREAD L

EN{CHIP}

ROMDATA<23> H

CAUDOR<S>

13
4

! el

Ep—

T TOVPROW

TDR=YZS

[ADDH<ds W~~~ 15~

—

ABBRSTE
<Td> R

ROMREAD L

j;"'“““'““{

ADDR<18> H

<T3> H

CADDHR<3>

;

LIl ool

TOVPROMT

i
e

EN[CHIP]

(1§

EN[CHIF]

12BKXBUVEP

ROMBANK<0> L
SELROM H__13_wr
o

—

DS H — 10 g%

.8
M—

. ROMREAD
L

SEROMH | Foon2

ROMBANK<1> L

MLO-004484

VO Devics Interfacing

8-41

PAGE

B-42

INTENTIONALLY

LEFT

BRLANK

Figure 8—-24

GTP“?C

VO Device Interfacing: DSP and Private RAM

mmma?mmmmb&-mmq

320025
£137

Bia

A—

D13 <A

P10
g)
0
0y Bl

+
T

'‘

03 <

B: B
0o

‘

ArS

;

Ald
A13

:
;

i
!

|
‘

Pt
200

A7
AS+

A0
DX

N
A8

1
>

W
o 3—-‘-——-———-—0o

A——

»0
Qwe

I A0
WE

ENO

BE <o ——
T
o

P
01

)

ENO

RAM

i —

5
01

BET—
04
A1

S
———

4
A3

o7 g—-}%—-

P
.

)

BS
04

2
A3
dcs

RAM

s
04
<13

;

| RAM

07 TA—H—

8
A3

i
|

{

Hoe )

RAM

:
:

‘

e
D4 <>

g
3
PR SN——

S————
- T

d
A3

£
A3
~

)
WE

A0
WE

ENO

L 2lcs

——

ENO

|
:
!

VO Device Interfacing

8-43

PAGE

8-44

INTENTIONALLY

LEFT

BLANK

Figure 8-25

1/O Device interfacing: DSP DMA Transcelver and Parity

Genearator

R&S

...BL_..._/

100

|»

ENBOMADAL (

ENBOMAWR |

DSPDMARDY H

I———

RICPATASIS®>
H

PEPDATA<TOs H

]

ADDR<O> L

z%;‘s

ENBOMAF

)

4ABF
N

TF 244

Rd> H

W _

ES)

EQRCEPERR|
—

B
;
57

;

é,~_‘_.p DD;

—— ign

e
- T
;
e
3A

"'”""Y"T"' 18

B ipg

-——-—————-——-»lCEN

CSDPed> L

CEOP-i> L
CSOP> |

YO Device Interfacing

8-45

PAGE

8-46

INTENTIONALLY

LEFT

BLANK

Figure 8-26

V1O Device Interfacing: DMA Address Drivers

4BF

Gotal
ASS

100

[£44

7as2

DAL<31> H

DAL<30> H

DAL«1S> H

1. A vo] -2

DALs14> H

LAY

1 Re2 2 _ 18 |,

14> H
SRAMADOR

SRAMADDR<13> M
<

3l
A

DMA Base Address Ragister

Extra g:; %?om"

.
L=

SRAMADDR<12> > H
<

SRAMADDR<!1>

SRAMADDR<10> H
SRAMADDR®> H
>

DAL<30>H

vap-d
17 E,_.. e

DAL<13> 1

ka1 H

3 ,.A.L_h_...‘
viorls
voor-2
11

OAL<l1> H
OAL<10> H

199 en

Octal
Driver

DAL<28> H

3
]

DAL<27> H

DAL<26> H
<253 H

DAL H

DAL<B» M

b e
sl

DAL<7> W

DAL <6> H

SRAMADDR<7» H

SRAMADOR
6> H

<S> H
SRAMADOR

L9~ En

48F

SRAMADDR<4> H

7 Jaa

SRAMADDR<3> H

18 an

SRAMADDR<2> M

13_{a

SRAMADDR<15 H

ENBADDR L

LI T

e
v2

o8
_ipe

—T ¥,

CSDP<3> L

0118

DAL«29>1

y-12
.

DAL <28> H
DAL<2Ts M

DAL <285 L4 H

7 o

<o,

] ENLK

DAL<S> H

-2

DAL<24> H

RE1

)

vz 18
vt

DPEL
DAL<1> H

DAL<0> H

BM<3> L

BM<Z L

ote
"

BM L
-

CSDP<2> L

CSDP<I» L

L SLPPY
i

2] EN
a0

n®

8BF

[]754,.-354
o8

DAL<23> H

18_ny

DAL<22> H

lhe

SRAMADDR<O>
L
Ot
19

DAL <23> H

pra

DAL<22> H

4 La

DAL<21> H

1 los

DAL<20> H

18 lng

P o2 DAR0>H

DAL<19> H

) D3

R2 ¢ & .

DAL<182 H

DAL<3> H

DAL<17> H

DAL<I7> H

<162

LATCHBADDA |

2 io

EN
9N,
1

DAL<16> M

EEERES A

— )

4BF
o
:

%h
z4F

)

Y3
Y2

2 ipo

D2
2

SRAMADDRO> H

DAL<192 H

DAL<16>

E56

[} {aa

C8OP<> L

ABF

DAL<18> H

DAL<2> H

AA—
Y RAS7

é‘s';z“
Sz

.
Scid

DAL <4> H

SRAMADDR<O» L

roaar

AL<25> H

0__

T4F244

DAL<29> H

OAL<2é» HAN

4BF

SRAMADDR<8> H

DAL<31> H

4BF

ESS

754

Qwa

95 eN

SRAMADDR<O> H__

DSPWAITE L
v

A60

a2
s lae

LAY

—

WR L

vg o
T <> L

voSl'!e

csopaost

14EN
MLO-004488

VO Device Interfacing

8-47

PAGE

B8-48

INTENTIONALLY

LEFT

BLANK

Figure 8-27
VAX-10-DSP One-Way-Mimor

1/0 Device Interfacing: VAX-to-DSP 1-Way Mirror Register

.BFM-M Message Register

UCLP40-DSP CSR Register
(Note: Register Values Afer Reset)

TRNSCVR

DSPDATACT> H

(Egsa

QUAL_IN_PROCESS = TRUE

‘-———E.TE

DAL<7> H

Bs <12
"""‘""—“as 14

B> H

Sttus LED

DAL<S> H

Saua LED

DSPDATA<4> H

T o
P
f__‘a;"“ 19

DSPDATA<3I> H

DSPDATAc2> H

§ > a2
~4
> At

DSPDATAO> H

DAL B> H

Inemupt Enable
Not Used

DAL<1> H

08P XF

(

|olo]olr

{x|x|x: x|x

ENAB

LCHAB
ENOAR

AXGSR

Booea
|

_—

Hold DSP

!
{

Rsast DSP

‘

Roset VAX

VAX-io-D8P One-Way-Miror

LCHBA
Lchea

x]x

DSP BIO

s
.
fi!fig&s{
H

interrupt DSP

——

DSPDATA H

ERETRRR T

ojojojofx

W e

—_—

1 Is Active; O Is Inmctive; X Ia Unpredictable

R19

100

UCLP and DSP Status Register Bus Drivers

4BF

T Octal |

| Tapoas
LB

LED H

17 .

LEDO> H

€,

FORCEPERR M

jm——
B
N
Yo

TiFza
-2

DAL<15s H

DAL<ld> H

DAL<13s W

BAL<12>» H

)

DAL<19> H

DAL82H

LATCHVAXNT H

INTDSP H

3 PO

‘

“o

Ra7

)

DAL<17> H

DAL<16> W

4BF

17 s

Y2
1

Dxiver
2

DSPRIO H

17 as

HOLDOSF H

RESETDSP H

{ay

€BET M

DAL<i1> H

DAL<10> H

DAL<9> H

[]

<
DAL<8>
H

¥1

190 EN
MLO-004488

VO Device interfacing

8-49

PAGE

B8-50

INTENTIONALLY

LEFT

BLANK

Figure 8-28

/O Device Intertacing: rtVAX 300 and DSP CSR

DSP Resst Synohronizer

af
DAL<11>

Eg2

DAL<10> HH
DAL<102

DSPBIO H

R-

DSPBIO LL
MOLODSP
N

Rz
S

HOLODSP
H
DSP H

DAL H

RESETDSP |

DAL<D» H

[15)

/Efi

HOLD L

RESETVAX L

8D Hop |

e A8

RESETOER

|508

ol
1

A5l 10

RS L

‘ mm———
11A% EN

N
TN

ciourz M

w
L8

P H

REGAESET

RST L

74
{s0s

DPS ineupt Synchronizer

LATCHVAXCSR H
18

‘oF

TWO CSRoa Status LEDs

!
x

DAL<19> H

113

|ha

_ 12

DAL<18> H

DAL<17s

PAL<18> M

RS |STE

1> H

1M000¢

ba
ED<O> H

rofoi—SERRB
M~
,

1N000g

ENBVAXINT H

IToet

—— 5V

_ENBVAXINT L

1
<
EN

DEPHADL L
-V —

220

xo 2
ATASs

1
BOSPOATA<S>
WATCHDSPCSR
H 2|

A
4

, P05

LATCHVAXINT H

LATCHVAXCSA L

YONEE

{

TWO CSR Output Staks Pins

RS2

ESq

ClK

DAL<14> M

+8V

57‘=3§

o P——L—fi—c;__vs

21 P00,

FORCEPERR

RO
o

R7e
220

FORCEPERR H

R
b

i_é{jcm

DAL<13> M
LATCHVAXCSR H

CLRDSPINT L

BSTL

-“
B

5,2
\

[}

w0 Ef

TR
58

DSPIACK L

ckouTz u_

BHp

RPO-S———

_'CE__"
[TGEN

ENBVAXCSR L

CLKA

LIOACK |

oJs

)

RST L

O Device Interfacing

8-51

PAGr

8-52

INTENTIONALLY

LEFT

BLANK

Figure 8--29

DMREADY L

kL]

*____ DSPOMARDY H
OMA Base - Address T Regisier
"PAL and

OSPSTRB L0

f
Ha
[

B
£24

8 DSPSTRB

/O Device Interfacing: DSP DMA Controller

CS A

Note: Socket used hers
2

CSR_BADDR PAL

271Y

7] g"

DMG L

7
"y
5
"

SELCSA L

—

gL
P

L- I

—
N

100

DSPSTES L

cua

HOLDA L

DSP RAM and ROM Selsct PAL

CLKB H

Note: Socket used here

~PAL

22V16
E134

DSP_MEMORY PAL

R1I07 RI01 RSO3

R110 RS
1

R77

R7L

WERAM<1 L

gg;%%t
“CEROM

BB r——wREADY H

irfom 4

DSPOMARDY H
DSPADDR 5>
<1A>

%ADDFR] z
"

13 e
Y Do
|
TDG
|
“

SOEROM L

OEROM L
SDSPPS L

DSPPS- |
SDSPBR L

!
|

DSPBA

x
DEPMSC .
HOLDA L

318%
1 ok
=

)

DSPSTRS L

CLKA H

sDSPSTRB L

VC Device interfacing

8-53

PAGE

B8-54

INTENTIONALLY

LEFT

BLANK

Figure 8-30

1/O Device Interfacing: D/A and A/D Interfece

ANALOGVCC
H

To Mt

i’

asv

{LM324
€74

RTR

—~A—2

.
1B

MICIN H

LM32ATM,

~
Fe——x—A—

-..

12y

]

3 TM

g&p

1ur

1 c:‘r 2

| 2ANALOGGNL
O

PO O

-l

o yis

+12v

25v

ANALOGVCC H

;

‘

()2

ANALOGGNDL ;g\f,:

l@F

ANALOGVCC |

M
LM3Z4

R116

%&.
1

MICINZ M
11

AAA

+1v

ROE
560
2

&
3

R103
100K

c87

I‘OUF
2

28V

VO Device Interfacing

8-55

PAGE 8-56

INTENTIONALLY LEFT BLANK

Figure 8-31

VO Device Interfacing: rtVAX 300 I/O Pin Connectors

A
Power Connmctor

seF

8-Posttion
Switch

N7}

q
]

+5V

:o SR Bby

__05

C’%

8 swW7
T

SWS
8 SN

y SWE_

4 R0
26

7]
o

+12v

E110

W o
)
GRETURN
—-O‘

-:;

\_/

‘

3 pow-

)

MVAX 300 50 Pin Connectors

:
T

VAXH,T

_ENBRSY |,
BOOT<3> L

[ 4
"?
C'L_—"Tr { = [14

CLKIN
CCRy

BOOT<1> |,

DALI>

-3

DAL<Z> H

TSOPYS T

UA]

DAL
<35 R

12
DAL<7>
H
7 ")

L o

L—“C 3 H

——

DAC<TE: F

Jfafal:

%fi

OR8>
H
3
DAL
W&l

DXL <165 7

BOOT<0» i

‘7;%1TPytE;]

+V —TEpPaE T
%
+5V

i
!

POOT<2> |,

’

W—Ti

—2

ggl

N - ¢ o)1~ TN R

4 SW3.

3(53

i
8
=

]

i
2,(“

— i En

BT <To5 :F

DAL<YE> W
:
i
AL
SL
N
e 14 [ ——

DAL <785 ¥

PDACCeA>
Pz
L

8~ DAL R

5l
&

]

£—
b

> |

cEE

NIRRT
Bl L

ML L

BOOT3> T

E
‘
NOTORN<d> H

KICONN<S> H

NOCORRS72 T
ROTORNSYoS

&V Toras Ts

E——’—ma

3.00 inchas

HOV T

DACe

r.d - Y sV
HCV -

]

I
AR

<<18> Ral
>

]L
&

—

RVAX 300 50 Pin Connectors

AT
s[SAL

Comole DEC-423 Connecior

T
>

Loader/Prinker DEC-423 Conmeotor

—

LN 3

% R1¢

o —
l

a:g

Atz
2 Al4
100 }%Dw

L BW_L’

.
P
T_‘__m

R20
2 A2
100 1&%

, BW|

MLO-00K:
77

VO Device Interfacing

8-57

PAGE

8-58

INTENTIONALLY

LEFT

BLANK

Flaure 8-32

C50

BUF T GauF
J0F TRF T
saov T Bov

50V

+5V
1

.. C89
T 33UF
0V
2

4 C72
T 33uF

50 v

e CW
T J3UF
2

to-I

cs2
3UF
v

T 33UF
50V
2

50V

[ |

K
3UF

Decoupling Caps

Cc39 J. [+74]

[ | C J: c78

33WF jf i

1 Ca§

4+ C4

VO Device Intertacing

4 Cée
T

4 C38

EIRE

4. C60
3

4 C88

4 C64

el Ls’o‘*\‘r“ L &%S\PF T g%a\yF T &SyF T &S\yF
2

AUF
v

+5V

MLO-004404

VO Device Interfacing

8-59

SANEREORESEIEIA
DO ENSHH0. 504

JEABABENSIBEREIINTIRESRI
GG NS OBININSS459.989.68.9.8
FEABISASOEBAGSFTIRISBEGAGADENNG000.00.0000.9
0601
JHAVEASA GBS SHADI OSSO G
JIRN SIS

SO N 09400900568

SOOGS0 0L OAEI G0085508000900094

LS8N AGONS SIS I IOAN SO09000800840064
JA SN

950008050880 96045.600086409.0940.4

FA A PR A

AR YO K

KX KK KA K

J9 89060800050 0503008004905040050908.1
PSR S060006950.005900.09090.4999004
$S00009606800509006060800090894
FH I80600690.0:0894090908.0489.¢

¥R YR AL LR AL VA LA L LA ELLAKAKA
$9.9.6.60.0495.0040.9099.0,6469994

p:9.96.$604.0:9:9:64.9.8.00.09¢

P0.0.60.0.8009.90.04.909.49.0.94

b9857.9.6.90.89.09.6.¢.9.

“”’

:9.9.0.9.0.9.6.0.6.9.9.0,:4.0.4
1:0.9.9.9.6.9.0.09.9:0.9¢

KAXKKXAKKEK
4
$.9.0.6.9.0,9.0.9
1:9.:8,0.9.8.9.¢
XHXXX
XXX
b4

XXX
XXXXX
XAXXXAK

XX XAXAAXXK
), 0.8.0.9.4.4.6.0.4.6¢
1:6.9.0.0.6.0.6.0.0.6.4.6.4
},0.9.¢.9.0.0.6.4.9.:8,0.0.0.4
XXAK XX AKX KXKKYUNXLX

)0.9.6:0.0.9.6.0.6.0.9.6.¢.05.0.68
19.0.0.86.0.4,.0.9.0.9.:¢.0,9,0,6.8,4.9.¢.6.{

§O.9.6.0.9.0.6.0.0.0.68.9.4.98.9.0.00491
1$.0.0.0.¢.8,909.9.9:0.8.8.9:4.0.6.0.4.6.0.9.9.0
i0:9.0.0.6.8,0.9.0.8.0.0.0.9.0.9.0.0.99.0.9.40.4¢
p9.9.0.0.6.0.6.900.9.8.909.0.0.0.4.6.0.9.¢,0.860
60
)8,8.0.8.6:4.0.0.6.9.09.4.0.606$8808680000846;
$.9.9.0.0.¢.9.0.90.8.0.6.0.¢5090.0.90.92.9:60999009686;

15:$.0.6.8.9.0.0.0.0.9060.6860.¢68$908¢860¢0.¢8.8!
$0.8:6.0.6.8.0.8.09.5.9.0.0.0.0.0.660.0.84.8.0.0.0¢¢68660800;

$5.0.0.8.69.0.8.0,0¢.0.88000850.08 0008084400608 8800
$0,0.0:0.9.8.9.0.0.0.0.0.6.9.0.6.9.9.909.8,0.6.68.0060.6660484898;
:0.9.0.0.0.09.0.3.9.6.9.0.6.0.9¢.0.00.89.00.9000.090$5900600809;

10.8.9:0.9.8.0.9.:0.0.6.0.0.80.0.88:0.9.9.9.¢:69.0.0.0.$.09.2.9 048090494008
)9.0:004:6.9.0.0.0:0.9.9.0.99.0.0.09.09.0.9.0.9.0:0.9:0.9.0.5.6.9 999099090009

9. 9:0.:8:0:0.8.9:6.9.9.90.09.0.0.0.0.9.9.9:00.0.0408¢.0.09.9609.090999.9
80008
}90.9:0.0.9:9:0.9:0.4:0/0.9.0.0.0.9.9.08.9:0.9.9.0.0.0.9.9.0.8:9.09¢9:9.9:0.9.0.09.0.00.60.99,

A
Physical, Electrical, and Environmental
Characteristics

This appendix discusses the following topics:

A.1

Phyvsical charactenstics (Section A1)

Electrical characteristics (Section A.2)

Environmental characteristics (Section A 3)

Physical Characteristics

The rtVAX 300 processor is a 117 mm x 79 mm 4 .61 1n. x 3.11 1n) module

encapslated in a black pair ted metallic body. The body acts as a heat sink to
d.ssipate the heat generateC by the rtVAX 300, The rtVAX 300 weighs 142 g
(5.0 oz +10%.

The rtVAX 300 has four mounting holes, one on each corner. Each hole is
threaded for a 4-40 (U.S.A.) screw You can use these holes either to bolt
the rtVAX 300 to the mother board by using up to four screws or to provide

extra grounding for the rtVAX 300 and 1ts cover, which can help reduce
electromagnetic interference (EMI. The recommended torque on the screws 1s

0.50 Wm (¢ 51n-lb) 220%.

“Jou can connect the rtVAX 300 connectors to other modules by means of its

190 square 0.635 mm x 0.635 mm (0.0251n. x 0.0251n.) pins.

You can mount the rtVAX 300 on another module either by using standard
sockets. for example, Digital part number 12-11004—05, or by soldering. Refer
to Figure A-2 for footprint dimensicns.
Igure A-1, Figure A-2, and Figure A-3 show a top. bottom, and side view of
the rtVAX 300, respectively.

Physical. Electrical, and Environmental Characteristics

A-1

Caution

The pin face of the rtVAX 300 module has conductive components,
Design the mounting to provide positive control of at least 0.010 1n.
clearance between these components of the rtVAX 300 module and the
applhcation module.

Figure A~1

rtVAX 300 Top View

AdS

T T

oL Tz oo

T T DT

;
!

ASC T T T

ssCocTozzcTIziiiziiiizice

78 984 mm

+/- G 254
mm

iIn
(3410
+- 0 01 m}

;

117 094 mm + U.254 mm

(4810:n «/- 0.01 in)

»
MLO-004406

A-2

Physical, Electrical, and Environmental Characteristics

Figure A~-2 rtvAX 300 Bottom View
»

TP 72517 mm +/- 0.254 mm
(2.855in +/- 0.010 in)

2.540 mm +/- 0.254 mm ___

!
6 422 mm +/- 0.254 mm ____
(0.255 in +/- 0.010.M

(0.255 in +/- 0.010 in)

Eo
[N

‘

RN
]
L
€ 2
ES
o @

:
|

1
i

i
|

{3.300 in

+-0.010in)
|

|
!

104.140 mm

+/- 0.254 mm

+/- 0.010 in)

o
o

c &

0
O

117.094 mm

+/- 0.254 mm
(4610 in

+-0.010in)

o
oo

o]
ol

= e
o o
1

] P

o C

+/-0264 mm
(4.355 in

o Q

l‘

(4.100 in

4001000

110.617 mm

M50
-

+/- 0.254 mm

)

83.820 mm

—

;

o
C
2

(2600 in ++- 0.010 in)

‘ @ . 66040mm 4+ 0254mm !

6.422 mm +/- 0.254 mm

b e . 68 580 mm 4 v2sdmm
{2.700in +/- 0.010 In)
I

+/- 0.010n)

(0100

Y
78 994 mm +/- 0.254 mm
(3.110in +/- 5.010 in)
MLO-004487

Physical, Electrical, and Environmental Characteristics A-3

Figure A-3

rtvVAX 300 Side View
5842 mm +/- 0.127 mm
(0.230 in «/- 0.005 in)

2.286 mm +/- 0.127 mm

3.175 mm +/- 0.381 mm

{0.090 in +/- 0.005 in)

(0.125in +/- 0.015 in)

Rg
8.763 mm +/- 0.254 mm
(0.345 in +/- 0.010 in)
MLO-004408

A-4

Physical, Electrical, and Environmental Characteristics

. A.2 Electrical Characteristics
The following tables summarize the rtVAX 300 processor’s electrical

characteristics:
¢

Table A-1—Recommended operating conditions

Table A-2—DC charactenistics

Table A-3—AC characteristics

Table A-1

Recommended Operating Conditions

. Symbol Patameter

Minimum

Maximum

Units

Vee

Power supply voltage

4.75

5.25

VDC

Input voltage

Vee

VDC

Output voltage

Vee

vDC

Operating free air temperature

+ 70.01

! To operatc at temperatures above 50°C, the tVAX 300 requires an airflow of at least 508 mny's 1100 LFM)

across the processor.

Table A-2

‘

DC Characteristics

Sv-bol

Parameter

Minimum

Maximum

Units

High-level input

2.00

Vil

Low-level input

0.8

Voh

High-level output (Ich = 24 mA)

3.7

Vol

Lov:-level output Toh = 24 mA:»

0.36

ioz

Tri-state output off-state current

0.5

TP\

Icc

Active supply current

2000

Input leakage current

0.1

Physical, Electrical, and Environmental Characteristics

A-~5

Table A-3

AC Characteristics

Number

Name

Description

Minimum

Maximum

Units

Lasp

Address strobe assertion delay

tpaLp

DAL address setup/

2p-27

DAL address hold

p+6

DAL address to high impedance

p+2

p+25

tpaLy
tpaLz

WR assertion delay

state

tBM

Byte mask setup

tpsp

DS strobe assertion delay

2p+27

tps

DAL data setup

tpH

DAL data hold

tpz

DAL data to high impedance state

tpops

Parity setup

tsws

RDY and ERR sample window setup

tsw

RDY and ERR sample window hold

ipsip

DS strobe deassertion delay

tasip

AS strobe deassertion delay

p+28

lparrz

DAL undefined delay

p+28

p+51

temME

BM hold

twrE

WR hold

tppPES

DPE setup

tDPEH

DPE hold time

tpasaosp

DMG assertion delay

tsHLZ

Strobe high impedance delay

tpspry

DS delay after DMG

tparurz

DAL high impedance delay

tsyns

Asynchronous input setup

tsynH

Asynchronous input hold

tasaprr

DAL hold during cache invalidate

tcerroye CCTL cycle time during octaword
invalidate

11p

(continued on next page)

A-6

Physical, Electrical, and Environmental Characteristics

. Table A-3 (Cont.) AC Characteristics
Number

Name

Description

Minimum

Maximum

Units

taspry

AS delay from asserting CCTL
during cache invalidate

tasaprs

DAL setup during cache invalidate

tomre

DMR maximum assertion after

6000

trsTW

Reset assertion width

30p

trRsTD

Strobe delay after reset

tinTasp

Initial AS delay

40p

tzrDY

Z-state RDY to RDY H

troYZ

RDY deasserted to RDY Z

torsas

CSDP<4> setup time

2p-42

taswo

Minimum AS assertion time for

21p

10p

. 33

trRsTs

DMG

Reset input setup prior to P1

2p-10

octaword cache invalidation

taswo

Minimum AS assertion time for

quadword cache invalidation

Note: p = 0.25 microcycle = 0.50 CLKA cycle = 25 ns for 20 MHz

Physical, Electrical, and Environmental Characteristics

A-7

A.3 Environmental Characteristics
Environmental characteristics include:

Temperature—Operating temperature 0°C to 70°C, with the following
restrictions:

0°C to 50°C—No fan required, natural convection cooling.

50°C to 70°C—Fan required with at least 508 mm/s (100 LFM) across
the rtVAX 300 processor.

The rtVAX 300 has no preferred orientation for cooling with fan-assisted
convection. When natural convection cooling is employed, the rtVAX 300

processor should be mounted with the internal circuit board in a vertical

plane.

Relative humidity
-

Operating: 10% to 90%, noncondensing.

—

Storage: 10+ to 95%, noncondensing.

Altitude—Operating and storage as they relate to altitude (standard
atmosphere and standard gravity) are as follows:

= Operating: The rtVAX 300 can operate at an altitude of up to 2.4 km. .
—

Storage: The rtVAX 300 is not mechanically or electrically damaged at
altitudes of up to 4.9 km.

Shock and vibration—Nonoperating tolerances are as follows:
—

Mechanical shock: 30 G, 11 ms, 1/2 sine pulses.

Vibration sine: 5 G peak, up to 2000 Hz.

Vibration random: 0.032 g2/Hz, up to 2000 Hz.
where g2 = the gravitational acceleration constant squared, where the
gravitational constant is 9.8 meters/sec/sec (32.2 feet/sec/sec)

Contamination—The rtVAX 300 should be stored and used in a noncaustic
environment.

A-8

Physical, Electrical, and Environmental Characteristics

XXAXX
XXXXAXXK

XXXXXXXXK
XXXAXKAXKXK

AAXA
XXXKX
LK ARXK

$8.8.6.9.3.$.94.¢.906441

h0.0/6.0.6.0.4.84.6.0.64.6494
b8000968699040
44

$.8.0.0.0.4.6.0.4.0.4.0.699.0.9.4.¢.6.¢4
P9 490.9008.006:8480.0048044

190 6.9.000.8.0.9.06.60 685006504041
PO0.09.690060.4.6.906.0.8:4000040.6604
PE 0680.65000860.6008608040040044
PO T80.8.0.6.8.0.6.066089.0.096.060060.6044
05,9.:0.0.0.0.0.0.0.0.0.0.4.9.59.0.4.8.0.6.90.0.9.9.05¢40.694

P08$:0.8.8.0.4.9.0.00.4.80.0.09.0.¢8.8.0600646936¢
BO.0..9.0.6:0.8.0.8.63.6.6.09.0.9.6.9.000.008.66000.964¢4]

DO48.8.6.0.00.008.00.000000.869889006000660¢0¢

$8.0.0.00.9.9.0.8.0.014.8¢9.0.0.00.86.6.9.6.0.6:0.9008¢.669990.09
19.0.9.0,0.9.0,80.0.60.¢.0.0.5.86.0.0.6.9900000.0.6.0.6:6.0.6064.00.0.6.94
PO.0.0.0.0,0.0.00,80.40.80.0.0¢8.¢.60.00006600.8009.60609000
0
0. 8.0.88,0.90.¢.6,0.90.8800.6,6068060.5000:00.600.0.6:0.69.059.0:0.0.04
:0,9.0.9.0.0:9.0.0.0.0.0,00.0,6:0.0.0.5.8.6.0.008:00.6.6096:0.0:0.600:8.9
$:.59.09.94

10.0.0,9.8:0.0.9.8.,6,06,¢.9.¢06.0.84.0.0:009.00.90.0.00
600000069001
.9946¢509

B
Acronyms
This appendix defines the acronyms used most frequently in this guide,
Acronym

Definition

+5V

+5 V dc power

20MHz

20 MHz clock output

ACR

DUART auxiliary control register

Address strobe bus interface signal

ASTLVL

AST level internal processor register

Byte masks

BTREQ

Request reboot output from Ethernet controller signal

CADR

Cache disable internal processor register

CAS

Column address strobe

CCTL

Cache control bus interface signal

CFPA

CVAX's floating-point coprocessor

CLKA

CPU clock outputs bus interface signal

CLKB

CPU clock outputs bus interface signal

CLKIN

System clock input signal

CLK20

20 MHz clock output bus interface signal

COL

Ethernet collision detect bus interface signal

CONE

Console enable signal

CRA

DUART channel A command register

CRB

DUART channel B command register

CsSDP

Cycle status/data parity bus interface signal

CSRA

DUART channel A clock select register

CSRB

DUART channel B clock select register

Acronyms

B-~1

B-2

Acronym

Definition

CTL

DUART counter/timer register (lower)

CTU

DUART counter/timer register (upper)

CVAX

CMOS VAX microprocessor, the rtVAX 300 processor's CPU

DAL

Data and address lines

DMA

Direct memory access

DMG

DMA grant bus interface signal

DMR

Direct memory request bus interface signal

DPE

Data parity enable bus interface signal

DRAM

Dynamic, random-access memory

Data strobe bus interface signal

DSP

Digital signal processor

DUART

Dual universal asynchronous receiver/transmitter

ERR

Bus error input interface signal

ESP

Executive stack pointer internal processur register

GND

5V ground (return) signal

HLT

Halt processor bus interface signal

ICCS

Interval clock control and status internal processor register

IMR

DUART channel A and B interrupt mask/status register

IPCR

DUART input port change register

IPL

Interrupt priority level

IPR

Internal processor register

IRQ

Interrupt request bus interface signal

ISP

Interrupt stack pointer internal processor register

ISR

Interrupt status register; interrupt service routine

KSP

Kernel stack pointer internal processor register

MAPEN

Memory management enable internal processor register

MRA

DUART channel A mode registers

MRB

DUART channel B mode registers

MSER

Memory system error internal processor register

Network Interface

OPCR

DUART output port configuration register

Acronyms

Acronym

Definition

POBR

PO base internal processor register

POLR

PO length internal processor register

P1BR

P1 base internal processor register

PILR

P1 length interns1 processor register

PCBB

Process control block base, internal processor register

PPTE

Processor page table entry, processor PTE

PTE

Page table entry, entry in page table of memory map

PWRFL

Power failure interrupt bus interface signal

QMR

Q22-bus map register

RAM

Random-access memory

RAS

Row address strobe

RCV

Ethernet receive data bus interface signal

RDY

Bus ready input interface signal

RHRA

DUART channel A Rx holding register

RHRB

DUART channel B Rx holding register

ROM

Read-only memory

RST

Reset bus interface signal

SAVPC

Console saved PC internal processor register

SAVPSL

Console saved PSL internal processor register

SBR

System base internal processor register

SCBB

System . ontrol block base internal processor register

SGEC

Second-generation Ethernet coprocessor

Serial interface adapter

SID

System identification internal processor register

SIRR

Software interrupt request internal processor register

SISR

Software interrupt summary internal processor register

SLR

System length internal processor register

SLU

Serial-line »nit

SRA

DUART channel A status register

SRAM

Static random-access memory

SRB

NUART channel B status register

Acronyms

bB-3

B-4

Acronym

Definition

Ssp

Supervisor stack pointer internal processor register

TBCHK

Translation buffer check internal processor register

TBIA

Translation buffer invalidate all internal processor register

TBIS

Translation buffer invalidate single internal processor register

THRA

DUART channel A Tx holding register

THRB

DUART channel B Tx holding register

USP

User stack pointer internal processor register

Write line bus interface signal

XMT

Ethernet transmit data bus interface signal

Acronyms

DO.0400868.0.68940400.656404.¢4

$.8.6.5066.49.0.69¢64:0690690094
p 08845566 04.440.465600(

0.$.6.9.0.9.9.9.0,0.90.4:4:0.0.0.6.0,64
9.8.6.6.0.8.6.9.0.6.0:4.0.6.0.64
D.0.4.6.6.4.0.0.6.4.9.4.6.4.¢.¢

$9.4.:4.0.4.0.0.0.4.6.4.44
)$.6.6.8.4.8.4.4.4.
44

HXXXXXXHH

16,006,944
XXYXX
XXX
X

XXXXX

XXXXXXX
XXXKAXKXK

XXXXXXAKX
XXX
}9.9.6,6.4.6.0.4.4.6.4.44

D90.0.9.6.9.66:4.9¢.6.4¢
$ 0. 8.600.66.44:484444.¢

B90 6086.8000.68.06466.04
AXA
XA XA
XXX
XAKAAXXKKAY

RSO O DG 30.000.0.406060609

P00.0.8:0.0.¢.0°0.0.6.9.0,6.40.68.56:465.4)
PO

0469¢9¢6660.9¢900000.¢44¢]

8000004.00.48600000.0004)

DOE00.0.9,66.0090.00096066064.90¢409.00]
F 0000090000908 0000066050609 0.000]

BP0 0.0.¢ 000480080 008040040040000404004
DG

BOP OV

0.4:8.0808 08060000
000.0 00094609,
040

OO PN

0G0 9 00608800 000009000 0]
D.0.0.0.0.9.0.0.8,0.8.09.0.0.0.0.0080.08608¢.090.60.66.990¢0
20, 8.0.0.0.80.04.0400650.00080000.56 000009066600
0 00
PO 008080060.80808.080000650.09.0.
00000 00¢0
00.09
0000
FE0:.0.0.0.00. 08 004308 €010¢.0.0.0:0.0:09.0:0.9.6.0 9080000
000000
8.0.0.9.9.9.0.0.6.6.4.6.0.6.£9:0.6.0.9.6.0:0.610.0.0:9.4.99.86 0000000000
0

DE.00.0.9.0.0.0.0.0.00.8/6.3.5:6.0.0.0:6.0/0.0.0.0
00000000
.9.0:09.00
0 00000
.9.49

C
Address Assignments
This appendix covers the following topics:

Memory space (Table C-1)

Input/output space (Table C-2)

Local register input/output space (Table C-3)

Table C-1

Memory Space

Address Range

Contents

00000000—0FFFFFFF

Cached read/write memory space (256M bytes)

10000000—1FDFFFFF

Cached read-only memory space (254M bytes)

1FE00000—1FFFFFFF

Reserved memory space (2M bytes)

Table C-2

Input/Output Space

Address Range

Contents

20000000—201FFFFF

Local register VO space (2M bytes)

20200000—3FFFFFFF

User /G space (510M bytes)

Address Assignments

€-1

Table C-3

C-2

Local Register input/Output Space

Address Range

Contents

20000000—20007FFF

Reserved local register I/O space

20008000—2000803F

Ethernet coprocessor register I/O space

20008040—2000FFFF

Reserved local register I/O space

20010000—2001007F

Network interface address ROM L/O sp ace

20010080—2003FFEB

Reserved local register 1/O space

2003FFEC—2003FFFF

Boot register

20040000—2007FFFF

rtVAX 300 boot/diagnostic ROM space

20080000—200FFFFF

User boot/diagnostic ROM space

20100000—2010003F

Console DUART register /O space

20100040—2010FFFF

Reserved local register /O space

20110000—20110003

Memory system control/status register

20110004—201FFFFB

Reserved local regiscer /O space

201FFFFC—201FFFFF

LED display/status register

Address Assignments

HEARLRTAE
YEELHALK

i‘......."

P 48,44

po.ad
¥

¥X¥
XAKAX

XXXAXLY
XAXAXAAWAK

XXXXKAXINAK
HHEXHELKAKAXLY,

AXA K AKX

LYAKLS,

AKX AN KX XA IKKARLY,

XXAXKE XK AR LKA T KELL XKL,
p U00640090846080844848044
DO$00.60480.0408080048
48044

P4009.040.00008.4046980646446
P 000900000 400904808480480675¢]

YHEX AR

KAKKX XK LK AR XU L KX

XLAKK

$0G 0560909089985 898480004948441
P0G 000000400808
09 840008009004 444
PO0.0.80.9.608060860084888048488084844¢544
[9.5.0.6.0.98.6.06.00.00000
080000888 084690840¢04
P9 40.9808468950006048
00 08868 084449048454
p04:00.805000008060¢00000000689+8666040
44044
F 0000000008086 0800098000008000 0000008004804
PO 8464080860008 850060800684809998690694804064]
§8.6.0.8000.00¢90600899589.9880.680069000.4860808486804004

b0 0 080.00.6808800.08
090908606 008009049 0080604880849
0.9.0.0.6.4.9.009.880000840006040990000809660009089488894040463

D
User Boot/Diagnhostic ROM Sample
This appendix contains a template of the functions that might be incorporated
in a user-supplied boot and diagnostic ROM.

.title

300USERROM - rtVAX 300 User Boot/Diagnostic Firmware

.ident

/rtVAX 300 v1.0-00/

Maynard,

Massachusetts

; This software is furnished under a license and may be used and
copied
; only in accordance with the terms of
such
license and with the
;

inclusion of the above copyright notice.

This software or

any

other

; copies thereof may not be provided or otherwise made available to any
; other person.
No title to and ownership of the
software
is
hereby
;

transferred.

; The information in this software is subject to change
without
notice
; and should not
be construed as
a commitment by Digital Equipment
;

Corporation,

; Digital assumes no responsibility for the use or
reliability
; software on equipment which is not supplied by Digital.

1its

User Boot/Diagnostic ROM Sample

D-1

; +

‘

; FACILITY:

;
;

rtVAX 300 User Boot/Diagnostic Firmware
ABSTRACT:

;

This module contains routines to provide user=-defined

;

ROM-based board-level initialization and diagnostics.

;
;

It is a template intended to serve as
the
starting point
for
implementing
rtVAX 300 User Boot and Diagnhostic routines.
When

used as a template,

;

routines should be modified and expanded as needed.

;

Assemble ROM-based firmware modules as follows:

;

§ MACRO/LIST/OBJECT 300USERROM.MAR+KERMAC .MLB/LIBRARY

;

Note that the above assumes

;

found in your default directory.

the code

and

definitions

for

that KERMAC.MLB macro

;

Build an executable image by specifying the ROM’s

;

$ LINK/SYSTEM:$X20080000/MAP/FULL 300USERROM.OBJ

;

.
;

;

rtVAX 300

the

sample

library can be

base

address

follows:

AUTHOR:

Realtime Software Engineering,

CREATION DATE:

15-Feb-1991

MODIFIED BY:
modifier’s name,

dd-mmm-yyyy,

VERSION:

svv.u-ep

01 - modification description

.sbttl

Module Declarations

INCLUDE FILES:

;

'kermac’

library symbol definitions

Scpu30def

. define rtVAX 300 specific offsets,
;

;

'starlet’

registers,

etc.

library symbol definitions

$dscdef

D-2

‘l

User Boot/Diagnostic ROM Sample

; define memory bitmap descriptor

MACROS:

; macro to define rom code or read-only data program section
macro

usrom_share psect alignment=long

.psect

usrom$zcode,pic,
rd, nowrt, quad

.list

meb

.align
.endm

psect alignment

usrom share

]

; EQUATED SYMBOLS:
;

rtvax 300 board-level test

$vield

_300,0,<

flagword fields
-

;

define test flagword fields

<btf testemd,l,m>,

;

explicitly invoked by TEST coumand

<btf _powerup,l,m>,

;

test

invoked by power-up sequence

<btf fatlerr,1,m>,

;

test

returns control immediately

;

upon failure
console

<btf _ consdev,l,m»,

<btf dsply,
<

1,m>,

-~
=~

;

led display is present

slu

is present

,27,>,

;

reserved

(always read as 0's)

; rtVAX 300 console program read/write data offsets
_300Sk_cpmbx
300 b cpflg
300$b bootdev
;

=
=

1
2

;
;

console program mailbox
console program flags

;

default boot device

rtVAX 300 user boot/diagnostic ROM offsets

300%v.rom, LOCAL, 0
$defini
30081usrom reserved 1l .bikb 28 ;
$def
’

Sdef
Sdef

$def
S$def
Sdef
Sdef
Sdef
$def
Sdef
$def

730061
_usrom_
“board init

reserved area

.blkl 1

;

address of board-level init

300$l usromtest 8
300$l_usrom_test_9

.blkl

;

addrecss of board-level test

.blkl 1
.blkl 1

;
;

address of board-level test
address of board-level test

30051
usrom test_12

30081 usrom test 11

.blkl 1
.blkl 1

;
;

address of board-level test
address of board-level test

30081usrom test 13

.blkl 1

;

address of beard-level test

.blkl 1

;

address of board-level test

.blkb 4

;

reserved area

.blkb 0

;
;

start of board-level init an
diagncstic testing code/data

730051 usrom test 10

300$l usrom_test 14
730081usrom reserved 2
30051 usIom_
. shared

$defend 300Susrom

User Boot/Diagnostic ROM Sample

D-3

; LOCAL STORAGE:
.

;

rtVaX 300 user boot/diagnostic rom entry points

.psect

usrom$ycode,pic,rd, nowrt,quad

_300%al _usromvector:
.long
x0003101

reserved

;

rom index numbers

.byte

00,01,02,03

.byte
.quad
quad
assume

02,02,02,02
; reserved
0
; reserved
0
; reserved (mbz)
<.-_300$alusrom vector> eq 30051usrom board init

assume

<.- 3005%alusromvector> eq

30051usromtest 8

assume

<.- 300$al usrom vector> eq

300$1 usrom test 9

assume

<.- 300%al usrom_ vector> eq

30051 usrom test 10

assume

<.- 300sal_usrom vector> eq

30051 usrom test 11

assume

<.- 300$al usrom
vector> eq

30051 usrom test 12

.address 300$usrom board init ; address of board-level m:.t.lal:.zatlon‘
.address

.address

.address
.address

300$usron test i

; address of board-lesvel test 8

300$usrom test "9

; address of board-level test 9

300$usrom test ~10

; address of board-level test 10

300$usrom test 11

; address of board-level test 11

.address
300 usrom test 12
; address of board-level test 12
assume <.- 300%al usromvector> eq 30051 usromtest 13

.address

; address of board-level test 13

300$usrom test_
T14

; address of board-ievel test 14

<.- 300$al usrom vector> eq

.long
assume

0
; reserved (mbz)
<.-_3005al
_usrom vector> eq 30051 usrom shared

.address

;

300$usrom test 13

assume

30051 usromtest_ 14

EXTERNAL REFERENCES:

’

; no external data/routines directly referenced in this module
.sbttl

D-4

rtVAX 300 Board-level Initialization

User Boot/Diagnostic ROM Sample

;

FUNCTIONAL DESCRIPTION:

;

This

;

firmware at

;

is called at

;

CALLING SEQUENCE:

;

routine

calls

(user-supplied) is called by the rtVAX 300's
resident
system power-on to do any board-level initialization. It

IPL 31,

in kernel mode with memory management disabled.

#3,_300$usrom_board_init

INPUT PARAMETERS:

;

cpmbx

address of console mailbox

;

bitmap

address of memory bitmap descriptor

;

scratch

address of

;
;

scratch memory area

IMPLICIT INPUTS:
* &

None

* %

; OUTPUT PARAMETERS:
;

;
;

;
H

;
:

None

%* %

IMPLICIT OUTPUTS:
* %

None

* %

ROUTINE VALUE:
* %

None

* %

SIDE EFFECTS:
% %

None

* %

; board-level initialization argument block offsets
offset

«-

cpmbx,

bitmap,

- ;

scratch

address of console mailbox
address of memory bitmap descriptor

;

address of scratch memory area

;

return

;

usrom share

byte

_300$usrom_board_init::
.word
ret

“m<>
to caller

User Boot/Diagnostic ROM Sample

D-6

FUNCTIONAL DESCRIPTION:

This routine

(user-supplied) is called by the rtVAX 300's
resident
firmware at system power-on to do board-level test 8.
It is called
at IPL 31, in kernel mode with memory management disabled.

CALLING SEQUENCE:

calls

#5, 300Susrom
test 8

INPUT PARAMETERS:

scratch
failing pc
expected data
actual data
flags

address of scratch memory area
address of longword to store failing pc
address of quadword to store expected data
address of quadword to store actual data

Dboard-level test

flags

IMPLICIT INPUTS:

** None **
OUTPUT PARAMETERS:

test results

IMPLICIT OUTPUTS:
** None

ROUTINE VALUE:

device not present or untestable

test failed

test passed

SIDE EFFECTS:
**

None

* %

-1

rtVAX 300 Board-level Test 8

.sbttl

; board-level test 8 argument block offsets

D—6

User Boot/Diagnostic ROM Sample

offset <=

scratch,

address of scratch memory area

failang pec,

address of longword to store failing
pc if test fails

expected_data,

address

of gquadword that

test

can

store expected data if test fails
address

actual data,

of quadword that

store actual data i1f test
board-level

flags

test

can

fails

flags

usrom share

byte

_300$usrom test 8::

Am<>

.word

;

ret

’

.sbttl

return to caller

rtVAX 300 Board-level Test

Dot

FUNCTIONAL DESCRIPTION:

;

This routine

;

firmware at

system power-on to do board-level test

in kernel mode with memory management disabled.

;

calls

resident
is called

#5, 300Susrom_test 9

INPUT PARAMETERS:

;

scratch

;

failing pc

;

expected_data

actual data

;

flags

;

** None **

OUTPUT PARAMETERS:

; IMPLICIT INPUTS:
:

IMPLICIT OUTPUTS:

;

** None **

address of scratch memory area

address of longword to store failing pe¢
address of quadword to store expected data
address of quadword te store actual data
board-level test flags

test results

;

is called by the rtVAX 300's

; CALLING SEQUENCE:
;

IPL 31,

(user-supplied)

ROUTINE VALUE:

-1 = device not present or untestable
User Boot/Diagnostic ROM Sample

D-7

wa
w.

<«
-

test failed
test passed

®ma

0
1

SIDE EFFECTS:
Kk

None

; board-level test 9 argument block offsets
offset

scratch,

- ; address of scratch memory area

expected data,

- ; pc if test fails

failing pc,

actual data,

flags

- ; address of longword to store failing

- ; address of quadword that test can

,;
;
;
;

store expected data if test fails
address of quadword that test can
store actual data if test fails
board-level test flags

usrom_share

9::
_300Susrom_test
.word

byte

~m<>

ret

.sbttl

D-8

; return to caller

rtVAX 300 Boar~-level Test 10

User Boot/Diagnostic ROM Sample

;

FUNCTIONAL DESCRIPTION:

This routine
firmware at

at
;

IPL 31,

(user-supplied)

called by the rtVAX 300’'s

system power-on to do board-level test

10.

resident
is

called

in kernel mode with memory management disabled.

CALLING SEQUENCE:

calls

#5, 300$usrom
test 10

INFUT PARAMETERS:

scratch

address of

failing pc

address of

scratch memory area
longword to store failing pc¢

expected data

address of quadword to store expected data

actual data

address of quadword to store actual data

flags
IMPLICIT

test

flags

INPUTS.:

** None **
;

QUTPUT PARAMETERS:

test results

IMPLICIT OUTPUTS:
**
;

;

None **

ROUTINE VALUE:

-1

device not present or untestable

test

test passed

failed

SIDE EFFECTS:
L4

None

* %

; board-level test 10 argument block offsets

User Boot/Diagnostic ROM Sample

D-9

offset <~scratch,

failing pc,

expected data,

actual data,
flags

- ; address of scratch memory area

- ; address of longword to store failing
- ; pc if test fails

- ; address of quadword that test can

- ; store expected data if test fails

- ; address of quadword that test can
- ; store actual data if test fails
- ; board-level test flags

byte

usrom _share

_300$usrom_test_10::
.word

ret

“m<>

; return to caller

rtVAX 300 Board-level Test 11

.sbttl
o+t

;

; FUNCTIONAL DESCRIPTION:

(user-supplied) is called by the rtVAX 300's

;

This routine

;

at IPL 31, in kernel mode with memory management disabled.

firmware at system power-on to do board-level test 11.

;

resident

It is called

; CALLING SEQUENCE:

calls

;

1l
#5, 300Susrom_test

; INPUT PARAMETERS:

;

scratch

;
;

expected data
actual_dEta

;

IMPLICIT INPUTS:

;

** None **

failing pc

;

flags

;

address of scratch memory area

address of longword to store failing pc

address of gquadword to store expected data
address of quadword to store actual data

board-level test flags

; OUTPUT PARAMETERS:

;
;
;

test results

IMPLICIT OUTPUTS:
**

None

* %

; ROUTINE VALUE:

;

-1

device not present or untestable

D-10 User Boot/Diagnostic ROM Sam,

‘

wa
we

-~
-

test failed
test passed

SIDE EFFECTS:
%

None

* i

Wms

0
1

; board-level test 11 argument block offsets
{=
e

pc if test fails
address of quadword that test can

expected_data,

address of scratch memory area
address of longword to store failing

failing pc,

scratch,

offset

store expected data if test

fails

actual data,

address of guadword that test can

flags

board-level test flags

store actual data if test fails
>

usrom share

_300%usrom test 11::

.word

ret

.sbttl

byte

~mC>
;

return to caller

rtVaxX 300 Beoard-level Test

User Boot/Diagnostic ROM Sample

D-11

;

FUNCTIONAL DESCRIPTION:

;

;
;
;

;
;

This routine

(user-supplied) is called by the rtVAX 300’s
resident
firmware at system power-on to do board-level test 12.
It is called
at IPL 31, in kernel mode with memory management disabled.

CALLING SEQUENCE:

calls

$5, 300Susrom
test 12

INPUT PARAMETERS:

;

scratch

address of

scratch memory area

;

failing pc

address of

longword to store

;

expected data

;

flags

;

;
;

;

actual data

address of quadword to store actual data
-

board-level test

flags

IMPLICIT INPUTS:
* %

None

* %

OUTPUT PARAMETERS:
r0

test results

IMPLICIT OUTPUTS:
* %

;

None

* %k

ROUTINE VALUE:

-1

;

test failed

;

test passed

;
;

device not present or untestable

SIDE EFFECTS:
F 34

None

* %

; board-level test 12 argument block offsets

D-12

failing pc

address of guadword to store expected data

User Boot/Diagnostic ROM Sample

offset

<scratch,

failing pc,
expected data,

- ; address of longword to store failing
-~ ; pc if test fails
- ; address of quadword that test can
-

;

store expected data if test

actual data,

;

address

;

store actual data if test

;

board-level test flags

;

return

rtVAY 300 Board-level Test

flags

;

address

of scratch memory area

of quadword that

fails

test

can

fails

usrom share

byte

_3008usrom
test 12::
.word

m<>

ret

.sbttl

caller

;

;
;
;
;

;

FUNCTIONAL DESCRIPTION:

This routine
(user-supplied) is called by the rtVAX 300’'s
resident
firmware at system power-on to do board-level test 13.
It is called
at IPL 31, in kernel mode with memory management disabled.
CALLING SEQUENCE:

calls

#5,_300Susrom
est 13

;

INPUT PARAMETERS:

;
;

scratch
failing pc

expected data

;

flags

;

,
:

;

address of scratch memory area
address of longword to store failing pc
address of quadword to store expected data

actual_dgta

address >f quadword to store actual data
-

board-level test flags

IMPLICIT INPUTS:
% K

None

* %

OUTPUT PARAMETERS:

test results

;

IMPLICIT OUTPUTS:

;

** None **

;

ROUTINE VALUE:

;

-1

device not present or untestable

User Boot/Diagnostic ROM Sample

D-13

;

test failed

;

test passed

;

SIDE EFFECTS:
** None

; board-level test 13 argument block offsets

wWe

pc if test

address of quadword that test

store expected data if test

address of quadword that test can

Wwe

actual data,

address of

expected_data,

flags

address of scratch memory area

failing pc,

scratch,

<«-

offset

longword to store

fails

Dbyte

_300$usrom_test_l3::
.word

‘m<>

ret

.sbttl

D-14

;

return to caller

rtVAX 300 Board-level Test 14

User Boot/Diagnostic ROM Sample

can

fails

store actual data if test fails
board-level test flags

usrom share

failing

;

FUNCTIONAL DESCRIPTION:

This routine

(user-supplied) is called by the rtVaX 300's
resident
firmware at system power-on to do board- level test 14.
It is called

;

IPL 31,

CALLING SEQUENCE:

calls
;

in kernel mode with memory management disabled.

#5,‘3005usrom_test_l4

INPUT PARAMETERS:

scratch

address of scratch memory area
address of longword to store failing pc
address of quadword to store expected data

board-level test flags

failing pc
expected data

actual data

flags

;

IMPLICIT

OUTPUT PARAMETERS:

test results

;

IMPLICIT OUTPUTS:

% None * %

;

of quadword to store actual data

INPUTS:

** None

;

address

ROUTINE VALUE:

-1

device not present

test

test passed

or untestable

failed

SIDE EFFECTS:
** None

; board-level test 14 argument block offsets

User Boot/Diagnostic ROM Sample

D-15

offset

«-

address of scratch memory area

scratch,

address of longword to store failing

failing pc,
expected data,

pc if test fails
address of gquadword that test can

actual data,

address of gquadword that test can

store expected data if test fails

store actual data if tes: fails
board-level test flags

flags
>

usrom_share

byte

_300%usrom test_14::
.word

‘m<>

ret

.end

D-16

User Boot/Diagnostic ROM Sample

return tc

caller

ARSI NSRRI RANT RS

XA,CHHTHT
peA4S
AN 44
fA8 09004
YEYEY

.44
b4

09450

LK AAAKK
$8904506544
PO 94300004
XHAELXY
Y ZALAEL,
YA LA AA LR LA LA AT L,

HAAL LKL

AL AL AALLLALK,

KAVH LA LA LA LXK AL LA
b

890080909 400444840 0

AKX ML KLY H XA L

ALY,

PO 0498048048040
984 60440,
PO OS00 0600400080 48040006440400

AR T ALY A XS

PRI S GNI A

K ALK KKK

KK KA KA A

HLHE ALY H AT

AL LKA KA XA

00800 0009888000804
0404

PPN ONO NN GO 909 0999998048 0438040404

PO SN OGNNSO 00098088608 8980008900000
POV II NI OA SIS NSNS 985060804800
044
LHEK AL LA AL

ALY ALK LA LA KA

KA L LA LA

KA ALY

XEXAKU A RK I A KK LR LA KA XL LA KA AL LA L LA AL ALK

VOGVGEIONGOOI
NI GGININIAINAO S DSV SNISGNISGIDAS

XAKA KA XL L L LKA R L LKA LR LA L L LL LA

L LA

L LA LN LA LA LR

E
Sample C Program to Build Setup Frame
Buffer

Example E-1 shows a C program to create the setup frame buffer for the
hashing filtering mode.

Example E-1

Hash Filtering Setup Frame Butfer Creation C Program

’/*
*x *

This program builds the setup frame buffer for the SGEC imperfect

**k

filtering.

* &

* %
*%

The addresses are read, in the IEEE 802 address display format
(xx-xx-xy-xx-xx-xx), from the file specified in the in_filename argument.

* %
**®

The setup frame is writen in the file specified by the out filename

x %

argument. If missing,

the setup frame is sent to the standart output.

* K

* &
**
xk

* %

Each multicast address generates a hit in the hash filter.
The first read physical addresses is kept as the physical address
following the hash filter.Subsequent non multicast addresses, if any,
are ignored.

*k
* &

* ¥

The address crc is generated by the crc polynomial specified by the
IEEE 802.3 standard:

* %

* %
*%k

FCS(X)

26
+X

23
+¥%

22
+X

16
+X

12
+X

11
+%X

190
+X

8
7
5
4
2
+X+X+X+X+X+X+1

*/
$include <stdio>
main{argc,argv}

int argc;

char *argv{];

(continued on next page)

Sample C Program to Build Setup Frame Buffer

E-1

Example E-1 (Cont.) Hash Flltering Setup Frame Buffer Creation C Program .
{

FILE *fopen(),*fin, *fout;

unsigned char

line[80],
physical
cnt = 0;
i, hash_index;

int
if

address[6],
setup frame[128],

(arge < 2)

{

printf ("\n Usage: program in_filename {out filename}\n");
exit (1),

}
if

(!'(fin = fopen(argv[1l],"r"))){

printf ("\n Error: %s cannot be open for read\n",argv[1l]);
exit

(1);

}
if

(arge >= 3)
if (!(fout = fopen(argv{2],"w"))){
printf ("\n Error: %s cannot be open for write\n",argv{2]);
fclose(fin)
;
exit

(1),

}
/* initialize the setup buffer */
for

(i=0;

i<128;

i++)

setup frame[i]=0;
while

(1)

{

/*get a Ethernet address */
if

(!fgets(line,80,fin)) break;

sscanf (line, "$2X~%2X~-%2X-%2X~-%2X~-%2X",
gaddress[0], &address[1], &address[2],
&address[3], &address([4], &address([5]);

/* check the address type */
if

(address[0]

& 1){

/* multicast address */
/* calculate the hash_index */
hash_index = crc_address(&address[0]):

/* update the hash filter */
setup_frame[hash index>>3] |=

(1 << hash_index%8)

;

}
(continued on next page)

E-2

Sample C Program to Build Setup Frame Buffer

Example E-1 (Cont.) Hash Flitering Setup Frame Buffer Creation C Program
else

{

/* physical address */
if

(!pbysical cnt)

for

(i=0;

i<6;

i ++)

setup frame[64+i]

= address[i};

physical cnt++;

continue;

}
}

** send a warning message if no, or more than one, physical addresses
/*

** have been found

*/
if

(!physical cnt)
printf{

else if

("\nWarning:

%s does not contain a physical address

!'\n\n",

argv(l]);

{physical
cnt > 1)

printf

("\nWarning:

%s contains more than one

(%d)

physical address

'\n\n®",

argv[l],physical_ecnt);

**store the setup buffer in the specified out file
/*

(argec >= 3)
for

{i=0;

1<18,

i++)

fprintf (fout, "%02X%02X%02X%02X\n",
setup frame[i*4+3],setup frame[i*4+2],
setupframe[i*4+1],
setup frame[i*4]);
else

for

(i=0;

i<18;

i++)

printf("$02X%02X%02¥%02X\n",
setup frame[i*4+3],
setup frame[i*4+2],

setup_frame[i*4+1],setup frame[i*4]);
fclose(finj;

fclose{fout);

i
int crc_address (addr)
char *addr;

(continued on next page)

Sample C Program to Build Setup Frame Buffer

E-3

Example E-1 (Cont.) Hash Filtering Setup Frame Buffer Creation C Program ‘
{

int

i/ kl m,
hash = 0;
unsigned char mean,
crc33];

/* Init CRC to all 1's */
for

(i=0;

i<33;

i++)

crcl[il = 1;

/* Compute the address CRC by running the CRC 48 steps */
for

(i=0;
1i<6;
i++4)
for (k=0;
k<8;
k++){

mean = crc32] * ({(*(addr+i)>>k)

& 1);

for (m=32; m>=2; m--)
cre(m]

= crem-1j];

crc[27] = cref27]

* mean;

crc{24] = crci24]

* mean;

crc{23] = crc[23] * mean:
crc{l7] = crc[17}
crc{l3] = crc[13]
crcli2] = crefl2]

crefil]
crc{09]
crc{08]
crc[06]
cre{05]
crc[03]
~rc[02)

= cre[ll]
= crc[09]
= crc[08]
= crc{06]
= crc05]
= crc[03]
= crcl02]

* mean:
* mean;
* mean;

~ mean;
* mean;
* mean;
* mean;
* mean:
* mean;
* mean;

crc{0il = mean;

}
/t

** Extract the hash_index from the CRC residue
** (warning: the bits are mirrored into the CRC :

**x

the msb bit of CRC residue is the lsb bit of the hash_index)

for (k=24;
k<33;
k+4)
hash = hash<<1 | crclk];
return (hash & 0xzl1FF);

E-4 Sample C Program to Build Setup Frame Buffer

800NN

SISV

0008 800600808 48.0.68080809

OOIS0
$60 080 89090008090000800800.404.4.4

KEC

R Y

XX XK KK XK XK XK

p:6.4:9.6:0.0.60.8.008.00.48.09.06005008800.6460.406.665.60.0.001
PS40 I 448480680800 400080804309.003.9995060064
PO

AP0

N0 E0 0480006040 60484808005000004

P p bGPt 08908080808 0880800840848088.8044
b 0008400000 080805400.60040.0.64606.0890.0.04
B AR08 80800.8.¢008648.00.0000.0.9¢6.00946
p4040400 04 080.65.00400.00053 009600064
XXX EX R TR EAURK XA Y XKL AR KK KL KK KKK
1.98.0.0.0.9.0.0.00.00.6308.8869.04065.¢0.04
$:9.0.0.9.0.6.0.0,8.9,90.0.6.4.0.0.9.0.0.0.9.8..0.4.4
R0040:0.9.80.4.0.0.8.0.896685.96.0.0.4.4
bEG 68048.59808.0060.4$50.0.4.4
b000.0.640.4.8.0.0.040¢904.4.64

p.4.0.0.8.0.9.0.0.4.00.6.08.00044
XXX HEXAUXKKALAY
}:0.6.0.0.0.0.0.9,6,0.¢4.6.4.6.4
b0.9.4.9.6.4.¢.4.0.89
.64
0.9.0.9.0.0.0.0.¢
¢4
XHAXAXXXK
XXXHXXX

XXXXX
XXX

XX
XXXX

XAXXKX
$.8.0.6.6,4.8,4.

EXAAKKXAXK
XXX AXXKKKXN

p5.8.0.0.49.0080.80
¢
fe .0860040080800
$0.4.0.0.0.9.0.0889.4.88404

XAXKXAAKX
KK AR XK KK XKXA

1$.0.00.000448058040
080090
PO OO

30800808800 0848¢4084

PO 0S4980008080000
38 000004
p6.0.00.00.60.¢8 4805082905408 208000
$.4.8.0.0.09.808.0.68.4008.40.008 50008000
D 0.6.0.9.0.00,68 088020844 48.08899.049.0090
$6.0,0.8.90.8.0.6909$.6000.08.4.6490885880000¢¢

FO.0.60:0.4.6.0.9.90060090.0.990.6.60.¢¢60008400.
}:9.0.0.00.6.0.6.0.0.8.$90.00.6.0,680.8404600046004404

JFR00.000048 6008809080000 08 8840008000044

) $.9.6.0.0.0.669.8.00.0.06.0608808.44¢0008 808086068004

P9 AG000490900009
0909009 600080908 08608¢8¢86894

0006000008900 8.4.000608.998600800060,880998060880
09.0.6.0.0.0.0:0.0.6.0.0.00.9.00.00.950.86000.508¢808080.060804890504
$9.4.9.0.9.0.6.00.0.99.608600808.809.6.0460089698900.698960460800

Index
Application module

address decoder equations,
pin settings, table of,

3-17

Abort, defined,

Architecture

Access

console,

/0,

abort,

6-3

8-3

cache memory,

CADR,

2-22

PAL,

table of pin settings,

5-36

decoding,

6-22

6-14

8-2 to 8-3
8-3

8-1

boot ROM,

latches,

ROM space,

3-10

translation

Altitude
operating,
storage,

A-8

3-16

3-17

floating-point accelerator,

3--30

3-20

hardware-detected errors, 3-26
hardware halt procedure, 3-27
hardware reset, 3-40
/O bus initialization, 3-41
3-40

interrupt action,

3-14

interrupt errors,

3-21

machine check, information saved on,

3--34

Q22-bus to memory, figure,

3-29

3-47 to 3-89

instruction-stream read references, 3-29
internal cache behavior on writes, 3-35

5-36, 6~15

internal cache,

fault,

initialization,

6-14

5-11

latches, figure,

3-29

floating-point errors,

6-14, 8-23

sample application, diagram,

latch,

exceptions,

5-33

decoder, figure,

CPU references,

Ethernet coprocessor,

5-34

boot ROM,

3-31

CFPA instructions, 3-30
data-stream read references,

6~-21

equations, table of,

3-32

3-36

CFPA data types,

5-36

3-34

3-31

cache organization,

decoder, 5-9
and power-up reset, figure,
application module
equations,

3-33

cache data block allocation,

5-3

de¢ .de and boot ROM,

3-31

cache address translation,

time for ROM, table of, 6-18
AC characteristics, table, A-6

PAL,

3-17

cacheable references,

ADAWT instruction,
Address

6-21

6-22

8-10

3--19
memory management errors,

3-20

microcode-assisted emulated instructions,
3-3 to 34
microcode errors,

3-21

index-1

Architecture (Cont.)
microprocessor,

Bus (Cont.)
3-1

control signals, 2-13
cycles and protocols, 2-24 to 2-43

MSER, 3-38
power-up initialization,

3-40

cycle types, table of,

processor initialization, 3-41
read errors, 3-21

resident firmware operation,
ROM address space, 3-10
SCBB, 3-24
SID, 3-28
summary,

trap,

data and address,

5-4

2-11

errors, response to, table,

3-10

8-6 to 8-32

master, rtVAX 300 as,

8-6

protocols,

2-24 to 2—43

retry cycles,

2-2

2-16

slave, rtVAX 300 as,

3-17

8-7

Byte

AUT connector, diagram, 7-9

8-7

interfacing techniques,

DAL masks, table of,

5-7

Byte mask

lines, 5-5 to 5-6
BNC connector, diagram, 7-9
Board-level initialization ROM,
Boot
command,

4-11

countdown,

4-27

device, irmware,

devices,

4-39

4-28

C
Cache,

3-32

address translation,

3-33

behavior on writes,

3-35

control line,

4-21, 6-12 to 6-19

5-8
control of internal,

5-8

display, 4-27
flags, firmware, 4-29

data block allocation, 38-34

from external ROM,

internal,

3-41

3-42

2-22

address decoder,
address latch,

design,

programming,

CADR,

6-19 to 6-35

4-45 to 4-47

user ROM bank 1 with drivers, figure,
6-24

user ROM bank 2, figure,

Central processor,

CFPA,

6-26

Bootstrap operations, 447 to 449

3-31

3-36

overview,

6-12

serial-line, directions,

[roak, 4-10

3-32

Cacheable references,

6-19 to 6-35

3-39

invalidate cycle, 2-42
octaword, figure, 243
quadword, figure, 2-43
organization,

6-13

illustrations,
PALs,

6-14

6-13

diagram,

3-36

2-5

internal, error detection,

disable register, figure,

6-12

3-2

1-2

2-2

data types,

3-31

instructions,

3-30

Chaining, data,

3-67

Chaining, descriptor,
Clock signals,

3-66

2-19

CMPBX contents,

4-35

Break detector,

6-11

Collision detect,

Buffer formats,

3-66

Column address, DRAM multiplexer,

Bus
connections,

Index-2

2-12

Comment (!) command,
2-6 to 2-7

5-12

4-21

Communications, DECnet,

7-1 to 7-2

Configuration, minimum,
Console
access,

CSR (Cont.)

2-5

for DSP,

6-3

circuit illustrations,

Cycle

6-19 to 6-35

command line firmware,
command restrictions,

bus,

2-24 to 243
console read and write timing,

4-11

console sequence,

device

locating,

4-24
8-36

DMA write timing, figure,
read, selection, table of,

interrupt acknowledge cycles,

6-15
rtVAX 300 data transfer and bus types,

6-4

4-9

line drivers and receivers,

status codes,

6-11

mailbox register (CPMBX), figure,
mailbox register fields, table of,
mode, entering firmware,

4-35

4-8

bus turnoff time,

read cycle timing, figure,

6-7

chaining,

6-3

parity checking, 5-7

6-6

transfer, table of types,

2-5

types,

6-7

Data-stream read references,

see console program

Control and Status Register,

figure,

8-54

DC characteristics, table,

8-19

2-2

329

A~5

DECnet communications,

7-1 to 7-2

Decode and control logic,

Decoder

CSDP

address,

IACK codes, table of,

IPR codes, table of,

3-29

D/A to A/D interface, sample application,

Contamination, A-8
Continue command, 4-12

CPU references,

5-4

3-2

Data and address line, see DAL

Console emulation

CPU,

2-11

3-67

DRAM, 5-17
RAM, figure, 5-40

4-24

write cycle timing, figure,

8-7

5-7

latches

to 6-11

terminal interface diagram,
timing parameters,

parity masks, table of,
and address bus,

64
6-1

5-7

parity errors, response to, table of,

Data

3-43

terminal, and firmware,

why needed,

4-36

6-29

system interface,

5-32

byte masks, table of,

4-36

program flags fields, table of,

state machine,

D
DAL

6-19 to 6-30

sequencer, PAL,

5-4

4-34

6-11

registers, table of,

6-5

5-15

ROM read timing,

interface, figure, 6-22

program flags, figure,

8-32

interrupt acknowledge timing,

DUART register, 3-43
I/0 mode, 4-8 to 4-25

PALs,

8-9

DMA timing, figure, 2-42

required capabilities,

oscillator,

6-7

DMA read timing, figure,

4-24

DSP interface, figure,

keys,

8-19

[Ctrix] characters, 4-10

5-11
5-11

boot ROM,

CSR

DSP, sample application, figure,

5-9

application module PAL,

8-50

5-34

6-14

I/O device interfacing figure,

8-23

index-3

Decoder

DRAM (Cont.)

address (Cont.)

4M-byte array,

sample design figure,
Decoding address,

6-14

8-2 to 8-3

memory refresh,

gample application, diagram,
Decoupling caps
sample application, figure,

8-3

5-39, 540

5-12

row and column address multiplexer,
5-12

8-58

terminating resistors,

Default boot device register, figure,

Delete], 4-10

5-15

memory array, figure,

4-37

5-16

timing parameters, 80 ns page mode,
5-26

Deposit command,

4-12

DSpP

Descriptor

and rtVAX 300 interface, diagram,

8-14

chaining,

3-66

CSR bits: hold, interrupt, and reset,

formats,

3-66

CSR for,

receive,

3-67

transmit,

8-19

DMA
base address register,

3-72

receive format, figure,

3-68

setup frame format, figure,
transmit format, figure,

cycles,
3-79

memory map,

mapping, /O,

8-10 to 8-13

8-2

RAM,

8-16

sample application

8-1 to 8-3

console interface, figure,

Diagnostics

3-87

Ethernet coprocessor, on-chip,

address drivers, figure,
3-88

controller, figure,

figure,

DMA
building DMA engine,
control signals,

2-18

8-24

DRAM memory array (2), figure,

242

8-24

devices
mapping registers,

8-10 to 8-13

optional mapping registers for,

8-10

sample application, figure,

read cycle timing, figure,

8-52

8-34

PGM loader ROM, figure,

8-24

RAM data latches, figure,

8-18

to rtVAX sample application,
8-20

2-4

write cycle timing, figure,

8-32

halting processor,
power-up,

DRAM
address path, figure,

reset,

5-13

CAS before RAS, table of,
data latches,

5-17

5-32

8-21

8-20 to 8-21

1-way mirror register,

5-15

8-24

1-way mirror register, figure,

8-9

state machine sequence, figure,
structure,

memory controller, figure,

private RAM, figure, 8-42

DSP DMA controller

index-4

8-44

DRAM address path, figure, 8-23
DRAM memory array (1), figure,

8-7

241

cycle, figure,

8-46

8-52

transceiver and parity generator,

Digital signal processor, see DSP

array,

8-36

DMA

Ethernet coprocessor,

cycle,

8-17

8-16

private memory,

DMA, mapping registers,

8-20

8-17

initialization ROM,

3-72

Device
0, mapping, figure,

8-19

Dual-ported memory,

8-19

8-13

8-48

8-13 to

. Dual universal asynchronous receiver
/transmitter, see DUART

DUART,

coprocessor (Cont.)

CSR2,

6-6

timing parameters, table of,

Ethernet

3-50, 3-51

format, figure,

6-7

table of bits,
CSR3,

3-51

3--51

3-51

format, figure,

Electrical characteristics,

A—5 to A-7

microcode-assisted,
Environment, figure,

table of bits,
CSR4,

Emulated instructions
3-3 to 34

3-52

3-51

format, figure,

2-6

table of bits,

Environmental characteristics,

A-8

CSR5,

Error

3-52

table of bits,

8-6

Ethernet coprocessor, reporting,
3-26

3 87

memory system register, figure,

3-38

hardware-detected,

response to bus, table,

write,

coprocessor,

3-47

349

table of bits,
3-50

3-50

CSR1,

format, figure,
table of bits,

3-63

3—63

3-64

3-52
3-51

address registers, table of,
diagnostics,

3-47

error reporting.

3-87

errors, summary table,

364

on-chip diagnostics,

3—64

3-64

format, figure,

3-64

364

3-65

format, figure,
table of, 3-65

3-88

3-85

3-86

loopback modes,

table of bits,

3-52

3-87

interrupts,

3-64

table of,

addresses, format,

364

3-64

table of bits,

3-85

3-66 to 3—83

address registers,

hardware reset,

table of bits,

CSR15,

3-62

descriptor list

diagram,

3-63

table of bits,

CSR14,

3-51

format, figure,

CSR13,

table of bits,

descriptor formats,

format, figure,

CSR12,

3-62

CSR fields after reset, table of,

3-66

CSR11,

348 to

3-61

format, figure,

to 3-89

control/status registers,

CSR10,

3-61

format, figure,
CSR9,

Ethernet

3-57

table of bits,

3-22

CSRO,

3-57

tabie of bits,

CSR7,

3-53

format, figure,

8-7

response to parity, table,

CSR6,

3-52

3-53

format, figure,

bus,

3-52

operation,

3-84

overview,

1-3

3-89

programming,

3--84

receive mode,

3-87

reflectometer,

3-89

3—88

registers

3-65

physical command/status,
table of,

3-48

Index-5

Ethernet

Examine command,

COprocessor

Example

registers (Cont.)
virtual command/status,

serial interface,

3-86

software reset,

3-85

testing,

boot process console display, 4--28

348

inspecting console field,

time-domain reflectometer,

3-89

Exceptions
and interrupts,

transmit mode, 3-87

architecture,

interface
implementation example,
programming the,
with rtVAX 300,

7-5

External ROM, booting from,

7-2 to 7-3

7-11

controller block diagram,

Fault, defined,

7-3

dc-to-dc converter, diagram,
design corner functions,
differential signals,

7-5

7-7

7-19

isolation boundary,

7-17

7-20

isolation transformer and jumpers
7-3

layout considerations,

7-15

layout for medium interface, diagram,
7-16

7-16

7-18

-7

3-63

CSR14 format,

3-64

CSR15 format,

3-865

CSRV/CSR2 format,

3-51

CSR3/CSR4 format,

3-52

CSR5 format,
CSRé6 format,

3-53
3-57

CSR7 format,

3-61

CSR9 format,

3-62

7-9

4--37

2-42

347

I/O device interfacing
8-23

address decoding block diagram,

transceiver interface,

7-7

transceiver interface signals,
4-25

7-5

address latches,

8-2, 8-23

coneole interface,

8-36

D/A and A/D interface,

registers and rtVAX 300,
thickwire connections,

DMA cycle,

address decoder and power-on reset,

transceiver and connectors, diagram,

index-6

3-50

CSR10 format,

Ethernet coprocessor block diagram,
help display, 4-16

7-9

transceiver, functional description,

listener,

4-34

4-36

default boot device register,

PCB layout considerations,
power,

console mailbox register,
CSRO format,

7-14

heat spreader, diagram,

3-36

console program flags,

7-17

external components,

6-21

cache disable register,

7-12

DP8392 transceiver chip,

application module address decoder
memory map,

7-12

DP8392 transceiver,

3-17

Figures

7-12

DP8392 chip block diagram,

transceiver,

6-12

7-6

board parts, table of,

diagram,

3-16

firmware, 4-20

interface sample

grounding,

3-12

External I/O bus reset register

3-48

EMC compliance,

4-28

modifying console field, 4-28
power-on display, 4-26

3-87

block diagram,

4-15

2-12

decoupling caps,

8-54

8-58

DMA address drivers,

848

8-3

Pigures

Figures (Cont.)

I/0 device interfacing (Cont.)

memory bitmap descriptor,

DMA read cycle timing, 8-9
DMA state machine sequence,
DMA write cycle timing,
DRAM address path,

memory organization,
8-18

8-32
8-24

microcycle timing,

DRAM memory array (2),

8-24

network interconnect

8-42

interface block diagram,

dc-to-dc converter,

8-14

DSP DMA controller, 852
DSP DMA transceiver and parity

HALT logic,

8-24

7-12
7-7

Ethernet interface block diagram,
7-6

7-17

isolation transformer and jumpers,

8-21

7-3

8-5

layout of ThinWire memium interface,
7-16

memory controller,

8-34

RAM data latches,

8-24

reset timer logic,

transceiver, BNC connector, and AUI
connector,

8-21

7-9

octaword cache invalidate cycle,

rtVAX 300 and DSP CSR,

8-50

rtVAX 300 I/O pin connectors,

8-56

rtVAX 300 ThinWire/thickwire
network connections,

8-24

user boot ROM bank 1 with drivers,
8-38

8-40

VAX-to-DSP 1-way mirror register,
8-48

3-82

2-35

perfect filtering setup frame buffer format,
3-81

Q22-bus map register,

3-19

Q22-bus to main memory address
8-10

quadword cache invalidate cycle,

internal cache
3-34

3-33

ROM boot block,

3-67

4-48

rtVAX 300 block diagram,

2-2

rtVAX 300 bottom view, A-3

3-32
3-32

3-33

interrupt registers,

3-15

3-9

LED status register,

rtVAX 300 memory and /O space,

2-20

1tVAX 300 memory bank organization,

internal read or write cycle, 240
interrupt acknowledge cycle, 2-37
interval timer,

5-36

receive descriptor format,

address translation,

tag block,

2-43

2-29

RAM memory map,

organization,

3-6

8-13

quadword-transfer read cycle timing,

information saved on machine check,

data block,

2-30

octaword-transfer write cycle timing,

translation,

imperfect filtering setup frame buffer

2-43

octaword-transfer read cycle timing,

processor status longword,

user boot ROM bank 2,

entry,

7-3

DP8392 chip block diagram,

heat spreader,

844

interrupt daisy-chain block diagram,

format,

2-24

controller block diagram,

DSP and rtVAX 300 processor

generator,

3-38

344

DRAM memory array (1),

DSP PGM loader ROM,

5-5

memory system error register,

memory system status/control register,

8-23

DSP and private RAM,

442

3—45

2-21

rtVAX 300 pin layout,

2-10

rtVAX 300 side view, A4
rtVAX 300 top view, A-2
sample design

index-7

Figures
sample design (Cont.)

Figures (Cont.)

add-ess decoder, 6-14
address decoder and power-up reset,
5-35

address latches, 5-36, 6-15
boot ROM functional block diagram,
6-13

console cycle sequence, 6—4
console interface, 6-22
console read and write cycle timing,

transmit descriptor format, 3-72
typical rtVAX 300 environment, 2-6
user boot/diagnostic ROM, 4-40
Find command, 4-15
Firmware
board-level initialization ROM, 4-39
boostrapping operating system, 4—7
boot device, default,

boot devices,
boot flags,

4-28

4-21

4-29

compatible consoles, 4-9

6-7

console terminal interface block

console command line,

diagram, 6-3
DRAM address path,

5-13
DRAM memory array (1), 5-38
DRAM memory array (2), 5-39
interrupt acknowledge cycle timing,
6-5

conscle commands,
L,

memory controller, 540
longword timing,

Boot, 4-11
Continue,

5-25

octaword write cycle timing,

Halt, 4-15
Help, 4-186
Initialize,

5-28

5-30

Set,

5-18

5-9

processor status display,

6-19

4-17

Show,

4-18

Start,

4-19

Test, 4-19

RAM data latches, 540
ROM read cycle timing,

Unjam,
6-15

6-24

console device,
locating,

6-26

setup frame descriptor format,

2-25

single-transfer write cycle timing, 2-34
system control block base register,
system identification register,

4-24

required capabilities, 4-24

3-79

single-transfer read cycie timing,

4-20

Xfer, 4-20

user boot ROM bank 1 with drivers,
user boot ROM bank 2,

4-17

Repeat, 4-17

memory subsystem functional

diagram,

4-12

Examine, 4-15
Find, 4-15

5-24

octaword read cycle timing,

refresh timing,

4-11 to 4-21

4-21

Deposit,

sequence,

4-11

console command restrictions, 4-11

3-28

3-24

requirements,

4-25

console entry and exit, 4-25

console keys and signals, 4-9
console mode. entering and exiting, 4-9
console program, 4-8 to 4-25

system ROM format, 4-2

console program messages, 4—22

system ROM part, 4-3

countdown status codes, table of,

system ROM set data, 4-4

CPU status LED register, 345
diagnostic test list, 4-29 to 4-33

system type register,

thickwire connections,

4-5

2-13

timing cycle for reset function,

index-8

entering console mode,
2-7

entry,

4-6 to 4-9

4-8

4-27

. Firmware (Cont.)

error messages, table of,

4-22

external /O bus reset register, 4-20
general description,

halt action,

4-1

4-28

access,

memory system control/status register,
3-44
power-on,

4-6 to 4-9

display, 4-26

initialization,

341

reset register,

3-41

cycle types,

8-3

resident, operation,

3-10

device mapping,

resident, overview,

1-3

devices and bus parity,

restart,

8-3

bus

4-7

8-1 to 8-3

ROM, format, 4-2

C-2

pin connectors

SCR$A_RESTORE_CONSOLE, 4-39

sample application, figure,

SCR$A_SAVE_CONSOLE, 4-39

space,

scratch RAM offset definitions, table of,

system illustrations,

4-34
4-26

Initialize command,

gystermn ROM part format, 4-2 to 4-3
system ROM set format, 44 to 4-5

Instruction

gystem scratch RAM, 4-34 to 4-39

set,

test number codes, table of,

4-29

8-23 to 8-60

microcode-assisted emulated,

Instruction-stream read references,

Interconnect, network,

user-supplied test procedures,

442

Interface
bus,

Floating-point accelerator,

Ethernet-rtVAX 300,

3-30

data block, figure,

3-66

2-1 to 2-5

3-32

error detection,

Internal cycles,

3-39

Help display, figure,

4-16

Humidity, operating, A-8

2-37

acknowledge cycle timing, figure,

control,

3-27
340

2-37

acknowledge cycle, figure,

8-21

Help command, 4-16

2-40

acknowledge cycle,

4-15

Hardware configuration, minimum,

3-32

3-33

Interrupt

4-28

HALT mode, see console program

Hardware reset,

entry, figure,

3-34

3-33

organization, figure,

Halt procedure,

2-5

tag block, figure,

HALT logic, figure,

7-2 to 7-3

address translation, figure,

Floating-point unit, see CFPA

Halt command,

8-6 to 8-32

Internal cache,

1-2

Floating-point processor, see CFPA

3-29

7-3

Firmware halt program, see console program

Halt action, firmware,

3-3 to 34

3-2

4-40

Functional description,

5-11

4-17

user initialization procedure,

Formats, descriptor and buffer,

8-56

2-20 to 2-23

IACK codes on CSDP, table of,

startup messages,

overview,

8-3

local register space, table,

2-5

6-5

2-18, 3~-13

daisy-chain, diagram,
daisy-chaining,

8-5

decoder, PAL,

6-33

8-5

decoder, PAL equations,
dispatching vector,

6-35

3-13

Ethernet coprocessor,

3-86

Index-9

Interrupt (Cont.)

internal hardware,
maskable,

3-14

nonmaskable,

3-14

registers, figure,
structure,

Mapping
/O device, 8-1 to 8-3
registers, DMA device, 8-10 to 8-13

3-13

3-15

in /O device interfacing,

in rtVAX 300,
timer,

3--13

vector,

8-6

Interval timer,
figure,

84 to 86

84 to 8-6

attachment unit,

2-12

bank organization, figure,

2-21

bitmap descriptor, figure, 4-42

controller

2-4, 3-9

figure,

3-9

IPR codes on CSDI’, table of,

540

longword timing, figure,

5-11

IPR cycles
external,

Maskable interrupt, 3-14
Memory
and VO space, 2-20 to 2-23

2-37

5-24

octaword read cycle, figure,

5-25

octaword write cycle, figure,

5-28

read timing, longword, 5-23

external read,

2-37

external write,

2-39

read timing, quadword,

Isolation transformer and jumpers diagram,
7-3

refresh timing,

refresh timing, figure,
sequence, figure,

5-30

5-18

setup times, table of,
state machine,

5-23

5--30

5-22

5-17

state machine setup time,
aldr>ss,

‘ot ROM,

Latches
address,

DRAM array, figure,

8-1

DRAM refresh,

6-14

dual-ported,
interface.

5-11

sample application, figure,
address, figure, 6-15, 8-2
LED status register, 6-19

8-23

figure,

8-13

5-3 to 5-4

management unit (MMU),
map, figure,

5-9

2-20
5-5

read cycle selection, tabie of,

3-45

LED test number codes, table of,
Line drivers, console, 6-11
Line receivers, console, 6-11
Listener, Ethernet, 4-25

5-39, 5-40

5-12

organization, figure,

fields, table of, 3-45

4-29

Longword memory controller read timing,
5-23

5-22

read cycle transfers,

5-20

reserved, locations,

2-2

5~15

space address assignment, table,
speed and performance,
structure,

C-1

5-2

5-5

subgystem
functional diagram, 5-9
sequencer PAL,

5-43

sequencer state machine,

543

system

design example,

Machine check
information saved,

3-19

information saved, figure,

3-19

Maintenance operation protocol, see MOP

index~10

5-§ te 5-20

error registers, figure,

3-38

octaword write cycle timing,
timing,

5-21 to 5-32

access calculations, 5-21

5-28

Memory management,
control registers,

Physical characteristics, A-1

3-11

3-12

enable (MAPEN) register,

and signal description,

3-12

Memory system control/status register
fields, table of,
figure,

layout, figure,

3—44

connections,

2-6

supply connections,

3-—44 to 345

Messages, firmware console program, 4-22
Microcode-assisted emulated instructions,

2-20

Power-down sequencing,

2-7

Power-failure, recovery from,

2-7

Power-on

to34

Microcycle, definition,

2-24

Microprocessor architecture,
Minimum configuration,

display,

3-1

2-5

4-26

flags, figure,

4-37

reset, figure,

8-23

Power-up

MMU,

5-9
MOP, 445
running test programs with,

MSER,

2-8 to 2-20

2-10

Power

3—44

Memory system register,

3-3

to A-2

4—45

3-38

initialization,

3-40

requirements,

2-6

reset and address decoder, figure,

sample applicaticn,

5-36

8-20

Processor

initialization,

Network
interconnect,

Interface,

state,

7-3

341

3-5

status display, figure,

2-2

status longword,

registers,

2-23

Nonmaskable interrupt,

3-14

figure,

3-6

/PROGRAM,

444

6-19

3-5

Programmable array logic, see PAL

Octaword
read cycle transfers,

5-20

write cycle timing, memory system,
Operating

altitude,

Q22-bus

map registers, see QMR

address translation, figure,

A-8

recommended conditions, table,
ternperature,

5-28

A-8

Oscillator, console,

1-1

map registers,

8-10, 8-12

8-10

8-12

QMR
map registers, figure,

8-13

Quadword

Parity
checking data,

5-7

control signals,

2-16

DAL masks, table of,
data, checking,

8-10

to main memory address translation,

6-11

Overview of rtVAX 300,

A-5

DMA devices,

memory controller read timing,
read cycle transfers,

5-23

5-20

5-7

index-11

/O bus reset,

RAM, 25

LED display/status, 3-45
local VO space, table, C-2

341

data latches, figure,

540

memory management control,

static vs. dynamic,

5-2

memory management enable (MAPEN),

Random-access memory, see RAM
Read cycle

3—12

3-12

memory system control/status,

3—-44

DMA timing, figure, 8-9
internal, figure, 2-40
memory selection, 5-15

memory system error, 3-38
monitor command, 3-85
processor status LED, 6-19

octaword-transfer, 2-29

revision number and missed frame count,

octaword, figure, 5-25

octaword-transfer, figure, 2-30
quadword and octaword transfers, table,
5-20

quadword-transfer, 2-26
quadword-transfer, figure, 2-29
ROM timing, 6-14
ROM timing, figure, 6-15

single-transfer, 2-24
single-transfer, figure, 2-25
Read references
data-stream, 3-29
instruction-stream,

3-63
status, 3-53
system base, 3-61
system control block base (SCBB), figure,

3-24
system identification, 3-28
system type,

4-5

translation buffer
check (TBCHK), 3-12
invalidate all (TBIA), 3-12
invalidate single (TBIS), 3-12

3-29

Receive mode, Ethernet coprocessor, 3-87
Recovery from power-failure, 2-7
Register
boot, 3-41
breakpoint address, 3—64
cache disable,

Q22-bus map bits, 8-13

3-36

transmit/receive polling demands,

3-50

vector address, IPL, sync/asynch, 3-49
watchdog timer, 3-62
1-way mirror, 8-19
Registers
boot message, 2-64
console interface,

3-41 to 3—46

command and mode, 3-57

control/status,

console boot device, 4-37
console DUART, table of, 3—43
console mailbox, 4-34
control and status, 8-19

DMA device mapping, 8-10 to 8-13
Ethernet coprocessor, 348
general-purpose, 3-5
internal processor, 3-7
interrupt, figure, 3-15

default boot device, 4--37

raemory management control,

descriptor list addresses, 3-51
DMA base address, 8-20

Network Interface, 2-23
Q22-bus mapping, 8-10, 8-12

console DUART, 3-43

3-48 to 3-66

3-12

Ethernet coprocessor

Relative humidity, operating, A-8

physical command and status, 348
table of, 3-48
virtuul command and status, 3-48
external /O bus reset, 4-20

Reliability, A-8
Repeat command, 4-17
Reserved memory locations, 2-2
Rese*, 8-20

ndex-12

‘

' Reset (Cont.)

rtVAX 300 (Cont.)

Ethernet CSR fields, table of, 3-85

side view,

requirements,

top view,

A-3

2-6

timer logic, figure,

8-21

rtVAX to DSP sample application,

2-7

timing, figure,

Resident firmware, overview,
Retry cycles, bus,
'Return|,

8-13 to

8-20

1-3

halting processor,

2-16

power-up,

reset,

4-9

8-21

8-20 o 8-21

8-20

to 8-21

ROM
access time, table of,
address space,

boot

6-18

Sample application

znA address decode, 2-22

address latch.

6-14

bleck, figure.

design,

6-19

to 6-35

programiming,

4—47

to 449

8-24

DSP console interface, figure,

848

8-36

8-50

DSP DMA address drivers, figure,

6-12

8-46,

8-48

initialization,

DSP DMA controller, figure,

2-22

internal cache error detection,

-39

8-52
DSP DMA transceiver and parity
generator, figure,

2-2

read cycle timing,

6-14

read cycle timing, figure,

6-15

system

format, figure,

8-58

DRAM address path, figure, 8-22
DRAM memory array (1), figure, 8-24

DSP CSR, figure,

2-23

external, booiing from,

iocations,

8-54

DSP 1-way mirror register, figure,

6-12

bootstrap cperations,

format, 4-2

8-23

DRAM memory array (2), figure,

6-19, 6-35

diagnostic,

8-3

address latches, figure,
decoupiing caps, figure,

6-13

illustrutions,

PAls,

address decoding, figure,

D/A to A/D interface, figure,

4-48

6-13

diagram,

3-10

4-2

8-44

DSP private RAM, figure,

8-42

1/0 pin connectors, figure,

8-56

memory controller, figure,

8-34

PGM loader ROM, figure,

8-24

part, figure,

4-3

RAM data latches, figure,

part format,

4-2 to 4-3

ThinWire/thickwire network connections,

set data, fignre, 44
set format,

turn-off *‘me,

figure,

44 to 4-5

6-18

user, programming,

2-23

6-24

user boot bank 2, figure,

6-26

Row and column address, DRAM
multiplexer,

5-12

840

3-24

figure,

3-24

table,

3-24 to 3-26

SCR$A_RESTORE_CONSOLE, 4-39
SCR$A_SAVE_CONSOLE, 4-39
Self-test routine cutput,

443

Senal interface, Ethernet coprocessor,

rtVAX 300
bottom view,
overview,

8-38

use boot ROM 2, figure,

SCBB,

user boot bank 1 with drivers, figure,

8-24

use boot ROM 1, figure,

A-4

1-1

Set command,

3-86

4-17

Setup frame buffer format

hash table,

3-83

Index-13

Setup frame buffer format (Cont.)
imperfect filtering, figure,

Tables (Cont.)
console sequencer state machine PAL,

3-83

6-29

perfect filtering, figure, 3-81
Setup frame descriptor format, figure,

3-79

Setup time, memory controller state
machine,

CSRO bits,

3-50

CSR10 bits,

3-63

CSR11/12/13 bits,

5-22

Shock tolerance,

A-8

CSR14 bits,

Show command,

4-18

CSR15 bits,

3-64
3-65

3-28

CSR1 bits,

figure, 3-28
table, 3-29

CSRS5 bits,

3-53

CSR6 bits,

3-57

SID,

3-51

CSR3/CSR4 bits,

3-52

Signal description, 2-8 to 2-20
Start command, 4-19

CSR7 bits,

3-61

Startup messages,

CSR9 bits,

3—62

DAL lines,

2-12

4-26

Status
control signals,

2-16

display, figure,

6-19

dc characteristics, A-5
decoder equations, 6-21
default boot device register fields,

3-53

Status LED register,

parameters,

5-32

DRAM timing parameters for 80 ns page

A-8

contamination,

/SYSTEM,

4-38

DRAM CAS before RAS refresh timing

3-45, 6-19

Storage

altitude,

3-64

mode IM Bit x 1, 5-26
Ethernet board parts list, 7-11

A-8

4-44

System control block base register, see SCBB
System control signals,

2-19

Systemn ROM part, figure,

errors,

4-2

System support functions,

3-85

3-88

/O space, C-1
interrupt decoder,

4-3

System ROM set data, figure,

after reset,

Ethernet coprocessor summary of reported

System identification register, see SID

System ROM format, figure,

Ethernet coprocessor CSR nonzero fields

6-33

irzerrupt decoder PAL equations,

1-3

interrupt priority assignments,

6-35

2-18

LED display chart, 3-46

LED status register fields,
local register 1/O gpace,

Tables

ac characteristics,
acronyms,

MAU signals description,

A-6

application module address decoder,
PAL,

5-36

byte masks,

5-22

5-15

C-1

5-43

mermory system error register fields,

2-8

Q22-bus map register bits,

2-14

cache disable register fields,

3--36

console program flags fields,

436

index-14

memory space,

machine PAL,

3-42

bus interface signals,

6-22

memory read cycle selection,

memory subsystem sequencer state

5-34

boot options,

7-6

memory controller setup times,

B-1

equations,

3-45

C-1

8-13

quadword and octaword read cycle
transfers,

5-20

RDESO fields,

3-68

3-39

. Tables (Cont.)

Thickwire (Cont.)

RDES]1 fields, 3-70

connections, figure,

RDES2 fields, 3-71
RDERSS3 fields,

network interconnect,

3-71

recommended operating conditions, A-5
response to bus errors and DAL parity
2-17

network connections, sample application,

figure,

8-24

Timer, reset logic,

rtVAX 300 CSDP<4:0> IPR and IACK

7-3

ThinWire/thickwire

rtVAX 300 support,

8-7

rtVAX 300 bus status signals,
codes,

7-3

ThinWire, rtVAX 300 support,

receive descriptor status validity, 3-72

errors,

2-13

7-5

8-21

Timing

5-11

console,

1tVAX 300 DAL parity and byte masks,

6-6

DMA cycle, figure,

242

DRAM CAS before RAS refresh, table,

5-7

rtVAX 300 data transfer and bus cycle
rtVAX 300 prucessor pin description,

2-9

rtVAX 300 responses to octaword-transfer
read cycle,

2-30

6-7

internal read or write cycle, figure,
interrupt acknowledge, figure,

2-40

2-37

memory controller longword, figure,

1tVAX 300 responses to quadword-transfer
read cycle,

5-32

DUART parameters, table of,

types, 54

2-29

figure,

SCN 2681 DUART timing parameters,
6-7

3-79

system identification register fields,
system type register fields,

5-25

memory controller octaword write cycle,
figure,

setup frame descriptor bits,

5-28

memory controller refresh, figure,
3-29

4-5

5-24

memory controller octaword read cycle,

microcycle, figure,

5-30

2-24

octaword cache invalidate cycle, figure,

TDESO fields,

3-72

TDES]1 fields,

3-74

octaword-transfer read cycle, figure,

TDES2 fields,

3-76

octaword-transfer write cycle, figure,

TDESS3 fields,

3-77

243

2-35

TMS320C25 digital signal processor
memory map,

2-29

typical ROM access time,

6-18

A-8

Terminating resistors, DRAM,
Test command,

reset cycle, figure,

2-7

single-transfer read cycle, figure,

2-25

single-transfer write cycle, figure,

2-34

Topology, figure,

2-2

Transfer cycle status codes,
Translation buffer,

4-44

445
4-45

Thickwire

7-7

3-11

check (TBCHEK) register,

creating and loading,

connections,

3-87

4-29

Test programs

running,

3-77

Transceiver chip, Ethernet interface,

Test number codes, table of,

MOP,

5-16

4-19

Testing, Ethernet coprocessor,

linking,

quadword-transfer read cycle, figure,

8-16

transmit descriptor status validity,

Temperature, operating,

2-30

3-12

invalidate all (TBIA) register, 3-12
invalidate single (TBIS) register, 3-12
Transmit mode, Ethernet coprocesser,
Trap, defined, 3-17
Turn-off time, ROM,

3-87

6-18

2-12 to 2-13

index~15

Unjam command,

4-20

Write cycle

User boot/ iagnostic ROM, figure,

4-40

DMA timing, figure,

internal, figure,

2-40

octaword, figure,

5-28

octaword, memory system timing,

Vector

dispatching interrupts,
interrupt,

octaword-transfer,

3-13

single-transfer,

A-8

3-30

X
Xfer command,

2-35

2-32

single-transfer timing, figure,
Write references,

5-28

2-35

octaword-transfer timing, figure,

8-6

Vibration tolerance,

index-16

8-32

4-20

2-34