Intel Embedded Intel486 Hardware Reference Manual page 143

cache unit. So, regardless of the state of KEN#, code fetches are always burstable. In addition,
several types of data read cycles are generated as 8-byte cycles. These cycles, mentioned previ-
ously, are descriptor loads and floating-point operand loads. These cycles can be burst at any
time.
The use of the KEN# input affects performance. The design example used in
one way to use this signal effectively.
BLAST#
KEN#
DATA
BRDY#
The primary concern when using KEN# is generating it in time for zero wait state read cycles.
Most main memory cycles are zero wait state if an L2 cache is implemented. The access to main
memory is one wait state during most read cycles. Any cache access takes place with zero wait
states. KEN# must, therefore, be valid during the first T2 of any read cycle.
Once this requirement is established, a problem arises. Decode functions are inherently asynchro-
nous. Therefore, the decoded output that generates KEN# must be synchronized. If it is not, the
CPU's setup and hold times are violated and internal metastability results. With synchronization,
the delay required to generate KEN# will be at least three clocks. In the example shown, four
clocks are required. In either case the KEN# signal will not be valid before BRDY# is returned
for zero or one wait state cycles.
This problem is resolved if KEN# is made active.
gram KEN# is active during the first two clocks of the burst cycle. If this is a data read cycle,
KEN# being active at this time causes it to be converted to a 16-byte length. The decode and syn-
chronization of KEN# takes place during the first two T2 states of the cycle. If the cycle turns out
to be non-cacheable, KEN# is deactivated in the third T2. Otherwise KEN# is left active and the
retrieved data is written to the cache.
T1 T2 T2
Sampled
here
1 2
Figure 5-1. Typical Burst Cycle
Figure 5-2
MEMORY SUBSYSTEM DESIGN
Figure 5-1
T2 T2
Sampled
here
3 4
illustrates this function. In this dia-
illustrates
A5242-02
5-3