You may have noticed the new “ZPU” section on the header of this site. The ZPU is a very useful little processor, and I think it’s under-appreciated because of a lack of documentation and design examples – so I’m trying to redress the balance a bit with my ZPUDemos repository.
So far I have a very simple Hello World project, which on an Altera DE1 board takes up a tiny 684 logic elements, including RS232 transmission. The ROM is also pretty tiny, bearing in mind it’s written in C, at under 2kb.
The repo also now contains Dhrystone benchmark projects, which use the ZPUFlex variant both with and without the optional hardware instructions, turning in about 1.7 DMIPS for the barebones configuration, and 5.1 DMIPS for the version with optional hardware instructions enabled.
More demos will follow in due course.
Great stuff. Thinking about using the zpu in a project of mine (Atari xl on de1) for sd card access and these examples will be very helpful.
Excellent – that’s exactly the kind of task for which the ZPU has the perfect balance between power and resource usage.
I have some simple “load files from SD Card” firmware waiting for me to tidy it up and add it to the ZPUDemos repo. If you compile it without emulated instructions t fits within 4kb of RAM, so only uses 8 M4Ks.
Best of luck with the project – are you documenting the progress anywhere?
If you’ve built sd reading firmware and don’t mind me using that would be awesome – save some time. Getting this in will, I hope, increase the number of testers. So far two people have been trying stuff and it would be good to have more feedback.
I’m mostly documenting it in my notebook right now, with the intention of writing it up later. Though since I’m quite excited about the project I keep replying to myself on atariage at http://atariage.com/forums/topic/213827-potential-new-hardware/. I’m uploading some sof files + changelog to my web server (see thread).
OK there’s now an SDBootstrap demo project in my ZPUDemos repository – hope it helps 🙂
There’s still some debugging to be done – I’ve just tested here with a handful of different cards; it’s worked fine with five, and failed with two.
(I’ve set up reset on the DE1 to be KEY0 xor SW0, which I’ve found useful for debugging – so if nothing seems to happen check that SW0 is up.)
Have fun 🙂
Many thanks. I’ll take a look.
Quick question… which ZPU version do you use? Zealot zpu_medium.vhd will not synthesize in Quartus 2. I’m trying zpu4 zpu_core.vhd but it gets stuck on the first IM. READ_EN/WRITE_EN are not asserted and MEM_BUSY is low. Looking at the vhdl I can’t see a ‘state <=' assertion for this instruction so I guess this version is just broken too.
Anyway its clear you are using a zpu_core.vhd from the code but neither version I can see in the stable archive has any generics…
I’m using my own variant, ZPUFlex, which you can find here: https://github.com/robinsonb5/ZPUFlex
If you check out the ZPUDemos git repo, you can pull the ZPUFlex core into the tree with
git submodule init
git submodule update
The code itself will be compatible with any ZPU variant, but you’ll probably have to adjust the linkscript if you don’t use my canned standalone examples.
Aha! I didn’t spot your ZPUflex. I was trying to get the ‘official’ ZPU up and running before running any of your examples. I’d just pulled down a Makefile and your linkscript from your repo – to compile a while loop that reads/writes memory, write a MIF file and put it into a block ROM.
As to why the zpu4 version isn’t working for me. I can see it does bump pc in the execute state which should be enough to move to the next instruction. However for some reason it gets stuck and never moves to another state or reads/writes RAM. Perhaps it just doesn’t synthesize properly in Quartus. I’ll debug in SignalTap some more – or perhaps I might even figure out how to use ModelSim! So far I’ve been avoiding it since it seems incredibly complicated to set up…
Hmmm – maybe it’s related to in_mem_busy? I presume you’re using the full ZPU4 core here, not zpu_tiny? (The tiny variant can’t execute code from outside the built-in blockram.)
Got it:-) I needed to latch the address on mem_read/mem_write. Doh.