apfelaudio / tiliqua

A powerful, hackable FPGA-based audio multitool for Eurorack.
CERN Open Hardware Licence Version 2 - Strongly Reciprocal
50 stars 3 forks source link

`DelayLine`: PSRAM zeroing needed post-configuration #53

Open schnommus opened 1 week ago

schnommus commented 1 week ago

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 force DelayLine 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.

schnommus commented 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.