J1 forth processor in FPGA - possibility of interactive work?

There is a developer that just ported the Verilog version of the J1 processor to MyHDL. You might be able to leverage this work to easily make the modifications you mention. Posting to the MyHDL newsgroup might get a response.

Regards, Chris Felt> Hi,

pga-j1.html

j1demo.tar.gz

Perhaps I don't understand what you are asking. The web page says there is a development system supported under gforth.

"Cross compiler runs on Windows, Mac and Unix"

Are you talking about extending the hardware design rather than new words in Forth?

Oh, you mean "interactive" rather than batch mode... I get it. No, that would require a certain amount of work on run time code on the device as well as supporting code on the host system.

You might take a look at Riscy Pygness. They have already done this for the ARM processor I believe. It might be easier to adapt that code to the J1 app than to reinvent (or recode) the wheel.

Rick

Well, this requires both extension of hardware (bidirectional port) and extension of Forth (compiler words in target system).

On the host system the minicom for UART connection should be enough. For JTAG connection I have ready to use open solutions which may provide conectivity to such bidirectional port.

Well, what I expect to have is something like amforth ( http://amforth.sf.n= et ) but without implementing of ARM core in FPGA. In fact I have already succesfully experimented with similar solution based on

BTW I have found, that the sources mentioned in the J1 paper as published under BSD license:

WZab

e_thread/thread/603f...

net

_c...

At this point I can't say I understand what you are asking. Do you have something specific you are asking about or have you figured it out at this point?

Rick

e_thread/thread/603f...

net

_c...

BTW, you might want to crosspost this to comp.lang.forth.

Rick

The idea was to have a small but efficient CPU inside of FPGA which could be used to collect some debugging data (e.g. connected to my

I've exchanged some e-mails with the developer who ported J1 to MyHDL and after this discussion I think, that the approach used in Riscy Pygness may be really the best solution.

-- Thanks, Wojtek

I once saw a 3-word Forth, which consisted of only three words running on the target board: fetch, store and execute. Everything else was done on the host system and the three words were invoked over a serial link. You have two options:

1. Words compiled on the host run on the host, performing any I/O over the serial link.
2. Words compiled on the host run on the target after being uploaded.

Do you need a CPU to implement the "three words" or can you use hardware? If you have a fast enough serial link (JTAG can be pretty fast), all you need is fetch and store in the FPGA and execute on the PC.

An interesting interface option, while not as fast as SPI/JTAG, is I2C. Silabs CP2112 is a USB HID to I2C interface chip. A Forth (or Python or whatever) Windows app can talk to your I2C stuff with no drivers other than the built-in USB HID support.

-Brad

Frank Sergeant's 3-instruction Forth:

Rod Pemberton

Those three useful commands are necessary to support any kind of remote download or bootstrap regardless of language, but they certainly don't constitute anything resembling Forth. Most microprocessor boards come with this facility on board, usually in some form of ROM. JTAG is one way of doing it, although it also has other functions.

Cheers, Elizabeth

Yes, the "Three Word Forth" is an attention grabbing title, not

Heck, "load, store, execute" would be a "three word forth" in any setting in terms of the absolute minimum bootstrap required, given knowledge of how to build a raw executable on the target.

I implemented SwiftX's XTL protocol (except for Execute) in VHDL to access stuff in my FPGA without the need for a CPU, for testing.

-Brad

Maybe you've looked at the CPU-less option before. Python has an interactive console, so it's almost like "C done right". In that respect, since you seem to know more Python than Forth, Python on the host end would make sense.

Usually a built-in CPU is used primarily to control things. The debugger is an added feature. If all you need is the debugger and you define the hardware, a CPU may not be necessary.

-Brad

Sounds like you will be doing what I would like to be doing. I have my own dual stack CPU design intended to run Forth. I have only used Forth as a sort of macro assembler for it and with no more work that needs such a CPU it has sat for a number of years with no further development.

I have considered a couple of alternatives for adding proper software development support for an embedded processor. One is using open source software such as Riscy Pygness. The other is working from a commercial package such as MPE Forth. From my perspective a commercial package has lot of benefits which include a wide software base that conceivably could be available to support complex projects. The down side is that the use of the processor would be limited to owners of the commercial tool.

The advantage of an open source tool is that it is available for anyone to work with and to work on. But you start with a lot less capability.

How do you plan to proceed? I assume you are looking for some initial capability that will let you compile code to machine instructions, download those instructions to the target and then interact with the target for debugging. Do you look for anything more?

Rick

I definitely prefer to use the open source approach (if I'm only allowed to ;-) - sometimes I'm bound by conditions set for the whole design, which do not allow me to publish it).

Well, unfortunately this a rather low priority project for me, which I'm doing only in my spare time. In fact all I need at the moment is a possibility to define new words for J1.

It could be done in a "Riscy Pygness" way, but then the tool running on the host (corresponding to riscy.tcl in RP) should record all the interactive session to allow further analysis, and extraction of best performing words defined during the session.

Wojtek

On 21/05/11 14:57, wzab wrote: . . .

Today it became possible to build an image and immediately test it using the hardware model description in MyHDL.

It should be possible to continue to use James Bowman's cross compiler after the target is running, once simple read/write/execute access is available.

ToDo:

If there's enough volunteers I'll find a nice open home for the project.

Jan Coombs

I have just prepared a code, allowing to connect a CPU or another SoC simulated in GHDL to the pseudoterminal in Linux (or similar system), and then communicate with it just as with real hardware connected to the real serial port.

I think, that this solution may be useful in development of J1 (ported to VHDL, e.g. via MyHDL) as an interective or tethered Forth system.

The announce of my solution is available in comp.arch.fpga:

The sources are published as public domain on alt.sources:

Wojtek

I have not done it, I'm just starting using FPGA, however the J1 is on my short list of processors to implement. I'm in the process of learning VHDL so I will be doing my own take using VHDL instead of Verilog. Once up and running then my plans is to do upgrades to it.

Sorry if this doesn't help you, but I'm heading in that general direction. Currently my plans are to implement the ep32 and the ep16 first since I have decent documentation and development software for those two CPUs.

Seems you replied to a rather old post. I expect wzab's project is quite done at this point.

I'm not sure what he meant by "interactively define new words and execute them". Someone else, maybe in the Forth group, wanted to do something like that where the basic instruction set could be extended by compiling Forth.

I have worked with microcoded machines and the only way I can think that would be done would be through a special set of primitives that were specific to the CPU rather than typical Forth primitives. You can think of Forth as the instruction set for a stack machine. Inventing new primitives would essentially mean writing new microcode rather than using the existing primitives. I think that would be rather a lot of Forth to generate that new microcode from Forth primitives. I suppose it is doable though. Maybe I just haven't been able to simplify the problem enough to see the solution.

Just to clarify, a microcoded machine has fields or individual bits which control... well, control points. The CPU has many register enables, multiplexers and other functions that need to controlled. The signals that do all this are "control points". A microcoded machine generates those control points either through a 1 to 1 mapping of microcode bits to control bits (a very wide instruction word) or control points that are mutually exclusive can be encoded into a field which is decoded by logic to generate the control points saving microcode memory. Even if the encoded control points aren't mutually exclusive by the hardware design, they will be if encoded.

The primitives for such a microcoded machine would be the control points. In Forth a word could be defined for each one and one for each of the possible selections in an encoded field (hopefully checking if any of the other mutually exclusive words had been used already in this instruction). Not entirely unlike assembly language done in Forth each field could be entered building up the instruction until a finishing word uses that instruction and inserts it into the microcode memory.

Maybe this is not so much more complex than standard assembly language, certainly there aren't all the addressing modes, etc. But I would have a hard time figuring out how to map existing Forth primitives to microcode to define new instructions/new Forth primitives. Simply inserting the same sequence of microcode words as exist in the definitions for the Forth primitives would not be terribly useful since there likely would be very little or even no overhead in using Forth primitives.

Being able to define new instructions that do new or different things would not be easy to specify in standard Forth primitives. This would need to be done using microcode primitives.