Howards home brew micro
Developing an embedded Native Forth micro in a XILINX FPGA
Wednesday 5 December 2007, 7:47 PM
Home Brew - Native Forth MICRO
Developing & Testing A ‘Home Brew’
Embedded Native Forth Microcomputer.
Why bother ?
Once upon a time when computes were young, and so was I, two languages were developed to ease the task of programming control functions. One was the now ubiquitous C and the other was the now near dormant Forth which appeared as fig-Forth around 1969. I did a couple of projects using Forth, went on a C programming course, and developed an affection for Forth which has lingered to this day.
What’s the attraction ? Firstly Forth has a relatively simple mechanism which is understandable. Forth is very compact traditionally occupying 8K bytes for a complete implementation. A big plus is that when you write a new word (subroutine) in Forth it is immediately available for test and de-bug. You move forward with tested routines, and then there’s the top-down, bottom-up question. Some people like to build systems by planning every detail then filling in the boxes. I like to start at the bottom, putting together the bits I know I’ll need, testing them one by one then combining them to build the system, testing all the way.
Then came to-days highly capable FPGAs and the possibility of embedding a processor, talking native Forth, in the FPGA. There’s a special attraction of this approach. Traditionally a processor has I/O ports which are set up and written to, or read from, to control peripheral functions which are built in the FPGA – hence the ‘system on a chip’. The embedded Forth processor can talk to peripherals, by including in the Forth word set, commands which drive the peripherals. Forth is a ‘stack oriented’ language. This means parameters are passed to and from Forth words on a parameter stack. Consider, as a simple example a pulse width timer requiring a varying count. The Forth program can control the timer using a word in the Forth dictionary which takes the parameter off the stack and loads the timer. This is efficient and has the benefit that, during development, the stack can be loaded from the terminal controlling the Forth computer, the timer word can be executed and the function tested well in advance of complete system test. The same facility is available at any later stage if needed. This ‘real time’ test availability is available throughout the project for all stages of the evolving program.
The implementation:
My native Forth embedded micro is based on Dr. Ting’s Systems Guide to fig-Forth (1981). This came out of the loft about 4 years ago, when I started this project, and has proved an almost infallible source of good code.
Unlike most fig-Forth machines I’ve organised the hardware as a 16 bit machine with 16 bit memory. The completed Forth code, including the editor, occupies 3,304 words. The machine is a large state machine, written in VHDL, and set up to execute the native Forth words in 3 to 5 stages, together with hardware to do the Forth ‘next’ function which moves the machine on from word to word and stack mechanisms. The native words and ‘colon definitions’ (higher level Forth words) are held in RAM blocks in the FPGA, and there’s also an interface to an external flash chip. The system runs on a Xilinx Spartan 3E demo board using the Spartan XC3S500E FPGA.
A difficulty with development of a Forth micro is that the language is highly recursive. I started by cherry picking words that didn’t need other words to work and placing them in the micro’s RAM and testing. Gradually the vocabulary was built up and the more complex colon definitions were introduced – very bottom-up!
The initial testing of words was done in a VHDL simulation environment, which started as a simple mechanism of placing parameters on the stack and executing the new word. As the complete Forth vocabulary was assembled into the RAM the simulation testing was evolved to a terminal simulation reading from an input file and writing to an output file. Finally simulations including flash memory were used to test the Forth built-in editor.
You know a Forth machine is working when you switch it on and the terminal displays ‘fig-Forth’ and ‘ok’ in response to the ‘return’ key. This point was reached on November 9th. 2007.
Next steps:
Now the machine is talking, all the words can be re-tested and any bugs disposed of. The next stage is to test the flash memory interface. The VHDL code will need tweaking to increase the clock speed (currently only 20MHz.). Any real application probably needs only a sub-set of the native Forth words and I hope to develop a utility to strip the code down to the minimal necessary to run an application. Ideally all the Forth facilities can be used to develop the application and then only the minimal code is used to manufacture the product in the smallest FPGA possible.
Some FPGA Stats for the XC3S500E:
Design Summary:
Number of errors: 0
Number of warnings: 6
Logic Utilization:
Number of Slice Flip Flops: 1,771 out of 9,312 19%
Number of 4 input LUTs: 5,353 out of 9,312 57%
Logic Distribution:
Number of occupied Slices: 3,385 out of 4,656 72%
Number of Slices containing only related logic: 3,385 out of 3,385 100%
Number of Slices containing unrelated logic: 0 out of 3,385 0%
*See NOTES below for an explanation of the effects of unrelated logic
Total Number of 4 input LUTs: 5,730 out of 9,312 61%
Number used as logic: 5,353
Number used as a route-thru: 17
Number used for Dual Port RAMs: 128
(Two LUTs used per Dual Port RAM)
Number used for 32x1 RAMs: 128
(Two LUTs used per 32x1 RAM)
Number used as Shift registers: 104
Number of bonded IOBs: 31 out of 232 13%
IOB Flip Flops: 6
Number of Block RAMs: 6 out of 20 30%
Number of GCLKs: 5 out of 24 20%
Number of DCMs: 1 out of 4 25%
Number of MULT18X18SIOs: 1 out of 20 5%
Design statistics:
Minimum period: 37.120ns (Maximum frequency: 26.940MHz)
Howard Myer. 29th. November 2007.
PreviousComments on this post
Congratulations! I played with Forth on Z80 and believe it or not, there was a Forth implementation for the Commodore C64! It was amazing what you could make either chip or system do with no more than 1K of code.
Byte Magazine had a series of articles and then a book was published with a Forth compiler WRITTEN IN FORTH for the Z80. Absolutely the tightest control code you could write in a "High Level" language. At one point a large number of telescope controllers were written in Forth and the world-wide astronomy community seemed to be revolving around Forth. I only know of this connection because of a project I was working on, digital packet radio, was being used by a couple of groups using the packet radio connections they made to remotely control Forth software controlled telescopes.
Now you've done it. I wonder if its possible to write a compiler for Forth that would work on the TI MSP430 micro-power CPU? More than likely!
Private message disabled
