Philips fb2012a DATASHEETS

Philips Semiconductors Futurebus+ Products Preliminary specification

FB2012AFuturebus+ central arbitration controller

November 11, 1994

GENERAL DESCRIPTION OF THE FB2012A

The FB2012A is the central arbitration controller for the Futurebus+ product family. When a module needs to send data to or obtain data from another module, it must first gain tenure of the bus. The FB2012A controls or arbitrates tenure of the bus to one module at a time.

The FB2012A includes BTL drivers and receivers for signals that use the Futurebus+ backplane. Since the request and grant lines are point-to-point, they need to be terminated only at the receiver. Request lines are terminated at the FB2012A, and grant lines are terminated at the individual Futurebus+ modules. If stub lengths to the FB2012A create problems for the RE* and PE* signals, an external BTL receiver may be used for RE* and and an external BTL driver may be sourced by the TTL PE* signal. If the external BTL receiver is inverting, the resulting TTL signal (RE*) must be inverted as well.

GENERAL DESCRIPTION OF THE FUTUREBUS+ CENTRAL ARBITRATION PROTOCOL

A requesting module asserts either a level-1 (RQH*) or a level-0 (RQL*) request to obtain bus mastership. A low-priority (level-0) request may become a high-priority request by leaving the low-priority request asserted while also asserting the corresponding high-priority (level-1) request.

A module may release the request(s) anytime after a grant is received from the FB2012A if the need for a bus transaction vanishes. Once a request is made, it may not be removed until the corresponding grant has been received (according to IEEE 896.1). (The FB2012A gives the user the option to release a request before the corresponding grant is asserted or to follow IEEE 896.1.)

A requesting module becomes the bus master only after it receives the bus grant and the current bus master releases its tenure (the current bus master has released its request, but may still be in the middle of a transaction). This condition is indicated by the continued assertion of ET*. When the current bus master has finished its transaction and has released the address/data bus, it releases ET*. Once the module with the asserted bus grant detects the release of ET*, it becomes the bus master and may begin its transaction. The bus master’s request(s) must remain asserted until it asserts ET*. Refer to FUNCTIONAL WAVEFORMS.

The central arbiter asserts PE* to indicate that a preemptive condition exists and that the current bus master should relinquish the bus. The definition of the preemptive condition is described in the FUNCTIONAL DESCRIPTION section below.

FEATURES

•The Philips Semiconductors Central Arbitration Controller is

compatible with the IEEE P896.6 Futurebus+ standard

•14 level-1 first-come-first-served requests

•14 level-0 first-come-first-served requests

•14 bus grants

•Priority preemption

•Timing for Futurebus+ RE* signal

– Bus initialization – System reset

•68-pin PLCC package

QUICK REFERENCE DATA

SYMBOL PARAMETER TYPICAL UNIT

PLH

Propagation delay 5.2

PHL

RQXn to GRn 8.6

Output capacitance 6 pF

TTL outputs 4

Output current

BTL outputs 80

Supply current 80 mA

ORDERING INFORMATION

PACKAGE

COMMERCIAL RANGE

= 5V±10%; T

amb

= 0 to +70°C

DWG

No.

68-pin Plastic Leaded Chip Carrier FB2012AA 0398E

Philips Semiconductors Futurebus+ Products Preliminary specification

FB2012AFuturebus+ central arbitration controller

November 11, 1994

PIN CONFIGURATION

6789

10 11 12 13 14 15 16

27 28 29 30 31 32 33

345

34 35 36 37 38 39

17 18 19 20 21 22

6812 656667

40 41 42 43

64 616263

23 24 25 26

RQL13*

ANYGR*

BINIT*

SYSRST*

PPE*

BIAS V

LOGIC GND

EN*

TESTEN

TCK (option)

TMS (option) TDO (option)

TDI (option)

RQH13*

GRO* GR1* GR2* GR3* BUS GND GR4* GR5* GR6*

BUS GND GR7* GR8* GR9* BUS GND GR10* GR11* GR12* GR13*

RQL12*

RQL11*

RQL10*

RQL9*

RQL8*

Vcc

RQL7*

RQL6*

RQL5*

RQL4*

LOGIC GND

RQL3*

RQL2*

RQL1*

RQL0*

RE*

BUS GND

RQH12*

RQH11*

RQH10*

RQH9*

RQH8*

Vcc

RQH7*

RQH6*

RQH5*

RQH4*

LOGIC GND

RQH3*

RQH2*

RQH1*

RQH0*

PE*

BUS GND

Futurebus+ Central

Arbitration Controller

FB2012A

SG00054

LOGIC DIAGRAM

RQH[13-0]*(BTL)

RQL[13-0]*(BTL)

EN*

PPE*

RE*(BTL)

TESTEN

BIAS V

NC = 18

LOGIC GND(3)

BUS GND(5) (BTL)

(3)

GR[13-0]* (BTL)

ANYGR*

PE* (BTL)

BINIT*

SYSRST*

JTAG (future boundary scan option)

TMS TCK

TDI TDO

26-31, 33-36, 38-41

1-3, 5-10, 63-66, 68

19, 37, 67

43, 48, 52, 56, 61

4, 17, 32

23 22

25 24

44-47, 49-51, 53-55, 57-60

CENTRAL

ARBITRATION

CONTROLLER

FB2012A

SG00055

Philips Semiconductors Futurebus+ Products Preliminary specification

FB2012AFuturebus+ central arbitration controller

November 11, 1994

FUNCTIONAL DESCRIPTION OF THE FB2012A

The FB2012A has two priority levels, each with 14 inputs. For ease of labeling, the two priority levels, labeled RQ1* and RQ0* in the Futurebus+ 896.1 specification, are labeled RQHn* (level-1) and RQLn* (level-0), respectively, on the FB2012A, where ‘n’ is the module number from 0 through 13. The assignment of a module to a particular request line has no significance; all requests (of a particular priority level) are treated identically. Once asserted, a request should remain asserted until the corresponding grant is received (according to IEEE 896.1). (If the user chooses to release a request before the corresponding grant is asserted, he may do so; the FB2012A allows this option.) Level-0 and level-1 requests may be asserted simultaneously. Refer to FUNCTIONAL WAVEFORMS for general functionality.

A grant will become active only after any metastable conditions involving its request(s) are resolved. Only one of the 14 grant lines will be active at a time. The order of serviced requests for each level is first-come-first-served (FCFS) — the request that has been asserted the longest receives the grant. However, level-0 requests are serviced only when no level-1 requests are asserted.

The grant outputs are enabled when the EN* input is Low. However, when EN* is released while a grant is active, the grant will remain active until the corresponding request(s) are released. Also, whenever a grant is asserted, the ANYGR* output signal will also be asserted.

The FB2012A has two preemption modes:

1. If the PPE* input is asserted (priority preemption mode), PE* and pe will be asserted whenever there is a level-1 request that is not being serviced while another grant is asserted. That is, the preemption lines will be asserted if more than one level-1 request is asserted or if a level-0 request is being serviced when a level-1 request(s) is asserted.

2. If PPE* is not asserted, PE* and pe will be asserted whenever two or more requests, regardless of their priority levels, are asserted. (Assertion of a level-1 request and a level-0 request from the same module is considered as a single request.)

The action taken by a module when PE* (and pe) are asserted is strictly up to the designer.

The FB2012A monitors RE* to detect the signaling of the bus initialize and system reset conditions. If the RE* input is asserted less than 2.0ms, neither BINIT* (bus initialize) nor SYSRST* (system reset) will be asserted. If RE* is asserted longer than

2.0ms, BINIT* may be asserted; and after 3.9ms BINIT* is

guaranteed to be asserted. If RE* is asserted longer than 30ms, SYSRST* may be asserted; and after 60ms SYSRST* is also guaranteed to be asserted. If asserted, BINIT* and SYSRST* will be released after RE* has been released at least 60ns and no more than 140ns.

When BINIT* is asserted, future grants are disabled in the same way that they are disabled in response to the de-assertion of the EN* signal. (Normally all requests are removed during bus initialization). When SYSRST* is asserted, PE* (and pe) will also be forced into the asserted state independently of pre-emption conditions. After RE* has been continuously released for at least

1µs and for not more than 2.2µs, the grants are re-enabled and PE* (with pe) is released from its forced assertion, if it had entered one. (In some systems, the assertion of PE* for at least 1µs after the release of RE* (following system reset) is a condition that signals the presence of a central arbiter.)

To accommodate the possibility of a system requirement for redundant and removable FB2012A, a BIAS V input is provided to bias the internal BTL circuity. This way the redundant FB2012A may be live inserted without disrupting system operation.

For designs with a single FB2012A, the BIAS V input should be connected to V

METASTABILITY CHARACTERISTICS OF THE FB2012A

One of the concerns when dealing with an asynchronous arbiter is understanding what would happen when competing requests arrive at the same time. Input requests are processed by a bank of mutual-exclusion elements. A mutual-exclusion element (ME) is a state-holding device that arbitrates between a pair of inputs. This is the point at which metastabilities can occur. The design of the ME precludes anomalous signaling by suppressing output assertion until metastabilities are resolved.

To determine the Mean Time Between Unacceptable Delays (MTBUD) the following formula is used:

MTBUD 

exp(

t



)

)(fr1fr2)

t’ is the maximum acceptable delay between the request edge (RQXn) and the corresponding grant output signal (GR*); and f

the frequency of the request inputs. The central arbiter has metastability characteristics of τ of 93ps, T

of 2.3E33 seconds, and a normal propagation of 8.76ns measured at room temperature and 5V V

. (Those unfamiliar with these parameters may consult Philips Semiconductors application note AN219, “A Metastability Primer”.)

The following example shows that at an individual ME, metastability induced delays of appreciable size are extremely rare.

Assume that there are two possible requests and the average request frequency for each is 250kHz. From the formula above, with a t’ of 10.76ns (8.76ns + 2ns), the MTBUD is calculated to be 341 hours. If t’ was 12.76ns, the MTBUD would be about 85 million years. Notice that 12.76ns is only an additional four nanosecond delay above the normal propagation delay. (This example assumes that a module may make a request immediately upon releasing tenure.)

The example illustrates only two modules competing for the bus. In real systems more request channels are active and more MEs are involved. If ‘n’ channels are active, then n(n-1)/2 MEs are active. Note, however, that any metastabilities that occur while a grant is active undesired delay would be noticed.

It is difficult to imagine that a user would ever experience a grant delay that cannot be tolerated.

+ 6 hidden pages