SDRAM performance on the seed is a constant battle. Well, DRAM performance everywhere is a battle even on your desktop. The 32 delay lines are scattered through the different rams on the H7 to improve performance. Only about 2/3 of the delay lines end up on the SDRAM. The SDRAM performance is actually what set the max delay time for the DV since we would have had to have put more delays on the SDRAM if they were any bigger.
To get decent SDRAM performance you have to work with the ARM data cache and the FMC (read the manuals on these!). Locality and in-sequence accesses are really important. We actually perform and cache 64 reads from the 32 delays delays before doing any of the dsp to improve the ram performance.
For another product we are working on (which has 48 memory reads per produced sample all in sdram and at 2x the sample rate of DV) i prototyped a mechanism with MDMA that would pull all the SDRAM data needed for the next frame into SRAM while it was doing the dsp for the current frame. Performance was a wash on that one because the particular application has some tricky nonlocality with the delays which ended up costing a lot to deal with. doing MDMA in the background however was very, very effective and its a tool I will def use in the future. If you are reading sequentially from a delay line at a more or less constant rate it would work really well.
In the seed’s favor… The SDRAM setup is about as good as the H7’s FMC can handle. Its pretty close to the max frequency and it is using the full bus width for transfers… So for this class of platform there isn’t much better performance to be had with external dram.