Closed Aljeshka closed 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.
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.
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).
My mistake. 0x00000000-0x0000000F is indeed 128 bits. That only Read Burst are available is a nice information. Thanks
One last question though. Is Burst length a constant? Or can i scale it down?
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
That helps me a lot, thank you!
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