Managed to get the core size small enough to allow a DRAM controller to fit as well as the rest of the system. A video frame buffer is small enough that it may fit as well. So, I am just trying that out ATM.

The multi-port memory controller is too large to fit though, so some simpler control logic was added to mux between the CPU and a video frame buffer.

100 MHz timing for the system was missed by 200ps. It may or may not work depending on the chip. But I did not feel in a gambling mood, so the clock was reduced to 89.29 MHz. In theory it should work at 96 MHz.

The design occupies over 90% of the FPGA. Timing was not met by a few hundred pico-seconds in the scratchpad RAM. The miss is entirely due to routing delay. The routing delay is over 98% of the time required. Only 200 ps are needed by the logic. I chalk this up to the fullness of the FPGA.

Shelving the multi-port memory controller. It is not as great a component as I thought, having thought about it some more. The issue is that it creates a lot of duplication of logic. The controller contains FIFOs for high-speed buffering of the data. The issue is that there are also FIFOs for data buffering in the devices connected to the memory controller. I wonder if double-FIFOing is really necessary. Started working on a newer better version.

For the Qupls SoC I created a simple DRAM bridge instead, which is used with a MUX at the inputs. It is much smaller than the memory controller and probably about 90% as effective.

I tried building the system out to a bitstream that can be loaded into the FPGA. Nothing worked of course. Just a blank screen with a few scrambled characters. There are about 15k LUTs left to use, which are being reserved to fix future mistakes.