SDRAM is designed to have as much of the complexity located in the controller and as little as possible in the DRAM chip itself.
This makes sense because you'd have a lot of duplicated logic when you gang multiple DRAMs together.
It allows the chip designer to make trade-offs between design complexity and performance. Modern DRAM controllers can be incredibly complex (and large!) when dealing with different kinds of traffic at the same time: prioritizing CPU traffic, which is latency sensitive, over graphics workloads, which is not.
Another, close to the metal, example is the the source-synchronous data strobe signal that travels with the data from the controller to DDR DRAM or the other way around.
Going from the controller to the DRAM, it is 90 degrees out of phase with the data, which allows the DRAM to clock in the data using the rising and falling edge of the DQS signal. It's on the controller to create this 90 degrees phase shift with a DLL or PLL.
But the other way around, from DRAM to the controller, there is a 0 degrees phase shift, once again forcing the controller to create a 90 degrees shifted signal.
This also makes is possible for the DRAM drop DLL and PLL logic in some cases.
The more-complex interface makes it possible to optimize performance with very fine adjustments - for instance, sufficiently-modern DRAM can be precharging one bank while also servicing data requests from an already precharged one. It can also help with specific data-access patterns: for instance, if the FPGA always reads a whole page then a single precharge could serve for many reads.
They make those too. HyperRAM is pretty popular for small FPGA projects: https://www.mouser.com/new/issi/issi-hyperram/ - there are tradeoffs in potential performance/interface/usability/etc but you end up saving a lot of LUT's and troubleshooting time.
Is there free and functional controller for HyperRAM available? In theory this type of memory is nice, but with no free IP block for this memory, it is a show stopper.
