litex-hub / linux-on-litex-rocket

Run 64-bit Linux on LiteX + RocketChip
BSD 2-Clause "Simplified" License
181 stars 18 forks source link

How to determine bit width of the point-to-point AXI link? #7

Closed troibe closed 3 years ago

troibe commented 3 years ago

I'm trying to run your project on an ULX3S however I'm now wondering what the appropriate bit width would be. Is there some table with the bit width of all supported litex boards? Where did you find this information?

gsomlo commented 3 years ago

Hi @developandplay -- thanks for pointing this out!

I just committed https://github.com/litex-hub/linux-on-litex-rocket/commit/cc45c13b2860653c08abb59aaeb0b6681e3cf098 which should explain where you can find the correct width to use.

troibe commented 3 years ago

Thanks a lot! Just in case anyone finds this thread and wants to take a shortcut:

INFO:SoCBusHandler:main_ram Region added at Origin: 0x80000000, Size: 0x02000000, Mode: RW, Cached: True Linker: False.
INFO:SoC:Converting MEM data width: 16 to 64 via Wishbone
INFO:ECP5PLL:Config:
clki_div   : 1
clko0_freq : 50.00MHz
clko0_div  : 8
clko0_phase: 0.00°
clko1_freq : 50.00MHz
clko1_div  : 8
clko1_phase: 90.00°
vco        : 400.00MHz
clkfb_div  : 16

So for the ULX3S it seems to be 16bits. That's interesting considering that it's using the same ECP5 chip. Then it's the SRAM that's used on the ULX3S that makes the difference I guess. Since 16 is smaller than the 64 standard which effect does it have?

gsomlo commented 3 years ago

On Sun, Mar 28, 2021 at 01:07:24PM -0700, developandplay wrote:

So for the ULX3S it seems to be 16bits. That's interesting considering that it's using the same ECP5 chip.

I'm no expert on LiteDRAM itself (recommend asking in #litex on Freenode for a better answer) -- but ultimately the bit-width of LiteDRAM depends on the physical DRAM chip(s) used and how they're wired to which pins on the FPGA. So it's much more a function of the actual board and how it decided to connect things to the ECP5 FPGA, than of the FPGA itself.

That said, it doesn't make a lot of sense to support a RocketChip variant that's narrower than 64 bits, so in this case it's probably OK to deploy SoC-gateware based width conversion.