PicoBlaze

[gbredthauer]

Hi all,

I've written mcx16, a free 16-bit microcontroller inspired by PicoBlaze.  It uses a similar instruction set, but is written in generic VHDL.  Some highlights:

• 16-bit addresses, data, port addresses and ports
• Can use 1 (non-pipelined) or 2 (pipelined) clocks per instruction
• 74MHz (74 MIPS) on a Spartan 3 XC3S200AN-4 non-pipelined, and 119 MHz when pipelined (59 MIPS), using 110/114 slices (area optimized, 16 registers, 32 deep stack, 512 word program, distributed stack)
• 107 MHz (107 MIPS) on a Spartan 6 XC6SLX9-2 non-pipelined, and 166 MHz when pipelined (83 MIPS), using 46/41 slices
• Pipelining, register count (1 – 256), stack depth (1 – 65536), and program memory size (1 – 65536 instructions) are all user-set generics
• Cross-platform assembler
• Optional JTAG loader using Kris Chaplin's technique and cross-platform Xilinx tools

It passes the testbenches I've written, and has talked over a serial port from a Spartan-3 and the Spartan-6 MicroBoard.  However, I'm sure there are bugs I've not yet uncovered.  Please let me know if you run into any problems.  Cheers!

-Greg

Update:

I've posted the mcx16 package plus a demo project on the Avnet Spartan-6 LX9 MicroBoard here:

mcx16

and I've attached the documentation.

[eilert]

Hi Greg,

you mentioned the mcx16 to be free.

But it seems like it is still locked on your harddrive. ;-)

Do you have some webpage, or can you make it an opencores project?

This way many people can take a look at it and supply you with bug reports and other useful hints.

Also, mcx16 is some very common term if you google for it.

(it appears even to be the name of an option of the gcc compiler)

So if yours is a 16 bit controller it might fill in the gap between micro and pico.

Take a look at this thread for inspiration:

http://forums.xilinx.com/t5/PicoBlaze/Can-you-develop-a-NanoBlaze/m-p/20260

______

Another questin that just comes to my mind:

You mentioned a lot of options to be user-setable by generics. Including registers and stack deepth.

Probably these Generics are bundled in some package.

So, does your Assembler read in that package as well, to be able to check for invalid use of non-available ressources?

(e.g. load S64, 0 should raise an error if the register configuration constrains the registers to S0..S31)

Im just writing this in a picoblaze-style since I don't know the details about the terms you are using in your design.

Have a nic esynthesis

  Eilert

[gbredthauer]

Hi Eilert,

It's true, I didn't jump straight to full distribution - my hope is that initial feedback will come from folks like you who are already proficient with VHDL, PicoBlaze, etc, as opposed to being deluged with support questions unrelated to the processor itself. 

I'll be hosting it on my webpage, under the simplified BSD license.  I don't know enough about the pros and cons of OpenCores to decide on that avenue.

I tried googling a few different potential names - always the hardest part!  mcx16 didn't seem to pop up coupled with VHDL much.  I'm open to other suggestions!

I actually chatted a bit with Ken Chapman to make sure it was OK to release a processor with an instruction set very similar to PicoBlaze, and about the "NanoBlaze" moniker.  Releasing the processor was deemed OK, NanoBlaze is reserved. Thanks again Ken!

My assembler does not check for the user using non-existent hardware.  The processor itself is a single VHDL source file, with the generics (number of registers etc) passed in at the top level.  Thus, they are set in the users code.  Having them in a separate package file that the assembler checks is an interesting idea, but how do you handle more than one mcx16 with different parameters in the same design?

I'd be happy to send you the source and documentation if you're interested in the details!

-Greg

[eilert]

Hi Greg,

sure, some qualified preinspection can't be wrong before launching it to the public.

I don't know of anything that would speak against opencores. The advantage surely is that people woh are looking for cores search there first to get an idea what is available. But if they find something useful there, they won't look anywhere else, even if better stuff could be found elsewhere.

___the package idea:

How about having of Generic value arrays or records in the package.

Then a local generic at the instantiation could select the used value from that package.

e.g: in package:

        const ProcInstance1 : natural := 3; -- Choose a setting for some Instances.

        const SelectNumberOfRegisters : array(0 to MaxSettings) of natural range 0 to 255 := (4, 16, 32, 8,16, 4 ,32,0,0,0);

                                                                                                                                         -- 0 for nonexisting parameter sets

       the instantiation:

      small_one:mcx16 generic map (SelectedSetting => ProcInstance1)...   -- this will choose the setting with 8 Registers

      mcx16_toplevel:

        const NumberOfRegisters : int := SelectNumberOfRegisters(SelectedSetting);

That's just some quick idea. There may be some smoother way, but it should be possible without too much coding effort.

 ## I just recognized some flaw in my idea. Of course the Assembler needs to know the setting too. ##

 ### Modified my example to handle this in one package. Now the Assembler just needs to know for which instance some source shall be compiled. ###

Have a nice synthesis

  Eilert

[gbredthauer]

Perhaps the user could create one package per desired configuration in separate files, and then pass that package name to the assembler for compiling a given instance?  That's definitely less error-prone than passing all of the generics to the assembler by hand.  This is one of those areas where some formal training would probably boost the elegance of my solution.

[gbredthauer]

Update: Code is now posted, enjoy!

[eilert]

Hi all,

I have tested the example design for the mcx16 core and uart on our Spartan2 based development boards.

(XC2S200-5: 10% slice utiization,  5 BRAMS, 44MHz (single cycle implementation))

Works great. Giving enhanced KCPSM3 power to old S2 devices.

Assembler works under linux too, using wine.

Regards

  Eilert

[sergemoutou]

Happy to see a new 16-bit architecture.

PicoBlaze is for me very interesting for teaching with undergraduate students. Extending ports is very easy that's the advantage of such architecture which is propably the case in your MCX16. The disavantage of picoBlaze is the lack of C compiler. In fact I have found one but I have not tried it. I suppose what we can do with it is very limited with such a little ROM space. This is not the case with your architecture but there is no C compiler.

The great advantage with source code soft-processor (free or not free) is we can only use web-pack licencing : very  interesting with students.

I'll have a look to your MCX16 next year but I don't know when.

[gbredthauer]

Hi,

Depending on the class, I can imagine mcx16 being useful for teaching. The VHDL is relatively compact, and the functions it's trying to implement are basic (no complex lookahead caching etc).

C compilers for PicoBlaze (and mcx16) will tend to be inefficient in both size and speed, since C really wants access to general purpose RAM and/or a stack.  Adding RAM or a stack can be done through the I/O ports, but it's not optimal.  I believe most people using PicoBlaze (or mcx16) are implementing small embedded functions that are too complicated for basic state machines but not so complicated that a full-blown processor is necessary.  I often use these little microcontrollers to interpret higher level serial commands and translate them into low level bit operations, such as configuring DACs, ADCs, or other devices on the board with the FPGA.

If you're teaching embedded logic/VHDL/FPGA classes, I would think the abstractions that C adds would detract from the material.  If you're teaching C software classes, writing code on a PC is a lot less work than running on an FPGA/ISE/microcontroller combo!

-Greg

[sergemoutou]

Probably C is adding an abstraction... But for the first time I will completly remove the assembler part of my microcontroller teaching this academic year !  Because our undergraduate students are unable to learn assembly language today. I hope it is not so all around the world.

I agree with the stack problem and didn't remember it was so important.

Teaching hardware is easier with softcore. For instance interfacing a VGA controller with a core is easy in a FPGA. This is the most important reason I use FPGA in my VideoGames projects : students like such projects where testing is playing.

Hope to use mcx16 as soon as possible.