J1 forth processor in FPGA - possibility of interactive work?

Rickman,

> > Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
> > it might be enough. Most early microcomputers had 80KB floppy disks.
> 
> I have no idea what you are trying to say with this.  Lots of things 
> were done in the early days of programming including using toggle 
> switches to enter programs.  I don't wish to duplicate any of that.

I am saying some programming environments are pretty small and some embedded
processors are getting large enough that the two can meet. Sure, small can
mean primitive and awkward but not necessarily. I find stuff build around
Eclipse pretty unusable so consider the GB of disk and RAM that they need
a waste.

> I don't know what you are trying to say here.  You mentioned your 
> "SiliconSqueak" which I assume is a processor design.  You seem to be 
> talking about running it on an rPi which doesn't make sense.  Were you 
> just using the rPi as a point of comparison?

Sorry about the confusion. SiliconSqueak is indeed my own processor and
I was talking about implementing it on low end FPGA boards (Gabor and
Dave Wade have just suggested some nice options in this thread) and
comparing their resources with those available on the Raspberry Pi.

The Squeak virtual machine (both the original interpreter and the new
Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
foundation's efforts to make Scratch more usable. This means you can
either run some software on the Pi with these VMs or on an FPGA board
with my processor. That makes comparing the two options interesting,
though an FPGA board costing around $100 might have less resources
than a Pi board costing $5.

-- Jecel

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
>
Its king of a round way to what you want, but the following is 
interesting and might accomplish what you wish.

The ep16 CPU contains within it's zip file the following;

weForth - a Windows version of eForth used to create a development system.
Meta compiler - for the ep16 but easily modified for other stack machines
eForth source - not in assembler but in Forth primitives  be 
meta-compile into the target CPU
Documentation - not just for the CPU, and more importantly for the software.

This package will result in a copy of eForth that would be resident in 
the target CPU

I am working with the ep32 which comes with the same software to learn 
VHDL, my next target is the ep16, followed by the J1, when I get there I 
will be modifying the target compiler to generate J1 primitives and in 
so doing ending with a copy of eForth that resides inside the J1. You 
can wait until I get there or you can Download the code for the ep16 and 
modify it yourself.

Theoretically the J1 has many new instructions built in without changing 
the FPGA code, you would have to add the extra instructions that are 
already there but nor used to the metacompiler software, it looks like 
it's a relatively simple task.

Have fun going Forth.

-- 
Cecil - k5nwa

On 6/17/2016 1:37 PM, Jecel wrote:
> Rickman,
>
>>> Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
>>> it might be enough. Most early microcomputers had 80KB floppy disks.
>>
>> I have no idea what you are trying to say with this.  Lots of things
>> were done in the early days of programming including using toggle
>> switches to enter programs.  I don't wish to duplicate any of that.
>
> I am saying some programming environments are pretty small and some embedded
> processors are getting large enough that the two can meet. Sure, small can
> mean primitive and awkward but not necessarily. I find stuff build around
> Eclipse pretty unusable so consider the GB of disk and RAM that they need
> a waste.

I have no idea why you are bringing Eclipse into a Forth discussion.

Programming from a PC is the easiest way to work unless your target is 
heavy enough to support an operating system.  So in the Raspberry Pi I 
program directly on the target.  Any embedded board, even with an on 
board Forth compiler, the PC gets used as the host for most development 
work while debugging is on the target.  I load the code which is one 
command and takes maybe a second.  I test a few words or word from the 
command line until I find a bug and make changes.  I forget the stuff 
just loaded, load the new code and in less than 5 seconds I'm back to 
debugging.  Hardly an onerous cycle.  In fact, I barely know I'm working 
from my laptop on a remote target until I get the target locked up and 
have to walk to the other room to push the reset.


>> I don't know what you are trying to say here.  You mentioned your
>> "SiliconSqueak" which I assume is a processor design.  You seem to be
>> talking about running it on an rPi which doesn't make sense.  Were you
>> just using the rPi as a point of comparison?
>
> Sorry about the confusion. SiliconSqueak is indeed my own processor and
> I was talking about implementing it on low end FPGA boards (Gabor and
> Dave Wade have just suggested some nice options in this thread) and
> comparing their resources with those available on the Raspberry Pi.

I haven't spent much time looking at FPGA boards.  I build products with 
FPGA but they are seldom on boards that would support other than fairly 
primitive processors that are doing simple control functions.  My 
current product does not have a processor, but the FPGA is maxed out. 
The FPGA is also obsolete and eventually the board will need to be 
redesigned.  When this happens the code will need to be ported and some 
of the slow speed stuff might be better in a soft CPU.


> The Squeak virtual machine (both the original interpreter and the new
> Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
> foundation's efforts to make Scratch more usable. This means you can
> either run some software on the Pi with these VMs or on an FPGA board
> with my processor. That makes comparing the two options interesting,
> though an FPGA board costing around $100 might have less resources
> than a Pi board costing $5.

If I thought anyone was interested and could find a software guy to team 
up with, I would produce an FPGA board which connected to the fast 
interfaces on a CPU like the rPi or maybe a BeagleBone and use the 
resources on the processor board as a low cost I/O processor for the 
FPGA.  That reminds me of the array processor I used to work on that had 
a compute head on one board and the entire rest of the two rack cabinets 
(including two 68010 processors) were support to get data in and out of 
the compute head.

-- 

Rick C

Rick,

sorry that I am not addressing the rest of your post, but I think we
have both said all there is to be said about the subject and won't
reach an agreement.

> If I thought anyone was interested and could find a software guy to team 
> up with, I would produce an FPGA board which connected to the fast 
> interfaces on a CPU like the rPi or maybe a BeagleBone and use the 
> resources on the processor board as a low cost I/O processor for the 
> FPGA.  That reminds me of the array processor I used to work on that had 
> a compute head on one board and the entire rest of the two rack cabinets 
> (including two 68010 processors) were support to get data in and out of 
> the compute head.

While perhaps not using the fast interfaces, there are FPGA expansions
for the boards you mentioned:

http://www.bugblat.com/products/pif/

http://valentfx.com/logi-pi/

http://valentfx.com/logi-bone/

The way to have the fastest possible interface between the FPGA and
the processor is to use a chip like the Xilinx Zynq, which includes
two ARM cores. There are many variations of the Zed board with this
chip:

http://zedboard.org/

The one most like what you were describing is probably the Parallella
board, which is essentially a Zed board in a Raspberry Pi form factor
plus an Epiphany chip with 16 (or 64) floating pointer processors:

https://www.parallella.org/

-- Jecel

>> The J1 can't address much memory, so a native Forth is possible but would
>> be a tight fit.
> 
> I don't recall the limitation, but I would expect it to be on the order 
> of many KB.  Mecrisp is not so large and in fact, I'm pretty sure it has 
> been ported to the J1.  I seem to recall this was done using an open 
> source package (the only one I've ever heard of) that compiles to a bit 
> stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth 
> to this target making the entire effort open source.  I can't recall for 
> sure, but I'm pretty sure the hardware is also open source.

Exactly, Swapforth by James Bowman and my descendant Mecrisp-Ice with
optimisations run happily in HX1K FPGAs, Icestick and Nandland Go are supported.

If you wish to add more opcodes to the CPU or need gates for something else,
you should go for the HX8K breakout board instead.

Matthias

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 the ep8080, the ep16, and ep32 cores now working along with a 
resident version of eForth in each of those CPUs, the next CPU will be 
the J1 but first I will need to take a slight detour.

I will continue working on the ep32 core for a while as a learning 
vehicle to learn VHDL, so after some minor upgrades such as adding an 
additional address register, and additional instructions, when I feel 
comfortable with VHDL I will proceed to the J1 CPU.

The first step will be to create a J1 Meta-compiler so I can create a J1 
version of eForth that resides in the J1 CPU. If by then you do not have 
a resident Forth compiler you might be interested in the J1 native 
version of eForth. Once that is working with the existing J1 CPU Verilog 
code, I will proceed to create a version of the J1 in VHDL.

If you are interested let me know and I can do the above in a slightly 
different order, but no matter what I will need to learn VHDL first as 
the  J1 is written in Verilog for a different FPGA than the ones I have so.

Maybe all the above is not necessary as there is a native eForth 
implementation available that I just found. Along with it is code to 
implement a serial port so the J1 can talk to the outside world.

<  https://github.com/samawati/j1eforth  >

-- 
Cecil - k5nwa