J1 forth processor in FPGA - possibility of interactive work?

On May 18, 2:15=A0pm, Elizabeth D Rather <erat...@forth.com> wrote:
> On 5/18/11 6:16 AM, Brad wrote:
> > I once saw a 3-word Forth, which consisted of only three words
> > *running on the target board*

> 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.

Yes, the "Three Word Forth" is an attention grabbing title, not
*really* a three word forth, especially since the execute implies
something to be executed, so for the "processor inside an FPGA"
system, you still need the processor for the execute to have something
*to* execute.

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.

On May 18, 11:15=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> Most microprocessor boards come
> with this facility on board, usually in some form of ROM. =A0JTAG is one
> way of doing it, although it also has other functions.

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

On May 18, 5:32=A0am, wzab <wza...@gmail.com> wrote:
> to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool)

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

On May 18, 8:32=A0am, wzab <wza...@gmail.com> wrote:
> > At this point I can't say I understand what you are asking. =A0Do you
> > have something specific you are asking about or have you figured it
> > out at this point?
>
> 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 myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool)
> and also to control behavior of user IP core.
> Forth seems to be the best solution due to it's extendibility
> and possibility to work using simple link (serial or other).
>
> 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.

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

On May 19, 4:46=A0am, rickman <gnu...@gmail.com> wrote:

> Sounds like you will be doing what I would like to be doing. =A0I have
> my own dual stack CPU design intended to run Forth. =A0I 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. =A0One is using open
> source software such as Riscy Pygness. =A0The other is working from a
> commercial package such as MPE Forth. =A0From 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. =A0But you start with a lot less
> capability.
>

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).

> How do you plan to proceed? =A0I 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. =A0Do you look for anything more?
>

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:
    . . .
>
> 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.

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

> 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.

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:
1) Documentation.
2) Write a test suite for the j1 to cover full instruction set.
3) Export Verilog/VHDL from MyHDL and import to Sim/Synth tools to 
come closer to hardware run.
4) Add interrupt system, to allow debug and modification of a live 
system.
5) Add back in James Bowman's VGA, Ethernet, and other peripherals.

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:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/beef5f55376f48fd
(or look for "Connecting of IP core simulated in GHDL to
pseudoterminal via UART-like interface"
news:<slrniufj16.de4.wzab@wzab.nasz.dom>)

The sources are published as public domain on alt.sources:
http://groups.google.com/group/alt.sources/browse_thread/thread/db9232e97431c019
(or look for "Pseudo UART allowing to connect via pseudoterminal to
GHDL simulated IP core"
news:<slrniufi5a.d67.wzab@wzab.nasz.dom>)

Wojtek

On 5/13/2011 7:34 AM, wzab wrote:
> Hi,
>
> I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
> I'd like to use it to implement simple non-time critical control and
> debugging layer
> in my FPGA based DSP system.
> However to accomplish it I need to add possibility of interactive work
> via console
> connected either by UART or by JTAG.
> Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
> with possibility to interactively define new words and execute them?
> --
> TIA & Regards,
> WZab
>
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.

-- 
Cecil - k5nwa

On 6/10/2016 9:36 PM, Cecil Bayona wrote:
> On 5/13/2011 7:34 AM, wzab wrote:
>> Hi,
>>
>> I'm very impressed with a J1 forth processor:
>> http://excamera.com/sphinx/fpga-j1.html
>> I'd like to use it to implement simple non-time critical control and
>> debugging layer
>> in my FPGA based DSP system.
>> However to accomplish it I need to add possibility of interactive work
>> via console
>> connected either by UART or by JTAG.
>> Has anybody tried to extend the J1 published in
>> http://excamera.com/files/j1demo.tar.gz
>> with possibility to interactively define new words and execute them?
>> --
>> TIA & Regards,
>> WZab
>>
> 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.

-- 

Rick C

On 6/10/2016 10:06 PM, rickman wrote:
> On 6/10/2016 9:36 PM, Cecil Bayona wrote:
>> On 5/13/2011 7:34 AM, wzab wrote:
>>> Hi,
>>>
>>> I'm very impressed with a J1 forth processor:
>>> http://excamera.com/sphinx/fpga-j1.html
>>> I'd like to use it to implement simple non-time critical control and
>>> debugging layer
>>> in my FPGA based DSP system.
>>> However to accomplish it I need to add possibility of interactive work
>>> via console
>>> connected either by UART or by JTAG.
>>> Has anybody tried to extend the J1 published in
>>> http://excamera.com/files/j1demo.tar.gz
>>> with possibility to interactively define new words and execute them?
>>> --
>>> TIA & Regards,
>>> WZab
>>>
>> 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.

-- 

Rick C