RDRAM Interface: Difference between revisions
Better explanation about bank status tracking, and why RAM is limited to 8MiB
(RI_REFRESH: Emphasize that "refresh enable" refers specifically to the automatic refresh issued on VI HSYNC, other small tweaks.) |
(Better explanation about bank status tracking, and why RAM is limited to 8MiB) |
||
Line 256:
'''Note:''' Some sources such as libultra's <code>rcp.h</code> header call this register <code>RI_WERROR</code>, however this register is unrelated to errors. The name <code>RI_BANK_STATUS</code> comes from a patent and is much more descriptive of the function of this register.
= Bank Status Tracking =
Each 1 MiB bank can only have one row (2 KiB) open. The only way to open a row on with version 1 of the Rambus spec is to just attempt a read or write operation. If the row is already open, the operation succeeds (hits) and the Rambus device responds with an Ack packet. If the row wasn't open, the operation fails and the Rambus device responds with a NAck packet, while simultaneously closing the currently open row and loading the next. This takes even longer if the current row is dirty and needs to be written back to the dram array first. The Controller must send a new request packet once the device has finished opening the row.
One possible implementation for a Rambus controller is to just retry any operations that miss, they will eventually succeed. But RI doesn't have any retry logic. It does detect unexpected NAcks and set the '''<small>NAck</small>''' bit in the '''RI_ERROR''' register.
Instead, RI tracks the current status of the state machine for each bank. Some of this shadow state machine is exposed via the '''RI_BANK_STATUS''' register where you can find the row valid and row dirty bits. The '''<small>MultiBank</small>''' field of the '''RI_REFRESH''' register also has some effect, as the two banks of a 2MiB chip share some resources. ''(Research Needed, exactly which timings are affected by Multibank?)'' Other parts of the shadow state machine are not exposed via registers, such as if the chips are currently executing a refresh operation, or which row is currently open. With this state tracking, RI always knows which requests will cause a miss and how long it needs to wait before resending the request packet.
RI only has resources for tracking 8 banks (of 1 MiB each, for a total of 8 MiB) and these banks are hardwired into the bottom 8 MiB of the memory-space, as 8 continuous banks.
While you could initialise more Rambus devices in the space above 8 MiB, or move one of the existing devices, without Bank Status tracking, the timings will be wrong ''(Research Needed, wrong in what way, presumably RI always assumes operations will always hit?).''
Bank Status Tracking also interferes with any attempt to use the Rambus' Address Swapping feature, as there is no way to configure Bank Status tracking's address to match the new layout.
= Memory addressing =
Line 271 ⟶ 284:
|-
|<code>0x0000 0000</code>
|<code>
|0
|(address >> 20) & 0x3F
Line 278 ⟶ 291:
|0
|Memory-space access
|-
|<code>0x0080 0000</code>
|<code>0x03EF FFFF</code>
|0
|(address >> 20) & 0x3F
|(address >> 11) & 0x1FF
|address & 0x7FF
|0
|Broken Memory-space access
Not covered by bank status tracking
|-
|<code>0x03F0 0000</code>
Line 297 ⟶ 320:
|Broadcast register write
|}
The same goes for accessing addresses above 8 MiB, no Rambus device will respond to requests.
▲Notice that memory-space accesses (0x00000000 - 0x03EFFFFF) that hit addresses where there is no RDRAM chip mapped will result in a sort of "no-operation" behavior: reads will return zero, and writes will be ignored. For instance, in a N64 with 8 MiB (through expansion paks), reads at the 9 MiB are not a mirror of the reads at the first MiB: they just return zero because no chips in the RAMBUS will reply to those requests.
Line 312 ⟶ 336:
* Early version of RCP reserved fewer bits for RDRAM register address (eg. Adr[35:20] = (address >> 9) & 0x3FF; Adr[19:0] = address & 0x1FF) which didn't allow to access RDRAM register 128 (Row register) which is at offset 0x200.
* The presented address map
* Standard DRAM initialization only supports up to 8 modules, but can mix 2x9Mbit and 1x9Mbit modules. In that case, 2x9Mbit modules are placed before 1x9Mbit modules.
* Standard DRAM initialization procedure, doesn't make use of address swapping feature,
* Register-space addresses duplicates the content between Adr[28:20] and Adr[19:11] to not be affected by RDRAM address swapping features. Indeed, whereas address swapping is desirable for RDRAM memory to benefit from row internal row caching, registers won't benefit from the swapping and would complicate usage of registers in such a case.
= RI_SELECT configurations =
| |||