Terminating Multiple And Burst Cycle Transfers - Intel Quark SoC X1000 Core Developer's Manual

®
Bus Operation—Intel Quark Core
Burst cycles begin with the Intel
asserting ADS# in the same manner as non-burst cycles. The Intel
Core indicates that it is willing to perform a burst cycle by holding the burst last signal
(BLAST#) deasserted in the second clock of the cycle. The external system indicates its
willingness to do a burst cycle by asserting the burst ready signal (BRDY#).
The addresses of the data items in a burst cycle all fall within the same 16-byte aligned
area (corresponding to an internal Intel
aligned area begins at location XXXXXXX0 and ends at location XXXXXXXF. During a
burst cycle, only BE[3:0]#, A2, and A3 may change. A[31:4], M/IO#, D/C#, and W/R#
remain stable throughout a burst. Given the first address in a burst, external hardware
can easily calculate the address of subsequent transfers in advance. An external
memory system can be designed to quickly fill the Intel
internal cache lines.
Burst cycles are not limited to cache line fills. Any multiple cycle read request by the
®
Intel Quark SoC X1000 Core can be converted into a burst cycle. The Intel
SoC X1000 Core only bursts the number of bytes needed to complete a transfer. For
example, the Intel
point non-cacheable read.
The external system converts a multiple cycle request into a burst cycle by asserting
BRDY# rather than RDY# (non-burst ready) in the first cycle of a transfer. For cycles
that cannot be burst, such as interrupt acknowledge and halt, BRDY# has the same
effect as RDY#. BRDY# is ignored if both BRDY# and RDY# are asserted in the same
clock. Memory areas and peripheral devices that cannot perform bursting must
terminate cycles with RDY#.
10.3.2.2

Terminating Multiple and Burst Cycle Transfers

The Intel
multiple cycle transfer. BLAST# is deasserted in the first cycle to inform the external
system that the transfer could take additional cycles. BLAST# is asserted in the last
cycle of the transfer to indicate that the next time BRDY# or RDY# is asserted the
transfer is complete.
BLAST# is not valid in the first clock of a bus cycle. It should be sampled only in the
second and subsequent clocks when RDY# or BRDY# is asserted.
The number of cycles in a transfer is a function of several factors including the number
of bytes the Intel
4, 8, or 16), the state of the bus size inputs (BS8# and BS16#), the state of the cache
enable input (KEN#) and the alignment of the data to be transferred.
When the Intel
are transferred and if the data is aligned. The external system must indicate whether
the data is cacheable (if the transfer is a read) and the width of the bus by returning
the state of the KEN#, BS8# and BS16# inputs one clock before RDY# or BRDY# is
asserted. The Intel
will take based on its internal information and inputs from the external system.
BLAST# is not valid in the first clock of a bus cycle because the Intel
X1000 Core cannot determine the number of cycles a transfer will take until the
external system asserts KEN#, BS8# and BS16#. BLAST# should only be sampled in
the second T2 state and subsequent T2 states of a cycle when the external system
asserts RDY# or BRDY#.
The system may terminate a burst cycle by asserting RDY# instead of BRDY#. BLAST#
remains deasserted until the last transfer. However, any transfers required to complete
a cache line fill follow the burst order; for example, if burst order was 4, 0, C, 8 and
RDY# was asserted after 0, the next transfers are from C and 8.
October 2013
Order Number: 329679-001US
®
Quark SoC X1000 Core bursts eight bytes for a 64-bit floating-
®
Quark SoC X1000 Core deasserts BLAST# for all but the last cycle in a
®
Quark SoC X1000 Core needs to complete an internal request (1, 2,
®
Quark SoC X1000 Core initiates a request, it knows how many bytes
®
Quark SoC X1000 Core determines how many cycles a transfer
®
Quark SoC X1000 Core driving out an address and
®
Quark SoC X1000 Core cache line). A 16-byte
®
Quark SoC X1000
®
Quark SoC X1000 Core
®
Quark
®
Quark SoC
®
Intel Quark SoC X1000 Core
Developer's Manual
199