offroad

"medium" ZPU simple example

Recommended Posts

Hi,

 

it can be surprisingly difficult to get started with a simple, embedded CPU without the luxury of infrastructure such as debugger or bootloader. 

One challenge is the toolchain between C code and the physical memory where the program code goes. Especially the last step can be hard and Xilinx' buggy data2mem utility doesn't exactly make it any easier.

 

Attached a simple example project with a medium-size ZPU that blinks the LED. It's maybe not the world's most powerful processor, but it leaves 80 % of the LX9 FPGA available for RTL (for comparison: The "small" zpu variant would leave 90 % free, but it is much slower).

 

One port of the dual-port RAM is left unused, so it's fairly easy to connect other blocks via shared memory (i.e. move the start of the stack back to leave some space). Also, connecting hardware to the processor's external bus is probably as easy as it can get, like in the good ol' days when you'd do this with a soldering iron and a GAL16V8 as address decoder...

The archive includes several configurations, for different memory size, together with a data2mem input file. See the README file.

 

The turnaround cycle for C compilation / bit stream merging / uploading is fairly quick, less than one second on Papilio Pro.

This makes it interesting for example to control RTL under development, as pattern generator, to check the output etc. I will probably add a UART and / or a RGB display for my own use, but let's post this now while it is all nice and simple :)

 

EDIT: upload revised (rtl/mem folder fixed)

ZPU_medium_tar.gz

Share this post


Link to post
Share on other sites

Excellent piece of code. This example make the integration of this CPU into an existing design quite simple .Too bad this core do not have interrupt support.

Need to have a trial later...

Share this post


Link to post
Share on other sites

True, no interrupts in this one.

 

You may be able to plug a different zpu variant into the top level file. For example, the "avalanche" has interrupt support, but I have not found a single example of someone actually using it. Otherwise, it looks good but I didn't succeed in making it work.

 

Now if you need interrupts but don't care about speed otherwise, try the "small" zpu. Here is a similar example:

http://forum.gadgetfactory.net/index.php?/topic/1863-bare-metal-zpu-hello-world/

 

This one has interrupt support. There is some wacky logic to prevent interrupt reentrance (should use a proper external IRQ controller) even though I learned later it wouldn't necessarily be a problem.

 

The attachment in the linked post also includes ZPU toolchain binaries for windows (but they aren't hard to find elsewhere).

Share this post


Link to post
Share on other sites

This one has interrupt support. There is some wacky logic to prevent interrupt reentrance (should use a proper external IRQ controller) even though I learned later it wouldn't necessarily be a problem.

 

The attachment in the linked post also includes ZPU toolchain binaries for windows (but they aren't hard to find elsewhere).

 

I spend several hour on avalanche implementation too. But the absence of "on the self working example" stop me.

 

Do you mean "interrupt reentrance is not necessarily a problem" ?

 

Not interrested by windows toolchain. I manage to build mine. But it's a pain : no documentation. One build script in zpu db refer to '-phi' switch on zpu-elf-gcc : which option are relevant of the platform and which one are relevant of the core ? Only way to understand what it does is to dig into zpu gcc fork ... The 64 bits toolchain version only compile with a 'magic' no documented...

No tutorial on how it would be possible to add a dedicated intruction in the compile toolchain, even in an asm section would be enough.

 

All this thing make that i never figure have fun with zpu cpu, because i's too difficult to use for me. I think with at least on good tutorial. With sometime basic things explain :

link script, uart integration in a bootcode/romcode and the role of the various compiler switch could reduce the gap and make this cpu core more popular.

Share this post


Link to post
Share on other sites

>> Do you mean "interrupt reentrance is not necessarily a problem" ?

 

yes, I think it will interrupt the interrupt handler just like any other code. Haven't investigated this, though, better avoid interrupts altogether.

I have no idea what "-phi" does. I was looking for that myself but came up with nothing.

 

Actually I think I downloaded my linux toolchain as binary. Wouldn't want to compile that myself.

Yes, unfortunately it seems like the C compiler is much more complex than the processor itself.

Share this post


Link to post
Share on other sites

Hi,

 

attached a somewhat extended version. This one includes a RGB interface (well, actually monochrome :) ) and printf() support in software.

The overhead is fairly small, the whole project is still at 20 % utilization.

 

I use the Xess RGB adapter, the UCF file may need some editing for the "offical" one.

The display adapter can even do graphics by redefining the character data that is in the same memory space.

 

A UART comes next, but I'll use polling instead of interrupts for simplicity.

edit LED address in code example is wrong, use 0x12000.

zpu_soc_tar.gz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now