
C161U
External Bus Interface
Data Sheet
194
2001-04-19
Synchronous READY
provides the fastest bus cycles, but requires setup and hold
times to be met. The CLKOUT signal
should be enabled
and may be used by the
peripheral logic to control the READY timing in this case.
Asynchronous READY
is less restrictive, but requires additional waitstates caused by
the internal synchronization. As the asynchronous READY is sampled earlier (see figure
above) programmed waitstates may be necessary to provide proper bus cycles (see also
notes on “normally-ready” peripherals below).
A READY signal (especially asynchronous READY) that has been activated by an
external device may be deactivated in response to the trailing (rising) edge of the
respective command (RD or WR).
Note:
When the READY function is enabled for a specific address window, each bus
cycle within this window must be terminated with an active READY signal.
Otherwise the controller hangs until the next reset. A timeout function is only
provided by the watchdog timer.
Combining the READY function with predefined waitstates
is advantageous in two
cases:
Memory components with a fixed access time and peripherals operating with READY
may be grouped into the same address window. The (external) waitstate control logic in
this case would activate READY either upon the memory’s chip select or with the
peripheral’s READY output. After the predefined number of waitstates the C161U will
check its READY line to determine the end of the bus cycle. For a memory access it will
be low already (see example a) in the figure above), for a peripheral access it may be
delayed (see example b) in the figure above). As memories tend to be faster than
peripherals, there should be no impact on system performance.
When using the READY function with so-called “normally-ready” peripherals, it may lead
to erroneous bus cycles, if the READY line is sampled too early. These peripherals pull
their READY output low, while they are idle. When they are accessed, they deactivate
READY until the bus cycle is complete, then drive it low again. If, however, the peripheral
deactivates READY
after
the first sample point of the C161U, the controller samples an
active READY and terminates the current bus cycle, which, of course, is too early. By
inserting predefined waitstates the first READY sample point can be shifted to a time,
where the peripheral has safely controlled the READY line (eg. after 2 waitstates in the
figure above).