NSC DS3875VX, DS3875V Datasheet

TL/H/10747

DS3875 Futurebus

a

Arbitration Controller

November 1995

DS3875 FuturebusaArbitration Controller

General Description

The DS3875 FuturebusaArbitration Controller is a member
of National Semiconductor’s Futurebus

a

chip set designed

specifically for the IEEE 896.1 Futurebus

a

standard. The
DS3875 implements Distributed Arbitration and Distributed
Arbitration messages in a single chip.

The DS3875 interfaces with Futurebus

a

through the
DS3885 BTL Arbitration Transceiver and the DS3884A BTL
Handshake Transceiver. The DS3885 BTL Arbitration
Transceiver incorporates the competition logic needed for
the Arbitration Number signal lines. The DS3884A BTL
Handshake Transceiver has selectable Wired-OR receiver
glitch filtering. The DS3884A is used for the Arbitration Se­quencing and Arbitration Condition signal lines.

Additional transceivers included in the Futurebus

a

chip set
are the DS3883A BTL 9-bit Data Transceiver and the
DS3886A BTL 9-bit Latching Data Transceiver. The
DS3886A transceiver features edge-triggered latches in the
driver which may be bypassed during a fall-through mode
and a transparent latch in the receiver. The DS3883A trans­ceiver has no latches in either direction.

The Logical Interface Futurebus

a

Engine (LIFE) I/O Proto­col Controller with 64-bit Data Path incorporates the Com­pelled Mode Futurebus

a

Parallel Protocol. The Protocol
Controller handles all the handshaking signals between the
Futurebus

a

and the local bus interfaces, and incorporates

a DMA Controller with built-in FIFOs for fast queueing.

Features

Y

The controller implements the complete requirements
of the IEEE 896.1 specification as a subset of its fea­tures

Y

Supports Arbitration message sending and receiving

Y

Supports the two modes of operation (RESTRICTED/
UNRESTRICTED)

Y

Software configurable double/single pass operation,
slow/fast, IBA/Parking and restricted/unrestricted
modes of arbitration

Y

Built-in 1 ms timer for use in the arbitration cycle

Y

User programmable 16 arbitration delays (8 slow and
8 fast)

Y

Built-in PLL for accurate delays. The PLL accepts
clocks from 2 MHz to 40 MHz in steps of 1 MHz

Y

Signal to unlock slave modules on transfer of tenure.
Auto unlock through a dummy cycle if the current mas­ter locked resources

Y

Programmable delay for releasing ar* after issuing
COMPETE/IBAÐCMPT. This is to ensure the assertion
of the arbitration number during competition, before the
release of ar*. Also this delay ensures there is suffi­cient time to assert the AD/DATA lines during Idle Bus
Arbitration before the release of ar*

Y

Read/Write facility with data acknowledge for the host
to load arbitration numbers, an arbitration message,
and control registers

Y

On chip parity generator unloads the host of the addi­tional parity generation function

Y

Separate interrupts to indicate error occurrence and ar­bitration message received. Interrupts cleared on a reg­ister write. Error status is available in a separate status
register

Y

A special output pin to indicate that a POWERFAIL
message was received

Y

Hardwired register to hold the first word of the arbitra­tion message

Y

FIFO strobe provided to store more than one arbitration
message externally to prevent overrun

Y

Idle Bus Arbitration (IBA) supported

Y

Parking implemented

Y

Bus initialization, system reset and Live-insertion sup­ported. (The logic to detect these conditions must be
implemented externally.)

Y

Testability in the form of reading from key registers
which include the STATE, MCW, 1 ms timer and pro­grammable input clock divider

TL/H/10747– 1

National’s FuturebusaChip Set Diagram

C

1995 National Semiconductor Corporation RRD-B30M115/Printed in U. S. A.

Table of Contents

1.0 INTRODUCTION TO FUTUREBUSaААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА6

2.0 INTRODUCTION TO FUTUREBUS

a

ARBITRATION АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА6

2.1 The Arbitration States ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА7

3.0 INTRODUCTION TO DS3875 ARBITRATION CONTROLLER ААААААААААААААААААААААААААААААААААААААААААААААААААААА7

3.1 Using the DS3875 in 896.1 Compliant Mode ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА7

4.0 DS3875 INTERFACES ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА10

5.0 ARBITRATING FOR FUTUREBUS

a

АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА12

5.1 Unrestricted/Restricted Modes of Operation АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА12

5.2 The Arbitration Number and Arbitration Circuit ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА12

5.2.1 Priority Field (PR)ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА14

5.2.2 Round Robin Field (RR) ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА14

5.2.3 Unique Field (U) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА14

5.3 Arbitration Categories АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА14

5.3.1 Competitor for the Parallel Bus ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА14

5.3.2 Competitor to Send a MessageААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА15

5.3.2.1 Using an External FIFO to Store MessagesАААААААААААААААААААААААААААААААААААААААААААААААААААААААА15

5.3.3 By-Stander АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА15

5.3.4 By-Stander who decides to invoke Preemption ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА15

5.3.5 Master АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА15

5.3.6 Master Elect ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА15

5.4 Futurebus

a

Optional Means of ArbitrationАААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА17

5.4.1 Idle Bus Arbitration (IBA) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА17

5.4.1.1 Masters Support Circuitry to Enable IBA АААААААААААААААААААААААААААААААААААААААААААААААААААААААААА17

5.4.1.2 Modules Support Circuitry to Participate in IBA ААААААААААААААААААААААААААААААААААААААААААААААААААААА17

5.4.2 Parking ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА18

5.5 The Arbitration Phases ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА18

5.5.1 Phase 0, Idle PhaseААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА20

5.5.1.1 Phase 0, Normal Arbitration Events That Cause a Transition to Phase 1 ААААААААААААААААААААААААААААААА20

5.5.1.2 Phase 0, Idle Bus Arbitration Events That Cause a Transition to Phase 1 АААААААААААААААААААААААААААААА21

5.5.1.3 Phase 0, ParkingААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА21

5.5.2 Phase 1, Decision Phase АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА21

5.5.2.1 Phase 1, Idle Bus Arbitration Events That Cause a Transition to Phase 2 АААААААААААААААААААААААААААААА21

5.5.3 Phase 2, Competition Phase ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА21

5.5.3.1 Phase 2, Idle Bus Arbitration Events That Cause a Transition to Phase 3 АААААААААААААААААААААААААААААА21

5.5.4 Phase 3, Error Check Phase ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА21

5.5.4.1 Phase 3, Idle Bus Arbitration Events That Cause a Transition to Phase 4 АААААААААААААААААААААААААААААА22

5.5.5 Phase 4, Master Release Phase АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА22

5.5.6 Phase 5, Tenure Transfer Phase ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА22

6.0 THE DS3875 ARBITRATION CONTROLLER SUPPORT OF LOCKING AND UNLOCKING АААААААААААААААААААААААААА31

7.0 REGISTER DESCRIPTION ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА33

7.1 ALL1S ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА34

7.2 TCXN0ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА34

7.3 TCXN1ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА34

7.4 TXMSG АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА35

7.5 CTRL1 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА35

2

Table of Contents (Continued)

7.0 REGISTER DESCRIPTION (Continued)

7.6 CTRL2 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА36

7.7 CTRL3 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА36

7.8 STATE ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА37

7.9 STATUS ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА37

7.10 RXCN0 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА37

7.11 RXCN1 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА38

7.12 RXMSG ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА38

7.13 CLRERI ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА38

7.14 CLRMGI АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА38

7.15 CLRPFI ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА38

7.16 REV NO АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА39

8.0 PROGRAMMING REGISTERSАААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА39

8.1 Host Write Cycle Using Falling Edge of DSACK*

(Figure T2a)

ААААААААААААААААААААААААААААААААААААААААААААААААААА39

8.2 Host Write Cycle Using Rising Edge of CS*

(Figure T2b)

АААААААААААААААААААААААААААААААААААААААААААААААААААААААА39

8.3 Host Read Cycle

(Figure T2c)

ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА39

9.0 CLOCK/TIMER/DELAY LINESААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА39

10.0 RESET/INITIALIZATION/POWER UP ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА40

11.0 LIVE INSERTION АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА41

12.0 LIVE WITHDRAWAL ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА42

13.0 TESTING THE DS3875 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА42

14.0 ELECTRICAL CHARACTERISTICS АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА43

15.0 AC PARAMETERS ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА43

TL/H/10747– 2

3

Pin Definition

Pin

Ý

of Pins Type Description

SIGNAL TO/FROM THE HANDSHAKE TRANSCEIVER

APO 1 O Arbitration handshake signal from the controller.

AQO 1 O Arbitration handshake signal from the controller.

ARO 1 O Arbitration handshake signal from the controller.

AC0O 1 O Arbitration condition signal from the controller.

AC1O 1 O Arbitration condition signal from the controller.

API 1 I Arbitration handshake signal from Futurebusa. This signal is the filtered and inverted version

of the Futurebus

a

backplane signal AP*.

AQI 1 I Arbitration handshake signal from Futurebusa. This signal is the filtered and inverted version

of the Futurebus

a

backplane signal AQ*.

ARI 1 I Arbitration handshake signal from Futurebusa. This signal is the filtered and inverted version

of the Futurebus

a

backplane signal AR*.

AC0I 1 I Arbitration condition signal from Futurebusa.

AC1I 1 I Arbitration condition signal from Futurebusa.

SIGNAL TO/FROM THE ARBITRATION TRANSCEIVER (Note: These pins are mapped to/from the DS3885 Futurebus

a

Arbitration Transceiver.)

CN(7:0) 8 I/O The bus to carry competition number to/from the arbitration transceiver.

CNp 1 O Parity bit of the competition number.

CMPT* 1 O Enables the Arbitration number onto Futurebusa.

ABÐRE* 1 O Direction control for the competition number bus to/from the transceiver.

CNÐLE* 1 O Latch enable for latching the Arbitration number from the controller into the transceiver.

PER* 1IPARITY ERROR: Indicates that a parity error was detected on the winner’s arbitration number.

WIN*ÐGT* 1 I Win signal when competing/greater than signal when not competing (used to preempt).

ALL1* 1 I Indicates that all the arbitration number lines on the bus are asserted (used for messages).

SIGNALS TO/FROM THE PARALLEL PROTOCOL CONTROLLER

BRQ* 1IBUS REQUEST: Indicates to the controller to acquire the bus for the module’s use.

BGRNT* 1OBUS GRANT: Signal asserted by the controller after the detection of a bus request. The

module can start using the bus.

RINT* 1 I Will put the arbitration controller in phase 0 and release all the bus lines except AR*.A

selective reset is performed. The rising edge will release controller from phase 0. This reset is
to be used for bus initialization.

RST* 1 I Reset signal from the host. An internal reset is performed. All bus signals are released. The

rising edge will put the controller in phase 0 (same as power-up reset).

HALT* 1 I Will halt the arbitration controller in phase 0. This signal is for use during live insertion.

ENDT* 1IEND OF TENURE: Indicates the true end of bus tenure of the current master. This line may be

asserted only after all the parallel protocol lines are released. (Generated via external logic
from BRQ* released.)

4

Pin Definition (Continued)

Pin

Ý

of Pins Type Description

SIGNALS TO/FROM THE HOST (CPU Plus External Interface Logic)

DATA(7:0) 8 I/O Data bus for the host to access the register bank of the controller.

ADD(3:0) 4 I Address bits for the register bank of the controller.

CS* 1ICHIP SELECT: The host can read or write to/from the controller.

RÐW* 1 I Read/write signal from the host.

DSACK* 1 O Data acknowledge pin for host read/write.

SEL 1 I SELECT: Determines how the controller latches in data. A ‘‘1’’ on the pin uses the rising

edge of CS*. A ‘‘0’’ on the pin uses the falling edge of DSACK*.

MGRQ* 1IMESSAGE REQUEST: Indicates to the controller to send an arbitration message.

MGTX* 1OMESSAGE TRANSMIT: Indicates the successful transmission of an arbitration message.

ERINT* 1OERROR INTERRUPT: Indicates that an error occurred during the arbitration cycle.

MGINT* 1OMESSAGE INTERRUPT: Indicates the reception of an arbitration message.

PFINT* 1OPOWER FAIL INTERRUPT: Indicates that a powerfail message was received.

EXTERNAL LOGIC

IBAÐCMPT* 1 O Signal to indicate that the Parallel Protocol controller may assert its bit on the ADDRESS/

DATA bus if it is participating in an Idle Bus Arbitration.

IBAÐS* 1 I This signal indicates that IBA was successful. If this module was a competitor in the IBA

competition (!BRQ*), then this module is the winner and now the bus master. If this module
was the master, but did not compete in the IBA competition and IBA was successful, then the
M bit (Status register) is negated.

ASÐCANCEL 1 I Indicates the start of the disconnection phase of the current master or cancel the current

arbitration cycle.

LKD* 1ILOCKED: Signal to indicate that resources have been locked in the current tenure and

hence generate either a dummy cycle if current master or UNLK* otherwise. (Decoded from
Futurebus

a

Command port output from Data Path Unit.)

UNLK* 1OUNLOCK: Transfer of tenure indication to the parallel protocol controller for unlocking its

resources. Generated only if the LKD* signal is asserted. (To external logic.)

FSTR* 1OFIFO STROBE: Signal generated to load an external FIFO for received arbitration messages.

CLK 1 I Clock input to the internal PLL.

C1 1 I External capacitor input for PLLÐ0.1 mF.

5

1.0 Introduction to Futurebus

a

Futurebusais a high-performance asynchronous multi­plexed address/data backplane bus designed by the IEEE

896.1 committee for use in a wide variety of multiprocessor
architectures. The Futurebus

a

standard is a next genera­tion backplane bus standard developed to a set of require­ments including openness, performance, and system facili­ties and flexibilities so as not to hinder systems using this
bus for many generations of computer systems. Future­bus

a

is a single cache coherent backplane architecture
featuring scalability, technology independent protocols, and
explicit provisions to extend to future applications. Require­ments set for the Futurebus

a

architecture by the IEEE

896.1 Futurebus

a

Working Group include:

1. Architecture, processor, and technology independent

2. A basic asynchronous (compelled) transfer protocol

3. An optional extended source-synchronized protocol

4. No technology-based upper limit to bus performance

5. Fully distributed parallel and arbitration protocols

6. Support for fault-tolerant and high-availability systems

7. Support for cache-based shared memory

8. Compatible message transport definition.

Compatibility of varying speed and technology boards con­nected to the same Futurebus

a

backplane is dependent
upon broadcast capability, or a snooping cache coherence
scheme. The performance of a Futurebus

a

backplane is
scalable over time to allow a low-end 32-bit system operat­ing at 100 Mbytes/sec to be expanded to a 256-bit system
operating at 3.2 Gbytes/sec in the future. This performance
is attainable by the use of source-synchronized protocols
which eliminate spatial skews and receivers which are trig­gered by the incident wave from the driver. The synchroni­zation protocol of the Futurebus

a

backplane allows the
synchronization domain of the sender to extend along the
backplane, presenting only one synchronization interface
between the bus and the receiver.

The Futurebus

a

backplane uses ‘‘Backplane Transceiver
Logic’’ (BTL). BTL is a signaling standard that has been
developed to enhance the performance of backplane bus­es. This standard eliminates the settling time delays, that
severely limit the TTL bus performance, to provide signifi­cantly higher bus transfer rates. BTL compatible transceiv­ers feature low output capacitance drivers to minimize bus
loading, a 1V nominal signal swing for reduced power con­sumption, and receivers with precision thresholds for maxi­mum noise immunity. For example, all Futurebus

a

signals
are open collector with termination resistors (selected to
match the bus impedance) connected to 2V at both ends.
The low voltage is typically 1V. All Futurebus

a

signals are
active low, indicated by an * after the signal name. (Refer to
Table I.) Further, signals can be driven simultaneously by
several modules. This requires that glitch filtering will be
needed for those times to filter out the transmission line
effect called the wire-or glitch. Refer to the Futurebus

a

specifications for details.

TABLE I. Signal Definitions

Signal Type,

Terminology

Logic

TTL BTL

Example Signal Level

Active High Asserted Logic 1 5V Ð

SignalÐName

Negated Logic 0 0V Ð

Active Low Asserted Logic 1 0V 1V

SignalÐName*

Negated Logic 0 5V Ð

Released

Logic 0 Ð 2V

(Open Collector)

2.0 Introduction to Futurebus

a

Arbitration

Futurebusauses an evolved version of the Parallel Con­tention Arbiter (see

Figure 4

). Through the application of a
unique arbitration vector to this logic, only one contender
will be uniquely selected as the winner. This implementation
requires no central logic on the backplane and gains the
following advantages:

1. The current master can see any requests and their priori-

ty to determine whether it should give up the bus.

2. Multiple priority levels can be implemented to allow sys-

tems to allocate bus bandwidth to modules running the
most critical tasks.

3. A Round Robin (fairness) protocol is implemented within

each priority level to ensure fair and equitable allocation
of bus tenure to all modules.

4. A master elect can be preempted by a higher-priority con-

tender. This allows the higher priority contender to ac­cess the bus with minimum latency (with some sacrifice
to the system performance).

5. Arbitration Messages or events can be broadcast on the

arbitration bus without disturbing the current transaction
on the parallel bus. Important system control functions
and interrupts can be sent using this mechanism without
the need of dedicated bus lines.

6. A Module may support either Idle Bus Arbitration or Park-

ing. Idle Bus Arbitration can be enabled by the current
master to decrease the arbitration latency when ony one
competitor is requesting the bus. If Idle Bus Arbitration is
not selected then Parking may be enabled by the master.
Parking allows the current master to regain bus tenure
(during Phase 0) to perform new bus transactions.

6

2.0 Introduction to Futurebus

a

Arbitration (Continued)

2.1 THE ARBITRATION STATES

Figure 1

is an Arbitration State Diagram showing four states
that a module may enter as well as the events that cause
the module to change states during the arbitration process.
Transitions from one state to another occur only when cer­tain conditions are met, based on the arbitration phase and
the arbitration bus lines. Once a control acquisition cycle
has started, all modules must participate in the arbitration to
remain synchronized within the system.

TL/H/10747– 3

FIGURE 1

3.0 Introduction to DS3875
Arbitration Controller

The DS3875 Arbitration Controller implements the complete
requirements fo the IEEE 896.1 specifications. For example,
both arbitration modes of operation (Unrestricted and Re­stricted) are supported. Also, either Idle Bus Arbitration or
Parking may be selected for cases when only one request
or no request for bus competition exist. The controller is
software configurable to operate as a slow/fast module.
This selects the minimum time the arbitration controller
must wait during the arbitration competition before it can
read the resulting competition status. This delay allows arbi­tration competition lines (AB[7... 0]*, ABP*) to settle due
to several arbitration numbers being applied to them (Wire­ored bus lines). Further, a built-in PLL, which accepts a
clock signal from 2 MHz to 40 MHz, in steps of 1 MHz,
controls several programmable delay lines used for releas­ing ar* after issuing CMPT*/IBAÐCMPT* (PS(1:0)). This
delay compensates for the chip to chip skew to ensure suffi­cient time to drive the arbitration competition number onto
the arbitration competition lines during normal arbitration; or
to assert the AD/DATA lines during Idle Bus Arbitration be­fore releasing ar*. Internally, the PLL also generates the 1
ms timer used during arbitration phase 2 and phase 4.

The Arbitration Controller supports Arbitration message
sending. A FIFO strobe, FSTR*, is provided to store more

than one arbitration message externally to prevent overrun.
Also a hardwired register contains the first word of the arbi­tration message (h

Ê

1ff). Additional registers which hold arbi­tration numbers, status information, controller configuration
information, and an arbitration message can be accessed
by the host through Read/Write operations. For outgoing
arbitration numbers, the on chip parity generator unloads
the host of the parity generation function. For incoming arbi­tration numbers, the DS3885 Arbitration Transceiver per­forms the parity check function and drives the PER* input
signal to the Controller. Separate interrupt pins for error oc­currence, reception of an arbitration message, and recep­tion of Powerfail message are available. These interrupts
are cleared by performing a dummy write cycle to these
registers.

3.1 DS3875 Futurebus

a

Arbitration Controller (Distrib-

uted) Configuration for IEEE 896.1 Compliance

The DS3875 Futurebus

a

Arbitration Controller implements
the complete requirements of the IEEE 896.1 specification.
On chip reset (RST*), the arbiter defaults to the 896.1 com­pliance configuration features.

The D53875 Distributed Arbiter was designed before the

896.1 specification was finalized. Thus, it contains additional
options that can he selected in proprietary bus applications
or 896.1 compatible bus applications. There are three fea­tures in total that can be chosen through register program­ming.

First an explanation of each feature will be given, so that if
an application can take advantage of the option, it can be
programmed. Then, the 896.1 compliance configuration is
given so the arbiter will operate in complete accordance
with the specification.

Arbitration Number: Unrestricted/Restricted Mode

In Distributed Arbitration, both priority and fairness protocols
are implemented. Applications requiring quick access to the
Futurebus

a

backplane can be assigned high priority to re­duce bus latency times. Applications with the same (equal)
need of the backplane bus, a fairness protocol is guaran­teed. Thus, distributed arbitration implements a fairness pro­tocol for modules assigned the same priority classification.

The arbitration competition number encodes this informa­tion onto eight lines: AB[7:0]and arbitration number line:
ABP. The Arbitration competition number consists of three
fields: priority, round robin, and geographical address. Dis­tributed Arbitration protocol allows from 1 to 256 priority lev­els. Systems not requiring more then two priority levels, a
single pass competition number will suffice, one bit for prior­ity. Systems with greater then two priority levels implement­ed will need a two pass competition number, where eight
bits are allocated for priority representation. Now, the com­petition number exactly contains: 5 bits for geographical ad­dress (this guarantees uniqueness), 1 bit for round robin,
either 1 bit for priority (single pass), or 8 bits for priority (two
pass), and 1 bit to designate if the number is single pass or
two pass. (Refer to Table II on page 14.)

When the DS3875 was designed, two modes of operation
were defined: Unrestricted and Restricted. The Unrestricted
mode allowed one and two pass competition numbers to
coexist in a system. The Restricted mode allowed only one
pass competition numbers. Now, the 896.1 specification

7

3.0 Introduction to DS3875
Arbitration Controller

(Continued)

only describes one method of operation. This method com­pletely corresponds to the Unrestricted mode. In the
DS3875, the R-U* bit in the CTRL2 register, configures the
operation mode of the arbiter. On reset, the arbiter is placed
in the unrestricted mode, in accordance to the 896.1 specifi­cation.

Arbitration Competition Settling Time

Distributed Arbitration uses contention logic to select the
winner of the competition cycle. The Arbitration competition
begins with all competing modules asserting the most signif­icant bit AB[7], of the competition number onto the back­plane lines. A bit wise comparison is performed where mod­ules are allowed to assert the subsequent bits only as long
as that module’s competition number bits thus far asserted
are greater than or equal to the bits seen on the backplane
lines. Thus, all competing modules begin asserting their
competition numbers onto the backplane lines, but at the
end, only the winning module will be allowed to assert it’s
competition number onto the backplane lines.

When the DS3875 was designed, two speeds where al­lowed in the FBUS

a

backplane system for the arbitration
competition settling time: Slow or fast. During the arbitration
cycle, modules would indicate if they had a fast or slow
competition settling time. If any module indicated that it had
a slow competition settling time, then all modules would
compete using the slow competition settling time, else, the
fast settling time would be used during the competition cy­cle. The DS3875 allows the user to program a fast or a slow
competition settling time. One of eight settling times can be
selected for each mode with 16 total possible delay times.

The IEEE 896.1 specification now allows each module to
use it’s worst case arbitration settling time, t

A

, as the mod­ule’s delay time to determine it’s win/lose status for the
arbitration competition. The ones and zeros combination in
the competition number plays a significant role in determin­ing the numbers settling time. Several factors are incorpo­rated into the t

A

calculation:

tpd: Maximum end to end signal propagation delay along

the transmission line (backplane). This is a function
of the maximum length of the transmission line.

tint: Delay between a change on any arbitration line,

ABx*, on the

input to a module

and the correspond-

ing

change on that module’s adjacent

arbitration
output, ab[x-1]*,orabp*, as its competition number
is applied to or withdrawn from those bits.

text: Delay between a change on any arbitration line,

ABx*,onthe

input of any other competing module

and the corresponding

changes on that module’s

ar­bitration outputs, ab[x-1]*,orabp*, as its competi-
tion number is applied to or withdrawn from those
bits.

twin: Maximum delay between the time when the arbitra-

tion bus, AB[7..0]*, becomes stable and equivalent
to cn[7..0]on the input to a module and the indica­tion within that module that it is the winner.

(Refer to 896.1 for more details).

Thus, now each module can evaluate it’s win/lose condition
when it’s t

A

time has elapsed. During a particular competi­tion, the winning module’s competition number will have the
longest worst case settling time since this is the module that
has placed all of it’s competition number bits onto the
FBUS

a

.

To use the DS3875 in the 896.1 compliant mode, the user
programs two delay values in the CTRL2 register that are
closest to the calculated worst case settling time for the
particular competition number. The FÐS* bit should corre­spond to the table (fast or slow) that the most desired delay
resides. The CTRL2 register bits PD3 to PD5 program the
delay number that corresponds to the fast mode operation,
and PD0 to PD2 program the delay number that corre­sponds to the slow mode operation. Thus, a delay that is
closest to the desired delay time should be selected both
from the fast (PD3 to PD5) table and the slow (PD0 to PD2)
table. The FÐS* bit will configure this arbiter in the fast or
slow mode of operation.

8

3.0 Introduction to DS3875
Arbitration Controller

(Continued)

CTRL2

7 6 543210

F

Ð

S*R

Ð

U*PD5 PD4 PD3 PD2 PDl PD0

During the competition cycle, if any module has selected the
slow mode of operation, AC0* is asserted during phase 1
for indication to all modules to operate in the slow mode.
Thus, each arbitration cycle will determine whether the pro­grammed fast delay value or the programmed slow delay
value is used for the arbitration number settling time delay.
The range of values in the fast and slow delay tables are
very close to each other and in some cases are exactly the
same that the desired delay value can be easily chosen.
The DS3875 is in complete accordance with 896.1 since
AC0* signal now only is evaluated in phase 3, 4, and 5, and
the t

A

number is individually determined for each number.

Idle Bus Arbitration

Previously, the Futurebus

a

specification allowed idle bus
arbitration. Idle Bus Arbitration (IBA) gives a module quick
access to Futurebus

a

when the current master has com­pleted it’s transfers. IBA occurs on the parallel highway,
AD[31:0]lines. When the arbitration cycle is in phase 0 and
the master module is not carrying out transactions, another
module initiates normal arbitration and IBA simultaneously.
In IBA, each module is assigned a particular AD[31:0]bit to
assert if a module wishes to get tenure of the bus. If more
then one module asserts a bit onto the address/data lines
then normal arbitration on the arbitration bus lines will deter­mine the new master. If only one module asserted a bit on
the address/data line, then during phase 2 of the normal
arbitration cycle that module will be given a bus grant signal.
Thus, IBA was specified to speed up the arbitration process
when there are not multiple contenders for the bus.

IEEE 896.1 no longer allows IBA. Now, only Parking is al­lowed. It lets the current Futurebus

a

master quickly access
the bus to perform other transfers when no other modules
want to use it. Parking issues the BGRNT* signal to the
current bus master during Phase 0.

For IEEE 896.1 compliance in the DS3875, the IBAÐPK* bit
of the CTRL3 register should disable IBA and enable Park­ing. On chip reset, Parking is selected. The IBAÐCMPT*
output signal of the DS3875 should not be connected and
IBAÐS* input signal should be connected to V

CC

.

Concluding Remarks

In retrospect, features which are no longer part of IEEE

896.1 specification were discussed. All of these features are
user selectable. The DS3875 can be easily configured to
operate in the 896.1 compliance mode. As a matter of fact,
on power up reset, the DS3875 is configured in the compli­ance mode. Briefly:

1. Arbitration Number:

CTRL2 register: RÐU* bit

Unrestricted mode now corresponds with
the 896.1 arbitration number representa­tion scheme.

2. Arbitration Settling Time Delay:

CTRL2 register: Program as desired.

Select a delay from the fast table and
slow table that closely matches the worst
case arbitration settling time number, t

A

.

3. IBA:

CTRL3 register: IBAÐPK* bit

Enable Parking for 896.1 compliance
which simutanously disables IBA.

9

4.0 DS3875 Interfaces

The Arbitration Controller interfaces with the DS3884A
Handshake Transceiver, DS3885 Arbitration Transceiver,
host with other support chips, Protocol Controller, and Re­set and Initialization logic.

Figure 2

depicts an internal block diagram of the DS3875

Arbitration Controller.

Figure 3

shows the interface between
the DS3875 Arbitration Controller and the other logic on the
module.

The DS3884A Handshake Transceiver drives the arbitration
handshake and condition signals to the arbitration controller
(API, AQI, ARI, AC0I, AC1I). The Arbitration Controller con­tinuously monitors the Futurebus

a

backplane through
these signals. Whether the Arbitration Controller is compet­ing in the current control acquisition cycle or not, it drives
the arbitration handshake and condition signals (APO, AQO,
ARO, AC0O, AC1O) which the handshake transceiver
drives onto the Futurebus

a

backplane.

TL/H/10747– 4

FIGURE 2

10

4.0 DS3875 Interfaces (Continued)

TL/H/10747– 5

FIGURE 3

When competing the DS3885 Arbitration Transceiver is en­abled to place the competition numbers CN(7 . . . 0) and its
associated parity bit, CNp, onto the Futurebus

a

backplane.
During every cycle, whether or not competing, the winning
module’s arbitration number is read, the value of
WIN*ÐGT* signal and PER* signal is determined and up­dated in the appropriate internal registers.

The host can read or write (R/W) into the Arbitration Con­troller registers to change the controller configuration,
check status, or R/W a new arbitration number/message.
The host can select to latch data either on the falling edge
of DSACK* or on the rising edge of CS* by releasing or
asserting the SEL pin.

The Module may become bus master during Phase 5 if the
normal arbitration cycle was successful, Phase 0 if Parking
was successful, or Phase 2 if IBA was successful. Upon
becoming bus master, the Arbitration Controller will issue
BGRNT*. This signal indicates to the Protocol Controller

that it can now perform the desired transactions on the Par­allel address/data bus.

The Protocol Controller will let the Arbitration Controller
know if it has locked resources by asserting the LKD* sig­nal. If resources were locked, then at transfer of tenure, the
Arbitration Controller will issue UNLK* to the Protocol Con­troller to unlock resources.

A dummy cycle will be initiated by the Arbitration Controller
to perform the unlocking function if lock (LKD*) is still as­serted after end of tenure (ENDT*) is asserted and no other
modules are competing. Unlock will be asserted at the
transfer of bus tenure (even if this module wins the competi­tion). If another module initiates arbitration competition this
module will participate in the competition and will issue the
unlock (UNLK*) signal upon transfer of bus tenure. When
the bus transaction is complete and no resources are
locked, the Protocol Controller has the option of enabling
either Idle Bus Arbitration or parking (IBAÐPK* in CTRL3).

11

4.0 DS3875 Interfaces (Continued)

The input signal ALL1* (AB[7...0]*and ABp* all asserted)
is used to determine if any module is sending an arbitration
message during pass 1. For convenience, the Arbitration
Controller outputs FSTR* (to an external FIFO) during mes­sage reception so more than one arbitration message may
be stored by the module.

The Arbitration Controller has dedicated interrupt pins
(ERINT*, MGINT*, PFINT*) that interface with the Protocol
Controller so that important messages and error indications
can be quickly detected.

The Protocol Controller will issue the message request or
bus request signals to the DS3875. When a message has
been transmitted (Second Pass of arbitration, Phase 5), the
Arbitration Controller will assert MGTX*.

On board reset, initialization, power-up, and live insertion
logic will inform the Arbitration Controller which type of reset
operation to perform: Power-Up Reset (RST*), Initialization
(RINT*), or live insertion (HALT*). See Sections 10.0 and

11.0 for more information.

5.0 Arbitrating for Futurebus

a

The arbitration process allows a module to seek and gain
tenure of Futurebus

a

to transfer data to or from another
module. The arbitration process is independent of the data
transfer process and may take place concurrently with data
transactions on Futurebus

a

. If a module (or several mod­ules) want to use the bus, an arbitration competition takes
place. The module with the highest arbitration number gets
tenure of the bus.

The National Semiconductor solution to Futurebus

a

arbi­tration includes the DS3875 Arbitration Controller, the
DS3885 Arbitration Transceiver and the DS3884 Hand­shake Transceiver (see front page system block diagram).
More information on Arbitration as it applies to the Future­bus

a

IEEE standard is available in Section 5 of the ‘‘Futu-

rebus

a

P896.1 Logical Layer Specification’’.

5.1 UNRESTRICTED/RESTRICTED MODES OF
OPERATION

The Arbitration Controller supports either the Unrestricted
or the Restricted mode of arbitration. In the system environ­ment, all modules must be configured to operate in the
same mode at any given time.

During initialization, the Unrestricted mode is set since it
must be supported by all modules. The Unrestricted mode
allows a single pass of an 8-bit arbitration number or a two
pass of a 16-bit arbitration number to be used.

Futurebus

a

allows arbitration numbers requiring a single

pass control acquisition cycle to be mixed with those requir-

ing a two pass control acquisition cycle. During the first pass
of a two pass cycle, more than one module may have the
same number; however, during the second pass only one
winner results where the competition numbers must be
unique. A logic zero in the RUÐbit of the CTRL2 register
selects the unrestricted mode.

The Restricted mode of operation is optional and is selected
by setting the RUÐbit to a logic one in the CTRL2 register.
This mode limits arbitration numbers to 8 bits. Thus, only a
single control acquisition cycle occurs where all numbers
are unique. The arbitration numbers are assigned by the
module and can be dynamically changed.

5.2 THE ARBITRATION NUMBER AND ARBITRATION
CIRCUIT

Each module has a unique arbitration number. When two or
more modules compete for the bus, the module with the
highest arbitration number will win the competition.

The DS3885 Arbitration Transceiver contains the arbitration
circuit. See

Figure 4

for a functional model of the arbitration
circuit. A Parallel Contention Arbitration Protocol controls
how modules assert and release the AB[7 ... 0]* and
ABp*. After a period of time (ta) the protocol ensures that
only the winners arbitration number will remain on the
AB[7... 0]*and ABp*.

The arbitration number consists of one or two competition
numbers, CN(7 . . . 0). The Arbitration Controller Transmits/
Receives the competition number to/from the Arbitration
Transceiver. The CNÐLE* signal latches the competition
number into the transceiver while the ABÐRE* signal al­lows the controller to read in the winner’s competition num­ber. Along with the competition number, the Arbitration Con­troller transmits the CNp bit, the generated parity bit of the
competition number, to the Arbitration Transceiver. Odd
parity, as specified in the Futurebus

a

specifications, is im­plemented. Thus, CNp is set when even number of ones are
present in the competition number. When CN(7 . . . 0) is
received from the Arbitration Transceiver, the PER* bit is
checked for error detection.

Referring to Table II, in the Unrestricted mode, the CN7 bit
indicates if the module requires another arbitration pass.
When a one pass and a two pass arbitration number occur
in the same control acquisition cycle, the one pass arbitra­tion number will win.

The DS3875 allows the module to dynamically change the
arbitration number by writing into the TXCN0 and/or the
TXCN1 registers (see Section 7). If the arbitration number is
changed during an arbitration cycle it will be used in the next
arbitration competition.

The arbitration number is composed of three fields: Priority
Field, Round Robin Field, and a Unique Field.

12

5.0 Arbitrating for Futurebus

a

(Continued)

TL/H/10747– 6

FIGURE 4. FuturebusaFunctional Model of the Arbitration Circuit

13

5.0 Arbitrating for Futurebus

a

(Continued)

5.2.1 Priority Field (PR)

The priority field represents a module’s priority class which
is determined by the system designer. In the unrestricted
mode, the length of this field is a maximum of eight bits
while in the restricted mode it is two bits.

5.2.2 Round Robin Field (RR)

This field is represented by a single bit, CN5, in both modes
of operation. The round robin protocol ensures that all mod­ules in the same priority class have fair and equal access of
the bus. A module is allowed to get tenure of the bus in a
sequence defined by its value in the unique field.

The round robin bit is adjusted by the Arbitration Controller
each time a transfer of tenure occurs in the module’s same
priority class whether or not the module is competing in the
control acquisition cycle. In the module’s same priority
class, the round robin bit is set when tenure of the bus is
transferred to a module with a larger unique field value or
the round robin bit is cleared when tenure of the bus is
transferred to a module with a lesser unique field value.

In the event, where the module’s arbitration number is
changed, after the next control acquisition cycle, the round
robin bit is adjusted accordingly.

5.2.3 Unique Field (U)

The five bit unique field, CN(4 . . . 0), guarantees the unique­ness of the module’s arbitration number. The unique num­ber may correspond to the module’s geographical address
or may be allocated by the system designer as he chooses

while also in such a way that minimizes the arbitration set­tling time. The value ‘‘11111’’ is not allowed in systems us­ing arbitration messages.

5.3 ARBITRATION CATEGORIES

A module can be in one of six categories when a control
acquisition cycle is in progress;

#

Competitor for the Parallel bus

#

Competitor to send a message

#

By-Stander

#

By-Stander who decides to invoke Pre-emption

#

Master

#

Master Elect

5.3.1 Competitor for the Parallel Bus

A Module may become a competitor for the parallel bus if it
issues a Bus Request (! BRQ*) to the arbitration controller
before the arbitration cycle Phase 1 starts, see

Figure 5a

.

If the module issues a bus request and the arbitration cycle
is in phase 0, the controller will assert APO to start an arbi­tration competition. If an arbitration competition has already
started, and the module’s bus request comes prior to API
being asserted on the arbitration bus, the module may enter
this arbitration cycle. If an arbitration competition has al­ready started, and the module’s bus request comes after
AP* being asserted on the arbitration bus, the module will
have to wait until the next arbitration cycle to compete (or
pre-empt the current arbitration cycle in Phase 3).

TABLE II. Arbitration Number

Bit CN7 CN6 CN5 CN4 CN3 CN2 CN1 CN0

Unrestricted ModeÐSingle Pass

Pass 1 1 PR0 RR U4 U3 U2 U1 U0

Unrestricted ModeÐTwo Pass

Pass 1 0 PR7 PR6 PR5 PR4 PR3 PR2 PR1

Pass 2 1 PR0 RR U4 U3 U2 U1 U0

Restricted Mode

Pass 1 PR1 PR0 RR U4 U3 U2 U1 U0

Arbitration Message

Pass 1 11111111

Pass 2 a7 a6 a5 a4 a3 a2 a1 a0

14

5.0 Arbitrating for Futurebus

a

(Continued)

5.3.2 Competitor to Send a Message

The Arbitration Controller supports message sending. Mes­sage sending is implemented in the unrestricted mode in a
two pass arbitration cycle. The first pass of all ones (1FF H)
in the competition number identifies the transaction as a
message. The ALL1* input signal is asserted by the Arbitra­tion Transceiver when it detects 1FF H on the AB[7...0]*
and ABp* lines. The arbitration controller has a hardwired
register that holds the first pass word. Further, a dedicated
pin MGRQ* (message request) places the Arbitration Con­troller in the message sending mode.

The message that is to be transmitted is loaded into the
TXMSG register. The message of 1FF H is reserved as the
powerfail message. Other messages are to be coded by the
system designer with the greater priority messages having a
higher arbitration number. Obviously, if more than one mod­ule simultaneously desires to send a message, the message
with the highest arbitration number will be transmitted.

When a message is sent, no transfer of tenure takes place.
Thus, the master (M) or the round robin (RR) bits are not
updated. Upon successfully transmitting the message,
MGTX** signal is asserted.

When a message is received by the Arbitration Controller
(Phase 5), message interrupt (MGINT*) is asserted and
FIFO Strobe (FSTR*) is negated. In the case of a Powerfail
message being received; the PFINT* signal is asserted.
When the PFINT* signal is asserted, the MGINT* and
FSTR* signals are not generated. See

Figure 5d

.

When sending a message, once the MGRQ* signal is as­serted, until the message has been transmitted, all other
requests are blocked. Upon the MGTX* signal being re­leased, the message request signal will be reevaluated to
see if another message needs to be sent.

If this module is the module sending the arbitration mes­sage, then the message interrupt (MGINT*) or the Powerfail
interrupt (PFINT*) will not be generated on this module.
These interrupts are generated only upon the reception of a
message from another module. Refer to

Figure 5e

.

5.3.2.1 Using an External FIFO to Store Messages

The Arbitration Controller provides a FIFO strobe (FSTR*)
signal to store more than one arbitration message in an
external FIFO. A rising edge on FSTR* is generated upon
the reception of an arbitration message.

See

Figure 3

and Timing Diagrams: T6, Phase 2 and Phase

5.

1. FSTR* is always asserted (! FSTR*) during phase 2.

2. FSTR* is negated (FSTR*) during phase 5 given the fol­lowing conditions.

1. The message is not being sent by this module.

2. This is the second pass of an arbitration message.

3. No errors occurred during this arbitration cycle.

4. This is not a powerfail interrupt message (! PFINT*).

The external latch shown in

Figure 3

is enabled by ABÐRE*
to temporarily hold the message. While ABÐRE* is low
(see timing diagrams phase 2 and 5), the latch is fall
through. Then, during phase 5 on the rising edge of FSTR*,
the message held in the latch will be strobed into the FIFO.

5.3.3 By-Stander

A Module is considered a by-stander in the arbitration com­petition if it does not issue a Bus Request (! BRQ*)tothe
arbitration controller before arbitration cycle Phase 1 starts.

5.3.4 By-Stander Who Decides to Invoke Pre-emption

A module with a higher arbitration number than the master
elect may initiate a new arbitration cycle to establish a new
master. This process, referred to as pre-emption, allows a
high priority to acquire tenure of the bus with minimum laten­cy.

Pre-emption is allowed in phase 3 when all of the following
conditions are met:

1. the arbitration number is greater than the arbitration

number on the bus

2. a bus request signal was recently received

3. did not participate in the arbitration competition phase 2.

The master elect may be preempted by asserting AC1O.

Pre-emption is not allowed during:

#

the first pass of a two pass cycle

#

message sending

These two events are given higher precedence.

If a module decides to preempt and changes its competition
number during phase 2 or phase 3 in the Arbitration Control­ler, the Arbitration Transceiver will still use the current
latched competition number to make the greater than com­parison. When the next arbitration cycle occurs, the new
competition number will be used.

5.3.5 Master

The Master is the module that currently has tenure of the
parallel bus.

5.3.6 Master Elect

The Master Elect is the module that won the current arbitra­tion cycle. The Master Elect will become master upon trans­fer of tenure.

15

5.0 Arbitrating for Futurebus

a

(Continued)

TL/H/10747– 7

a. Normal Bus Request Timing

TL/H/10747– 8

b. Idle Bus Arbitration Timing

TL/H/10747– 9

c. Parking

FIGURE 5. Bus Request Timing (Normal Arbitration, Idle Bus Arbitration and Parking)

16

5.0 Arbitrating for Futurebus

a

(Continued)

TL/H/10747– 10

d. Message Receiving

TL/H/10747– 11

e. Message Sending

FIGURE 5. Bus Request Timing (Normal Arbitration, Idle Bus Arbitration and Parking) (Continued)

5.4 FUTUREBUS

a

OPTIONAL MEANS OF

ARBITRATION

Besides the normal Futurebus

a

Parallel Contention Arbitra-

tion, the Futurebus

a

Specification allows two other option-

al arbitration methods to acquire the parallel bus quickly:

#

Idle Bus Arbitration

#

Parking

Both of these arbitration methods are supported by the Na­tional Semiconductor DS3875 Arbitration Controller.

5.4.1 Idle Bus Arbitration (IBA)

Idle Bus Arbitration (IBA) is selected by setting the IBAPK*
bit in CTRL3 register. The aim of IBA is to give a module
quick access to Futurebus

a

when the current master has

completed its transfers.

IBA is invoked the same as a normal arbitration bus request
(! BRQ*) but uses the parallel bus (AS* negated, DS* as­serted, and the parallel address/data bus) to determine the
winner of the arbitration cycle, see

Figure 5a, b

.

During normal arbitration the transfer of Futurebusatenure
occurs during phase 5. During IBA the transfer of Future­bus

a

tenure occurs during phase 2. During IBA the AC1O
arbitration condition signal will be asserted by the new mas­ter. This will cancel the transfer of tenure during the normal
arbitration cycle. Note that Futurebus

a

tenure was trans­ferred but only the two modules involved in the IBA (the
master and the master elect) know that the transfer of ten-

ure has taken place. All the other modules involved in the
normal arbitration cycle see that the transfer of tenure dur­ing the normal arbitration cycle was canceled.

If two or more modules have a request, then normal arbitra­tion will determine which module will gain access. IBA takes
place on the parallel highway, AD/DATA (31 . . . 0). Each
module is assigned a bit which is to be asserted during IBA.
If only one bit is asserted during the IBA competition, then
IBA issues the bus grant signal to that module. Concurrently
with IBA, normal arbitration takes place. If a module does
not want IBA to issue a bus grant, IBA may be inhibited by
asserting DI*. During phase 5, normal arbitration will deter­mine appropriate actions.

5.4.1.1 Masters Support Circuitry to Enable IBA

If IBA is allowed, it is invoked during phase 0. In order to
support IBA external logic is needed in addition to the arbi­tration controller. The Masters external logic must monitor
the arbitration control acquisition synchronization signals
(AP*,AQ*,AR*) and the parallel bus address handshake
signals (AS*,AK*,AI*). If the master supports IBA it should
wait until it is ready to end its bus tenure (ENDT* asserted).
Then when it releases AS* it should assert ds* to enable
modules to participate in IBA competition.

5.4.1.2 Modules Support Circuitry to Participate in IBA

If a module wants to use IBA to gain tenure of Futurebus

a

it must use external logic to monitor the arbitration control

17

5.0 Arbitrating for Futurebus

a

(Continued)

acquisition synchronization signals (AP*,AQ*,AR*), the
parallel bus address handshake signals (AS*,AK*,AI*), the
parallel bus data sync signal (DS*) and data acknowledge
inverse (DI*), and the IBAÐCPT* output from the arbitration
controller.

5.4.2 Parking

During Power Up, the Arbitration Controller is programmed
to perform either Idle Bus Arbitration or Parking by setting or
clearing the IBAPK* bit in the CTLR3 register. Parking is
selected by clearing the IBAPK* bit. The aim of Parking is to
give the Futurebus

a

bus Master quick access to the bus to
perform other transfers when no one else desires to use it.
Thus, it is not necessary for the master to go through the
entire arbitration cycle to get the BGNT* signal. Parking is­sues BGNT* in Phase 0, see

Figure 5c

. If another module
gets a message request or bus request, the arbitration com­petition cycle begins like it normally does to handle the re­quest.

All of the following conditions should be met to take advan­tage of Parking:

1. Parking in selected

2. module must be the current Master

3. ENDT* signal is high

4. BGRNT* signal is high

5. BRQ* signal is asserted low while in phase 0

6. LKD* signal is high (Resources are not locked)

When these conditions are true, the Arbitration Controller
issues the BGRNT* signal (asserted low) in phase 0. Upon
end of tenure, BGRNT* signal will be released. The Master
may continue to use Parking to perform transactions until
after the arbitration competition cycle selects a new master
(see

Figures 5c

and7).

Parking is allowed only when the Master has all resources
unlocked (indicated by LKD* signal being high). During
phase 0, if the master still has resources locked (ENDT*
and BGRNT* signals are high), the Arbitration Controller will
immediately initiate a dummy cycle to unlock resources. The
UNLK* signal is generated during phase 5 upon the suc­cessful transfer of tenure. The transfer of tenure may be
with itself or another module.

5.5 THE ARBITRATION PHASES

The arbitration process consists of transitioning through six
phases (Phase 0 thru Phase 5) of the three arbitration syn­chronization signals (AP*,AQ*,AR*). To transition between
control acquisition phases only one of the three arbitration
synchronization signals will transition.

The Arbitration process is asynchronous and occurs as fast
as all the modules that contain arbitration logic can tran­sition through the arbitration phases. If a two-pass arbitra­tion competition has been selected the entire control acqui­sition cycle is repeated twice.

Each arbitration synchronization signal (AP*,AQ*,AR*)
represents the wire-OR of each of the individual synchroni­zation signals from each of the modules. For any of the
synchronization signals on the bus to be released, all the
modules must release their individual synchronization sig­nals (ap*,aq*,ar*). Therefore, the release of a synchroniza-
tion signal forms a global synchronization point for all the
modules. Likewise, during the assertion of a synchronization
signal all modules must remain synchronized by asserting
their own signals in response.

Each module must participate in the control acquisition cy­cle, whether or not the module is competing, to remain syn­chronized with the other modules.

Figure 6

is a timing dia-

gram of the Control Acquisition Sequence.

Figures 7a –f

are
state transition diagrams of the DS3875 Arbitration Control­ler. Tables III and IV represent the internal register bits that
are affected by the arbitration states and their transitions.

The DS3875 Arbitration Controller transitions to the next
arbitration phase upon (see

Figure 6

):

1. APO output signal being asserted to phase 1

2. ARI input signal being negated to phase 2. (This input is

filtered and indicates all modules have released the AR*
synchronization signal on the Futurebus

a

backplane.)

3. AQO output signal being asserted to phase 3

4. API input signal being negated to phase 4. (This input is

filtered and indicates all modules have released the AP*
synchronization signal on the Futurebus

a

backplane.)

5. ARO output signal being asserted to phase 5

6. AQI input signal being negated to phase 0. (This input is

filtered and indicates all modules have released the AQ*
synchronization signal on the Futurebus

a

backplane.)

18