Motorola DSP96002 User Manual

Page 22

MOTOROLA

DSP96002 USER’S MANUAL

2 - 19

ZZ = ^end_of_sequence

v ( ext_acc_req & ^

—

–

G )

(note 3)

ZW = ^ext_acc_req

& ^

—

–

WX = ^ext_acc_req

—

–

WY = NON-EXISTENT ARC

(note 2)

WZ = ext_acc_req

WW = ^ext_acc_req & ^

—

–

Notes: 1. Illegal arcs in DSP96002 since once the request of the bus is pending, it will not be canceled

before the execution of the access.

2. Non-existent arc since if ext_acc_req arrives together with the negation of

—

–

G, the device

becomes active master and begins its bus transfers.

—

–

G is

—

–

G delayed by one phase. This is done to provide a response to the

ext_acc_req signal when it is asserted at the same phase together with

—

–

G negation.

5.16.3 Bus Arbitration Example Cases

5.16.3.1 Case 1 – Normal

If the device requesting mastership asserts

—

–

R: the arbiter asserts the requesting devices’

—

–

G and

—

–

B is deasserted indicating the bus is not busy. The requesting device will assert

—

–

5.16.3.2 Case 2 – Bus Busy

If the device requesting mastership asserts

—

–

R: the arbiter responds by asserting the requesting devic-

es’

—

–

G; however, the bus is busy because

—

–

B is asserted. The requesting device will not assert

—

–

A until

—

–

B is deasserted.

5.16.3.3 Case 3 – Low Priority

If the device requesting mastership asserts

—

–

R: the arbiter withholds asserting the requesting devices’

—

–

G because a higher priority device requested the bus.

—

–

A of the requesting device will not be as-

serted.

5.16.3.4 Case 4 – Default

If a device does not request the bus and it is not in the bus parking state but rather it is in the idle state: the

arbiter, by design (i. e., default), asserts

—

–

—

–

A will remain deasserted.