Homebuilt processors
- To: MISC
- Subject: Homebuilt processors
- From: Ales Hvezda <ahvezda@xxxxxxxxxxxx>
- Date: Fri, 14 Nov 1997 22:53:33 -0500 (EST)
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