Specifications

Intel
®
Quark SoC X1000 Core
October 2013 Developer’s Manual
Order Number: 329679-001US 199
Bus Operation—Intel
®
Quark Core
Burst cycles begin with the Intel
®
Quark SoC X1000 Core driving out an address and
asserting ADS# in the same manner as non-burst cycles. The Intel
®
Quark SoC X1000
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
®
Quark SoC X1000 Core cache line). A 16-byte
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
®
Quark SoC X1000 Core
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
®
Quark
SoC X1000 Core only bursts the number of bytes needed to complete a transfer. For
example, the Intel
®
Quark SoC X1000 Core bursts eight bytes for a 64-bit floating-
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
®
Quark SoC X1000 Core deasserts BLAST# for all but the last cycle in a
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
®
Quark SoC X1000 Core needs to complete an internal request (1, 2,
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
®
Quark SoC X1000 Core initiates a request, it knows how many bytes
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
®
Quark SoC X1000 Core determines how many cycles a transfer
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
®
Quark SoC
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.