System_Bus_Specification_Feb88.pdf part of arete_arix System Bus Specification Feb88 System_Bus_Specification_Feb88.pdf, . Rare and Ancient Equipment arete_arix a3000 System_Bus_Specification

Text preview for : System_Bus_Specification_Feb88.pdf part of arete_arix System Bus Specification Feb88 . Rare and Ancient Equipment arete_arix a3000 System_Bus_Specification_Feb88.pdf

Back to : System_Bus_Specification_ | Home

Feb 25 17:55 1988 sbus.spec Page 1

1---------------------------------------1
1
1 ARETE SYSTEMS CORPORATION
1
1
1 1
1 PROPRIETARY AND CONFIDENTIAL 1
1 1
1---------------------------------------1
System Bus Specification

General

The system bus is an N-port time-division multiplexed transmission switch.
A module installed in any of the N ports (backplane positions/slots) can
send (receive) transmissions to (from) any of the N ports, including itself.
Each transmission consists of a SOURCE port address, a DESTINATION port
address, a transmission TYPE and 8 bytes of "DATA". The transmission TYPE
determines what the DATA field contains. Error detection is provided for
the SOURCE slot address, DESTINATION slot address and transmission TYPE
fields and optionally provided for the DATA field. The maximum value of N
is 16 (ports). The clock rate is 20 MHz. The instantaneous peak data
transfer rate is ( 8 Bytes * 20 MHz = ) 160 MB/sec.
Modules installed in bus ports interact with each other by exchanging
transmissions over the bus. There are two types of transmissions, COMMANDS
and RESPONSES. A module on the bus begins an interaction with another module
by sending a COMMAND. The source of the COMMAND is the MASTER for that
interaction; the destination of the COMMAND is the SLAVE. The SLAVE sends
a RESPONSE back to the MASTER if required to complete the COMMAND.
Bus Arbitration and Flow Control

The bus arbiter controls access to the bus. To transmit on the bus, a
module asserts ARB REQUEST, ARB DEST(3:0] (the DESTINATION port address)
and optionally, a request modifTer (ARB RESP and/or ARB MODIFY) to the
arbiter. If the request is to send a COMMAND, the arbiter checks
that the destination port has a COMMAND input buffer available. A port
with a COMMAND input buffer available is said to be READY. If the request
is to send a RESPONSE, the module also asserts ARB RESP to the arbiter. In
this case the destination port is required to have-to have enough RESPONSE
input buffers available for the size of the RESPONSE it requested. Ports
wanting to send COMMANDS to destinations that are READY and ports wanting
to send RESPONSES arbitrate for time slots on the bus. Arbitration occurs
for each available time slot. The arbiter asserts ARB GRANT to each port
that wins an arbitration.
Arbitration priority is a function of the port number of the requesting port.
Ports are numbered (N-1) to O. The ports are divided into 2 groups.
Ports (N-l) thru (N-n) form the first group. Ports (N-n-1) thru 0 form
the second group. The priority of ports in the first group is the same as
their port number. Port (N-1) has the highest priority, and port (N-n)
has the lowest. The priority of ports in the second group is lower than
that of the ports in the first group. And unlike the first group, the
Feb 25 17:55 1988 sbus.spec Page 2

priority of the ports in the second group is periodically changed so that
each port in the group has the same average priority. Half the time, the
priority of the ports in the second group is the same as their port number
(Port (N-n-1) has the highest priority, and port 0 has the lowest). The rest
of the time, the priority of the ports is inverse to their port number
(port 0 has the highest priority, and port (N-n-l) has the lowest).
The initial implementations of the sbus and arbiter have the same number
of ports in each group (n = N/2).
Each module indicates to the arbiter when it has COMMAND input buffers
available. Each COMMAND input buffer holds one transmission. If the
module has at least one COMMAND buffer available, it asserts ARB READY! to
the arbiter. If the module has at least 3 COMMAND buffers available, it
may also assert ARB READY3 to the arbiter. When the arbiter grants the
transmission of a COMMAND, it asserts ARB RDY DEC to the destination port
to inform the destination of the grant. This-allows the destination port
to update its values of ARB READY! and ARB READY3 while the transmission
is occurring. -
The maximum rate at which a module can receive COMMANDS is determined by
whether ARB READY3 is asserted. Assertion of ARB READY3 allows a COMMAND
to arrive every bus clock tick. If ARB READY3 is-not asserted, COMMANDS
can arrive no more frequently than every other bus clock tick. RESPONSES
can arrive every bus clock tick.
Interlocked Sequences

The bus arbiter also supports interlocked sequences of operations. These
sequences are required to to support the TAS, CAS and CAS2 instructions of
the Motorola 68020 and are a generalization of the READ/MODIFY/WRITE
operation. Interlocked sequences are atomic to each other and are composed
of any number of READ and WRITE commands. The signal ARB LOCK is asserted
by the arbiter when an interlocked sequence is in progress.
To request an interlocked sequence, a module asserts ARB REQUEST,
ARB DEST[3:0] (of the first interlocked COMMAND) and ARB-MODIFY to the
arbIter. The interlocked sequence begins when ARB LOCK Is not asserted
and a port asserting ARB REQUEST and ARB MODIFY to-the arbiter is granted
the bus. The interlockea sequence lasts-as long as ARB MODIFY is asserted
by the locking module and ends when the locking module aeasserts ARB_MODIFY.
To minimize performance loss, an interlocked sequence does not lock out
commands from ports not asserting MODIFY to the arbiter.
Bus Transmissions

The arbiter grants access to the bus by asserting ARB GRANT to each module
that wins an arbitration. ARB GRANT is asserted to a-module for one bus
clock cycle. A module receiving ARB GRANT may transmit on the bus during
the clock cycle immediately following the clock cycle in which ARB GRANT
was received.
When a module is GRANTED the bus to send a RESPONSE, the module may use
Feb 25 17:55 1988 sbus.spec Page 3

the bus for up to four consecutive clock cycles by asserting ARB BURST to
the arbiter during all but the last clock cycle. The assertion of ARB BURST
during a clock cycle prevents the arbiter from issuing ARB GRANT to any
module for use of the bus during the next clock cycle. OnTy RESPONSES can
be sent in BURST mode. BURST mode RESPONSES can be to one or more
DESTINATION ports.
When a module transmits on the bus, it asserts the signal BUS ACTIVE to
indicate the presence of a transmission. -
Each module monitors all bus transmissions. Each transmission is first
checked for destination field errors. A module recognizes a transmission
as addressed to it if the destination field contains no detected errors and
matches the module's port (slot) number. The transmission is then checked
for source and type field errors. If the TYPE of the transmission is not
CONTROL WRITE and BUS DATA PAR VLD was asserted, the DATA field is checked
for parTty errors. It the-transmission is a RESPONSE, it must be expected
and the SOURCE field must be that of the expected source.
Each transmission received without detected error is indicated by asserting
BUS_ACK on the bus during the second clock cycle after the transmission.
Transmissions received with one or more detected errors or with a TYPE field
value that the module can not process are indicated by asserting BUS NACK
on the bus during the second clock cycle after the transmission. -
Errors in the DATA field of transmissions of TYPE CONTROL WRITE or in
transmissions with BUS DATA PAR VLD deasserted are ignorea. These
transmissions are ACKea or NACKed based on the detection of errors in the
source and type fields.
Only the destination port asserts BUS ACK or BUS NACK for a transmission.
Transmissions with destination field errors or destination fields not matching
the port (slot) number of any installed module are neither ACKed nor NACKed.
When a system bus transmission fails, retry is permitted, but not required.
If retry is attempted, the module that issued the COMMAND resulting in the
failed transmission restarts the transaction by reissuing the COMMAND.
Transmission Format

Each transmission has a DESTINATION field, a SOURCE field, a TYPE field and a
DATA field. The DESTINATION field contains the destination port number and,
for error detection, the compliment of the DESTINATION port number. The
SOURCE field contains the source port number and its compliment. The TYPE
field indicates the type of COMMAND or RESPONSE and the format of the DATA
field. The TYPE field has a parity bit for single-bit error detection. A
parity bit is also defined for each byte of the DATA field for single-bit
error detection, but implememtation is optional. The source of a bus
transmission indicates whether data parity bits have been sent by asserting
BUS_DATAPAR_VLD during the transmission.
The DATA field is organized as 8 bytes of 8 bits each. The bytes are
numbered 0 through 7 with byte 0 the most significant and of lowest address.
Bits within a byte are numbered 7 through 0 with bit 7 the most significant.
Each bit in the DATA field has a name of the form BUS_DATA[B,b] where B is
Feb 25 17:55 1988 sbus.spec Page 4

the byte number and b is the bit number within the byte. The optional
parity bit for byte B is BUS DATA PAR[B]. Data field parity is even. The
',0

bit BUS DATAPAR VLD indicates whether data field parity is implemented.
System addressing is by 4 bits of physical port number and 32 bits of offset.
The address of an operand is the address of its first (most significant and
lowest address) byte.
The bus COMMANDS are:
READ [size = 1, 2, 3, 4, 8, 16 or 32 bytes]
The operand of a READ command for 4 bytes or less must not
cross a long word (4 byte) boundary. The operand of a READ
command for 8, 16 or 32 bytes must be aligned on an 8, 16
or 32 byte boundary, respectively. READs of 8, 16 and 32
bytes are not supported by all module types. The offset