The circuit I cobbled together a few weeks ago to add sound support to the Gotek floppy emulator worked up to a point, but it was ugly as hell, and suffered from occasional stray oscillations. H.M. – the mastermind behind the new Amiga-compatible firmware for the Gotek unit – suggested using a MOSFET instead of the BJTs, and since I’m still shaky on the use of transistors it seemed like a good opportunity to learn.
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.