7.0 Bus Interface (Continued)
7.3.6 Bus Exceptions (Bus Retry)
The SONIC-T provides the capability of handling errors during the execution of the bus cycle
(Figure 7-18)
.
The system asserts BRT (bus retry) to force the SONIC-T to
repeat the current memory cycle. When the SONIC-T detects the assertion of BRT
, it completes the memory cycle
at the end of T2 and gets off the bus by deasserting BGACK
or HOLD. Then, if Latched Bus Retry mode is not set (LBR
in the Data Configuration Register, Section 6.3.2), the
SONIC-T requests the bus again to retry the same memory
cycle. If Latched Bus Retry is set, though, the SONIC-T will
not retry until the BR bit in the ISR (see Section 6.3.6) has
been reset and BRT
is deasserted. BRT has precedence of
terminating a memory cycle over DSACK0,1
, STERM or
RDYi
.
BRT may be sampled synchronously or asynchronously by
setting the EXBUS bit in the DCR (see Section 6.3.2). If
synchronous Bus Retry is set, BRT
is sampled on the rising
edge of T2. If asynchronous Bus Retry is set, BRT
is double
synchronized from the falling edge of T1. The asynchronous
setup time does not need to be met, but doing so will guarantee that the bus exception will occur in the current bus
cycle instead of the next bus cycle. Asynchronous Bus Retry may only be used when the SONIC-T is set to asynchronous mode.
Note 1: The deassertion edge of HOLD is dependent on the PH bit in the
DCR2 (see Section 6.3.7). Also, BGACK
is driven high for about 0.5
bus clocks before going TRI-STATE.
Note 2: If Latched Bus retry is set, BRT
need only satisfy its setup time (the
hold time is not important). Otherwise, BRT
must remain asserted
until after the Th state.
Note 3: If DSACK0,1, STERM
or RDYi remain asserted after BRT, the next
memory cycle, may be adversely affected.
7.3.7 Slave Mode Bus Cycle
The SONIC-T’s internal registers can be accessed by one of
two methods (BMODE
e
1 or BMODEe0). In both methods, the SONIC-T is a slave on the bus. This section describes the SONIC-T’s slave mode bus operations.
7.3.7.1 Slave Cycle for BMODE
e
1
The system accesses the SONIC-T by driving SAS,CS,
SRW
and RAk5:0l. These signals will be sampled each
bus cycle, but the SONIC-T will not actually start a slave
cycle until CS
has also been asserted. CS should not be
asserted before SAS
is driven low as this will cause improp-
er slave operation. Once SAS
has been driven low, between
one and two bus clocks after the assertion of CS
, SMACK
will be asserted to signify that the SONIC-T has started the
slave cycle. Although CS
is an asynchronous input, meeting
its setup time (as shown in
Figures 7-19
and
7-20
) will guar-
antee that SMACK
, which is asserted off of a falling edge,
will be asserted 1 bus clock after the falling edge that CS
is
clocked in on. This is assuming that the SONIC-T is not a
bus master when CS
was asserted. If the SONIC-T is a bus
master, then, when CS
is asserted, the SONIC-T will complete its current master bus cycle and get off the bus temporarily (see Section 7.4.8). In this case, SMACK
will be as-
serted 5 bus clocks after the falling edge that CS
was
clocked in on. This is assuming that there were no wait
states in the current master mode access. Wait states will
increase the time for SMACK
to go low by the number of
wait states in the cycle.
If the slave access is a read cycle
(Figure 7-19)
, then the
data will be driven off the same edge as SMACK
.Ifitisa
write cycle
(Figure 7-20)
, then the data will be latched in
exactly 2 bus clocks after the assertion of SMACK
. In either
case, DSACK0,1
are driven low 2 bus clocks after SMACK
to terminate the slave cycle. For a read cycle, the assertion
of DSACK0,1
indicates valid register data and for a write
cycle, the assertion indicates that the SONIC-T has latched
the data. The SONIC-T deasserts DSACK0,1
, SMACK and
the data if the cycle is a read cycle at the rising edge of SAS
or CS depending on which is deasserted first.
Note 1: Although the SONIC-T responds as a 32-bit peripheral when it
drives DSACK0,1
low, it transfers data only on lines Dk15:0l.
Note 2: For multiple register accesses, CS
can be held low and SAS can be
used to delimit the slave cycle (this is the only case where CS
may
be asserted before SAS
). In this case, SMACK will be driven low
due to SAS
going low since CS has already been asserted. Notice
that this means SMACK
will not stay asserted low during the entire
time CS
is low (as is the case for MREQ, Section 7.3.8).
Note 3: If memory request (MREQ
) follows a chip select (CS), it must be
asserted at least 2 bus clocks after CS
is deasserted. Both CS and
MREQ
must not be asserted concurrently.
Note 4: When CS
is deasserted, it must remain deasserted for at least one
bus clock.
Note 5: The way in which SMACK
is asserted due to CS is not the same as
the way in which SMACK
is asserted due to MREQ. The assertion
of SMACK
is dependent upon both CS and SAS being low, not just
CS
. This is not the same as the case for MREQ (see Section 7.3.8).
The assertion of SMACK
in these two cases should not be con-
fused.
TL/F/11719– 45
FIGURE 7-18. Bus Exception (Bus Retry)
67