AMD LX 900@1.5W Computer Hardware User Manual


 
AMD Geode™ LX Processors Data Book 215
GeodeLink™ Memory Controller
33234H
6.1.1.2 Arbitration
The pipelining of the GLMC module requests consists of
the GLIU0 interface request plus two request buffers: the C
(closed) and O (open) slots (see Figure 6-7). A request is
accepted at the GLIU0 interface as long as there is a slot
available. The C slot holds a request to a closed page, or a
request to an open page that matches a row address. The
O slot holds a request to an open page that matches a row
address.
Figure 6-7. Request Pipeline
Arbitration between the request at the GLIU0 interface, the
C request, and the O request at the DRAM end, depend on
selection factors that try to optimize DRAM bus utilization
and maximize throughput. This may involve reordering
transactions as long as ordering rules and coherency are
maintained. Requests from the same GeodeLink device
source are kept in order. Requests from different sources
may pass each other as long as the addresses do not
match.
If reordering is allowable, requests may be reordered for
the following reasons:
1) A request with a higher priority can pass a request in
front of it with a lower priority, as long as the higher-
priority request is ready to run and nothing else is
already running. (Conversely, a request with a lower
priority may not pass a request in front of it with
greater or equal priority.)
2) A younger request that hits to an open page can pass
an older request in front of it that is not a page hit.
3) A write request still gathering its write data may be
passed by a request behind it that is ready to run.
4) Writes and reads are clumped together by the GLMC
to minimize bus turnarounds.
The criteria for reordering is prioritized as above, with the
requests’ priority fields (PRI) taking top precedence in
determining if reordering may be performed. Reordering
based on criterion #2 may only happen if the relative priori-
ties are sorted out as per criterion #1, and so on.
Requests in the C and O slots are run before the request at
the GLIU0 interface if the DRAM is ready to receive them.
The GLIU0 interface request can pass C and O requests
only if the interface request is a read; a write needs to
gather data in the write buffer first so it ends up moving to
the C and possibly O slot while waiting. (For the case
where a GLIU0 non-burst write request and its single beat
of write datum are valid in the same clock, writes could
possibly be optimized to bypass the write buffer, thus
allowing write requests from the GLIU0 interface to be run
on the fly at the DRAM interface. Note that only single
writes may be optimized; burst writes must be buffered first
as there may be bubbles between data beats.)
Requests from the same source whose addresses are
within the same cache line are run in order; otherwise,
reordering from the same source is allowed.
Typically, refresh requests are run when GLIU0 has indi-
cated that a refresh can be initiated via a NULL refresh
request transaction. The GLMC has a refresh counter that,
once enabled and initialized with an interval count, freely
counts down to keep track of refresh intervals. Each time
this refresh counter times out, a refresh request is added to
the GLMC refresh queue, which can queue up to eight
refresh requests. Once a NULL refresh request is received
from GLIU0, and there is at least one refresh request in the
refresh queue, and all outstanding transactions are fin-
ished in the GLMC, the GLMC deletes one request from
the queue and performs one refresh cycle.
If GLIU0 fails to send a NULL request in a timely manner,
and eight refreshes queue up without a NULL request from
GLIU0, the refresh request is upgraded to the highest prior-
ity, and one refresh proceeds. Requests from the GLIU0
interface will not be accepted until the high-priority refresh
runs. Mode-register-set requests and low-power-entry are
arbitrated at the same level as high priority refresh.
GLIU FF
Refresh/Low Power/Mode Set
C Slot FF
O Slot FF
SD FF
GLIU0
Req