10-26-2011 06:06 PM - edited 11-17-2011 06:10 PM
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:
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!
I've posted the mcx16 package plus a demo project on the Avnet Spartan-6 LX9 MicroBoard here:
and I've attached the documentation.
10-26-2011 11:01 PM
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:
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
10-26-2011 11:35 PM
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!
10-27-2011 04:05 AM - edited 10-27-2011 04:49 AM
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
small_one:mcx16 generic map (SelectedSetting => ProcInstance1)... -- this will choose the setting with 8 Registers
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
10-27-2011 07:51 AM
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.
11-23-2011 10:50 PM
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.
12-23-2011 08:12 AM
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.
12-23-2011 10:22 AM
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!
12-30-2011 06:30 AM
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.
01-03-2012 12:23 AM
the academic question wether to teach C or ASM these time is discussed everywhere and the opinions disagree widely.
But I would never blame the students not to be able to learn some given topic.
They might be unwilling and refusing it, which leads to a bad motivation.
Today where cheap microcontrollers have more computing power than the good old IBM-PCs while being powered by some tiny battery the need for some higher language like C seems obvious. And this is true when you focus on microcontrollers like 1GHz ARMs and such.
(Or even AVRs with their C-optimized Opcodes. This is nothing to be learned by humans, just to be implemented once in a compiler!)
For the smaller ones, let it be 8 or 16 bit architectures with simple ASM languages, like Picoblaze or 8051-alike controllers, it might still be good to teach these with assembler, rather than C.
There are good reasons fort this.
The students get a better understanding of the hardware and dataflow inside a microprocessor.
Also, someone who is just able to write "Apps" may not be able to write code for some non-standard hardware device. May it be a Laser Printer or a Coffe-Machine. It needs to be considered wether this range of topics can be covered in a single semester course, and to what extent.
Since you said you intend to use the FPGA and Picoblaze/mcx16 for some VideoGame project you might trick your students into learning assembly language.
Video games are quite demanding, especialy on a limited hardware platform. Even with some C-compiler available there's a high chance that some parts require the use of assembler e.g. to meet real-time requirements that can not be met with the C-compiler results. So at least inline ASM code is needed, which urges the students to get in touch with the assembly language and loose their believe in the almightyness of Compiler languages. Also they learn about physical limits of hardware/software systems. Todays students are hardly aware of their existence.
Basically I would say that if your course is hardware oriented, you should still teach assembly language. Just find a way to "sell" it to the students. If they understand why this "old scool subject" is still highly important, you may raise their motivation and attention level. Still if you have access to some C-compiler for the Picoblaze, you may also demonstrate what's really behind this "extended macro assembler". ;-)
01-03-2012 07:59 AM
Eilert, I completly agree with your view but things are not always like we want they are.
In fact when I said our students will not learn assembly, it is not completely exact because we use picoBlaze (only three hours of practice and 3 hours of theory).
My projects with videoGames are very simple (pong game last year and breakout the present year). They are respectively build with embedded free PIC16F84, embedded free AVR ATMega8 and microBlaze but processors spend more time to wait than to calculate. Then optimisations are not our main problem. (Our students are between 18 and 20 years old)
Because this thread is about mcx16, I want to say I will probably use it. In any case I have a colleague very interesting with this 16-bit architecture because he is making also little videoGame but with picoBlaze and has many 16-bit comparisons to process : probably more easy to do with mcx16 than with picoBlaze.
If somebody knows enough French and want to translate, here is my free Wikiversity Book in French
For your information, if Xilinx had a private WIKI, it is the kind of stuff I would translate in a private wiki. But because of my poor English I will never do the same in a wikipedia site.
01-03-2012 10:59 PM
agreed , within such a small timeframe it is almost impossible to get familiar with a new architecture and ASM language.
From my viewpoint as an outsider of your university, I wonder about the high diversity of architectures you are teaching. (PIC, ATMEGA, Picoblaze and Microblaze) You may have reasons for it, but I see the problem that a great deal of time is wasted in explaining the special features of these architectures if teached in a single semester. Focussing on one architecture for the main time of the semester and giving a short outlook to the existence of other architectures in the end would be my prefered way of teaching microcontroller techniques.
But it's very impressive that your students have to (and are able to) implement some videogame on a FPGA.
Are there separate classes for VHDL and Microcontroller in your teaching plan?
Here we have a class for VHDL and another for Microcontrollers. Unfortunately the second one does not use IP-cores on FPGAS, which would be a great optimisation for the lab.
An open XILINX-Wiki has been proposed in other threads too. If such a thing will come, it could as well be multilingual.
About wikipedia, there's
which you probably already know. But your pages are probably a bit too specific for the generic wikipedia.
For a lokal Xilinx or another FPGA related Wiki they seem to be very valuable.
I have bookmarked your Website.
It may be useful for our students with african background. They are partially more fluent with french than with german.
01-04-2012 10:20 AM
We have a specific course on microcontroller : PIC16F where I finally decide to give up with assembly (approximatively 60 hours).
We have a separate VHDL course after an introduction to logic. Untill now I only teach until FSM and the begining of FSMD (only 25 hours). But this year for the first time I teach picoBlaze : frankly it's not a great success. As you point out, we have not enough time to learn this architecture (even if it is a simple one).
Projects are maid with two students with about 80 hours. Two students learn microBlaze while other learn AVR. Of course one student doesn't have skills with so much architectures. Only the teacher has to know so many architectures. Instead it is probably too much for the teacher and for the students.
>> Are there separate classes for VHDL and Microcontroller in your teaching plan?
No, All our classes learn both microcontroller and VHDL
>> Unfortunately the second one does not use IP-cores on FPGAS, which would be a great optimisation for the lab.
One of my dream is to teach microcontroller with FPGA kit : completly transparent : what is the difference between an easyPIC Developpment system and a spartan3E kit ? Not a great one ! We can then teach one year the PIC and alterning next year with the AVR, both without making a line of VHDL. But I have not found a free core with enough peripheral at the moment.
>> An open XILINX-Wiki has been proposed in other threads too. If such a thing will come, it could as well be multilingual.
I think wiki is a very great system to share knowledge. I have worked in OpenOffice area and publish an English book with my poor English because it was a private Wiki. Both wiki and forum are good together.
>> But it's very impressive that your students have to (and are able to) implement some videogame on a FPGA.
I think our teaching is very specific in France. I don't want to speak of performance because it is as everywhere, I think. But our students have probably too many lectures exercises and practice (30 hours/week) and then they are less free than in other countries. When they have projects we are in the project room spending many time to explain... and as result, it is difficult to say at the end if this is the student's project or the teacher's one.
>> I have bookmarked your Website.
It's not my website in fact : wikiversity belongs to wikipedia : it's a wikipedia's area left for university lectures or practices.
Where do you work in Germany ?