Having found that clip of the Pat Metheny Group on YouTube a couple of weeks ago, I wanted to get hold of the DVD from which it was ripped. Unfortunately it seems to be really hard to track down – I can find it easily enough on VHS, and also on Laserdisc, but not on DVD. So I acquired it by… ahem… “other means”. Since I’ve never actually handled a Laserdisc, though, I couldn’t resist the urge to buy a copy from a Stateside seller on EBay.
It arrived yesterday.
It was wrapped in newspaper, and I can honestly say this is a headline I never thought I’d see:
In my last post I mentioned that I had to employ some ugly hacks in the boot firmware for my ZPU project, to make sure certain structures ended up in SDRAM rather than the initial Boot ROM.
To illustrate the problem let’s look at a minimal test program:
int main(int argc,char **argv)
This little program declares a 16-bit word global variable, and then writes to it. The assembly output produced by
zpu-elf-gcc -Os -S bsstest.c
is as follows:
.type main, @function
.size main, .-main
.ident "GCC: (GNU) 3.4.2"
Note the storeh instruction half way down. That’s the source of my problem. I’ve implemented storeh in hardware for SDRAM, but not for the BlockRAM-based Boot code, and I’d really like to avoid doing the latter if possible, because doing a 16-bit write to a 32-bit wide RAM is going to be messy and eat up logic elements. The boot code is also rather on the large side, so it would be nice to avoid storing unitialised data in there at all if possible. Continue reading →
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 →
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.
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 →