A System-on-Chip in 2300 logic elements!

My experiments with the “small” variant of the ZPU processor have resulted so far in a reasonably functional and tiny System-on-Chip. Supported so far are:

  • ZPU processor with GCC toolchain support
  • SDRAM controller with cache
  • VGA video output, 640x480x16-bit (Dithered on DE1 board)
  • Millsecond counter
  • SD card access
  • UART
  • HEX display (DE1 only)

All within a mere 2300 logic elements.
Continue reading

More Follin Fandom

It doesn’t seem to matter which platform’s sound chip Tim Follin composed for, he always seemed to find some way of squeezing more out of it than anyone previously thought possible. Here are just a few examples, found on YouTube…
Continue reading

Something Completely Different

This isn’t remotely tech-related, but it’s definitely Retro.  I found this on YouTube recently and have to say I love it!

Quite apart from the musicianship, look out for Pat Metheny displaying his usual facial contortions, and Lyle Mays looking for all the world like the carny from Despicable Me!

Sadly the DVD this was ripped from (More Travels) isn’t easy to get hold of now.

More ZPU experiments

Since my last post I’ve been continuing to work on the ZPU small core, adding hardware implementations of the optional instructions while trying to keep the core as small as possible.

Certain instructions are closely related enough that once one is implemented the others come almost for free. Sub, Eq, Neq, Lessthan and Lessthanorequal come under that category.
Continue reading

Speed / size tradeoffs

I’ve been playing some more with the small version of the ZPU core, and have successfully integrated it into a cut-down version of my previous MiniSOC project. The “official” small core only supports BlockRAM access, with external access reserved for IO. I’ve reversed this so that only the stack is in the CPU core’s internal BlockRAM, and program data comes from external RAM.

In addition, I’ve added optional hardware implementations of a few of the emulated instructions, namely mult (the Cyclone II has hardware multipliers, so why not use them?), eq, eqbranch and neqbranch. I think I can add the comparison instructions without bloating the core too much, as well.

By way of a benchmark, I’ve written a simple framebuffer test which simply writes a pattern of ascending longwords into the framebuffer. With the optional instructions disabled, this achieves about 1.9 frames per second, and the CPU takes up 621 logic elements.
With eq and eqbranch/neqbranch in hardware, the frame rate goes up to about 5.25, and the core takes 781 logic elements.

There’s lots still to do – reading from SDRAM is untested, and writes are currently always 32-bit – but the project is available here (currently DE1 toplevel only) for anyone who might be interested.

ZPUFramebufferTest

A Tiny CPU

There are various FPGA projects which could benefit from the existence of a really small CPU core to handle things like loading ROMs from SD card. The Minimig project either uses an external microcontroller (For the original Minimig and now also the MIST board), or throws in a second fully-fledged CPU into the FPGA itself. This is either a second instance of the TG68, or in the case of Chaos’s DE1 port, an OpenRisc CPU.

The only problem with this approach is that the second CPU takes up valuable resources – the OpenRisc CPU is smaller than the TG68, but still takes up over 2000 logic elements, so there’s definitely a need for a really small CPU core. Continue reading

Caching and Bus Snooping

When I first added the Turbo ChipRAM feature to the Minimig core, there were suprisingly few unpleasant side-effects. However, one side-effect did become apparent when I added the Two-way CPU cache.

On a real Amiga, it’s possible for the CPU’s bus and the chipset’s bus to operate independently, so if Fast RAM is available, the CPU can conduct a FastRAM operation at the same time as the chipset is reading or writing from Chip RAM. On the TG68-based Minimig variants, there’s only one type of RAM available – SDRAM, and no matter how they’re handled, Chip RAM and Fast RAM accesses ultimately all end up in the same RAM chip. Chip RAM accesses are coordinated by the Minimig’s chipset emulation, while Fast RAM accesses use a different port in the SDRAM controller and bypass the Minimig chipset emulation entirely, which is much faster. This is the key to my “Turbo ChipRAM” option – which basically allows Chip RAM to be accessed through the SDRAM controller’s Fast RAM port.

The problem is that the Fast RAM port is cached, so if the chipset writes to a piece of Chip RAM which happens to be in the cache, the cached data becomes stale, and next time the CPU reads that address it received the stale data, not the newly-written data.

The solution to this is to perform Bus Snooping. The CPU cache needs to monitor the SDRAM controller’s Chip RAM port, watching for writes, and any time it sees a write to an address that’s in cache, it must either update or flush the cached data.

I’ve taken the easier but slower option here, simply marking the data as invalid, forcing it to be re-read from SDRAM next time the CPU wants to access it. There’s scope to improve performance by updating the cached data and leaving it marked as valid. The cost for this would simply be the extra logic elements needed to store the written data temporarily and write it to the cache.

Source for the Two-way cache with Bus Snooping can be found here – and I’ll try and release a new version of the Chamemleon core in the near future with this change included.

ProjectXG Redux

Anyone remember CU Amiga Magazine’s “ProjectXG”?  This was a DIY project they ran, based on a hack that was published on Aminet, to interface a Waveblaster MIDI daughterboard to the Amiga’s serial port, to provide a pretty good quality MIDI tone module.

The daughterboard most commonly used for this project was Yamaha’s DB50XG, though any card which attached to a “Waveblaster” header could be used.  (Googling Waveblaster now, however, will find you a Yamaha product of quite a different nature.)

The DB50XG’s successor, the DB60XG was manufactured under license by NEC as the XR385, and this seems to be the easiest such card to find these days.  It’s very similar to the DB50XG, it just has some very subtly different voicing, and can apply its DSP effects to incoming audio as well as its own sounds.

Having built a ProjectXG many years ago, then selling it a year or so back and promptly building another one, I naturally wanted to interface a Waveblaster card to one of my Minimig variants, and listen to some old MIDI files again.
Continue reading

Lest I be thought a hypocrite…!

I have a confession to make!

After my post about video game music and references – deliberate or otherwise – to pop music of the day, I remembered my old AMRWolf project and the ProTracker module I wrote to serve as its title music:

Wow – does that say *1996*?  Now I feel old!  Anyhow, bonus points to anyone who can identify the piece of 80s pop music that inspired the backing track…

The module itself, in case anyone’s interested, can be found here.  (Yes, imaginatively titled “Untitled2”.  I could occasionally come up with music tracks that were worth not deleting on the spot, but I never could come up with decent names for them!  I still can’t, for the very occasional pieces I come up with these days – “Ode to a Girl who Works in Lidl” *really* doesn’t cut it!)

The sampled breaks were themselves created in ProTracker, then rendered down to a single sample to squeeze as much from the 4-channel sound chip as possible.  Sadly I don’t have the source tracks any more.