home .. forth .. misc mail list archive ..

Homebuilt processors


Hi All,


>>>Anybody else share the hobby of building home-made processors?
>>That's something I'm interested in.  Any tips for beginners?


	Yup I'm into homebrew as well.  <shameless plug> See
http://www.cybercom.net/~ahvezda/hardware/ for some (hopefully)
useful stuff related to homebrew. </shameless plug>

kc5tja had some good tips; here's some of my comments.  


> 1) ALWAYS have a clean distinction between functional units in your CPU.
> Design your CPU as you'd design a Forth program -- always abstracting.
> Unlike analog electronics, digital circuits make this quite easy. 


	Critical!  Since once you get several functional units on the same
board debugging is a whole lot easier if you can debug each one without
too many interdependencies between them.  Granted you can't necessarily 
achieve total isolation of functional units, but by starting with a 
"known working part" and build upon each incremental checkout (or test), 
eventually you will (hopefully) end up with a totally working processor.


> 2) ALWAYS keep timing parameters in mind.  I can't tell you how difficult
> it was to get my first 4-bit execution unit running... 


	I always sit down before I even touch any hardware and run through
all the various data/control paths (especially the critical paths: the
longest paths) just to make sure I'm not violating any setup, hold,
or other timing parameters.


> 3) ALWAYS treat the CPU as if it were a PERIPHERAL on the bus, not the
> bus-master proper.  This means the CPU will use an external bus arbiter, 
> but that's OK -- it makes for better bus design anyway.
> 4) The CPU *ALWAYS* has the least bus priority anywhere.  Otherwise,
> things like sound peripherals and video peripherals would loose all of
> their data streams before they could refresh themselves.  

	Agreed.

> 5) KISS.  Don't strive for too much too fast.  My first CPU was a 4 bit
> unit that could only address 128 bytes of RAM (256x4), and had eight
> instructions (load/store accumulator, display accumulator, hide display,
> increment accumulator, decrement accumulator, jump if zero, and no
> operation).  Theoretically, my first CPU was Turing complete, but with
> only 256 addressable nybbles, it didn't do too much... :)  


	Ah my favorite concept, KISS.  Don't try to overdue the processor.
It's a whole lot easier to debug a simple straightforward processor that
a processor that's loaded with nasty complexities.  Especially if it's
your first time (that is homebrewing :-)  My first CPU had an 8 bits data
bus with a 16 bit address bus.  Check out Brad Rodriguez's 
"A Minimal TTL Processor for Architecture Exploration" paper for an idea
for what is pretty close to KISS.  http://www.forth.org/fig/piscedu2.html 

	Also related, don't try to make the first try run too fast.  My
first CPU ran at 2.5 MHz with some of the control paths running at 5 MHz.
This was plenty fast for me and I probably could have run my CPU faster.
I plan to run my next processor at the same rate initially but this time
I plan to increase the rate to the max that my control/data paths allow.


> 6) RE-USE EXISTING DESIGNS.  If the bus arbiter for the 4-bit architecture
> worked like a dream, then use the same technology for the 8-bit and 16-bit
> CPUs you build!! :)    


	Yup.  Gives you a warm fuzzy feeling knowing that that arbitrator
is a known design and will work as you expect it.  You can spend less time
worrying about it and spend that time worrying about the other new units.


> 7) DOCUMENTATION, DOCUMENTATION, DOCUMENTATION.  I'm literally kicking
> myself everyday because I never recorded my results when I built my 4 and
> 8 bit units.  I wish I had, because then I could write to magazine
> articles on the subject. 

	
	Ah another really important point!  I was forced to write documentation
on my first homebrew (did it as school project), and I still have all of it. 
I am constantly looking at it seeing how I did something or another.  Keep 
all documentation.  I kept everything, including the source to the various 
incremental microcode tests.   Now I document everything I do; I keep 
everything related to a project in a big three ring binder.


> I even pondered the concept of a GNU Processor Architecture, of a freely
> redistributable and GNU copylefted processor architecture design.
> Unfortunately, with me having so little time, it never took off.             


	I've pondered this as well ( even though I probably wouldn't release
it under GNU, probably something a bit more like BSD )  Fortunately I do
have the time :-), so I am continuing to explore this idea with the next
generation of my CPUs; which has been on the drawing board for sometime,
since I keep realizing the mistakes I made on previous projects, and
redefining what I hope to achieve.   Hope to have something finalized 
by this December (that's a hard deadline for me.)

	There is a mailing list about homebrew processors (which I
archive the articles for) which has totally died down in traffic,
so if you want to discuss homebrew more, see my web page for more
details (http://www.cybercom.net/~ahvezda/hardware/hotwired.html)
Gee I hope that list is still up.

Anyway enough of my rambling.


								-Ales

--
   v      v
Ales V. Hvezda
ahvezda@cybercom.net
http://www.cybercom.net/~ahvezda