Support for multiple SDRAM PHYs in single SoC

[mglb]

Requires enjoy-digital/litedram#157

Summary:

• Multiple SDRAM PHYs can be added with LiteXSoC.add_sdram(...):
  • Each SDRAM can be added as part of main_ram or as a fully independent region (pass main_ram = False to add_sdram()).
  • Each SDRAM has a separate L2 cache.
• Generated headers contain additional code:
  • An array of structs with information about each SDRAM has been added to sdram_phy.h. Each entry contains properties and pointers to functions used by BIOS code.
  • An array with SDRAM regions and L2 cache sizes has been added to mem.h.
  • CONFIG_L2_SIZE has been replaced by CONFIG_L2. The former was not removed for compatibility with older code.
  • New headers are backward compatible - old code still works.
• Software/BIOS:
  • All SDRAMs are initialized and tested on boot.
  • memtest optionally takes 2 arguments: base address and size in bytes.
  • New command for listing SDRAM regions: meminfo.
  • New command for choosing the SDRAM on which low-level functions (like sdrhw or sdrrdbuf) operate - currentsdramphy <phy_number>.
  • flush_l2_cache flushes all L2 caches.
• Support for multiple SDRAMs in litex_sim with --add-sdram key=val [key=val ...] command line argument:
  • Available keys: module, data-width, address, max-size, region-name, verbosity, init.
  • Can be used with --with-sdram (and other old sdram-related arguments) or without it.

Known limitations:

• Only SDRAMPHYModel and S6HalfRateDDRPHY are supported

Todo:

• Tests/CI
• Some cleanup

I'm testing the code with litex_sim and on Pano Logic G2 (litex-buildenv).

Example litex_sim command:

litex_sim \
    --add-sdram module=IS42S16320  address=0x10000000 \
    --add-sdram module=MT48LC16M16 address=0x18000000 \
    --add-sdram module=MT48LC16M16 address=0x1c000000 \

[enjoy-digital]

Thanks for this. This is a huge work that enhances the capabilities, but i'm also wondering if it's does not complexify too much the code for the actual use-case it's trying to cover. I suggest we discuss in #346 before going further.

[mithro]

Hi @mglb, I believe this PR can be reworked to be significantly smaller and less invasive, however it is unlikely I'll get a chance to provide proper suggestions until early next week.

[mglb]

@mithro like, first commit (f0ada2e) + enjoy-digital/litedram@069d89c + enjoy-digital/litedram@a9add8e? All other commits add support for multiple PHYs in BIOS or make it possible to write generic software with support for arbitrary number of PHYs.

[enjoy-digital]

Closing, we'll continue the discussion in: #346. In the future I would appreciate being able to discuss these features before too much time is spent in the implementation, since here it was probably too early for the project and could probably have been worked around for the Pano Logic G2.