another Forth CPU design

While trying to minimize my microcode implementation to implement a small

6502 CPU, eventually I designed a new Forth CPU:

formatting link

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
Reply to
Frank Buss
Loading thread data ...

Frank Buss wrote in news:1ki61sjualhfi.xxscjrzdk91a$. snipped-for-privacy@40tude.net:

Simulate first.

jrh

Reply to
jrh

I once implemented a microcode assembler generator in Common Lisp. The specification for the mnemonics and arguments were written in Verilog (as `define statements). The program would read this specification and 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?
 Click to see the full signature
Reply to
Petter Gustad

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:

formatting link

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
Reply to
Frank Buss

Impressive.

With a simple core, that is not clock constrained (ie spare cycles at the core), how feasible is it to time-share that core, with two code/data streams, so effectively you see two independant 'multi-processor' cores ?

Not sure if I have mentioned IEC 61131 Instruction List pgm before, but this looks fairly close to that.

Some quick reading on IL is

formatting link
formatting link
formatting link
formatting link

I'd be interested in any comments you have, on doing an IL version of your FPGA.Forth ?

I'd guess one would make MUL.DIV optional, and constrain the data types to shrink the core.

-jg

Reply to
Jim Granville

This should be easy. The only states in the core are A, SP, RP and PC, which have to be swapped.

But instead doing it on the hardware level, I think it would be better to do it in software: First the CPU needs to be enhanced to allow interrupts and to load/save the SP and RP registers. Then you can implement a scheduler for as many threads you want.

I don't know IL, but it looks a bit too low-level. Creating a function like decribed at

formatting link
would look like this in Forth (the stack notation in parantheses ( s _r -- ) is only a comment and can be omitted)

value q : sr ( s _r -- ) q and or to q ;

Then you can test it interactively at the Forth command prompt ("q ." shows the current value of q. Anything after "\" in a line is comment)

1 1 sr q . \ set flipflop 1 ok

0 1 sr q . \ set input = 0 => q is not changed

1 ok

0 0 sr q . \ reset flipflop

0 ok

Maybe an IL core could be a bit smaller, because it doesn't have a data stack, but I think programs would be larger and are more difficult to write and maintain than Forth programs.

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

That's the more conventional way, but I like the deterministic nature of hardware time-sliced cores - and they can of course, also run interrupts (giving SW threads on the HW threads.. :).

The problem with interrupts, is the more complex a system is, the bigger the jitters become. With HW timeslice, each task is invisible to the other, in the time domain, and they need to share some data to communicate.

IL does allow brackets, and expressions inside the brackets evaluate first, just like in maths, and that gives a Data Stack. So the IL 'Assembler/Compiler' would have to generate the opcodes to support the stack to support the brackets.

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.