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.

Part 1: The Plan!

Having received the ESM-BB10 Spartan 6 board a couple of weeks ago I was naturally keen to see it in action.  Since I only have the free “WebPack” version of Xilinx’s ISE design suite, I can’t use the ChipScope logic analyzer (roughly equivalent to SignalTap, I believe) – so debugging is going to be tricky.  Therefore I’ve taken a methodical, step-by-step approach, testing the various parts of the board one by one.

The ZPUDemos collection is ideal for this purpose, since the projects there range in complexity from a simple “Hello World” that requires no peripherals apart from RS232 serial, to projects that make use of VGA, SDRAM and SD card. Continue reading →

Apologies for the lack of recent updates.  I haven’t been completely idle but my time’s being filled with other things at the moment, including replacing light fittings, hanging pictures and learning the guitar!

Despite the silence, I’ve not been completely inactive on the FPGA front, however, and I’m still slowly building my library of demo projects for my “Flex” variant of the ZPU processor.  In the process I’m redesigning and streamlining a lot of the components that made up the TG68MiniSOC project, so that will be updated with the results before too much longer, and I’ve also started branching out from being purely Altera-based into Xilinx too.

This last development is the result of reader Emanuel Stiebler very generously supplying me with a Spartan-6 board!

This has an XC6SLX45 FPGA, 32 megabytes of SDRAM, 4 megabyte of SSRAM, a microcontroller, dual micro-SD slots (one for the µC, one for the FPGA) and an assortment of IO ports.

I’ve already ported a few of the ZPU Demos to this new board (and a couple of the simpler ones to the original Minimig board while I’m at it!) but will post about the process in more detail soon.

So while I’m experimenting with FPGA boards I generally upload a design into them at runtime via a USB-Blaster JTAG cable, and only rarely do I store a design permanently in a board’s configuration device.

Some of the boards I use have two separate connectors for the USB Blaster – one for direct programming of the FPGA and the other for Active Serial programming of an EPCS series flash device.  Others have an onboard microcontroller which handle configuration – and then there’s the Vampire 500 board.  This has a single JTAG connector and an EPCS4 configuration device, but no immediately obvious means of programming the EPCS4. Continue reading →