Open schnommus opened 1 week ago
This is now fixed - for now, the strategy is that each DelayLine
just initializes its own backing store. This means a lot of extra PSRAM traffic at boot, but seems to work fine.
Merged in: https://github.com/apfelaudio/tiliqua/commit/c500de6d8b79612090e4d1e0a0bc0b440a41608c
Regardless, I think it might be neater (and more resource efficient) to just have the PSRAM controller zero the whole memory space at boot.
External memory comes out of reset full of garbage. In cases where we have no SoC initializing the external memory, this means any
DelayLine
instance backed by external memory will emit garbage for a while.Probably a neat solution to this would be to propagate up all the
DelayLine
memory regions using amaranth-soc's memory window abstraction, and have the PSRAM memory controller initialize all these sections to zero. Or, we just force each DelayLine to emit zeroes (ignoring the memory values) until the write pointer has cycled through once. Or we forceDelayLine
to write zeroes to itself during startup.Alternatively, we could just have the memory controller initialize the whole memory space to zero on startup. Even with 32MByte PSRAM, we can erase at approx. maximum memory bandwidth of 240MByte/sec (60MHz base clock) or 400MByte/sec (100MHz base clock, not merged), which suggests ~100msec startup delay.