Visible to Intel only — GUID: hco1416492079460
Ixiasoft
Visible to Intel only — GUID: hco1416492079460
Ixiasoft
11.2.2. Auto-Precharge Commands
The memory device automatically closes or auto-precharges the page that is currently being accessed, so that the next access to the same bank is faster. The Auto-Precharge command is useful when you want to perform fast random memory accesses.
The Timer Bank Pool (TBP) block supports the dynamic page policy, where depending on user input on local autoprecharge input would keep a page open or close. In a closed-page policy, a page is always closed after it is accessed with auto-precharge command. When the data pattern consists of repeated reads or writes to addresses not within the same page, the optimal system achieves the maximum efficiency allowed by continuous page miss limited access. Efficiency losses are limited to those associated with activating and refreshing. An efficiency of 10-20% should be expected for this closed-page policy.
In an open-page policy, the page remains open after it is accessed for incoming commands. When the data pattern consists of repeated reads or writes to sequential addresses within the same page, the optimal system can achieve 100% efficiency for page-open transactions (ignoring the effects of periodic refreshes, which typically consume around 2-3% of total efficiency), with minimum latency for highest priority single transactions.
If you turn on Enable Auto-Precharge Control, you can instruct the controller to issue an autoprecharge read or write command. The next time you access that bank, the access is faster because the controller does not have to precharge the bank before activating the row that you want to access.
The controller-derived autoprecharge logic evaluates the pending commands in the command buffer and determines the most efficient autoprecharge operation to perform. The autoprecharge logic can reorder commands if necessary. When all TBP are occupied due to tracking an open page, TBP uses a scheme called on-demand flush, where it stops tracking a page to create space for an incoming command.
The following figure compares auto-precharge with and without look-ahead support.
Without using the look-ahead auto-precharge feature, the controller must precharge to close and then open the row before the write or read burst for every row change. When using the look-ahead precharge feature, the controller decides whether to do auto-precharge read/write by evaluating the incoming command; subsequent reads or writes to same bank/different row require only an activate command.
As shown in the preceding figure, the controller performs an auto-precharge for the write command to bank 0 at cycle 1. The controller detects that the next write at cycle 13 is to a different row in bank 0, and hence saves 2 data cycles.
The following efficiency results apply to the above figure:
Without Look-ahead Auto-precharge |
With Look-ahead Auto-precharge |
|
---|---|---|
Active cycles of data transfer |
16 |
16 |
Total number of cycles |
19 |
17 |
Approximate efficiency |
84% |
94% |
The look-ahead auto-precharge used increases efficiency by approximately 10%.
The following figure shows how you can improve controller efficiency using the auto-precharge command.
The following sequence of events describes the above figure:
- The controller accepts a read request from the local side as soon as the local_ready signal goes high.
- The controller gives the activate command and then gives the read command. The read command latency is approximately 14 clock cycles for this case as compared to the similar case with no auto precharge which had approximately 17 clock cycles of latency (described in the "data Transfer" topic).
When using the auto-precharge option, note the following guidelines:
- Use the auto-precharge command if you know the controller is issuing the next read or write to a particular bank and a different row.
- Auto-precharge does not improve efficiency if you auto-precharge a row and immediately reopen it.