Digital PDFs

MISC-68363BDC

December 1987

62 pages

Original

2.4MB

Document:	Firefox Workstation M-Bus Specification
Order Number:	MISC-68363BDC
Revision:	0
Pages:	62
Original Filename:

OCR Text

Firefox Workstation M-Bus Specification
Revision 2.1

Michael Nielsen (DECWSE: :NIELSEN)

Workstation Systems Engineering
Digital Equipment Corporation
100 Hamilton Avenue
Palo Alto, CA 94301
415-853-6779

December 29, 1987

RESTRICTED DISTRIBUTION

Copyright 1986, 1987 by Digital Equipment Corporation
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 occur in this document. This specification does not describe any program or product
which is currently available from Digital Equipment Corporation. Nor does Digital Equipment Corporation commit to implement this specification in any product or program. Digital Equipment Corporation
makes no commitment that this document accurately describes any product it might ever make.

Blank Page

Table of Contents

4. Firefox M-Bus Specification

4.1. Terminology . .... ... .. ... .. .. .......... .. ... ..... .... ... .. ..... ....... ... .. ..... .. ... .. .. ... .. ..... .. ... .. ... .... ... .. ... .. .. ....

4.2. Operation .. ... .. .. ... .. ... .. .. .......... .. ... ....... .. ... .. ..... .. ..... ... .. ..... .. ... .... ... .. ... .. .. ..... ... .. .. ... ..... .... ... .

4.3. Addressing .......................................................................................................................

4.4. Signals .. .. ...... .. ..... .. ... ............ .. .. ............ ........ .. ..... .. ... .... ..... ... .. .. ... .. ... .... ... .. ... .. .. ... .. ... .. .. ....

4.4.1. M-Bus Arbitration ..............................................................................................

4.4.1.1. l\ffiRQ ..............................................................................................................
4.4.1.2. l\ffiUSY ...........................................................................................................

6
9

4.4.2. Data Transfer .. ................................................... .............. ...................................

4.4.2.1. ivlCI\ID .............................................................................................................
4.4.2.2. MST AT ............................................................................................................
4.4.2.3. 1v1DAL ..............................................................................................................
4.4.2.4. !vfXPAR ...........................................................................................................
4.4.2.5. ~1SHARED ......................................................................................................
4.4.2.6.1v1DATINV ......................................................................................................

10
12
14
14
15
15

4.4.3. Workstation Control ...........................................................................................

4.4.3.l. ~ ..................................................................................................................
4.4.3.2. l\1R.ESET ..........................................................................................................
4.4.3.3. MPOK ..............................................................................................................
4.4.3 .4. 1v1DCOK ........... ......................................... ....... ..... .............. ... .. ... ....... ..... .. .. ... .
4.4.3.5. l\1R.UN .............................................................................................................
4.4.3.6. MIRQ ...............................................................................................................
4.4.3.7. w-IALT ...........................................................................................................
4.4.3.8. MABORT ........................................................................................................

16
16
16
17
17
17
17
17

4.4.4. Clock Distribution ... .. ...................... .... ... .. ... ....... ..... ....... .. ............ ... .. .. ........ .... ....

4.4.4.1. MCLKA ..... ..... ....... .. ... ..................... ..... ... ............ ............................... ..... .. ......
4.4.4.2. MCLKB ... .... ... ....... .......... ....... .. ..... .......... .. .. .................... .. .. ... ..... .............. .. ....
.. _4.4.4.3. MCLKI ............................................................................................................

19
19
19

4.5. Transactions .....................................................................................................................

4.5.1. Transaction Notation ..........................................................................................
4.5.2. Memory-Space Reads .........................................................................................
4.5.3. ~lemory-Space Writes ........................................................................................
4.5.4. I/0-Space Reads ............................... .,......... ...................... ..
. .. . .. .. .. .
4.5.5. I/0-Space Writes ................................................................................................

21
21
22
23
24

lll

4.5.6. Interlocked Transactions .. ...................................................................................
4.5.7. Interrupt-Acknowledge Transactions .................................................................

24
25

4.6. Example Transactions ......................................................................................................

4.6.1. Memory Read to Unshared Line . .................................. ....... ..............................
4.6.2. Memory Read to Shared Oean Line .. ... .. ..... .. ........ .... ... ..... .. .. ... ..... .... ... .... ... .. ... .
4.6.3. Memory Read to Shared Dirty Line ...................................................................
4.6.4. Memory Read with Uncorrectable ECC Error ...................................................
4.6.5. Memory Read to Non-Existent Memory ............................................................
4.6.6. Victim Write .......................................................................................................
4.6.7. Victim Write with Internal Parity Error .............................................................
4.6.8. Write-Through to Unshared Line ..................................................... ..................
4.6.9. Write-Through to Shared Line ...........................................................................
4.6.10. Victim Write with Address Parity Error ...........................................................
4.6.11. I/0 Read ............................................................................................................
4.6.12. I/0 Read with No Slave Response .... ...................... .......... ......... ..... .......... ........
4.6.13. I/0 Write ...........................................................................................................
4.6.14. I/0 Write with No Slave Response ...................................................................
4.6.15. Interrupt Ack:rlowledge .....................................................................................
4.6.16. Interrupt Acknowledge with No Slave Response .............................................

26
28
30
32
34
35
36
37
38
40
41
42
43
45
46

4.7. M-Bus Interface Registers ...............................................................................................

4.7.1. M-Bus MODTYPE Interface Register ...............................................................

4.8. Initialization ... .. ... .. ..... .. ..... ... ............ .. ............ .. .................... .... ... ......... ............... ..... ........

4.8.1. Powerup ..............................................................................................................
4.8.2. Powerdown .........................................................................................................
4.8.3. Workstation Reset ...............................................................................................

48
49
49

4.9. Electrical ..........................................................................................................................

4.9.1. M-Bus Transceivers/Drivers and Input Loads ....................................................
4.9.2. M-Bus Driver/Receiver DC Characteristics .......................................................
4.9.3. M-Bus Signal Capacitance .................................................................................
4.9.4. M-Bus Timing .....................................................................................................
4.9.5. Module AC Characteristics .................................................................................
4.9.6. DC Power ............................................................................................................
4.9.7. AC Power ............................................................................................................

50
51
52
52
53
53
53

4.9.7.1. Operation ofM-Bus with Extended Modules ..................................................

4.9.8. Backplane Signal Assignments ...........................................................................

4.10. Mechanical .....................................................................................................................

Revision History

I Date

126 Dec 87
I

Version : Changes
Added READU transaction
2.1
Added l\1R UN signal
Added M-bus state diagram
Added slave MBRQ assertion during MWP6
Revised M-bus timing
1

30 Apr 87

2.0

Arbitration priority changed to LRU
Support two simultaneous interlocks
MSHARED,:MDATINV,MBUSY,MHALT added
Local I/0 space added
MACKOK renamed to MPOK
More reserved signals added
-12 volt etch added (for future use)

27 Jan 87

1.1

MACOK added; :MDCOK updated

10 Jan 87

1.0

First external release

() ()

Preliminar:' draft

Blank.Page

4. Firefox M-Bus Specification

Tllis is the design specification of the Firefox M-bus. The M-bus is a synchronous memory interconnect
between Firefox modules. The M-bus protocol allows the processor snoopy caches to maintain consistent
data in all caches on a cycle-by-cycle basis.
The M-bus supports a maximwn of eight modules that arbitrate for the M-bus via a least-recently-usedpriority, distributed-resolution scheme. The M-bus can transfer up to 32 bits of address or data in a single
M-bus cycle. M-bus memory-space transactions always transfer 4 longwords of data between caches and
memory. Memory-space reads and cache victim writes are unmasked transfers. Cache write-throughs are
masked transfers. M-bus l/0-space transactions always transfer one masked longword of data between processors and I/0 devices. M-bus interrupt-acknowledge transactions transfer an interrupt vector between a
processor and I/0 device. M-bus transactions nominally complete in 4 to 10 cycles, depending on the
number of data longwords transferred. Slave devices may insert additional wait cycles before completing
M-bus transactions.
The target M-bus cycle time is 70 ns. The internal module logic need not be synchronous to the M-bus
clock. Nevertheless, modules that participate in memory space must meet the timing for indicating shared
status~ Consequently, some processor modules may require a longer minimum M-bus cycle time. M-bus
modules are not required to support M-bus cycle times in excess of 100 ns.
The M-bus time· multiplexes and encodes its control signais to minimize signal cowit and power consumption. Even though signals are time-multiplexed, the protocol design is such that different modules never
drive the same signal on consecutive M-bus cycles, which eliminates problems with overlapping in the
backplane tristate driver.
The M-bus supports single-bit error detection on its command and data signals with parity. The M-bus
supports detection of single-bit errors on its M-bus arbitration signals with distributed protocol checking.
The M-bus does not support hardware error correction.
The following sections describe the M-bus terminology, M-bus operation, M-bus addressing, M-bus signals, M-bus transaction types and sequences, M-bus example transactions, M-bus interface registers, and
M-bus electrical specifications.
In all discussions of M-bus signals, values will be described as asserted or deasserted. This refers to their
logical value, independent of their physical active-high or active-low signal levels. In all figures, M-bus
signals will be shown with a high level for asserted, and a low level for deasserted. All addresses are in
hexadecimal.

4. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification I

DIGITAL EQUIPMS"l.;'T CORPORATION - RESTRICTED DISTRIBL'TION

4.1. Terminology.
The following tenns describe the operations of the M-bus:
Cycle

One cycle is the period of time between rising edges on the bus A clock. During a given
cycle, the M-bus may be idle, arbitrating, transferring an address or data between
modules, or waiting for a module to respond to a request.

Transaction

A transaction is the sequence of bus cycles that accomplish a logical operation. An
example would be, reacting four longwords of data from memory. Transactions are
atomic sequences of bus cycles; there are no pending transactions.

Master

The M-bus module that arbitrates for the M-bus and initiates a bus transaction is the
master. For read class transactions the master specifies an address and waits for a slave
to supply read data. For write class transactions the master specifies an address and supplies write data to a slave.

Slave

The M-bus module that monitors bus transactions and responds to a request initiated by
a master is the slave. Some M-bus transaction requests may be completed by more than
one slave, in which case the slaves arbitrate for the right to complete the transaction.

Longword

A longword is 32 bits of data, which can be transferred between modules in a single bus
cycle.

Octaword

An octaword is 128 bits of data, which can be transferred between modules in four
sequential bus cycles.

Line

A line is one entry of a cache. Firefox cache lines are octaword in size.

Victim

A victim is the cache entry that will be removed to make room for a new cache entry.

Shared

A cache line is marked as shared when the same octaword address may be present in
more than one cache.

Dirty

A cache line is marked as dirty when it has been modified in the cache since it was read
from memory.

Masked

If a data transfer is masked, then only some of the bytes in a longword should be
read/written.

Unmasked

If a data transfer is unmasked, then all of the bytes in a longword must be read/written.

Undefined

For masked transfers, the value of nonrequested bytes in the longword is undefined; that
is, the value may not correspond to the transaction address. However, the data-bus signals are still driven with some specific value, and this value is used in any parity calculations.

2 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.2.

DIGITAL EQCIPME.'\! CORPORATION - RESTRICTED DISTRIBL!IOr\

4.2. Operation
The M-bus supports communication between modules for memory-space operations, IiO-space operations,
and interrupt operations.
Memory-space references are always cached and only generate M-bus transactions to support:
•

Read-miss fills

•

Write-miss fills

•

Dirty-victim writes

•

Shared-cache-line write-throughs

•

Interlocked reads

•

Unlock writes

When a cache reference misses, the cache entry is reallocated and filled with a M-bus memory read. 1bis
applies to either a cache read or write. If the victim entry in the cache line targetted for reallocation is
dirty, a M-bus memory write flushes the data out to memory before the reallocation and a M-bus memory
read occurs. After cache writes to lines that are shared, the cache generates a M-bus memory write-through
to update the other caches and memory. Cache writes to unshared cache lines do not generate M-bus transactions.
Whenever a M-bus memory read or write-through occurs, all caches probe their tag store to determine
whether or not they contain the specified octaword. If a cache contains the octaword referenced by a
memorv read and the octaword is dirty. the cache supplies the read data in p1ace of a rnemory module
1bis ensures that the data from dirty cache entries is used rather than stale memory data All caches that
contain the octaword referenced by a memory write-through update their data store with the supplied write
data. This ensures that shared cache lines remain consistent. After every M-bus memory read or writethrough, caches that contain the octaword update the shared bit of their tag store that indicates whether or
not the line is in more than one cache.
The M-bus supports two simultaneous interlocked transactions to different hexaword addresses. Internal
interlocked reads and unlock writes always generate M-bus reads and writes. Unlock writes are functionally equivalent to write-through transactions. Every M-bus interface contains a two-entry contentadd.ressable-memory that records addresses that are currently locked. This algorithm allows all M-bus
interfaces in the workstation to stall conflicting interlocked reads from their internal logic until the current
interlocked transaction is completed Stalled interlocked reads do not generate M-bus traffic until the
current interlocked transaction is completed. Noninterlocked transactions proceed regardless of whether or
not an interlocked transaction is in progress.
M-bus memory-space read transactions to nonexistent memory modules abort the M-bus cycle after a
memory module normally responds.
Global I/0-space references are never cached and always generate M-bus t:ramactions. M-bus 1/0-space
references to non-existent modules abort the M-bus cycle after an 1/0 module normally responds. M-bus
I/0-space references to address-space holes in I/0 modules abort after a timeout of tens of microseconds.
M-bus I/0 space references may terminate with an indication that the reference should be retried later to
avoid deadlocks between the M-bus and busses accessed through adapters.
Global interrupt-acknowledge references always generate M-bus transactions. Since multiple modules
may service the same interrupt level, interrupt-acknowledge races are resolved by passive-release termination to all but the first module to issue an M-bus interrupt acknowledge. Passive release means that the
interrupt is not seen by software.

4.2. Firefox. M-Bus Specification

December 29, 1987

Firefox. System Specification 3

DIGITAL EQUIPME..1'.'T CORPORATIO~ - RESTRICTED DISTRIBCTION

Table 4-1 lists the peak bandwidth of the M-bus for the various transaction types in '.Mbytes/second.
Table ~1:

M-Bus Peak Transaction Bandwidth

Transaction
Memory read
Memory write
1/0 read
1/0 write

Minimum Cycles
10
6
4
4

Bytes
16
16
4
4

BW@70 ns
22.9
38.1
14.3
14.3

BW@80ns
20.0
33.3
12.5
12.5

BW@90ns
17.8
29.6
11.1
11.1

BW@lOOns
16.0
26.7
10.0
10.0

4.3. Addressing
The M-bus supports a 2-Gbyte memory address space and a separate 2-Gbyte 1/0 address space. Each
module is assigned a 32-'.Mbyte region of 1/0 space as a function of its backplane slot. Table 4-1 lists the
address-space assignments.
Table ~2:

Address-Space Assignments for the M-Bus Module

M-Bus Address Range
00000000 .. lFFFFFFF
20000000 ..7FFFFFFF
80000000 .. 87FFFFFF
88000000 .. 8FFFFFFF
90000000 .. 91 FFFFFF
92000000 .. 93FFFFFF
94000000 .. 95FFFFFF
96000000 .. 97FFFFFF
98000000 .. 99FFFFFF
9AOOOOOO .. 9BFFFFFF
9C000000 .. 9DFFFFFF
9EOOOOOO.. 9FFFFFFF
AOOOOOOO .. FFFFFFFF

VAX Address Range
00000000 .. lFFFFFFF
20000000 .. 27FFFFFF
28000000 .. 2FFFFFFF
30000000 .. 31FFFFFF
32000000 .. 33FFFFFF
34000000 .. 35FFFFFF
36000000 .. 37FFFFFF
38000000 .. 39FFFFFF
3A000000 .. 3BFFFFFF
3C000000 .. 3DFFFFFF
3EOOOOOO.. 3FFFFFFF

Mbytes
512
1536
128
128
32
32
32
32
32
32
32
32
1536

Function
Memory space
Reserved memory space
Global I/0 space
Local I/O space
Slot 0 I/O space
Slot 1 I/0 space
Slot 2 I/0 space
Slot 3 I/0 space
Slot 4 I/O space
Slot 5 I/0 space
Slot 6 1/0 space
Slot 7 1/0 space
Reserved 1/0 space

Memory modules and processor caches jointly maintain the memory-space region. There are no preconceived ideas about memory-space assignments as a function of backplane slot. Memory modules have programmable memory-space base addresses via a register in their I/0-space assignment Other modules that
might reside in memory space (graphics modules, for example) should have similar functionality. Programmable base addresses need only resolve to 1-'.Mbyte boundaries. This allows the address range of multiple memory modules to form a single, contiguous region of memory starting at address 00000000.
Current VAX processors cannot access the reserved memory space. Processors that generate 32-bit physical addresses can access the full 2 Gbytes of memory space.
The glooil I/0 space is defined by the implementation; that is, some VLSI I/0 devices have hardwired base
addresses that fall in this region. I/O modules that require more than the 32 Mbytes associated with their
backplane slot can map some of their resources to the global I/O space.
The local 1/0 space is also defined by the implementation. It is for use by modules that have strictly local
resources in 1/0 space. For example, processor modules could implement special purpose coprocessors in
local 1/0 space so that the coprocessor appears at the same physical address for each processor.
The slot-specific 1/0 space should contain all of the I/O resources associated with a module. There is one
M-bus interface register required of all modules that serves to identify the module class and M-bus interface chip. This register is mapped to the top of the slot-specific 1/0-space region. The remainder of the
slot-specific 1/0-space region is dependent on the implementation. AM-bus module must not respond to
the slot-specific region for another backplane slot.

4 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.3.

DIGITALEQVIPME..'ff CORPORATION -RESTRlCTED DISTRlBCTIO~

Current VAX processors cannot access the reserved I/O space. Processors that generate 32-bit physical
addresses can access the full 2 Gbytes of I/0 space.
Current VAX processors only generate 30-bit physical addresses. Table 4-2 lists the connection of their
address signals to MDAL signals for cycle P2 of M-bus transactions. For all other M-bus cycles the VAX
DAL<3 l :00> is directly connected to :MDAL<31 :00>.
Table 4-3:

VAX 30-Bit Physical Address to M-Bus 32-Blt Physical Address Mapping

M-Bus Address
.MDAL<31>
MDAL<30>
MDAL<29>
MDAL<28 :00>

VAX Address
DAL<29>
0
0
DAL<28:00>

4.4. Signals
The M-bus consists of four groups of signals that implement M-bus arbitration, data transfer, workstation
control, and clock distribution. Table 4-4 lists the M-bus signals and their functions. The asserted column
indicates the active assertion state on the backplane.
Table 4-4:

Summary of M-Bus Signals

Count
8

Type
TTI.

Asserted
Low
Low

Function
Bus requests
Module busy

MCMD
MSTAT
MDAL
MXPAR
MS HARED
MDATINV

4
2
32
3

TRI
TRI
TRI
TRI

High
High
High
High
Low
Low

Bus cycle command
Bus cycle status
Data and address
Parity
Shared line
Data invalid

:MID
l\1RESET
MAB ORT
MIRQ
MHALT

3
1

TTI.

4
1

oc
oc
oc
oc

High
Low
Low
Low
Low

Module ID
Workstation reset
Transaction abort
Interrupt requests
Halt processors

1
1
1

oc
oc
oc

High
High
Low

AC power OK
DC power OK
System running

MCLKA
MCLKB
MCLKI

TIL
TTI.

Total

Signal
l\1BRQ
l\1BUSY

:MPOK
MDC OK

MRUN::

oc
oc

Bus clock-A phase
Bus clock-B phase
Interval clock

----------~-~---·--

4.4. Firefox. M-Bus Specification

December 29, 1987

Firefox. System Specification 5

DIGITAL EQUIPMTh"T CORPORATION - RESTRJCTED DISTRJBL"TION

Table 4-5 shows the cycles composing a single minimum-length, read-class, M-bus transaction. The
module column indicates the module driving the MDAL signals. The wait cycles (P3 through P5) are used
for cache probes in processor modules and memory-array access in memory modules. During cycle P6, if
a cache hits on the address it asserts the MSHARED signal. If a cache hits and the line is dirty, the cache
also asserts its MBRQ signal and supplies the read data in place of a memory module. If no cache hits with
a dirty line, then a memory module provides the read data. The slave module may insert wait cycles starting with P7.
Table 4-5:

Cycle
Pl
P2
P3
P4
PS
P6
P7
P8
P9
PIO

Cycles in a M-Bus Read Transaction

Module
Master
Master

Slave
Slave
Slave
Slave

Action
Bus arbitration
Address
Wait
Wait
Wait
Shared status
Read data
Read data
Read data
Read data

Table 4-6 shows the cycles composing a single minimum-length, write-class, M-bus transaction. The
module column indicates the module driving the MDAL signals. During cycles P3 through P6, processor
caches that hit on the address, together with the selected memory module, write the data. Any caches that
hit indicate this by asserting their MSHARED signal during cycle P6.
Table 4-6:

Cycle
Pl
P2
P3
P4
P5
P6

Cycles In a M·Bus Write Transaction

Module
Master
Master
Master
Master
Master
Master

Action
Bus arbitration
Address
Write data
Write data
Write data
Write data, shared status

The M-bus cycle boundaries, Pn, are defined by the rising edge of MCLKA. Unless otherwise noted in the
following sections, all transitions of M-bus signals are synchronous with respect to MCLKA.
4.4.1. M-Bus Arbitration

The :MBR"Q signals perform arbitration for the M-bus among the modules within a Firefox workstation.
M-bus arbitration serves three functions: determination of the next M-bus master, determination of the Mbus slave for some types of transaction, and indication of the module driving the M-bus. M-bus arbitration
employs a least-recently-used-priority, distributed-resolution algorithm.
4.4.1.1. MBRQ

Each module drives exactly one of the eight MBRQ signals and monitors the MBRQ signals from the other
7 backplane slots. The MBRQ signal for a given slot corresponds to the backplane slot number. For example, slot 0 drives MBRQ<O> and monitors MBRQ<l :7>, and slot 4 drives MBRQ<4> and monitors
:rvIBRQ<0:3,5 :7>.

6 Firefox. System Specification

December 29, 1987

Firefox. M-Bus Specification 4.4. l. l.

DIGITAL EQUIPME.~1 CORPORATION - RESTRJCTED DISTRJBL"'TIO~

Each module asserts its MBRQ signal on a standard connector pin during an idle M-bus cycle when it
needs to acquire the M-bus. Otherwise, a module deasserts its MBRQ signal. A module may not assert its
MBRQ signal during arbitrary M-bus cycles; it may do so only during idle M-bus cycles and when it is
driving the M-bus. After winning the arbitration cycle, the M-bus master continues to assert its MBRQ signal during P2 and P3 of all transactions, and during P4 and P5 of memory-space transactions. During the
course of some M-bus transactions, multiple potential M-bus slaves arbitrate for the slave role. These
potential slaves use the ~IBRQ signals to arbitrate. After winning the slave-arbitration cycle or being
selected by the transaction address, the slave asserts its MBRQ signal during P4 of 1/0-space transactions,
during P4 and PS of intenupt-acknowledge transactions, during P6 of memory-write transactions, and during P7, P8. and P9 of memory-read transactions.
Each module monitors the state of the remaining seven MBRQ signals to independently resolve a M-bus
arbitration. The seven other MBRQ signals are connected to a fixed set of backplane connector pins in a
slot-dependent fashion. These pins are called MBRM<0:6> to identify them as the slot-dependent wiring
of the MBRQ signals.
Table 4-7 shows the backplane permutation of the MBRQ signals for each slot. During a Pl arbitration
cycle, a module loses if any MBRM signal at a higher priority is asserted. The decision as to whether or
not a particular MBRM signal is at a higher priority for this particular cycle is implemented as a MBRM
mask maintained by each module. If the mask bit for a given MBRM signal is set, that module is at a
higher priority. If the mask bit for a given :MBRM signal is clear, that module is at a lower priority. The
MBRM mask is only updated after Pl M-bus arbitration~ slave arbitration does not update the MBRM
mask.
Table 4-7:

MBRQ Wiring to MBRM Pins for Each Backplane Slot

Slot
MBRM<O>
MBRQ<l>
0
1
MBRQ<O>
2
MBRQ<O>
3
MBRQ<O>
4 ' MBRQ<O>
5
MBRQ<O>
6
MBRQ<O>
7
MBRQ<O>

MBRM<l>
MBRQ<2>
:MBRQ<2>
:MBRQ<l>
MBRQ<l>
MBRQ<l>
MBRQ<l>
:MBRQ<l>
MBRQ<l>

MBRM<2>
MBRQ<3>
:MBRQ<3>
:MBRQ<3>
MBRQ<2>
MBRQ<2>
MBRQ<2>
MBRQ<2>
MBRQ<2>

MBRM<3>
MBRQ<4>
:MBRQ<4>
:MBRQ<4>
MBRQ<4>
MBRQ<3>
:MBRQ<3>
MBRQ<3>
MBRQ<3>

MBRM<4>
MBRQ<5>
:MBRQ<5>
MBRQ<5>
MBRQ<5>
MBRQ<5>
MBRQ<4>
:MBRQ<4>
:MBRQ<4>

MBRM<S>
MBRQ<6>
:MBRQ<6>
MBRQ<6>
MBRQ<6>
:MBRQ<6>
:MBRQ<6>
:MBRQ<5>
:MBRQ<5>

MBRM<6>
MBRQ<7>
MBRQ<7>
MBRQ<7>
MBRQ<7>
MBRQ<7>
MBRQ<7>
MBRQ<7>
MBRQ<6>

The MBRM mask is initialized after :MRESET or MABORT from a decoded value of the MID signals that
makes slot 0 the highest priority and slot 7 the lowest priority. Table 4-8 shows the initial :MBRM-mask
values for each module. For example, the module in slot 2 initializes its :MBRM<0:6> mask to 1100000#2
so that slots 0 and 1 are initially at higher priority, and slots 2 though 6 are initially at lower priority.
Table 4-8:

lnltlallzatlon Values for MBRM Masks

Slot : .MJJRM<O>
0
0
1
2
3
4
1
1
5

MBRM<l>

6
7

0
0
1
1
1

4.4. l. l. Firefox M-Bus Specification

MBRM<2>
0

MBRM<3>
0

MBRM<4>
0

0
0

1
1
1
1

0
1
1
1
1

December 29, 1987

MBRM<5>
0
0

MBRM<6>

0
0

0
0
0
0

0
1

0
0

Firefox System Specification 7

DIGITAL EQUIPME'i"T CORPORATION - RESTRICTED DISTRIBCTION

Whenever a module wins a M-bus arbitration, it sets all its MBRM mask bits; that is, the winner views all
other modules as higher priority for the next M-bus arbitration. Whenever a M-bus-arbitration cycle completes, all modules clear the MBRM mask bit of the winner, that is. the winner is viewed as lowest priority
for the next M-bus arbitration. Table 4-9 shows the change in the MBMR. mask from the initial value after
the module in slot 2 wins a P 1 arbitration cycle.
Table 4-9:

Slot
0
1
2
3
4

5
6
7

Initialization Values MBRM Masks

MBRM<O>
0
1
1
1
1
1
1
1

MBRM<l>
0
0
1
1

1
1

MBRM<2>
0
0
1
0
0
0
0
0

MBRM<3>
0
0
1
0
1
1
1
1

MBRM<4>
0
0
1
0
0
1
1
1

MBRM<S>
0
0
1
0
0
0
1
1

MBRM<6>
0
0
1
0
0
0
0
1

When a module loses an arbitration cycle to a higher-priority module, it must deassert its MBRQ signal
until the end of the current M-bus transaction. The module that wins an arbitration cycle continues to
assert its M-bus request until the M-bus slave takes over the M-bus. Whenever a slave module is driving
the MSTAT and MDAL signals, it must assert its MBRQ signal.
When a module loses an arbitration cycle, it must still monitor the M-bus transaction to maintain synchronization with the other modules.
During idle M-bus cycles, all MBRM signals are monitored to determine the start of M-bus transactions
initiated by other modules.
Each module should implement M-bus-monitoring logic that detects assertion of other MBRQ signals
when it is driving the M-bus. If multiple modules erroneously believe they won a M-bus arbitration, they
will observe each other's MBRQ signal as asserted and signal a M-bus error. If multiple slaves erroneously respond to a M-bus transaction, they will observe each other's MBRQ signal as asserted and signal a
M-bus error. This serves as a form of single-bit error detection on the MBRQ signals.
Table 4-10 lists cycles in which exactly one M-bus master, M, or exactly one M-bus slave, S, should be
asserting its MBRQ signal.
Table 4-10:

M-bus Cycles Requiring MBRQ Checking

Transaction
I Pl
Memory Read
Memory Write
I/0 Read
I/0 Write
Interrui>t Ack.

M
M
M
M
M

M
M

s
s

Modules must also assert their MBRQ signal when MRESET is asserted. This allows M-bus-monitoring
logic to determine which backplane slots contain modules, even if the modules have hardware failures that
prevent them from responding as M-bus slaves during M-bus transactions. Because of timing restrictions,
assertion of MBRQ during reset must be pipelined; that is, MRESET is ORed into the next cycle state for
MBRQ. This implies that the MBRQ signals will still be asserted during the first cycle that MRESET
becomes deasserted. Consequently, M-bus-interface state machines must not interpret MBRQ assertion
during this cycle as M-bus arbitration. Tiris may be implemented by using a one-cycle-delayed copy of
l\1RESET to reset internal logic.

8 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.4. l. l.

DIGITAL EQUIPME.~'T CORPORATION - RESTRICTED DISTRIBL'TION

Figure 4-1 shows a workstation with modules in backplane slots 0. 4, and 5. In response to the assertion of
MRESET, all modules reset their internal logic and their M-bus-interface logic asserts their lvIBRQ signals.
Backplane termination resistors maintain a deasserted level on the slot 1, 2, 3, 6, and 7 :MBRQ signals.
During cycle P4, a M-bus-interface register may latch and save the value of :MBRQ<0:7> for use by
software. Cycle PS is the first M-bus cycle that a M-bus transaction can start.
I PO I Pl I P2

I P4

PS I P6 I

MBRQ<O>
MBRQ<l>
MBRQ<2>
MBRQ<3>
MBRQ<4>
MBRQ<S>

MRESET
Figure 4-1:

MBRQ Assertion During MRESET

It is recommended that M-bus-interface logic monitor its own :MBRQ backplane signal and verify that it is
driven with the correct state.
4.4.1.2. MBUSY

Commencement of a new M-bus transaction can be stalled by asserting the :MBUSY signal. Assertion of
MBUSY during a transaction has no effect on the current transaction. Assertion of :MBUSY suppresses
transition of the M-bus state from Pl to P2. The primary use of :MBUSY is to stall commencement of a
new transaction until a memory-write transaction completes in all slaves. Tilis is necessary because
memory writes are broadcast transactions and may complete in a different number of M-bus cycles in the
slaves.
4.4.2. Data Transfer

Data transfer between two or more modules is accomplished via the MDAL signals under the control of the
MCMD·and MSTAT signals. The :MXPAR signals enable single-bit error detection of the MCMD,
MSTAT, and MDAL signals.
The :MDAL signals are driven by M-bus masters to specify addresses, write data, and interruptacknowledge levels. The :MDAL signals are driven by M-bus slaves to specify read data and interrupt vectors. The MC:MD signals are driven by M-bus masters to specify the transaction type and I/0-space byte
masks. The ~ST AT signals are driven by M-bus slaves to indicate the status of the current transaction.

4.4.2. l. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 9

DIGITAL EQlJIPME..~"T CORPORATION - RESTRICTED DISTRIBUTION

4.4.2.1. MCMD

When a M-bus master is driving the MDAL signals, the MCMD signals indicate the contents of the MDAL
signals. There are three uses of the MCMD signals: transaction type, memory write-through byte mask,
and I/0-read/write byte mask. Table 4-11 lists the interpretation of MCMD during various transaction
cycles. All transactions are shown without slave wait cycles.
Table 4-11:

Interpretation of MCMD During Transaction Cycles

Transaction
All transactions
All transactions
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read

Cycle

Pl
P2

P3
P4
PS
P6

Interpretation
<Not driven>
Transaction type

PlO

Memory write
Memory write
Memory write
Memory write

P3
P4
PS
P6

Byte mask
Byte mask
Byte mask
Byte mask

I/0 read
I/0 read

P3
P4

Byte mask
<Not driven>

I/0 write
I/0 write

P3
P4

Byte mask
<Not driven>

Interrupt acknowledge
Interrupt acknowledge
Interrupt acknowledge

P3
P4
PS

fY7

P8
P9

10 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.4.2. l.

DIGITAL EQliIPME.'f\IT CORPORATION - RESTRICTED DISTRIBCTION

Table 4-12 lists the encoding of the MCrvffi field during cycle P2 of all M-bus transactions. A memoryspace versus an 1/0-space transaction is specified by MDAL<31> of a read or write address; rvIDAL<31>
is 0 for memory space and 1 for 1/0 space. M-bus masters must drive rvIDAL<31> to 1 for intenuptacknow ledge transactions.
Table 4-12:

MCMD Encoding During Cycle P2 of Transactions

Value

Mnemonic

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

RESERVED
RESERVED
RESERVED
RESERVED
RESERVED
READ
RESERVED
WRITET
RESERVED
READI
WRITE
WRITEU
RESERVED

Function

Request read
Request write-through
Request read interlocked
Request victim or 1/0 write
Request write unlock

I~'TACK

Req~est interrupt ackno·.vledge

READU
RESERVED

Request read unshared

When the M-bus master issues an 1/0-space read or write. the MCrvffi signals specify the byte mask for the
longword address. For both 1/0 reads and writes, the M-bus master supplies the byte mask during cycle P3
of a M-bus transaction. Table 4-13 lists the correspondence of mask bits to rvIDAL bytes. If MCrvffi<n> is
asserted, then the corresponding byte of the longword is to be transferred. If MCrvffi<n> is deasserted,
then the corresponding byte of the longword contains undefined data. When some bytes of rvIDAL are
undefined because of byte masks, they still enter into the calculation of rvIDP AR.
Table 4-13:

Mask Bit
MCrvffi<3>
MCrvffi<2>
MCrvffi<l>
MCrvffi<O>

Correspondence Between Mask Bits and MDAL Bytes

MDAL Byte
rvIDAL<31 :24>
rvID AL<23: 16>
rvIDAL<l 5 :08>
MDAL<07:00>

A M-bus master should only drive the MCMD signals during a cycle in which it is specifying a transaction
type or byte mask. When a M-bus master is driving the MCMD signals, it must specify valid parity on
MCPAR.-

4.4.2.2. Firefox. M-Bus Specification

December 29, 1987

Firefox System Specification 11

DIGITAL EQUIPMEN1 CORPORATION -RESTRICTED DISTRIBtITION

4.4.2.2. MSTAT

When a M-bus slave responds to a M-bus transaction, it asserts its MBRQ signal, specifies transaction
status on the MSTAT signals, and supplies data on the MDAL signals for read-class transactions. Table
4-14 lists the interpretation of MSTAT during each cycle of the various M-bus transactions. All transactions are shown without slave wait cycles.
Table 4-14:

Interpretation of MSTAT During Transaction Cycles

Transaction

Cycle

All transactions
All transactions
All transactions

Interpretation
<Not driven>
<Not driven>
<Not driven>

P3
P4
P5
P6

Memory read
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read

PIO

<Not driven>
<Not driven>
<Not driven>
Data status
Data status
Data status
Data status

Memory write
Memory write
Memory write

P4
PS
P6

I/O read

Transaction status

1/0 write

Transaction status

Interrupt ack
Interrupt ack

P4
PS

<Not driven>
Transaction status

fY7

P8
P9

If no MBRQ signal is asserted during the first M-bus slave cycle of a transaction, then no slave responded
and the transaction is immediately terminated. Table 4-lS lists the first M-bus slave cycle for each transaction type.
Table 4-15:

First Slave Cycle of Transactions

Transaction
Memory read

First Slave Cycle

1/0 read-~

P4
P4
P4

I/0 write
Interrupt acknowledge

12 Firefox System Specification

December 29, 198 7

Firefox M-Bus Specification 4.4.2.2.

DIGITAL EQUIPME.'\;"T CORPORATION -RESTRJCTED DISTRlBCTION

When a M-bus slave does respond, it specifies cycle status on the MSTAT signals. Table 4-16 lists the
MST AT encodings.
Table 4-16:

Value
00
01
10
11

MSTAT Encoding

Mnemonic
WAIT
GOOD
CORRECTED/RETRY
ERROR

Function
Stall transaction
I/O write complete/good read data
Corrected memory-read-data/retry-I/O transaction
Transaction error

If a M-bus slave requires additional cycles to complete the current transaction, it specifies WAIT status. A
M-bus slave must not specify WAIT status after returning the first longword of a memory-space read. If

WAIT is specified during P8, P9, or PlO of a memory read, the M-bus master should treat it as GOOD
status.
AM-bus slave specifies GOOD status when it completes an 1/0 write, and also when it returns memoryread data, I/0-read data, or an interrupt vector.
A M-bus slave specifies CORRECTED status while it returns memory-read data that bas a corrected
single-bit error. A M-bus slave specifies RETRY status when 1/0-space transactions must be retried or
when a dead.lock with another resource would result.
A. M-bus slave srecifies ERROR status for I/0-space transactions that referenc,e non .. existent resourr-es
Non-existent-resource references should be minimized, as they take up to 256 M-bus cycles to time out

When a M-bus slave is driving the MSTAT signals, it must specify valid parity on MSPAR.

4.4.2.3. Firefox. M-Bus Specification

December 29, 1987

Firefox System Specification 13

DIGITAL EQUIPME..1'i1 CORPORATION -RESTRJCTED DISTRIBCTION

4.4.2.3. MDAL

The rvIDAL signals transfer information between modules during M-bus transactions. Table 4-17 lists the
interpretation of rvIDAL during the various M-bus transaction cycles. All transactions are shown without
slave wait cycles. Modules may only drive MDAL when acting as a M-bus master or slave. Whenever a
module is driving the MDAL signals, it must specify valid parity on MDPAR.
Table 4-17:

Interpretation of MDAL During Transaction Cycles

Transaction
All transactions

Cycle
Pl

Signals
<Not driven>

Interpretation

Memory read
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read
Memory read

P2
P3
P4
PS
P6

Octaword address

P8
P9
PIO

MDAL<31 :04>
<Not driven>
<Not driven>
<Not driven>
<Not driven>
MDAL<31 :00>
MDAL<31 :00>
MDAL<31 :00>
MDAL<31 :00>

Memory write
Memory write
Memory write
Memory write
Memory write

P2
P3
P4
PS
P6

MDAL<31:04>
MDAL<31 :00>
MDAL<31 :00>
MDAL<31:00>
MDAL<31 :00>

Octaword address
Data
Data
Data
Data

I/0 read
I/0 read
I/0 read

P2
P3
P4

MDAL<31 :02>
<Not driven>
MDAL<31:00>

Longword address

I/0 write
I/0 write
I/0 write

P2
P3
P4

MDAL<31 :02>
MDAL<31 :00>
<Not driven>

Longword address
Data

Interrupt acknowledge
Interrupt acknowledge
Interrupt acknowledge
Interrupt acknowledge

P2
P3
P4
PS

MDAL<06:02>
<Not driven>
<Not driven>
MDAL<15:00>

Level

Data
Data
Data
Data

Data

Vector

For read - and write transactions, a memory-space versus an 1/0-space transaction is specified by
MDAL<31> of the address; MDAL<3 l> is 0 for memory space, or 1 for I/0-space or interruptacknowledge transactions.
4.4.2.4. MXPAR

The MCP AR signal specifies even parity for the MCMD signals. The MSPAR signal specifies even parity
for the MSTAT signals. The MDPAR signal specifies even parity for the :MDAL signals. Even parity
means that there is an even number of ls in a signal group and its corresponding parity bit.
Whenever a module drives any signal of MCMD, MSTAT, or MDAL, it must drive all signals of the
group, plus the corresponding :MXPAR signal.

14 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.4.2.4.

DIGITAL EQUIPME.~1 CORPORATION -RESTRICTED DISTRIBliTION

Table 4-18 lists the M-bus cycles for which modules must check M-bus parity. The five types of M-bus
transactions are shown, together with an indication of which cycle C , S , or D checking is required for the
MCMD/MCPAR, MSTAT/MSPAR, and MDAL/MDPAR signals. All transactions are shown without
slave wait cycles. MDAL parity errors must be ignored during slave wait cycles.
Figure 4-2:

M-bus Cycles Requiring Parity Checking

Transaction

Memory read
Memory write
I/0 read
I/0 write
Intenupt acknowledge

P2
CD
CD
CD
CD
CD

P3
CD

c
CD

P4
CD
SD

PS
CD

PIO

s
SD

4.4.2.5. MSHARED

When memory-read, memory-read-unshared, memory-read-interlocked, memory-write-through, and
memory-write-unlock transactions start on the M-bus, all caches probe their tag store to determine whether
or not they contain the octaword. If a cache does contain the octaword, it asserts MSHARED during P6.
Caches that contain the octaword update their tag-shared bit with the value of MSHARED during P7.
4.4.2.6. MDATINV

Whenever a module drives data onto MDAL that is known to contain a parity error, it asserts MDATINV
Local parity errors occur when cache data stores have parity errors, memory modules have uncorrectable
ECC errors, or devices have hardware failures. When modules receive data with .MDATINY asserted,
either they must indicate an error to the transaction request and not use the data, or they must retain an indication that the data is invalid along with the data. For example, when caches receive invalid data during fill
operations, they could intentionally write the data store with invalid parity. This prevents the undetected
spread of invalid data.
4.4.3. Workstation Control

The ?vfiD, MRESET, MPOK, MDCOK, :MRUN, MIRQ, MHALT, and MABORT signals initialize and
coordinate the various modules in a Firefox workstation.

4.4.3.1. Firefox. M-Bus Specification

December 29, 1987

Firefox. System Specification 15

DIGITAL EQUIPMENT CORPORATION -RESTRICTED DISTRIBUTION

4.4.3.1. MID

The MID signals uniquely identify each M-bus backplane slot with a value from 0 to 7. The MID signals
are connected to the backplane +5-volt and ground planes to achieve the value for a given slot. Table 4-18
lists the MID connections for each slot. The MID value is used in the M-bus-arbitration logic and I/0space-address decoding to eliminate the need for switches or jumpers on M-bus modules. The MID value
must be available to each module via a CSR.
Table 4-18:

Slot
0
1
2
3
4
5
6
7

MID Slot Connections

MID<2>

MID<l>

MID<O>

GND
GND
GND
GND

GND
GND

GND

+5V
+5V

GND

+5V
+5V
+5V
+5V

GND
GND

GND

+5V
+5V

GND

+5V
+5V
+5V
+5V

Since the MID signals are tied directly to power planes, modules must provide a series resistor for each
MID signal as appropriate for their interface logic to avoid device damage.
4.4.3.2. MRESET

The :MRESET signal is asserted to initiate a workstation-wide reinitialization. While :MRESET is asserted,
all logic on M-bus modules must be set to a known state and the current M-bus transaction must be
aborted. On the asserted to deasserted transition of MRESET, modules that perform self-testing or that
require more extensive internal restart processing should commence their tests or processing. Such
modules should provide a status bit accessible at all times via a CSR in their M-bus interface that other
modules can use to ascertain whether or not their services are available for use.
The preceding paragraph does not imply that modules must perform self-testing when :MRESET first
becomes deasserted. Some modules may require software coordination or direction of self-testing. For
example, if all memory modules perform self-testing in parallel, the power-distribution capacity of the
workstation might be exceeded.
~ESET has a minimum assertion width of eight M-bus cycles. ~ESET must be asserted for a
minimum of 70 milliseconds after DC power is available on powerup. :MRESET must be asserted whenever the l\1DCOK signal is deasserted Transitions of the :MPOK signal have no effect on :MRESET.

Any module or any package-switch logic may be used to assert :MRESET .
....

4.4.3.3. MPOK

The MPOK signal is asserted by the workstation power supplies when the AC line power is within
specification. When MPOK becomes deasserted, modules should initiate power-failure actions. Deassertion of MPOK does not reset or abort M-bus transactions; it is a higher-level indication that a shutdown is
imminent.
The transitions of MPOK are asynchronous with respect to the M-bus clocks.
Since Firefox workstations do not support battery backup of memory, the only activity expected, when
MPOK transitions from asserted to deasserted, is completion of disk sector writes in progress. Modules
must not stop responding as M-bus slaves when :MPOK is deasserted.

16 Firefox. System Specification

December 29, 1987

Firefox. M-Bus Specification 4.4.3.4.

DIGITAL EQUIPMENT CORPORATION - RESTRICTED DISTRIBUTION

4.4.3.4. MDCOK

The 'MDCOK signal is asserted by the worlcstation power supplies when they are supplying DC power
within specification. When :MDCOK becomes deasserted, modules may freeze internal resources as
appropriate and stop responding to M-bus transactions.
The transitions of MDCOK are asynchronous with respect to the M-bus clocks.
4.4.3.5. M RUN

The l\.1RUN signal may be asserted by a workstation module to indicate that the workstation is running.
The l\1RUN signal is typically connected to a front-panel LED as an indication that the workstation has
passed module self-test and is either booting or running the operating system. The :MR.UN signal may be
driven by any module, though typically is only driven by the workstation I/O module.
The transitions of l\1RUN are asynchronous with respect to the M-bus clocks.
4.4.3.6. MIRQ

The MIRQ signals are asserted to indicate a pending interrupt. When internal logic on a module has a
pending interrupt, it asserts its interrupt-request signal. The M-bus interface propagates this interrupt
request onto one of the MIRQ signals. The M-bus interface of a module that is servicing interrupts propagates the MIRQ signal onto its local interrupt request.
M-ous-imerface iogic should proVIde a mechanism that botn masks propagauon of internal mterrupt
requests onto MIRQ signals and propagation of MIRQ signals onto internal interrupt requests. This
scheme is based upon the ac;sumption that a module either requests or services interrupts for a given level
but never does both.
Transitions of the MIRQ signals are asynchronous to the M-bus clocks.
4.4.3.7. MHALT

When the MR.ALT signal is asserted, workstation processors should halt. Any module or any packageswitch logic may assert MR.ALT.
Transitions of the MR.ALT signal are asynchronous to the M-bus clocks.
4.4.3.8. MABORT

The MABORT signal is asserted by any module detecting an error condition during a M-bus transaction.
Transaction errors are the following:
•

M-bus-arbitration errors (multiple masters or slaves)

•

·Parity errors on the MC:MD, MSTAT, or MDAL signals

•

Reserved values of the MCMD codes

.. -

Too many slave wait/busy cycles

•

Interlock violations

•

Cache tag-parity errors

M-bus-arbitration errors occur when multiple l\1BRQ signals are asserted when only one module, either the
M-bus master or the M-bus slave, should be in control of the M-bus. When a master or slave detects a
MBRQ signal from another module asserted while it is driving the M-bus, it should assert its MABORT
signal. M-bus errors should also be generated if the M-bus master/slave l\1BRQ signal is prematurely
deasserted during a transaction.
Parity errors on the MC:MD, MSTAT, and MDAL signals occur when there are M-bus transceiver failures,
connector failures, logic failures that cause no module to drive the M-bus, logic failures that cause multiple
modules to drive the M-bus, and failures in the parity-checking logic. Parity errors can also result when
AC timing is marginal, in which case only some of the modules may detect the error. When any module

4.4.3.8. Firefox ~-Bus Specification

December 29. 1987

Firefox System Specification 17

DIGITAL EQUIPME.~i CORPORATION -RESTRICTED DISTRlBLiION

detects a parity error on MCMD, MSTAT, or MDAL during one of the M-bus cycles specified by the table
in the :MXPAR section, that module should assert its MABORT signal.
Only 7 of the possible 16 MC:MD encodings are valid during P2 of M-bus transactions. Invalid encodings
result when there is a hardware failure in the M-bus master's M-bus-interlace MCMD logic, when there is
a hardware failure in the monitoring module's M-bus-interlace MCMD logic, or when the monitoring
module is out of sync in a different transaction phase than the M-bus master. When any module detects an
invalid encoding during P2 of a M-bus transaction, it should assert its MABORT signal.

If a M-bus slave specifies WAIT status for more than 256 M-bus cycles, MAB ORT should be asserted.
M-bus slave interfaces should implement their own timeout logic for M-bus-initiated, internal-bus transactions. If an internal timeout occurs, the slave module's M-bus interface should specify ERROR status to
terminate the M-bus transaction. To minimize the length of time that the M-bus is stalled, the internal
timeout should be the minimum necessary for the specific module. Indicating ERROR status also limits the
failure status to only the module that initiated the M-bus transaction. The M-bus slave wait timer is
intended to catch failures of slave M-bus-interface logic, which affects the entire workstation. When any
module detects too many slave wait-status cycles, it should assert its MABORT signal.
When a read-interlocked transaction is initiated. all M-bus interfaces update their interlocked unit. The
address is interlocked against other interlocked reads to that same address until a write-unlock transaction
is initiated. While an address is interlocked, M-bus interlaces must stall internal requests for readinterlocked transactions to that same address. If a M-bus interface obseives a read-interlocked transaction
on the M-bus for an address it considers interlocked, this means that a hardware failure has caused the
interlock units to become inconsistent between the M-bus interlaces of the modules. As a result, the interface should assert its MABORT signal. Similarly, if a M-bus interlace obseives a write-unlock transaction
for an address it does not consider interlocked, it should also assert its MABORT signal. Modules that
never act as M-bus masters need not implement the interlock unit and corresponding checking logic.
During memory-space transactions, all caches probe their tag store to determine whether or not the octaword is present in their cache. If a parity error is detected in the tag for the specified octaword, the cache
probe cannot be completed. When such a tag-parity error occurs, the module must assert its MABORT signal.
Once a module asserts its MABORT signal, it must remain asserted for eight cycles to ensure the current
M-bus transaction has been completed and that all M-bus interlaces have returned to the idle state. The
current M-bus master and/or M-bus slave should abort the transaction as soon as practical. At the end of
the current transaction, a workstation-wide machine check should be initiated. Inherent pipelining of the
M-bus may result in some errors not being detected until the cycle after the one in which the transaction
was completed on the M-bus.
Lack of slave response is immediately indicated during fY7 of memory-space read transactions, during P4 of
1/0-space transactions, and during P4 of interrupt-acknowledge transactions, because none of the MBRQ
signals are asserted. 'Ibis results in immediate termination of the M-bus transaction. Modules must not
assert MABORT in this situation; instead, the M-bus interlace of the M-bus master should indicate an error
to its internal logic, and the M-bus should immediately return to the idle state.
M-bus interlaces must clear their interlocked-sequence-in-progress flags whenever MABORT is asserted
on the M=bus, as part of returning to an idle state. The state of the interlocked-sequence-in-progress flags
is unchanged by cycles that terminate because of no slave response. Read interlocked transactions must
only be issued at addresses to which a slave is known to respond, as the interlock flag is set as soon as the
M-bus master acquires the M-bus.
4.4.4. Clock Distribution

The MCLKA and MCLKB signals are the master clocks for all of the M-bus interface logic. The MCLKI
signal functions as an interval-timer interrupt.

18 Firefox. System Specification

December 29, 1987

Firefox. M-Bus Specification 4.4.4. l.

DIGITAL EQuIPME.VI' CORPORATION -RESTRICTED DISTRIBL'TION

4.4.4.1. MCLKA

MCLKA is the master clock for the M-bus. All signal transitions and M-bus-interface state machines are
referenced to MCLKA. The M-bus cycles, Pn, are defined by the rising edge of MCLKA. M-bus signals
transition after the rising edge of MCLKA; that is, MCLKA should be used to clock registers and enable
latches driving the M-bus. MCLKA is radially distributed to each module to minimize skew between
modules.
4.4.4.2. MCLKB

MCLKB is the slave clock for the M-bus. M-bus receiver registers and latches should be clocked by
MCLKB. MCLKB will be positioned with respect to MCLKA to meet receiver hold-time requirements in
the presence of clock skew. MCLKB is radially distributed to each module to minimize skew between
modules.
4.4.4.3. MCLKI

The MCLKI signal is a 100-Hz square wave for use as an interval-clock interrupt. Transitions of the
MCLIG signal are asynchronous with respect to the M-bus clocks. Multiple modules may have circuitry to
generate the MCLKI signal. Consequently, modules that do implement MCLKI circuitry must default to
not driving the signal until enabled by software. This implies that no modules drive the MCLKI signal after
workstation reset (MRESET asserted). Software must enable driving MCLKI on one of the modules
before processors receive interval clock interrupts

4.5. Transactions
There are five categories of M-bus transactions:
•

Memory read

•

Memory write

•

I/0 read

•

I/O write

•

Interrupt acknowledge

Memory-space operations transfer data between two or more modules and maintain data consistency
between all caches. Memory-space transactions always transfer four longwords (one cache line) between
modules. When a memory-space read or write-through transaction is initiated, all modules probe their
cache to determine whether or not the line is shared. For memory-space reads, a cache supplies the read
data for shared dirty lines, and a memory module supplies read data for unshared lines or shared clean
lines. For memory-space write-throughs, the memory module, as well as all caches that contain the line,
update the line. For memory-space victim writes, only the memory module updates the line.
I/0-space transactions transfer data between exactly two modules. I/0-space transactions transfer one
masked)q11gword between modules. I/0-space data is never cached.
Interrupt-acknowledge tramactions transfer one interrupt vector between exactly two modules.
Figure 4-3 shows the M-bus states for the various phases of transactions. The MR phase prefix stands for
memory read. The MW phase prefix stands for memory write. The IR phase prefix stands for 110 read. The
IW phase prefix stands for 110 write. The IA phase prefix stands for interrupt acknowledge. The AnyArb
and Wait terms represent derived signals within M-bus interface logic. For the I/0 read and write states, no
slave resporne termination of the transaction is implicit in the !Wait term which contains AnyArb.

4.5. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 19

DIGIT AL EQUIPMENT CORPORATION - RESTRICTED DISTRIBUTION

Table 4-19:

M-Bus State Diagram

MRESET OR MABORT

e
I

Any Arb

=MBRM«>> OR ... OR MBRM<6> OR MBRQ

Wait= Any Arb AND (MSTAT =WAIT)

'¥
Pl

20 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.5.l.

DIGITAL EQUIPME."'-'T CORPORATION -RESTRICTED DISTRIBUTION

4.5.1. Transaction Notation

The following sections contain sample M-bus transactions in the format shown in Table 4-20 cycle column
lists the sequential transaction phase, for example, P3. The MBRQ column lists the module asserting its
~RQ signal, with arbitration assertions in parentheses. The MCMD column lists the cycle-type code
present on the MCMD signals. The MSTAT column lists the cycle-status code present on the MSTAT signals. The MDAL column indicates the interpretation of the value present on the MDAL signals. The function column describes the operation that occurs during the cycle.
Table 4-20:

Cycle
Pn

M-Bus Cycle Nomenclature

MBRQ
WHO

MCMD
OP/MASK

MSTAT
STATUS

MDAL
VALUE

Function
WHAT

4.5.2. Memory-Space Reads

Table 4-21 shows the cycles that compose a memory-space read transaction. During cycle Pl, the initiating
module arbitrates for the M-bus. During cycle P2, the M-bus master indicates the type of transaction and
the read address. The octaword address is specified on MDAL<30:4>; MDAL<31> and MDAL<3:0> must
be 0. During cycles P3 through P6, the master waits for a slave to respond. A memory module or cache
transmits read data dunng cycles P7 through PlO.
Tabla 4-21:

Cycle
Pl
P2
P3
P4
PS
P6
P7
pg
P9

M-Bus Memory-Read Transaction

MBRQ

MCMD

MST AT

MDAL

(M)

M
M
M
M

READ

Address

(S)

s
s
s

PlO

GOOD
GOOD
GOOD
GOOD

DataO
Data 1
Data2
Data 3

Function
Bus arbitration
Read address
Wait
Wait
Wait
Wait
First longword
Second longword
Third longword
Fourth longword

The M-bus cycles P3 through P6 provide dynamic RAM-access time for memory modules. Memory
modules must not provide read data before cycle P7. Memory modules requiring more RAM-access time
may insert additional WAIT cycles after cycle P6. Starting in cycle P7, memory modules must either
specify WAIT or read data.
During a memory-space read transaction, all caches in Firefox workstations have M-bus cycles P3 through
PS to complete a probe of their tag store. If a cache hit to a dirty line results, the modules' M-bus interface
asserts its ~RQ signal during cycle P6 and drives the "MBRQ, MSTAT, and MDAL signals during cycles
P7 through PlO. This applies only to shared dirty cache lines; memory modules supply data for shared
clean lines.
There are two types of memory-read transactions, READ and READU. Both transactions have the same
format, require cache modules to probe their tag store, assert the MSHARED signal if a hit results, and
supply data if a hit to a dirty line results. If no cache arbitrates to supply read data, then the selected
memory module supplies read data. After a READ transaction, tag stores with hits set their SHARED bit.
After a READU transaction, tag stores do not modify their SHARED bit.
The READ transaction must be used by processor modules and I/0 modules that require a coherent
memory-space. 1/0 module that do not need require write-through updates of previously read data should

4.5.2. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 21

DIGITAL EQUIPME.l'IIT CORPORATION - RESTRICTED DISTRIBUTION

use READU. This allows such I/O modules to read communication blocks cached in processor modules
without the processor modules incurring the ovetbead of unnecessary write-throughs.

If a memory module detects any :MBRQ signal asserted during cycle P6, it aborts its read cycle.
When modules present read data on the MDAL signals, the MSTAT signals specify either GOOD, indicating that no data errors occurred, or CORRECTED, indicating that a single-bit error was detected and
corrected. If the module detects a parity error or double-bit ECC error it asserts 1vIDATINV while driving
that longword onto MDAL. If memory modules implement ECC on words wider than 32 bits, they may
specify CORRECTED for each longword transfer of memory words whether or not that longword is the
one that actually contains the corrected single-bit error. Table 4-22 shows an example of a memory read of
corrected data.
Table 4-22:

Cycle
Pl
P2
P3
P4
PS
P6
P7

P8
P9
PlO

Memory-Read Transaction with Corrected Data

MBRQ

MCMD

MST AT

MDAL

(M)

M
M
M
M

READ

s
s
s

Address

GOOD
GOOD
CORRECTED
CORRECTED

Data 0
Data 1
Data2
Data3

Function
Bus arbitration
Read address
Wait
Wait
Wait
Wait
First longword
Second longword
Third longword
Fourth longword

Once the first longword of data is supplied, no additional slave wait cycles are allowed. The four longwords of data must be transferred in four consecutive M-bus cycles. M-bus-interface logic must interpret
additional WAIT status as ERROR status.
Whenever a M-bus interface detects CORRECTED status in response to a memory-space read, it should
generate an interrupt to its local processor.
4.5.3. Memory-Space Writes

Table 4-23 shows the cycles that compose a memory-space write transaction. During cycle Pl, the initiating module arbitrates for the M-bus. During cycle P2, the M-bus master indicates the type of transaction
and the write address. The octaword address is specified on MDAL<30:4>; MDAL<31> and MDAL<3:0>
must be 0. During cycles P3 through P6, the M-bus master transfers write data.
Table 4-23:

Cycle
Pl
P2
P3
P4
PS
P6

M-bus Memory-Write Transaction

~BRQ

MCMD

MSTAT

MDAL

Function

Address
DataO
Data 1
Data2
Data3

Bus arbitration
Write address
First longword
Second longword
Third longword
Fourth longword

. (M)
M
M
M
M

WRITE
MASK
MASK
MASK
MASK

During each M-bus cycle in which a master transfers write data on MDAL, MCMD functions as a byte
mask. If MCMD<n> is asserted, then the corresponding byte of MDAL must be written into a shared
cache line. If MCMD<n> is deasserted, then the corresponding byte of MDAL should not be written into a
shared cache line.

22 Firefox. System Specification

December 29, 1987

Firefox. M-Bus Specification 4.5.3.

DIGITAL EQUIPME.1'.il' CORPORATION - RESTRICTED DISTRIBUTION

Memory modules always write the entire octaword, regard.Jess of the byte mask. This implies that memory
modules have invalid contents for shared dirty lines until the victim write occurs. However, since caches
supply read data for M-bus reads of shared dirty lines, the memory module value is irrelevant.
If any byte of a longword has an internal module-parity error, the module must assert MDATINV while it
drives the longword containing that byte onto MDAL. Modules that write the invalid data into their internal storage must store an indication that the data is invalid along with the data. For example, memory
modules force a bad check-bit-field for the affected memory address; caches force bad parity for the
affected byte.

During a memory-space write transaction, all caches in Firefox workstations have M-bus cycles P3 through
PS to complete a probe of their tag store. If a cache detects a hit, it must assert MSHARED during cycle
P6.
Memory modules or caches that are referenced by the memory address assert their MBRQ signal during
P6. The M-bus master should treat the lack of any MBRQ as a no-slave response. Memory modules or
caches that require more cycles to complete the write transaction may assert MBUSY to stall subsequent
transactions.
4.5.4. 1/0-Space Reads

I/0-space read transactions adhere to the same M-bus protocol as memory-space read transactions except
that I/0-space references are uncached and transfer at most one longword of data. Consequently, caches
need not :11critcr I/0 spJ::::e t~ansactions. Sin~ ~a..:hcs are not L.'1volvcd, the mJ.nJatory -wait .:y.:le~ have
been eliminated. Table 4-24 shows an I/0-read transaction.
Table 4-24:

Cycle
Pl
P2
P3
P4

M-Bus 1/0-Read Transaction

MBRQ

MCMD

MST AT

MDAL

(M)

M
M

READ
MASK

Address
GOOD

Data

Function
Bus arbitration
Read address
Byte mask
Readdata

During cycle Pl, the initiating module arbitrates for the M-bus. During cycle P2, the M-bus master indicates the type of transaction and the read address. The longword address is specified on :MDAL<30:2>;
MDAL<31 > must be 1; :MDAL<l :0> is undefined. During cycle P3, the M-bus master specifies the byte
mask for the longword address.
The M-bus slave may stall the return of read data, starting in cycle P4, by specifying WAIT on MSTAT.
Most I/0 devices will require several WAIT cycles.
If the M-bus slave specifies GOOD status, the M-bus transaction terminates and the M-bus master returns
the read data to its internal logic.
If the M-bus slave specifies RETRY status, the M-bus transaction terminates and the M-bus master
instructS its internal logic to retry the transaction at a later time.
If the M-bus slave specifies ERROR status, the M-bus transaction terminates and the M-bus master informs
its internal logic that the read failed. The M-bus interface of the master should implement a status register
that allows internal logic to determine whether no slave responded or a slave responded with an error.

4.5.5. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 23

DIGITAL EQUIPME..'\j"T CORPORATIO!'i - RESTRlCTED DISTRJBL'TIO:--;

4.5.5. 1/0-Space Writes

I/0-space write transactions adhere to the same M-bus protocol as memory-space write transactions except
that l/0-space references are uncached and transfer at most one longword of data. Consequently, caches
need not monitor l/0-space transactions. Since caches are not involved, the mandatory wait cycles have
been eliminated. Table 4-25 shows an I/0-write transaction.
Table 4-25:

Cycle
Pl
P2
P3
P4

M-bus 1/0-Wrlte Transaction

MBRQ

MCMD

MSTAT

MDAL

Function

Address
Data

Bus arbitration
Write address
Write data
Write completed

(M)

M
M

WRITE
MASK
GOOD

During cycle Pl, the initiating module arbitrates for the M-bus. During cycle P2, the M-bus master indicates the type of transaction and the write address. The longword address is specified on MDAL<30:2>;
MDAL<31> must be 1; MDAL<l:O> is undefined. During cycle P3, the M-bus master specifies the byte
mask.for the longword address and the write data.
The M-bus slave may stall the completion of the write transaction starting in cycle P4 by specifying WAIT
on MST AT. Most 1/0 devices will require several WAIT cycles.
If the M-bus slave specifies GOOD status, the M-bus transaction terminates and the M-bus master indicates
successful completion of the write to its internal logic.
If the M-bus slave specifies RETRY status, the M-bus transaction terminates and the M-bus master
instructs its internal logic to retry the transaction at a later time.
If the M-bus slave specifies ERROR status, the. M-bus transaction terminates and the M-bus master informs
its internal logic that the write failed. The M-bus interface of the master should implement a status register
that allows internal logic to determine whether no slave responded or a slave responded with an error.
4.5.6. Interlocked Transactions

Interlocked transactions are initiated by an interlocked-read transaction. Interlocked-read transactions are
identical to normal read transactions except that they also record the interlocked address and set the
interlocked-sequence-in-progress flag in one of the two interlock-unit slots. Write-unlock transactions are
identical to normal write transactions except that they also deassert the interlocked-sequence-in-progress
flag for the locked address.
When a processor generates an interlocked read, its cache must force a miss. 1bis guarantees that the interlocked read generates a M-bus transaction. If a processor requests an interlocked-read transaction of its
M-bus interface, and that address is locked or the interlock unit is full, the processor must be stalled until
the ad~§ is unlocked.
Regardless of the state of the interlocked-sequence-in-progress flags, noninterlocked M-bus transactions
proceed. In other words, the interlock unit only blocks interlocked-read transactions from arbitrating for
the M-bus until the write-unlock transaction for the interlocked address is completed.
Assertion of MABORT unconditionally clears the interlocked-sequence-in-progress flags.
Refer to the sections discussing memory-space transactions for detailed descriptions of the M-bus protocol.

24 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.5.7.

DIGITAL EQUIPMli.°"11 CORPORATION - RESTRICTED DISTRIBlffION

4.5.7. Interrupt-Acknowledge Transactions

An interrupt-acknowledge transaction follows the same protocol as a memory space read transaction. In
place of a read address, the M-bus master provides an interrupt level. All modules with a pending interrupt
at that level assert their M-bus-arbitration request (MBRQ) signal dwing cycle P4. The module with the
highest M-bus priority supplies an interrupt vector during cycle P5. The highest-priority module may
insert additional WAIT cycles before providing the vector. Most I/O devices will require multiple W AlT
cycles to produce a vector. Lower-priority modules abort the transaction after cycle P4. Table 4-26 shows
an example of an interrupt-acknowledge transaction.
Table 4-26:

Cycle
Pl
P2
P3
P4
P5

M-Bus Interrupt-Acknowledge Transaction

MBRQ

MCMD

MST AT

MDAL

(M)

M
M
(S)

!~!ACK

Level

GOOD

Vector

Function
Bus arbitration
Interrupt level
Wait
Slave arbitration
Intermpt vector

During cycle Pl, the initiating module arbitrates for the M-bus. During cycle P2, the M-bus master indicates the tvpe of transaction and the interrupt level The intermpt level is c;pecified on MDAL<6:2>:
MDAL<31 > must be 1; MDAL<30:7> and .MDAL< 1:0> are undefined
If no .MBRQ signals are asserted during cycle P4, indicating that no M-bus interfaces are arbitrating to provide an interrupt vector, the M-bus interface of the M-bus master should initiate passive-release processing
( passive release means that software is uninterrupted). If multiple processors simultaneously initiate an
interrupt-acknowledge transaction, the highest-priority processor receives the interrupt vector, and all other
processors receive passive releases. This allows an interrupt level to be serviced by multiple processors.
If the M-bus slave specifies GOOD status, the M-bus transaction terminates and the M-bus master returns
the intenupt vector to its internal logic. The interrupt vector is encoded on MDAL<15:0>; MDAL<31:16>
is undefined.
If the M-bus slave specifies RETRY status, the M-bus transaction terminates and the M-bus master
instructs its internal logic to retry the transaction at a later time.
If the M-bus slave specifies ERROR status, the M-bus transaction tenninates and the M-bus master informs
its internal logic that the interrupt acknowledge failed. This is equivalent to a no-slave-response passive
release.

4.6. Example Transactions
The following sections show sample memory, I/0, and interrupt-acknowledge transactions.
All signals in pictorial diagrams are shown with active-high assertion state for clarity. This may not
correspond to the assertion state on the backplane.

4.6. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 25

DIGITAL EQUIPME.°'i CORPORATION -RESTRICTED DISTRIBlffION

4.6.1. Memory Read to Unshared Line

Figure 4-3 shows a no-wait-state memory read for an unshared cache line with two modules arbitrating for
the M-bus.
PO

Pl I P2 I P3

I P4

I PS

P6 I P7

I P8

I P9

I PlOI Plll

MBRQl
MBRQ3
MBRQ6
MCMD

----------<Read>---------------------------------------------

MDAL

----------<Addr>-------------------<DataXDataXDataXData>-----

MSTAT

-----------------------------------<GoodXGoodXGoodXGood>-----

MS HARED
MDATINV
MBUSY

Figure 4-3:

Memory Read Transaction to Unshared Line

The M-bus is idle.

The modules in slots 1 and 6 arbitrate for the M-bus.

Slot 1 has higher priority, wins the M-bus arbitration, and continues to assert its MBRQ signal to
confirm this, at the same time that it drives MC:MD with READ and MDAL with the memory
address. Slot 6 deasserts its MBRQ, since it lost the M-bus arbitration.

Modules monitoring the M-bus transaction start decoding the address.

Modules monitoring the M-bus transaction continue setvicing the request.

~qdules monitoring the M-bus transaction continue setvicing the request.

No caches contain the referenced line, so MSHARED remains deasserted.

The memory module in slot 3 contains the referenced line. It asserts its MBRQ, indicates good data,
and supplies the first longword.

Slot 3 supplies the second longword.

Slot 3 supplies the third longword.

Pl 0 Slot 3 supplies the fourth longword, ending the transaction.

26 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6. l.

DIGITAL EQUIPME..Vf CORPORATION - RESTRICTED DISTRIBUTION

Pll

Slot 6 rearbitrates for its pending transaction. This is the earliest cycle that a new transaction may
start.

4.6. l. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 27

DIGITAL EQUIPMENT CORPORATION -RESTRICTED DISTRIBUTION

4.6.2. Memory Read to Shared Clean Line

Figure 4-4 shows a memory read for a shared. clean cache line.
I PO

Pl I P2

I P3 I P4 I PS

I P7 I PB I P9 I PlO I Pll I

MBRQ2
MBRQ4
MBRQ7
MCMD

----------<Read>---------------------------------------------

MDAL

----------<Addr>-------------------<DataXDataXDataXData>-----

MS TAT

-----------------------------------<GoodXGoodXGoodXGood>-----

MS HARED

MD AT INV

MBUSY

Figure 4-4:

Memory Read Transaction to Shared Clean Line

The M-bus is idle.

The module in slot 2 arbitrates for the M-bus.

Slot 2 asserts its l\IBRQ signal to confirm that it won the M-bus. It also drives MC:MD with READ
and MDAL with the memory address.

Modules monitoring the M-bus transaction start decoding the address.

Modules monitoring the M-bus transaction continue seIVicing the request.

Modules monitoring the M-bus transaction continue servicing the request.

The cache of the module in slot 7 contains the referenced line, which is unmodified, so it asserts
MSllARED, but leaves its MBRQ signal deasserted.

The memory module in slot 4 supplies the first longword.

Slot 4 supplies the second longword.

P 19 Slot 4 supplies the third longword.
P 10 Slot 4 supplies the fourth longword, ending the transaction.

28 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.2.

DIGITAL EQUIPME..Vf CORPORATION - RESTRICTED DISTRIBlTfION

Pl 1 There are no pending transactions, so the M-bus remains idle.

4.6.2. Firefox. M-Bus Specification

December 29, 1987

Firefox. System Specification 29

DIGITAL EQUIPME.J."IT CORPORATION -RESTRICTED DISTRIBl.iTION

4.6.3. Memory Read to Shared Dirty Line

Figure 4-5 shows a memory read for a shared, dirty cache line.
I PO

Pl I P2 I P3 I P4 I PS

P6 I P7 I P8 I P9 I PlOI Plli Pl21

MBRQ2
MBRQ4
MBRQ7
MCMD

----------<Read>--------------------------------------------------

MDAL

----------<Addr>-------------------<UndfXDataXDataXDataXData>-----

MST AT

-----------------------------------<WaitXGoodXGoodXGoodXGood>-----

MS HARED
MDATINV

MBUSY

Figure ~5:

Memory Read Transaction to Shared Dirty Line

The M-bus is idle.

The module in slot 2 arbitrates for the M-bus.

Slot 2 asserts its MBRQ signal to confirm that it won the M-bus. It also drives MCMD with READ
and MDAL with the memory address.

Modules monitoring the M-bus transaction start decoding the address.

Modules monitoring the M-bus transaction continue servicing the request.

The cache of the module in slot 7 contains the referenced line, which has been modified, so it asserts
bQth MSHARED and its :MBRQ signal.

Slot 7 continues to assert its :MBRQ and indicates wait status. The selected memory module in slot 4
aborts its read operation.

Slot 7 supplies the first longword.

Slot 7 supplies the second longword.

P 10 Slot 7 supplies the third longword.

30 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.3.

DIGITAL EQUIPME.Vf CORPORATION - RESTRICTED DISTRIBlJTION

Pl 1 Slot 7 supplies the fourth longword, ending the transaction.
P12

There are no pending transactions, so the M-bus remains id.le.

4.6.3. Firefox M-Bus Specification

December 29. 1987

Firefox System Specification 31

DIGITAL EQUIPMENT CORPORATION - RESTRICTED DISTRIBUTION

4.6.4. Memory Read with Uncorrectable ECC Error

Figure 4-6 shows a no-wait-state memory read for an unshared cache line with an uncorrectable ECC error
in the second quadword.
I PO

Pl I P2 I P3

I P4 I PS

P6 I P7

I P8 I P9 I PlO I Pll I

MBRQl
MBRQ3
MCMD

----------<Read>---------------------------------------------

MDAL

----------<Addr>-------------------<DataXDataXDataXData>-----

MS TAT

-----------------------------------<GoodXGoodXGoodXGood>-----

MS HARED
MBUSY
MDATINV

Figure 4-6:

Memory Read Transaction with Uncorrectable ECC Error

The M-bus is idle.

The module in slot 1 arbitrates for the M-bus.

Slot 1 wins the M-bus arbitration and continues to assert its MBRQ signal to confinn this, at the same
time that it drives MCMD with READ and MDAL with the memory address.

Modules monitoring the M-bus transaction start decoding the address.

Modules monitoring the M-bus transaction continue servicing the request.

No caches contain the referenced line, so MS HARED remains de asserted.

fY7

nie-memory module in slot 3 contains the referenced line. It asserts its MBRQ, indicates good data,
and supplies the first longword.

Slot 3 supplies the second longword.

Slot 3 supplies the third longword, and it asserts MDATINV to indicate that the data is known to
have an error.

PIO

Slot 3 supplies the fourth longword, and it asserts MDATINV to indicate that the data is known to
have an error.

32 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.4.

DIGITAL EQUIPME."1 CORPORATION - RESTRICTED DISTRIBUTIO~

Pl 1 This is the earliest cycle that a new transaction may start.

4.6.4. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 33

DIGITAL EQUIPME..Vf CORPORATION - RESTRICTED DISTRIBUTION

4.6.5. Memory Read to Non-Existent Memory

Figure 4-7 shows a memory read to a non-existent memory-space address.
I PO

Pl I P2

I P3 I P4 I PS

I P7 I PS I

MBRQl
MBRQ3
MBRQ6
MCMD

----------<Read>------------------------------

MDAL

----------<Addr>------------------------------

MS TAT
MS HARED
MDATINV
MBUSY

Figure 4-7:

Memory-Read Transaction with No Slave Response

The M-bus is idle.

The modules in slots 1 and 6 arbitrate for the M-bus.

Slot 1 has higher priority, wins the M-bus arbitration, and continues to assert its MBRQ signal to
confirm this, at the same time that it drives MC:MD with READ and :MDAL with the memory
address. Slot 6 deasserts its MBRQ, since it lost the M-bus arbitration.

Modules monitoring the M-bus transaction start decoding the address.

Modules monitoring the M-bus transaction continue servicing the request.

No caches contain the referenced line, so MSHARED remains deasserted.

No memory module contains the referenced line, so all the MBRQ signals remain deasserted. This is
the last cycle of the transaction.

Slot 6 rearbitrates for its pending transaction. This is the first possible cycle for a new transaction.

34 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.5.

DIGIT AL EQUIPMENT CORPORATION - RESTRICTED DISTRIBUTION

4.6.6. Victim Write

Figure 4-8 shows a victim write to flush out a dirty cache line.

MBRQ2
MBRQ4
MBRQ6
MCMD

----------<WritXUndfXUndfXUndfXUndf>----------

MDAL

----------<AddrXDataXDataXDataXData>----------

MS TAT
MS HARED
MD AT INV
MBUSY

Figure 4-8:

Victim Write Transaction

The M-bus is idle.

The modules in slots 4 and 6 arbitrate for the M-bus.

Slot 4 wins the arbitration and asserts its :MBRQ signal to confirm that it won the M-bus. It also
drives MCMD with WRITE and MDAL with the memory address.

Slot 4 drives MDAL with the first longword.

Slot 4 drives MDAL with the second longword.

Slot 4 drives MDAL with the third longword.

31~4 drives MDAL with the fourth longword. The memory module in slot 2 asserts :MBRQ to indi-

cate that it is the slave.
P7

The memory module in slot 2 asserts :MBUSY while it complete the write. The module in slot 6
rearbitrates for the M-bus.

The memory module has completed the memory write, so it deasserts :MBUSY. Since .MBUSY was
asserted in P7, the module in slot 6 continues to rearbitrate for the M-bus.

4.6.6. Firefox. M-Bus Specification

December 29, 1987

Firefox. System Specification 35

DIGITAL EQUIPMENT CORPORATION -RESTRICTED DISTRIBCTION

4.6.7. Victim Write with Internal Parity Error

Figure 4-9 shows a memory victim write to flush out a dirty cache line that has a parity error in the second
longword.
I PO I Pl I P2 I P3 I P4 I PS I P6 I P7 I P8 I
MBRQ2
MBRQ4
MBRQ6
MCMD

----------<WritXUndfXUndfXUndfXUndf>----------

MDAL

----------<AddrXDataXDataXDataXData>----------

MS TAT

MS HARED

MBUSY
MDATINV

Figure 4-9:

Victim Write Transaction with Internal Parity Error

The M-bus is idle.

The modules in slots 4 and 6 arbitrate for the M-bus.

Slot 4 wins the arbitration and asserts its MBRQ signal to confirm that it won the M-bus. It also
drives MCMD with WRITE and l\IDAL with the memory address.

Slot 4 drives l\IDAL with the first longword.

Slot 4 drives l\IDAL with the second longword and asserts l\IDATINV to indicate that an internal
parity error was detected on the data.

Sl9t_4 drives l\IDAL with the third longword.

Slot 4 drives :MDAL with the fourth longword. The memory module in slot 2 asserts :MBRQ to indicate that it is the slave.

The memory module in slot 2 asserts :MBUSY while it complete the write. The module in slot 6
rearbitrates for the M-bus.

The memory module has completed the memory write, so it deasserts :MBUSY. Since :MBUSY was
asserted in P7, the module in slot 6 continues to rearbitrate for the M-bus.

36 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.7.

DIGITAL EQUIPMENT CORPORATION -RESTRICTED DISTRIBL"TIOZ'i

4.6.8. Write-Through tO Unshared Line

Figure 4-10 shows a memory write-through for a cache line that was shared but has become unshared. The
memory address references a memory module in slot 2.

MBRQ2
MBRQ4
MBRQ6

MCMD

----------<WritXMaskXMaskXMaskXMask>-----

MDAL

----------<AddrXDataXDataXDataXData>-----

MS TAT
MS HARED

MDAT IN\/

MBUSY

Figure 4-10:

Write-Through Transaction to Unshared Line

The M-bus is idle.

The modules in slots 4 and 6 arbitrate for the M-bus.

Slot 4 wins the arbitration and asserts its MBRQ signal to confirm that it won the M-bus. It also
drives MCMD with WRITE and MDAL with the memory address.

Slot 4 drives MCMD and MDAL with a byte mask and the first longword.

Slot 4 drives MC:MD and MDAL with a byte mask and the second longword.

Slot 4 drives MCMD and MDAL with a byte mm and the third longword.

Slot 4 drives MCMD and MDAL with a byte mask and the fourth longword. The referenced line was
not in any other cache, so MSHARED remaim deasserted. The memory module in slot 2 asserts
MBRQ to indicate that it is the slave.

The memory module in slot 2 has completed the write transaction, so it does not assert :MBUSY.
The module m slot 6 rearbitrates for the M-bus.

4.6.8. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 37

DIGITAL EQUIPMENT CORPORATION - RESTRICTED DISTRIBlJTION

4.6.9. Write-Through to Shared Line

Figure 4-11 shows a memory write-through for a shared cache line.
I PO I Pl I P2 I P3 I P4 I PS I P6 I P7 I PS I P9 I
MBRQ2
MBRQ3
MBRQ4
MBRQ6
MCMD

----------<WritXMaskXMaskXMaskXMask>---------------

MDAL

----------<AddrXDataXDataXDataXData>---------------

MS TAT

MS HARED
MDATINV

MBUSY

Figure 4-11:

Write-Through Transaction to Shared Line

The M-bus is idle.

The modules in slots 4 and 6 arbitrate for the M-bus.

Slot 4 wins the arbitration and asserts its J\.ffiRQ signal to confirm that it won the M-bus. It also
drives MCMD with WRITE and :MDAL with the memory address.

Slot 4 drives MC:MD and :MDAL with a byte mask and the first longword.

Slot 4 drives MC:MD and MDAL with a byte mask and the second longword.

Sl.ot.4 drives MC:MD and MDAL with a byte mask and the third longword.

Slot 4 drives MCMD and MDAL with a byte mask and the fourth longword. The referenced line is in
another cache in slot 3, which asserts both MSHARED and J\.ffiRQ. The memory module in slot 2
asserts :MBRQ to indicate that it is the slave.

The memory module in slot 2 has completed the write transaction so it does not assert J\.ffiUSY. The
cache is not finished with the write-through, so it asserts J\.ffiUSY. The module in slot 6 rearbitrates
for the M-bus.

The cache is not finished with the write-through, so it continues to assert :MBUSY. The module in
slot 6 continues to rearbitrate for the M-bus, since :MBUSY was asserted in P7.

38 Firefox. System Specification

December 29, 1987

Firefox. M-Bus Specification 4.6.9.

DIGIT AL EQUn>M8'.'T CORPORATION - RESTRICTED DISTRIBl7fION

The cache bas completed the write through so it deasserts !vIBUSY. The module in slot 6 continues
rearbitrates for the M-bus since MBUSY was asserted in P8.

4.6.9. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 39

DIGITAL EQCil'MENT CORPORATION - RESTRICTED DISTRIBUTION

4.6.10. Victim Write w1th Address Parity Error

Figure 4-12 shows a memory victim write with a .MDAL parity error during P2.
I PO

Pl I P2 I P3 I P4 I ..

I Plll P121

MBRQ4
MCMD

----------<WritXUndfXUndfXM .. ------------

MDAL

----------<AddrXDataXDataXD .. ------------

MS TAT

MABORT
MS HARED

MDATINV

MBUSY

Figure 4-12:

Victim Write Transaction with Address Parity Error

The M-bus is idle.

The module in slot 4 arbitrates for the M-bus.

Slot 4 asserts its :MBRQ signal to confirm that it won the M-bus. It also drives MC.MD with WRITE
and MDAL with the memory address.

A slot detected a parity error on the value ofMDAL/.MDPAR on the M-bus during cycle P2.

Slot 4 drives MDAL with the second longword. The slot that detected the parity error asserts
MABORT.

PS-PlO M-bus interfaces return to idle state.
Pl 1

The module that detected the error continues to assert MABORT. All M-bus interfaces should ini..tl'ate a machine check of their internal logic.

P12

MAB ORT is deasserted after eight cycles.

40 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.10.

DIGITAL EQUIPMENT CORPORATION - RESTRICTED DISTRIBL'TION

4.6.11. 1/0 Read

Figure 4-13 shows an 1/0 read.
I PO I Pl I P2 I P3

P4 I PS I P6

P7 I

MBRQO
MBRQl
MBRQ4
MCMD

----------<ReadXMask>--------------------

MDAL

----------<Addr>--------------<Data>-----

MS TAT

--------------------<WaitXWaitXGood>-----

MS HARED

MDATINV

MBUSY

Figure 4-13:

1/0-Read Transaction

The M-bus is idle.

The modules in slots 1 and 4 arbitrate for the M-bus.

Slot 1 wins the arbitration and asserts its :MBRQ signal to confirm that it won the M-bus. It also
drives MCMD with READ and MDAL with the 1/0 address.

Modules decode the I/0 address. Slot 1 specifies the byte mask on MCMD.

Slot 0 asserts its MBRQ to indicate that it is processing the I/0 read, but it specifies WAIT on
MST AT, since data is not yet available.

Slot 0 asserts its MBRQ to indicate that it is processing the l/O read, but it specifies WAIT on
M.STAT, since data is not yet available.

Slot 0 drives read data onto :MDAL and specifies GOOD on MSTAT to complete the transaction.

Slot 4 rearbitrates for its pending transaction. This is the first possible cycle for a new transaction.

4.6.11. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 41

DIGIT AL EQUIPMENT CORPORATION - RESTRICTED DISTRIBUTION

4.6.12. 1/0 Read with No Slave Response

Figure 4-14 shows an 1/0 read.
I PO

Pl I P2

I P3

P4 I PS

MBRQl
MBRQ4
MCMD

----------<ReadXMask>----------

MDAL

----------<Addr>---------------

MST AT
MS HARED
MDATINV
MBUSY

Figure 4-14:

1/0-Read Transaction with No Slave Response

The M-bus is idle.

The modules in slots 1 and 4 arbitrate for the M-bus.

Slot 1 wins the arbitration and asserts its l\IBRQ signal to confirm it won the M-bus. It also drives
MCMD with READ and MDAL with the 1/0 address.

Modules decode the 1/0 address. Slot 1 specifies the byte mask on MCMD.

The address referenced non-existent 1/0, so no slaves responded. The M-bus master's M-bus inter-

face should indicate an error to its internal logic. This is the last cycle of the transaction.
P5

Slot 4 rearbitrates for its pending transaction. This is the first possible cycle for a new transaction.

42 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.12.

DIGITAL EQUIPMENT CORPORATION -RESTRICTED DISTRIBL!ION

4.6.13. 1/0 Write

Figure 4-15 shows an I/0 write.
I PO I Pl I P2 I P3

P4 I PS

P6 I

MBRQO
MBRQ2
MBRQS
MCMD

----------<WritXMask>---------------

MDAL

----------<AddrXData>---------------

MST AT

--------------------<WaitXGood>-----

MS HARED

MDATINV

MBUSY

Figure 4-15:

1/0-Wrlte Transaction

The M-bus is idle.

The module in slot 2 arbitrates for the M-bus.

Slot 2 asserts its MBRQ signal to confirm it won the M-bus. It also drives MCMD with WRITE and
l\IDAL with the I/0 address.

Modules decode the I/0 address. Slot 2 specifies the byte mask on MCMD and supplies data on
l\IDAL.

Slot 0 asserts its MBRQ to indicate it is processing the I/0 write, but it specifies WAIT on MSTAT,
since the write has not been completed.

Slpt_O continues to assert its MBRQ and specifies GOOD on MSTAT to complete the transaction.

Slot 5 rearbitrates for a pending transaction. This is the first possible cycle for a new transaction.

4.6.13. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 43

DIGITAL EQUIPMENT CORPORATION - RESTRICTED DISTRlB'CTION

4.6.14. 1/0 Write with No Slave Response

Figure 4-16 shows an I/0 write with no slave response.
I PO I Pl I P2 I P3 I P4 I PS I
MBRQO
MBRQ2
MBRQS
MCMD

----------<WritXMask>----------

MDAL

----------<AddrXData>----------

MS TAT

MS HARED
MDATINV
MBUSY

Figure 4-16:

1/0 Write Transaction with No Slave Response

The M-bus is idle.

The module in slot 2 arbitrates for the M-bus.

Slot 2 asserts its MBRQ signal to confirm it won the M-bus. It also drives MCMD with WRITE and
MDAL with the I/0 address.

Modules decode the 1/0 address. Slot 2 specifies the byte mask on MCMD and supplies data on
MDAL.

No module was referenced by the I/O address, so all the MBRQ signals remain deasserted. This is
the last cycle of the transaction.

~l.<lt_5 rearbitrates for a pending transaction.

44 Firefox System Specification

This is the first possible cycle for a new transaction.

December 29, 1987

Firefox M-Bus Specification 4.6.14.

DIGITAL EQUIPME.~'T CORPORATION - RESTRICTED DISTRIBl.JTION

4.6.15. Interrupt Acknowledge

Figure 4-17 shows an interrupt acknowledge.
I PO I Pl I P2 I P3

P4 I PS I P6 ! P7 ! P8 I

MBRQO
MBRQl
MBRQ3
MBRQ7
MCMD

----------<Iack>------------------------------

MDAL

----------<Levl>-------------------<Vctr>-----

MS TAT

-------------------------<WaitXWaitXGood>-----

MS HARED
MDATINV
MBUSY

Figure 4-17:

Interrupt Acknowledge Transaction

The M-bus is idle.

The modules in slots 1 and 3 arbitrate for the M-bus.

Slot 1 wins the arbitration and asserts its MBRQ signal to confirm it won the M-bus. It also drives
MCl\ID with INTACK and MDAL with the interrupt level.

Modules check to see if they are asserting MlRQ<Level>.

Slots 0 -and 7 assert their :MBRQ to indicate they have a pending interrupt at this level.

Stor..O asserts its :MBRQ to indicate it was the highest-priority interrupter and specifies WAIT on
MSTAT, while it generates an internal interrupt-acknowledge cycle.

Slot 0 continues to assert :MBRQ and specify WAIT on MSTAT, while its internal interruptacknowledge cycle proceeds.

Slot 0 drives the vector onto :MDAL and specifies GOOD on MSTAT to complete the transaction.

Slot 3 rearbitrates for its pending transactions. 1bis is the first possible cycle for a new transaction.

4.6. l 5. Firefox. M-Bus Specification

December 29, 1987

Firefox System Specification 45

DIGIT AL EQuIPMENT CORPORATION - RESTRICTED DISTRlBlITION

4.6.16. Interrupt Acknowledge with No Slave Response

Figure 4-18 shows an interrupt acknowledge with no slave response.
PO

I PS I

MBRQl
MBRQ7
MCMD

----------<Iack>---------------

MDAL

----------<Levl>---------------

MS TAT

MS HARED

MDATINV
MBUSY

Figure 4-18:

Interrupt Acknowledge Transaction with No Slave Response

The M-bus is idle.

The module in slot 1 arbitrates for the M-bus.

Slot 1 wins the arbitration and asserts its MBRQ signal to confirm it won the M-bus. It also drives
MC11D with INTACK and 11DAL with the interrupt level.

Modules check to see if they are asserting MIRQ<l..evel>.

No modules believe they are asserting :rvflR.Q<l..evel>. The M-bus master's M-bus interface should
indicate a passive release to its internal logic. This is the last cycle of the transaction.

Slot 7 rearbitrates for its pending transaction. Tilis is the first possible cycle for a new transaction.

46 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.6.16.

DIGITAL EQUIPME.""IT CORPORATION - RESTRICTED DISTRIBL"TION

4. 7. M-Bus lnterta·ce Registers
Every M-bus module must implement one register within its slot-assigned, 32-Mbyte region of 1/0 space.
Table 4-27 lists the register name; the address offset from the base of the 32-Mbyte, slot-specific region,
and the function of the register.
Table 4-27:

Required Interface Registers for the M-Bus

Offset

Function

MODTYPE

OlFFFFFC

Module type

4.7.1. M-Bus MODTYPE Interface Register

Figure 4-19 shows the format of the read-only MODTYPE register, which indicates the class of the
module, class-specific information, the interface-chip type, and the interface-chip revision. The classspecific information is specific to the interface chip. For example, a memory module might indicate the
DRAM size and number of banks.
Address: 0 lFFFFFC#l 6

Name: MODTYPE

2 2
4 3

3
1
MODTYPE:

Access: R

1 1
6 5

8 7

REVISION

INTERFACE

SUBCLASS

f
I

0
CLASS

REVISION
INTERFACE ~~~~~~~~~~_,
SUBCLASS
CLASS
Figure 4-19:

MODTYPE Register Format

To read the MODTYPE register for slot 0, issue a longword 1/0 read to address 91FFFFFC (VAX address
31FFFFFC); to read the MODTYPE register for slot 5, issue a longword 1/0 read to address 9BFFFFFC
(VAX address 3BFFFFFC).
Table 4-28 lists the module classes currently defined
Table 4-28:

_Defined Module Classes for the M-Bus

CLASS
Module class
01#16 . - Bus-adapter class
02#16
Graphics class
04#16
I/0 class
08#16
CPU class
10#16
Memory class
20#16
Reserved
40#16
Reserved
80#16
Reserved

4.7.l. Firefox M-Bus Specification

December 29, 1987

Firefox Syste:n Specification 47

DIGITAL EQUIPMENT CORPORATION - RESTRlCTED DISTRlBUTION

Table 4-29 lists the interface-chip types currently defined.
Table ~29:

Defined Interface Chip Types for the M-Bus

Interface chip
Resetved
Firefox Bus Interface Chip (FBIC)
Firefox Memory Data Path and Control (FMDC)
PixelStamp
Rigel processor
uPrism processor
Resetved

INTERFACE
0
1
2
3
4
5
6 .. 255

4.8. Initialization
M-bus initialization is coordinated by the :MRESET, MPOK, and MDCOK signals. When the ~ESET
signal is asserted, the state of the entire Firefox workstation is (re )initialized. When the MPOK signal is
asserted, the AC input to the power supplies is within specification. Processor modules may use the MPOK
signal as a power-fail interrupt to initiate power-fail processing. When the MDCOK signal is asserted, the
DC output of the power supplies is within specification. Modules with nonvolatile storage may use the
MDCOK signal to freeze the state of their storage device.
In the following figures, l\.fRESET is shown with its backplane active-low assertion state.
4.8.1. Powerup

When a work.station powers-up, the power supplies assert MDCOK when their DC output is within
specification. Then the power supplies assert MPOK when their AC input is within specification. The
~ESET signal, which the Firefox Work.station I/0 Module generates in most configurations, is held
asserted for approximately 70 milliseconds after DC power is available to allow the M-bus clock generator
and module internal logic to stabilize. Figure 4-20 illustrates this sequence.
MDCOK
MPOK

_ _ _! ! ___________________________________________
I
I
I
I
______________________ / I
-----/
I

MRESET _________________ !

! ______________________________

> 70 ms
Figure ~28:

> 8 cycles

Powerup Sequence

48 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.8.2.

DIGITAL EQCrPME.'\,'T CORPORATION - RESTRICTED DISTRIBlmON

4.8.2. Powerdown

When AC input to the power supplies falls out of specification, they deassert MPOK. If the power supplies
can no longer maintain their DC outputs within specification, they deassert :MDCOK. The power supplies
continue to supply DC power within specification for at least 4 milliseconds after AC power is lost. In
response to the loss of :MDCOK, :MRESET is asserted. Figure 4-21 illustrates this sequence.
MPOK
MDCOK
MRESET

> 4 ms
Figure 4-21 :

Power-down Sequence

4.8.3. Workstation Reset

\\ ben the ~1RESET signal is asserted, all moduies initialize their internal logic. In addition t0 powerup
and powerdown events, modules may implement logic to assert rvIRESET either from a switch or by writing to a control register. Figure 4-22 illustrates this sequence.
MPOK
MDCOK
MRESET

> 8 cycles
Figure 4-22:

Workstation-Re..t Sequence

4.9. Electrical
All M-bus modules must use the same type, number, and physical placement of M-bus transceivers/drivers.

4.9. l. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 49

DIGITAL EQUIPMB.'41 CORPORATION -RESTRICTED DISTRIBlJTION

4.9.1. M-Bus Transceivers/Drivers and Input Loads

Table 4-30 lists the mandatory M-bus transceiver/driver components for M-bus modules. All
transceiver/driver components must be in SOIC packages. When termination is specified, a series resistor
is required immediately after the M-bus transceiver/driver output. Series resistors must be discrete,
surface-mounted resistors of at least 0.125-watt rating. When pull-up is specified, a pull-up resistor to +5.0
volts is present on the backplane. Backplane resistors must be discrete and of 0.250-watt rating, at least.
Table 4-30:

M-Bus Module Transceiver/Driver Components

Component

Termination

Pull-up

Signal(s)

74F244

20ohm

4.7Kohm

MBRQ

74F245
74F245
74F245
74F245
74F245

20ohm
20ohm
20ohm
20ohm
20ohm

4.7Kohm
4.7Kohm
4.7Kohm
4.7Kohm
4.7Kohm

MDAL<31 :24>
MDAL<23: 16>
MDAL<15 :08>
MDAL<07 :00>
MDPAR

74F245

20ohm

4.7Kohm

MCMD<3:0>,MCP AR

74F245

20ohm

4.7Kohm

MSTAT<l:O>, MSPAR

74AS760

143n68 ohm

MSHARED, MDATINV, MBUSY, MABORT

74AS760

1.5K ohm

:MIRQ<3:0>

Table 4-31 lists the mandatory M-bus-driver components for the M-bus backplane. When termination is
specified, a series resistor is required immediately after the M-bus transceiver/driver output. Series resistors must be discrete of 0.125-watt rating, at least. The :MRESET and MCLKI signals may be driven by an
M-bus module in some configurations, in which case the indicated driver must be used on that module.
Table 4-31:

M-Bus Backplane Driver Components

Component

Termination

74F244

10 ohm

Pull-up

Signal(s)
MCLKA, MCLKB

74AS760

143n68 ohm

MRESET, MCLKI

74XXXX

180/390 ohm

:MPOK, MDCOK, MHALT, :MR.UN

50 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.9.l.

DIGITAL EQUIPMENT CORPORATION -RESTRlCTED DISTRIBlJTION

Tabie 4-32 lists the allowed per-module loading for each M-bus signai. Loading is in addition to the output
driver, if appropriate. For example, the MABORT signal has one 74F244 output driver and two CMOS
input loads for each M-bus module.
Table 4-32:

Allowed Input Loading Per Module for the M-Bus

Signal(s)

Loading
1(2) CMOS INPUTS

MBRQ,MBUSY

1 74F245 TRANSCEIVER
1 7 4F245 TRANSCEIVER
1 74F245 TRANSCEIVER
1(2) CMOS INPUTS

MDAL,MDPAR
MCMD,MCPAR
MSTAT, MSPAR
MSHARED, MDATINV, MABORT

1(2) CMOS INPUTS

MRESET

1(2) CMOS INPUTS
1(2) CMOS INPUTS
NONE

MPOK
MDCOK

:MR.UN

1r:n C\.10S T!\.rptTTS
1(2) CMOS INPUTS

:MJIALT

2 CMOS INP'UTS
1(2) CMOS INPUTS

MCLKA, MCLKB
MCLKI

\1IRQ

Signals with a loading of 1(2) indicate that dual processor modules are allowed two loads on those signals,
whereas all other modules may only have one load on those signals. The M-bus clocks must have two
loads on all modules to minimize clock skew between backplane slots with dual processor modules and
backplane slots with other module types.
4.9.2. M-Bus Driver/Receiver DC Characteristics

Table 4-33 lists the DC characteristics for the various driver/receiver classes. All input and output voltages
are in volts. All input, output, and leakage currents are in milliamperes. The F245 transceiver class is
associated with the MDAL, MDPAR, MCMD, MCPAR, MSTAT, and MSPAR signals. The F244 driver
class is associated with the MBRQ, MCLKA, and MCLKB signals. The AS760 driver class is associated
with the MSHARED, MDATINV, MBUSY, MABORT, MIRQ, 1\-iR.ESET, MCLKI, MPOK, MDCOK,
MB.ALT, and MRUN signals. The CMOS receiver class is associated with the MBRM, MCLKA;
MCLKB, MSHARED, MDATINV, MBUSY, MABORT, MIRQ, MRESET, MCLKI, MPOK, MDCOK,
and MB.ALT signals.
Table 4-33:

M-Bus Driver/Receiver DC Characteristics

Class

Voh

F245
F244
AS760
CMOS

2.0
2.0

Ioh
-15.0
-15.0
0.1

Vol
0.55
0.55
0.55

4.9.3. Firefox M-Bus Specification

Iol
64.0
64.0
64.0

Vil

2.0

Iih
0.07

0.8

Ill
-1.0

2.0

0.01

0.8

-0.01

Vih

December 29, 1987

Iz
0.05
0.05

Firefox System Specification 51

DIGITAL EQUIPMENT CORPORATION - RESTRlCTED DISTRlBt;TION

4.9.3. M-Bus Signal Capacitance

Table 4-34 lists the allowed module capacitance for the various signal classes. All capacitance values are
in picofarads. Capacitance values in parentheses are for dual processor modules.
Table 4-34:

M-Bus Module Slgnal Capacitance

Signals
MCLKA,MCLKB
:MBRQ
:MBRM
:rvIDAL,MCMD,MSTAT,MXPAR
MSHARED,:rvIDATINY ,:MB USY ,MABORT,MRESET ,MCLKI,MH.ALT,MIRQ
:MPOK,MDCOK

Cin
40

Cout

Cio

13
17(35)
13
27(45)
20(40)

4.9.4. M-Bus Timing

The M-bus AC timing is determined by four components:
•

Bus interface output propagation delay

•

M-bus driver/receiver propagation delay

•

Bus interface input setup/bold time requirements

•

M-bus clock distribution skew

Figure 4-23 shows the wave forms generated by the M-bus clock generator. The clock generator is based
on a divide-by-six circuit of the master oscillator. The clock generator must be free-running and selfinitializing from an arbitrary power-up state within a few oscillator cycles.

osc
MCLKA

MCLKB
Figure 4-23: . M-Bus MCLKA/MCLKB Waveforms

52 Fin:fox System Specification

December 29, 1987

Fin:fox M-Bus Specification 4.9.4.

DIGITAL EQUIPMENT CORPORATION - RESTRICTED DISTRIBUTION

All M-bus output signals and bus driver control signals must be outputs of flip-flops clocked on the rising
edge of MCLKA. All M-bus input signals must be latched on the falling edge of MCLKB. Table 4-35
shows the timing budget for each component of the module-to-module communication path. All times are
in nanoseconds. Refer to the Firefox M-bus Data Line Signal Integrity Study and the M-bus lnteiface
Logic Clock Distribution System Signal Integrity Study for a detailed discussion of the SPICE simulations
conducted to derive the F245-driver timing and the clock-distribution-skew timing.
Table 4-35:

M-Bus Module-To-Module Timing Budget

SComponent
Bus interface output delay
F245 M-bus driver delay
F245 M-bus receiver delay
Bus interface input setup time
Bus interface input hold time
M-bus clock distribution skew

Symbol
To
Td
Tr
Ts
Th
Tc

Minimum Time
0.0
2.5
2.5

Maximum Time
TBD
18.0
7.0
TBD
TBD
9.2

The minimum M-bus cycle time is determined by: Tcycle =(To.max+ Td.max +Tr.max+ Ts+ Tc) * 6/5
The available input hold time is determined by: Th= (Tcycle/6) - Tc - To.min
Note that the available-input-hold-time equation does not include a temi for the backplane driverlreceive-r
propagation delay. This is necessary for dual processor modules which do not have a backplane
driver/receiver in the path between the two bus interfaces.
4.9.5. Module AC Characteristics

Table 4-36 lists the AC characteristics that M-bus modules must meet for input and output responses. All
timing is measured with respect to the threshold voltage of M-bus signals, Vt equal to 1.4 volts, at the
backplane connector.
Table 4-36:

Module AC Characteristics

Class
Outputs to MCLKA rising
Inputs to MCLKB falling

To
TBD

TBD

4.9.6. DC Power

Each M-bus slot has sixteen +5 volt pins, three + 12 volt pins, and thirty-six ground pins. Each connector
pin is rated for a minimum of 1.0 amperes, resulting in a maximum of 16.0 amperes at +5 volts and 3.0
ampere~ ~t +12 volts.
4.9.7. AC Power

The M-bus has a +5 volt or ground pin for each three signal pins. The power pins for the two rows of the
backplane connectors are staggered. This provides an AC ground within 100 mils of each signal pin.
M-bus modules must implement sufficient power supply decoupling to limit ripple imposed back on the
backplane +5 volt plane to 25 millivolts.

4.9.7.l. Firefox M-Bus Specification

December 29, 1987

Firefox System Specification 53

DIGITAL EQUIPMENT CORPORATION -RESTRICTED DISTRIBUTION

4.9.7.1. Operation of M-Bus with Extended Modules

The M-bus worst-case timing margins do not allow operation of the M-bus with modules connected to the
backplane via an extender module at the nominal M-bus clock period.
With typical timing margins, it should be possible to operate the M-bus at nominal M-bus clock period with
one module on an extender.
SPICE simulations indicate that the M-bus backplane switching time increases by 5.0 ns with a 12.0-inch
extender. Calculations indicate that clock skew is increased by 2.5 ns. This implies that the M-bus cycle
time must be increased by 15.0 ns to run a worst-case system with one module on an extender.
The extender module must be a four-layer PCB with +5-volt and ground planes. Signal traces must be
routed on alternate sides to minimize crosstalk. The etch length must not exceed 12.0 inches. There must
only be one additional connector in the signal path.
If the M-bus cycle time is increased, memory modules may not receive adequate DRAM refresh.

Under no circumstances is extension of more than one M-bus module supported.

4.9.8. Backplane Signal Assignments

Table 4-37 shows the backplane connector-pin assignment for each of the M-bus signals. Each of the two
connector blocks has a standard power and ground pattern that gives one AC ground for each three signals.

54 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.9.8.

DIGITAL EQlJIPME.''ff CORPORATION -RESTRICTED DISTRIBli"""TION

Table 4-37:

M-Bus Backplane Signal Assignments

Pin
AOl
A03
I A05
A07

Signal

A09

GND

I
I

All
,A13
\ Al5
I A17
I Al9
: A21
A23
A25
A27
A29
A31
A33

A35
! A37
A39
! A41

GND

+5V

GND

+5V

I A43

A45
: A47
A49
I A51
j A53
A55
1

GND

I A57
I A59
A61
I A63
I A65
I A67
I A69

IA71
A73
. r~75
A77
A79
; A81
A83
! A85
i A87
· A89
A91
A93
1

GND

+5V

GND
-12V

GND
.MRSVA83
MDATINV
rvIBUSY
+SV
"MHALT

MPOK

4.9.8. Firefox. M-Bus Specification

Pin
A02
A04
A06
A08
AlO
Al2
Al4
A16
A18
A20
A22
A24
A26
A28
A30
A32
A34
A36
A38
A40
A42
A44
A46
A48
A50
A52
A54
A56
A58
A60
A62
A64
A66
A68
A70
A72
A74
A76
A78
A80
A82
A84
A86
A88
A90
A92
A94

Signal

+5V

GND

+5V

GND

+5V

GND

+5V
-12V
MR.UN
MR.SVA84

GND
MSHARED
MAB ORT
MDCOK

GND

! Pin

Signal

BOl
B03
BOS
B07
B09
Bll
Bl3
B15
B17
Bl9
B21
B23
B25
B27
B29
B31
B33
B35
B37
B39
B41
B43
B45
B47
B49
B51
B53
B55
B57
B59
B61
B63
B65
B67
B69
B71
B73
B75
B77
B79
B81
B83
B85
B87
B89
B91
B93

GND

December 29, 1987

MCLKA

GND
MCLKB

GND
+12V
MBRQ
MBRMO
+5V
MBRM3
MBRM5
MBRM6

GND
MSTATl
MIRQl
MIRQ2

GND
MCMDO
MCMD2
MCMD3
+5V
MDPAR
MIDl
MID2

GND
MDALO
MDAL2
MDAL3

GND
MDAL6
MRESET
MDAL8
+5V
MDALll
MDAL13
MDAL14

GND
MDAL17
MDAL19
MDAL20

GND
MDAL23
rvIDAL25
MDAL26
+SV
MDAL29
rvIDAL31

Pin
B02
B04
B06
B08
BlO
B12
Bl4
B16
B18
B20
B22
B24
B26
B28
B30
B32
B34
B36
B38
B40
B42
B44
B46
B48
B50
B52
B54
B56
B58
B60
B62
B64
B66
B68
B70
B72
B74
B76
B78
B80
B82
B84
B86
B88
B90
B92
B94

Signal
+5VBAT

GND
+5V

GND
+12V
+12V

GND
MBRMl
MBRM2
MBRM4

GND
MSPAR
MSTATO
MIRQO
+5V
MIRQ3
MCPAR
MCMDl

GND
MRSVB40
MS LOT
MIDO

GND
MCLKI

GND
MDALl
+5V
MDAL4
MDAL5
MDAL7

GND
MDAL9
MDALlO
MDAL12

GND
MDAL15
MDAL16
MDAL18
+5V
MDAL21
MDAL22
MDAL24

GND
MDAL27
rvIDAL28
:MDAL30

GND

Firefox. System Specification 55

DIGITAL EQUIPME."''T CORPORATION - RESTRICTED DISTRIBCTION

The signals on the B block labeled :MBRM<0:6> are the M-bus-request signals from the other slots. Table
4-38 lists the connections for the :MBRQ signal from each of the slots to the other 6 slots.
Table 4-38:

MBRQO
MBRQl
MBRQ2
MBRQ3
MBRQ4
MBRQ5
MBRQ6
MBRQ7

M-Bus MBRQ Connections per Slot

SlotO

Slotl

Slot2

Slot3

Slot4

SlotS

Slot6

Slot7

813
815
816
818
Bl9
B20
B21
823

815
B13
Bl6
818
819
B20
B21
823

815
Bl6
Bl3
Bl8
819
B20
B21
823

B15
Bl6
818
813
819
820
B21
B23

815
Bl6
B18
819
813
B20
821
B23

Bl5
816
Bl8
B19
B20
Bl3
B21
B23

Bl5
816
818
Bl9
820
B21
813
823

815
816
818
819
820
821
823
813

The l\.1RSRVD signals are bussed across all slots.
MCLKA and MCLKB are radially distributed to each slot from the M-bus clock subsystem. The M-bus
clock-generator components are located on the M-bus backplane.
The unspecified signals on the A connector block are reserved and must not be connected to any internal
logic of M-bus modules. However, M-bus modules must still connect the assigned power pins, as they are
part of the DC power-distribution network.
The maximum stub length for the MC:MD, MSTAT, :MDAL, and .MXPAR signals is 1.5 inches, where stub
length is the amount of etch between the top of the edge finger and the IC pin. Stub length of all other Mbus signals must not exceed 3.0 inches.

4.10. Mechanical
M-bus modules use the new L-series-q'Utld module format with two L-series one-piece connectors resulting
in two paddles of 94 edge-fingers on 100-mil centers.

56 Firefox System Specification

December 29, 1987

Firefox M-Bus Specification 4.10.