pef20320 Infineon Technologies Corporation, pef20320 Datasheet - Page 43

• Manufacturer Part Number: pef20320
• Description: Multichannel Network Interface Controller For Hdlc With 32 Channels
• Manufacturer: Infineon Technologies Corporation

PEB 20320
Functional Description
2.2.2
Motorola Mode
In Motorola mode the bus is used in an asynchronous manner. The bus operation uses
the handshake lines (AS, DS, DSACK and BERR) to control data transfer as shown in
Figure 21, Figure 22. Address strobe AS indicates the validity of an address on the
address bus (A31 … A2) and of the bus definition R/W (Read or Write cycle). It is
asserted half a clock cycle after the beginning of a bus cycle. The data strobe DS signal
is used as a condition for valid data of a write cycle. MUNICH32 asserts DS one full clock
cycle after the assertion of AS during a write cycle. The data is placed on the bidirectional
data bus (D31 … D0) half a clock cycle after AS is driven low. For a read cycle,
MUNICH32 asserts DS to signal the external memory to drive the data on the bus. DS
is asserted at the same time as AS during a read cycle. The data is latched with the last
falling edge of the clock for that cycle.
The bus cycle is terminated if the data transfer acknowledge (DSACK) is asserted with
the falling edge of the third clock period. Otherwise MUNICH32 inserts wait cycles until
DSACK is recognized. AS and DS are driven high half a clock period before bus cycle
end.
The bus error BERR is also a bus cycle termination indicator. It can be used in the
absence as well as in conjunction with DSACK. If an abnormal termination has occurred
during a read cycle, MUNICH32 generates an interrupt and aborts the corresponding
transmit channel. For a write cycle no further action is performed.
As the MUNICH32 is used in a multi-bus-master application, bus arbitration has to be
done to avoid simultaneous system bus access by more than one master. In Motorola
mode the bus arbitration protocol of the 68020 is established using the signals BR, BG,
BGACK and BGO as shown in Figure 23. The wired-or Bus Request (BR) is driven low
to indicate to the processor that one of the MUNICH32s requires control of the bus. The
activated Bus Grant (BG) signals the availability of the system bus. If the MUNICH32 has
activated the bus request itself, it asserts the wired-or Bus Grant Acknowledge to
indicate that it has assumed bus mastership. Otherwise it will pass the BUS GRANT
signal to the device cascaded next (BGO). At the same time it releases the Bus Request.
After finishing the last bus cycle, the Bus Grant Acknowledge is deactivated and the Bus
Grant is passed on. In order to prevent blocking in the case of continuous request by one
device, MUNICH32 does not generate another Bus Request before the external Bus
Request and Bus Grant Acknowledge have been deactivated.
After getting the bus mastership MUNICH32 drives the bus and starts the first bus cycle
one clock after assertion of BGACK. After finishing the memory access it releases the
bus and de-asserts BGACK at the same time.
User’s Manual
43
01.2000