Rework bus system and memory map

[stnolting]

In order to tackle #629 and #576 I am experimenting with a new processor-internal bus system. Right now we have a single bus (high fan-out!) and all the modules to the address check by themselves. A more-centralized address decoding (at least for specific address sections) might be more efficient as the synthesis tool has more freedom for optimizations. Furthermore, this would also simplify customization (@biosbob).

So this is my idea:

• split the entire address space into fixed sections
  • instruction address space (IMEM)
  • data address space (DMEM)
  • memory-mapped XIP flash (but at a fixed address; no more programmable)
  • bootloader ROM address space
  • IO address space

The address sections would be defined by package constants or maybe even by a single (huge) table (record) to allow easy customization. The decoding would be done by a centralized interconnect.

In order to simplify the address decoding of the IO modules I would like to...

• add ADDR_BASE and ADDR_MASK generics to each module (RFC: [rtl] Replace peripheral's direct access to XXX_base_c constants with a generic #576) to the modules can be re-used by the user (for example to add several SPIs cores); the individual IO address decoding would still be implemented by the devices themselves
• extend the address space of each IO device to 256 bytes; "unused" addresses would simply mirror existing registers

Any thoughts?

[biosbob]

this is quite exciting, and i'm anxious to merge your PR with my own experiments with compressed addresses....

one immediate question is the alignment requirements of each of these sections.... this is important for me, as i'm planning to pack everything into a 17-bit space....

clearly there are some challenges with XIP, which typically opens up a very wide window.... since i'm executing out of IMEM and ROM, i'm not using XIP at all; my bootloader uses the standard SPI block to copy code from the FLASH to IMEM.... does your proposal allow me to opt-out of XIP altogether, meaning no part of my address space is used as a FLASH window and hence doesn't need to be decoded???? (seperately, i'll open a discussion on an alternative XIP design which could support a compressed address space....)

as for IO space, 256 bytes per device is quite generous -- and is only used today by CFS, which could have easily been realized as CFS0, CFS1, etc using fewer bytes per device.... since this effectively determines the width of the address portion of the IO bus, there are opportunities to save LUTs.... i would favor 32 bytes per device, to minimize the internal fragmentation of address space; and if we can support "byte-level" addresses that still read/write 32-bits of data, we're really not looking much difference at all....

in practice, you'd like to limit the number of "top-level" IO devices to (say) 32.... indeed, many devices like SPI and I2C are in fact controllers for a sub-bus that contains many more devices.... currently, we deal with a relatively small number of "top-level" interrupts from these devices anyhow....

you could imagine a centralized IO bus decoder which splits the address into a <device number, register number> pair, where each part may be 5-bits in width.... the latter bits are shunted onto the address portion of the IO bus, while the former bits are used to "enable" the corresponding IO device; the device itself would only decode the register number when its enable signal is driven by the central decoder.... (this is not unlike having multiple chip-select lines in the master SPI module....)

finally, my latest work on compressed addresses has led me to the following map:

• 0x00000000 - 0x00007FFF IMEM
• 0x0000C000 - 0x0000FFFF ROM
• 0xFFFF0000 - 0xFFFF7FFF DMEM
• 0xFFFF8000 - 0xFFFFFFFF IO

with this rather strange mapping, the lower 17-bits of the 32-bit addresses remain unique.... most important, though, is whether your proposed design can handle this specific configuration....

[stnolting]

one immediate question is the alignment requirements of each of these sections.... this is important for me, as i'm planning to pack everything into a 17-bit space....

One of the goals of that PR is to make the entire address mapping as configurable as possible. Finally, there will be one (big?) address table in the package file that can be altered while all possible side-effect are resolved by the (new) bus infrastructure. At least that is the plan 😅

clearly there are some challenges with XIP [...]

The memory-mapped XIP flash access will be mapped to a fixed address space (0xE0000000 to 0xEfffffff). If the XIP controller is disabled all accesses to this address space will end up in the "void" (and will be redirected to the external memory interface if implemented).

as for IO space, 256 bytes per device is quite generous [...]

True, but right we already have two modules with such a big address space: the CFS and the on-chip debugger. Sure, we could split the CFS into smaller portions, but splitting the debugger modules would be quite hard...

in practice, you'd like to limit the number of "top-level" IO devices to (say) 32 [...]

That is exactly what I am planning. A maximum of 32 devices in the IO space so they can be accesses with a 5-bit portion of the address.

you could imagine a centralized IO bus [...]

This is also exactly what I am working on 😉

Here is the my proposal for the upcoming address map consisting of 5 main address regions (again, the base addresses of these regions can be customized):

• 0x0000_0000 - 0x7fff_ffff: instruction address space (2GB); internal IMEM is mapped to the beginning of this region
• 0x8000_0000 - 0xdfff_ffff: data address space (1.5GB): internal DMEM is mapped to the beginning of this region
• 0xe000_0000 - 0xefff_ffff: memory-mapped XIP flash access region (256MB)
• 0xffff_c000 - 0xffff_dfff: bootloader ROM address region (8kB)
• 0xffff_e000 - 0xffff_ffff: IO address region (8kB)

All accesses that do not match any of these regions will end up in the "void" (being redirected to the external memory interface if enabled; otherwise an exception is raised).