frank buss

While trying to minimize my microcode implementation to implement a small
6502 CPU, eventually I designed a new Forth CPU:

http://www.frank-buss.de/vhdl/forth-cpu2.html

I would like to have a full Forth system for it, which could run at about 4
MIPS with a 50 MHz clock on a FPGA with internal block RAM. This could be
at least doubled with some more thinking about the RAM interface. With this
system I can implement a 6502 CPU emulation :-)

But first I would like to hear some comments. What do you think about the
instruction set architecture (ISA)? Any ideas how to modify the VHDL code
(see bottom of the page) or the ISA to use less LEs, but without impact on
the compactness of code for the CPU?

At the bottom of the page you can find a full Quartus 7.1 project for
testing it. Looks like adjusting some settings can increase or decrase the
number of LEs by 20% and more. E.g. when changing "Auto RAM replacement" to
"On" in "More Settings" in "Analysis & Synthesis Settings" increases the LE
count from 590 to 697 LEs, which is strange, because I would expect that
replacing registers and logic with RAM should save LEs, and if not, the
compiler should not use it.

When the design is finished, I want to implement an assembler for the
system in Forth. How could the mnemonics look like and are there any good
examples of assemblers in Forth, which could be used to implement my ISA?
For testing, an emulator would be nice, too, but this should be easy to
implement, because of the simple and orthogonal ISA.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

jrh

Simulate first.

jrh

petter gustad

Frank Buss <fb@frank-buss.de> writes:

I once implemented a microcode assembler generator in Common Lisp. The


generate an assembler on the fly and then assemble the
microprogram. There were only two hard-coded instructions: ORG and
LABEL. The assembler source would be written using Common Lisp
syntax. The actual assembler generator was only a couple hundred lines
long.

The advantage was that the Verilog code was consistent with the
assembler and the designer did not have to fiddle with lex, yacc
etc. Only the Verilog source had to be updated to add new instructions
and/or parameters.


Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

frank buss

This sounds like a good idea for more complex designs, but I've simplified
my design again, now the whole VHDL CPU core is 173 line, including
comments, for which a generator would be overkill:

http://www.frank-buss.de/forth/cpu1/

While developing the CPU, I implemented it in VHDL, first. Then I ported
the VHDL source to an emulator, and I tested it with an assembler, both
written in Forth. With the emulator it was easy to find some bugs, which
changed the VHDL source, too. Now it is a nice little CPU core, not very
fast (it needs 4-6 clock cycles per instruction), but small (423 LEs with
an Altera Cyclone I device, about 7% device utilisation).

The next step is a Forth cross-compiler. This should be easy, because
basicly a colon definition needs only to define a constant with the highest
bit set to 1 for the address (because then this will be interpreted as a
call in other words by the CPU) and the content will be simply storing the
value of constants to memory. A bit more tricky will be loops and if/then.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de