J1 forth processor in FPGA - possibility of interactive work

[wzab]

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

 

[Christopher Felton]

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 Felton

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

 

[rickman]

On May 13, 8:34 am, wzab <wza...@gmail.com> 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 inhttp://excamera.com/files/j1demo.tar.gz
with possibility to interactively define new words and execute them?
--
TIA & Regards,
WZab

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

 

[wzab]

On May 14, 12:40 am, rickman <gnu...@gmail.com> wrote:

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?

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

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.

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.
https://groups.google.com/group/alt.sources/browse_thread/thread/38186c49dc5cf32e
https://groups.google.com/group/alt.sources/browse_thread/thread/603ff14bdf020776

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.

Well, what I expect to have is something like amforth ( http://amforth.sf.net
)
but without implementing of ARM core in FPGA.
In fact I have already succesfully experimented with similar solution
based on
6809 core published on googlecode : http://code.google.com/p/rekonstrukt/
However the 6809 SoC is slow and resource hungry. J1 is both faster
and simpler.

BTW I have found, that the sources mentioned in the J1 paper as
published under BSD
license:
http://excamera.com/files/j1.pdf
and which may be downloaded via:
svn co https://code.ros.org/svn/ros-pkg/stacks/camera_drivers/trunk/wge100_camera_firmware/src/
are much better for experiments then j1demo.tar.gz (eg.they allow you
to use different Ethernet
PHY).

WZab

 

[rickman]

On May 14, 7:37 am, wzab <wza...@gmail.com> wrote:

On May 14, 12:40 am, rickman <gnu...@gmail.com> wrote:

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?

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

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.

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.https://groups.google.com/group/alt.sources/browse_thread/thread/3818...https://groups.google.com/group/alt.sources/browse_thread/thread/603f...

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.

Well, what I expect to have is something like amforth (http://amforth.sf.net
)
but without implementing of ARM core in FPGA.
In fact I have already succesfully experimented with similar solution
based on
6809 core published on googlecode :http://code.google.com/p/rekonstrukt/
However the 6809 SoC is slow and resource hungry. J1 is both faster
and simpler.

BTW I have found, that the sources mentioned in the J1 paper as
published under BSD
license:http://excamera.com/files/j1.pdf
and which may be downloaded via:
svn cohttps://code.ros.org/svn/ros-pkg/stacks/camera_drivers/trunk/wge100_c...
are much better for experiments then j1demo.tar.gz (eg.they allow you
to use different Ethernet
PHY).

WZab

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

 

[rickman]

On May 14, 7:37 am, wzab <wza...@gmail.com> wrote:

On May 14, 12:40 am, rickman <gnu...@gmail.com> wrote:

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?

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

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.

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.https://groups.google.com/group/alt.sources/browse_thread/thread/3818...https://groups.google.com/group/alt.sources/browse_thread/thread/603f...

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.

Well, what I expect to have is something like amforth (http://amforth.sf.net
)
but without implementing of ARM core in FPGA.
In fact I have already succesfully experimented with similar solution
based on
6809 core published on googlecode :http://code.google.com/p/rekonstrukt/
However the 6809 SoC is slow and resource hungry. J1 is both faster
and simpler.

BTW I have found, that the sources mentioned in the J1 paper as
published under BSD
license:http://excamera.com/files/j1.pdf
and which may be downloaded via:
svn cohttps://code.ros.org/svn/ros-pkg/stacks/camera_drivers/trunk/wge100_c...
are much better for experiments then j1demo.tar.gz (eg.they allow you
to use different Ethernet
PHY).

WZab

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

Rick

 

[wzab]

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?

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 http://www.ise.pw.edu.pl/~wzab/fpgadbg tool)
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.

--
Thanks,
Wojtek

 

[Rod Pemberton]

"Brad" <hwfwguy@gmail.com> wrote in message
news:75de307b-6c91-46ed-9ee6-e2a57c5716a0@s41g2000prb.googlegroups.com...
On May 18, 5:32 am, wzab <wza...@gmail.com> wrote:

Forth seems to be the best solution due to it's extendibility
and possibility to work using simple link (serial or other).

I once saw a 3-word Forth,

Frank Sergeant's 3-instruction Forth:
http://pygmy.utoh.org/forth.html


Rod Pemberton

 

[Elizabeth D Rather]

On 5/18/11 6:16 AM, Brad wrote:

On May 18, 5:32 am, wzab<wza...@gmail.com> wrote:
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 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.

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

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

 

[Brad]

On May 18, 5:32 am, wzab <wza...@gmail.com> wrote:

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

 

[BruceMcF]

On May 18, 2:15 pm, 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.

 

[Brad]

On May 18, 11:15 am, Elizabeth D Rather <erat...@forth.com> wrote:

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.

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

 

[Brad]

On May 18, 5:32 am, 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

 

[rickman]

On May 18, 8:32 am, wzab <wza...@gmail.com> wrote:

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?

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

 

[wzab]

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

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.

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

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

 

[Jan Coombs]

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

 

[wzab]

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&gt

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&gt

Wojtek

 

[Cecil Bayona]

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

 

[rickman]

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

 

[rickman]

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