enjoy-digital / litedram

Small footprint and configurable DRAM core
Other
382 stars 122 forks source link

litedram does not use full address space? #263

Closed Aljeshka closed 3 years ago

Aljeshka commented 3 years ago

I just created a vexriscv design on my arty, and looking over the litedram core i noticed that "main_litedramcore_sdram_bankmachine5_cmd_buffer_source_payload_addr" only has [20:0] bits. [20:7] for the row and [6:0] for the column. If you take the 3 Bank Pins, this would mean that only ~16MB of the 256MB of the DRAM chip are being used. Why? Are there some timing issues which make it more difficult to use the whole chip memory? Or is it a riscv issue?

Greetings Alec

jedrzejboczar commented 3 years ago

Hi, as far as I understand it, BankMachine uses address_width: https://github.com/enjoy-digital/litedram/blob/4326fe7f36699ae219dbaccc38d9176b749f6d8e/litedram/core/controller.py#L89 which is taken from LiteDRAMInterface where it is calculated as: https://github.com/enjoy-digital/litedram/blob/4326fe7f36699ae219dbaccc38d9176b749f6d8e/litedram/common.py#L282 where address_align depends on burst length (8 for DDR3): https://github.com/enjoy-digital/litedram/blob/4326fe7f36699ae219dbaccc38d9176b749f6d8e/litedram/core/controller.py#L55 I think you have to also add x2 for the fact that a single column address means 16 databits, so this would give you 16MB 2^3 2 = 256MB, but maybe someone could verify my calculations.

Aljeshka commented 3 years ago

I understand your approach @jedrzejboczar, but I'm not quite sure how the Burst Length and the Double Data Rate (16 bits per column) lead to less column bits.

For the 256MB address space I need 28 address bits. I have [13:0] Row Bits, [2:0] Bank Pins, and 'only' [6:0] column pins, instead of [10:0]. In Fact the column bits are set like this:

'main_litedramcore_sdram_bankmachine5_cmd_payload_a <= ((main_litedramcore_sdram_bankmachine5_auto_precharge <<< 4'd10) | {main_litedramcore_sdram_bankmachine5_cmd_buffer_source_payload_addr[6:0], {3{1'd0}}});'

So by Default the 4 missing Bits are always 0, right?

So if my address is 0x00000000, i should get the whole data chunk up until the address 0x0000000F? Meaning 16*8 Bytes of data per address. This would be 1024 bits of data and to be honest it sounds like a lot.

jedrzejboczar commented 3 years ago

The controller can only read full bursts, so the address has log2(burst_length) less columnbits and the lower bits are then set to 0. As for the number of bits, 0x00000000-0x0000000F is 128 bits of data (16 bytes => 16 8 bits) and this is what a single read should give you. The data width is defined here: https://github.com/enjoy-digital/litedram/blob/4326fe7f36699ae219dbaccc38d9176b749f6d8e/litedram/common.py#L282-L283 So on Arty this will be dfi_databits=32 (DQ[15:0] x2 for DDR) and nphases=4 (MC:DRAM clock ratio). This is equivalent to databitsburst_length (16 * 8).

Aljeshka commented 3 years ago

My mistake. 0x00000000-0x0000000F is indeed 128 bits. That only Read Burst are available is a nice information. Thanks

Aljeshka commented 3 years ago

One last question though. Is Burst length a constant? Or can i scale it down?

jedrzejboczar commented 3 years ago

I think it's not possible to modify the burst length. I am not sure what is your exact use case but you can use the width converter to change the data width: https://github.com/enjoy-digital/litedram/blob/4326fe7f36699ae219dbaccc38d9176b749f6d8e/litedram/frontend/adapter.py#L356 but under the hood it will perform the whole burst and just return a "window" of data from it. Litex SoC usually converts the LiteDRAMNativePort to Wishbone and uses wishbone.Converter or L2 cache to adjust the data width: https://github.com/enjoy-digital/litex/blob/e0d5a7bff55923def45f8b1b6bf0a62eded77a31/litex/soc/integration/soc.py#L1359-L1382

Aljeshka commented 3 years ago

That helps me a lot, thank you!