> I found it amazing that the OWON folks thought emulating a DDR2 memory in an FPGA was good design.
The SoC has the same kind of memory connected to it, so the memory controller in the SoC is configured for DDR2. And many uCs and SoC don't like it if their address banks are not configured for the same kind of clocking and do weird things otherwise.
For example the STM32F407 (and probably the 205, 207 and 405) truncate the last clock in a transmission toward the fastest clock speed configured in the FSMC banks. That caused quite a bit of trouble in a project. Also it's an undocumented erratum, or at least it was at the time when we had to deal with it.
Yes, but this particular CPU/SoC has a parallel bus with the NAND flash connected to it. Which would be the more traditional way to connect an FPGA.
For a recent example: The TI Sitara am57xx has 8 individual chip-selects on its "General-Purpose Memory Controller (GPMC)" and supports a few flash-specific modes, but also "Asynchronous SRAM-like memories and ASIC devices" (quote from the datasheet http://www.ti.com/lit/ds/symlink/am5728.pdf p245). So, to connect a FPGA the data/address lines would be shared between flash and FPGA but individual chip-selects would select one or the other.
As one can (typically) configure very relaxed timings on these busses, it's much, much easier to interface to and sufficient for everything that doesn't have to be super-fast. Of course with the disadvantage of being slower this might have been THE reason to go for the DDR2 memory bus.
> Yes, but this particular CPU/SoC has a parallel bus with the NAND flash connected to it. Which would be the more traditional way to connect an FPGA.
Absolutely.
> As one can (typically) configure very relaxed timings on these busses, it's much, much easier to interface to and sufficient for everything that doesn't have to be super-fast.
"super-fast" is probably the keyword here. In an oscilloscope you normally want a very short trigger re-arm interval. Which means that you want to get the data out of the acquisition buffer as fast as possible. At the sampling rates the used ADC supports the regular parallel bus timings might be to slow, but by implementing a DDR2 interface a very quick transfer could be implemented.
Actually if I had to design this (actually only recently I did design something like this) I'd not transfer acquired samples to main system memory at all but instead present the FPGA attached DDR2 to the SoC in a double buffered manner and even do things like averaging, envelope tracking and similar acquisition tasks in FPGA on the backbuffer memory.
The SoC has the same kind of memory connected to it, so the memory controller in the SoC is configured for DDR2. And many uCs and SoC don't like it if their address banks are not configured for the same kind of clocking and do weird things otherwise.
For example the STM32F407 (and probably the 205, 207 and 405) truncate the last clock in a transmission toward the fastest clock speed configured in the FSMC banks. That caused quite a bit of trouble in a project. Also it's an undocumented erratum, or at least it was at the time when we had to deal with it.