Visible to Intel only — GUID: rkv1547133791428
Ixiasoft
Visible to Intel only — GUID: rkv1547133791428
Ixiasoft
10.4.1. 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, autoprecharge would keep a page open or closed. In a closed-page policy, a page is always closed after it is accessed with an 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 auto-precharge 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 auto-precharge logic evaluates the pending commands in the command buffer and determines the most efficient auto-precharge operation to perform. The auto-precharge logic can reorder commands if necessary. When the TBP is occupied due to tracking an open page, the 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.
![Comparison With and Without Look-ahead Auto-Precharge](/content/dam/docs/us/en/683216/21-4-2-6-0/bzy1549296073754.png)
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 the 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%.
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.