Part 14: Improving the SDRAM controller

One limitation of the MiniSOC project so far has been that only a very basic 16-bit 640×480@60Hz screenmode is supported.  The reason for this is mainly RAM bandwidth, since the boards I’m targetting have single-data-rate SDRAM.

The SDRAM controller I’m using is derived from the one Tobias Gubener created for the TG68-based versions of the Minimig core.  The original controller used 4-word bursts when reading from SDRAM, wrote in single words, and operated on a fixed 16-clock cycle, which had the advantage of guaranteeing a deterministic response time for the Amiga emulation. Continue reading →

Part 13: Timing closure at last!

In the TG68MiniSOC project, I took the lead from the way the CPU was implemented in the Minimig project and clocked everything at a single high-speed clock.

The TG68 itself can’t run at much more than 32MHz, and it it’s only possible to clock it faster than this because it has a “clkena” signal, which allows it to be halted while the combinational logic inside catches up.  While this approach works (mostly) it causes issues for the FPGA synthesis software, which reports severe timing violations when combinational paths are more than a single cycle long.  It’s possible to inform the software that these long paths are OK, and anticipated in the design by way of “multicycles”, but finding and specifying them all, without including anything that shouldn’t be included, is long-winded, tedious and error-prone.  This issue is the primary cause of the build-to-build stability problems that have dogged several TG68-based projects.

Today, however, I’ve been trying a different approach, with split clocks.  This version of the project uses a 100MHz clock for the SDRAM controller and VGA controller, and a 25MHz clock (generated within the same PLL as the 100MHz clock, and thus aligned with it) that runs the CPU, the main state machine and peripherals.  Dealing with data transfer between these two clocks turned out to be much easier than I’d anticipated, and simply making sure that all signals from the CPU are registered before being handed over to anything running at the faster clock rate seems to be the main trick.

The big news is that this approach allows the project to achieve timing closure!  When building for the venerable DE1, TimeQuest no longer reports any timing violations.  I have yet to run any benchmarks on this version of the project, so I don’t yet know what sort of speed penalty the project will suffer, but the increased tidiness of the main state machine, and the added reliability that should come from the tools being able to understand the project’s structure should make the performance penalty well worthwhile.

As always, full source can be found on my github page.  I tag the repository at key points, and this post refers to the code tagged as SplitClock_20140405.