The Memory Controller defaults to a page open policy. It leaves banks open,
even when there are no transactions pending. It only closes banks when a refresh is due,
a page miss transaction is being processed, or when explicitly instructed to issue a
transaction with a RDA or WRA CAS command. The app_autoprecharge port
on the UI allows you to explicitly instruct the controller to issue a RDA or WRA command
in the CAS command phase of processing a transaction, on a per transaction basis. You
can use this signal to improve efficiency when you have knowledge of what transactions
will be sent to the UI in the future.
The following diagram is a modified version of the “look ahead” example from
the previous section. The page miss transaction that was previously presented to the UI
in cycle 3 is now moved out to cycle 9. The controller can no longer “look ahead” and
issues the Precharge to Bank 0 in cycle 6 because it does not know about the page miss
until cycle 9. But if you know that transaction 1 in cycle 1 is the only transaction to
Row 0 in Bank0, assert the app_autoprecharge port in cycle 1. Then, the
CAS command for transaction 1 in cycle 5 is a RDA or WRA, and the transaction to Row 1,
Bank 0 in cycle 9 is no longer a page miss. The transaction in cycle 9 is only needed as
an Activate command instead of a Precharge followed by an Activate tRP later.
| Transaction Flow | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| System Clock Cycle | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| UI Transaction Number | 1 | 2 | – | 3 | – | – | – | – | 4 | – | – | – | – |
| UI Transaction | R0, C0, B0 AutoPrecharge |
R0, C0, B1 | – | R0, C0, B2 | – | – | – | – | R1, C0, B0 | – | – | – | – |
| FSM0 FIFO Stage 2 | – | R0, C0, B0 | R0, C0, B0 | R0, C0, B0 | R0, C0, B1 | R0, C0, B1 | R0, B0, B1 | – | – | R1, C0, B0 | R1, C0, B0 | R1, C0, B0 | – |
| FSM0 FIFO Stage 1 | R0, C0, B0 | R0, C0, B1 | R0, C0, B1 | R0, C0, B1 | – | – | – | – | R1, C0, B0 | – | – | – | – |
| FSM1 FIFO Stage 2 | – | – | – | – | – | R0, C0, B2 | R0, C0, B2 | R0, C0, B2 | – | – | – | – | – |
| FSM1 FIFO Stage 1 | – | – | – | R0, C0, B2 | R0, C0, B2 | – | – | – | – | – | – | – | – |
| DDR Command Bus | Act R0, B0 | – | – | Act R0, B1 | Act R0, B2 CAS-A C0, B0 |
– | – | CAS C0, B1 | Act R1, B0 CAS C0, B2 |
– | – | – | CAS C0, B0 |
A general rule for improving efficiency is to assert
app_autoprecharge on the last transaction to a page. An extreme
example is an address pattern that never generates page hits. In this situation, it is
best to assert app_autoprecharge on every transactions issued to the
UI.
The controller has an option to automatically inject an autoprecharge on a
transaction. When the Force Read and Write commands to use
AutoPrecharge option is selected, the Memory Controller issues a
transaction to memory with an AutoPrecharge if Column address bit A3 is set High. This
feature disables the app_autoprecharge input signal on the User
Interface. The Force option when used with the
ROW_COLUMN_BANK_INTLV address mapping improves efficiency for transaction patterns with
bursts of 16 sequential addresses before switching to a different random address.
Patterns like this are often seen in typical AXI configurations.