I am sending the following sequence from Forth:

$9a emit 36 emit $80 emit

in a loop, and I am seeing:

0000000 c000 0000 0000 0000 00c0 0000 0000 c000
0000010 0000 0000 0000 00c0 0000 0000 c000 0000
0000020 0000 0000 00c0 0000 0000 c000 0000 0000
0000030 0000 00c0 0000 0000 c000 0000 0000 0000
0000040 00c0 0000 0000 c000 0000 0000 0000 00c0

directly out of port /dev/ttyUSB1, either by cat'ing to a file and dumping it, or some terminal program ..
However, sometimes it is ok ... and I get the right data.

Is there some problem with the timing at 460800 baud? It only seems a problem after sending an 8-bit value ..

I have been trying to use the mini-oof.fs module out of common. It doesn't want to work for the j1a processor ..

I have identified two problems with it, so far.

1. There is no "noop" baseword which makes "end-class" not compile.
   My base words are as follows .. no "noop" in sight ...

>words
 init .s tasksel quit evaluate refill accept char postpone literal ' abort chars char+ cells r@ r> >r depth io@ nip over drop dup swap u< < = invert or and xor - + 2/ 2* decimal unloop j i +loop loop ?do leave do recurse does> until again then begin if ahead ; exit :noname : [ ] immediate sliteral s, compile, c, , allot parse parse-name \ source 2! 2@ cmove> cmove fill >number sfind align um/mod m* * um* d2* d0= m+ s>d dabs dnegate d+ aligned /string here abs words forth tth >in state base type bounds count c! c@ max min 2over 2swap +! 2dup ?dup 2drop tuck -rot rot true false @ execute .x .x2 bl cr space emit key key? rshift lshift io! ! u> 0> 0< > 0<> <> cell+ 0= 1- negate 1+  ok

1. the word "var" doesn't seem to work, I try:

1 cells var test
10 test !
test @ .

and I get rubbish result, it can even lock up quit ... and have to CTRL-C to get prompt ..
I notice that a lot of files in "common" are used in the j2a processor examples, have they been tested for j1a?

Submitted via email by MK

\ A human friendly accept with UTF-8 support

\ Unicode-Characters encoded in UTF-8 have this format:
\ 11xx xxxx, 10xx xxxx, 10xx xxxx......

\ Adding an Unicode char simply can be done byte for byte.
\ Take care: For simplicity, this simple implementation may cut off a multibyte character in the middle
\ when the string is full. But as this defective character can be "backspaced", it should be ok.
\ If desired, length can be detected with number of leading 1's of the first byte.

\ Removing one character with support for Unicode in UTF-8 encoding needs special attention.
\ If the last character has 10... then we have to delete until we reach a character that has 11....

: delete-last-char-from-string ( string-addr length -- string-addr length* )
dup if 8 emit 32 emit 8 emit then \ If there is at least one character, emit Backspace-Space-Backspace sequence.

begin
dup 0= if exit then \ Any characters left ?
1- 2dup + c@ \ Fetch and remove last character
$C0 and $80 <> \ If this character has 10xx xxxx, then we need to remove another one.
until
;

: accept ( string-addr maxlength -- length )

r 0 ( string-addr 0 R: maxlength )

begin
key dup 9 = if drop 32 then \ Replace TAB with Space
dup 8 = over 127 = or if drop delete-last-char-from-string else \ Handle Backspace & DEL
dup 10 = over 13 = or if drop nip r> drop space exit else \ Handle CR & LF
dup 32 < if drop else \ Discard all other control characters
over r@ < if dup emit >r 2dup + r> swap c! 1+ else drop then \ Handle letters
then then then
again
;

\ Just to try
: sq ( -- ) cr dp @ dup 8 accept ." >" type ." <" cr ;

Not an issue as such, but due to the lack of a forum will post here.

I would like to run the clock much higher to see what the limit is to run swapforth at.
I tried to het a handle on this by implementing a bare minimal PWM verilog module and ramped up the PLL until the PWM stopped working.
This went ok till about 560Mhz, (2.2MHz PWM at 8 bits) which I thought was pretty awesome ..

As a 1st attempt with swapforth, I doubled the PLL to 96Mhz (7 as the .DIVF instead of 3) and in the uart.v module doubled the CLKFREQ constant to keep the baudrate at 460800 baud. However it does not work. I am not sure if the problem is the uart or just running that fast ... any idea's

There doesn't seem to be a way to save an image with #flash whilst a word is running.

Is there any mechanism by which a system image can be made that will be running a custom application word from startup, yet still be able to be connected to and stopped/restarted via shell.py for further work if necessary?

Without this, it's a bit difficult to deploy standalone, and to fix / debug after deployment.

But 38400 works ok. Any ideas what can cause this? Host: stock ubuntu 14.04.
// j1a on icestick

The sb_warmboot hardware component would let the core do a full reboot, and possibly select another image to boot the FPGA from.

MK writes:

throw without having catch is quite useless, and throw is not required by ANS core http://lars.nocrew.org/dpans/dpans6.htm - you only have one type of error, the "not found" error. I would remove throw completely, simply print a question mark on not found and quit. More convenient: Print the word which is not recognized and a question mark.

To reproduce, run see ms.

Output with minicom.py is:

see ms 
12C0 8000       $0000 
12C2 4460       recurse
12C4 6127       alu: 0127 
12C6 9762       $1762 
12C8 8000       $0000 
12CA 4460       recurse
12CC 6127       alu: 0127 
12CE 6B1D       alu: 0B1D 
12D0 449C       ������
12D2 2966       Z 12CC 
12D4 4403       `��>@��<@���a�k�k
12D6 6B1D       alu: 0B1D 
12D8 449C       ������
12DA 2962       Z 12C4 
12DC 4403       `��>@��<@���a�k�k
12DE 608C       alu: 008C  ok
  ok

Hi Guys,

Not to create any offence. But is this project actively worked on? I see no push's for 5 months, and no current issues worked on.

I am happy to help out, at least with finding bugs .
I hope this project is not dead, as I think it has a lot of promise.

Currently I am using it in my "Electronic Drum Brain" project, where the main requirements are writing Verilog peripherals and interfacing them to SwapForth side. (A proper IO address decoder here would be useful). The Forth code will tie it all together and send Midi commands to the host PC which has a drum synthesiser ... eventually I would like to do away with the PC completely, and send the drum sample sounds directly to a DAC ....

: hangs 0 0 ?do 0 +loop ;

hangs swapforth, but not gforth.

I tried running "make bootstrap" for j1a .. but it fails ..

make bootstrap
make -C verilator
make[1]: Entering directory '/home/bmentink/Builds/SwapForth/swapforth/j1a/verilator'
Makefile:33: warning: overriding recipe for target '../build/nuc.hex'
Makefile:12: warning: ignoring old recipe for target '../build/nuc.hex'
verilator -Wall --cc -DVERILATOR=1 j1a.v ../verilog/*.v --top-module j1a --exe sim_main.cpp
make -C obj_dir CXXFLAGS="-fPIC" OPT_FAST="-O2" -f Vj1a.mk Vj1a
make[2]: Entering directory '/home/bmentink/Builds/SwapForth/swapforth/j1a/verilator/obj_dir'
g++ -fPIC -I.  -MMD -I/usr/share/verilator/include -I/usr/share/verilator/include/vltstd -DVL_PRINTF=printf -DVM_TRACE=0 -DVM_COVERAGE=0 -Wno-char-subscripts -Wno-parentheses-equality -Wno-sign-compare -Wno-uninitialized -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable      -O2 -c -o sim_main.o ../sim_main.cpp
../sim_main.cpp: In function ‘int main(int, char**)’:
../sim_main.cpp:23:12: error: ‘class Vj1a’ has no member named ‘v__DOT__ram_prog’; did you mean ‘j1a__DOT__ram_prog’?
       top->v__DOT__ram_prog[i] = v;
            ^~~~~~~~~~~~~~~~
At global scope:
cc1plus: warning: unrecognized command line option ‘-Wno-parentheses-equality’
make[2]: *** [Vj1a.mk:65: sim_main.o] Error 1
make[2]: Leaving directory '/home/bmentink/Builds/SwapForth/swapforth/j1a/verilator/obj_dir'
make[1]: *** [Makefile:9: obj_dir/Vj1a] Error 2
make[1]: Leaving directory '/home/bmentink/Builds/SwapForth/swapforth/j1a/verilator'
make: *** [Makefile:8: bootstrap] Error 2

Looks like ram is still 8K, I believe the ICE40HX8k fpga has 32K?

Just as a heads up, using the very latest versions of icetools, arachne-pnr, and yosys, the process fails with:

yosys  -q -p "synth_ice40 -top top -blif j1a.blif" j1a.v uart.v ../verilog/j1.v ../verilog/stack2.v
Warning: Wire top._uart0._rx.hh has an unprocessed 'init' attribute.
arachne-pnr -p j1a.pcf j1a.blif -r -o j1a.txt
seed: 2531206741
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif j1a.blif...
prune...
read_pcf j1a.pcf...
instantiate_io...
pack...

After packing:
IOs          40 / 96
GBs          0 / 8
  GB_IOs     0 / 8
LCs          1309 / 1280
  DFF        711
  CARRY      73
  CARRY, DFF 8
  DFF PASS   103
  CARRY PASS 15
BRAMs        16 / 16
WARMBOOTs    1 / 1
PLLs         1 / 1

place_constraints...
promote_globals...
  promoted _bn00.RCLK, 751 / 786
  promoted _j1.rstack.move, 305 / 305
  promoted _j1.dstack.move, 259 / 259
  promoted $abc$9478$n767, 36 / 36
  promoted unlocked, 17 / 17
  promoted _j1.rstack.delta[1], 304 / 304
  promoted _j1.dstack.delta[1], 260 / 260
  promoted $abc$9478$n2252, 16 / 16
  promoted 8 nets
    3 sr/we
    4 cen/wclke
    1 clk
  8 globals
    3 sr/we
    4 cen/wclke
    1 clk
realize_constants...
  realized 1
place...
fatal error: failed to place: placed 1121 LCs of 1310 / 1280
Makefile:7: recipe for target 'j1a.bin' failed

MK writes:

serialize allows for a quick dump, but it is useless for a human being reading the output. I would suggest that you replace it permanently by the human friendly dump and change the Python shell to parse its output instead. That will be a slower, but binary image generation is not the main application of the Icestick :-)

Any chance of support for this board? Development is usually by attachment to a RPi, then SSH into it from your PC. Would it be possible to have a virtual console to interact with Forth this way?
Programming sram/flash should work out-of-the-box.

(The connection between the two is SPI through a Linux kernel driver, but not sure if both ways is implemented ..)

Deleted

Hi James, I've been studying and successfully building the x64 version on OSX, but then realised that the code contains a few AVX instruction not supported on slightly older machines (e.g. my 2010 MBP i7 lacks AVX). Are these really needed or could they be conditionally be rewritten using only SSE2/3/4? I'll do some digging what these instruction exactly achieve and might create a PR (if I'm successful), but any guidance would be appreciated. Thanks!

First thank you for this Python emulator. A great way for a Python developer to learn about the J1 CPU.

So I fired it up.
python3 nuc.py nuc.py:765: DeprecationWarning: tostring() is deprecated. Use tobytes() instead. self.SFIND() nuc.py:463: DeprecationWarning: tostring() is deprecated. Use tobytes() instead. self.defining = self.pops().upper() nuc.py:716: DeprecationWarning: tostring() is deprecated. Use tobytes() instead. was = self.pops() nuc.py:522: DeprecationWarning: tostring() is deprecated. Use tobytes() instead. self.SFIND() nuc.py:449: DeprecationWarning: tostring() is deprecated. Use tobytes() instead. c() Loaded 306 words +

All that looks quite easy to fix. Then I played around with it some. And after a while I made a mistake. Let me reproduce it here.
With an empty stack, I asked it to print the top of stack.

+.
Of course that did not work. The error message is below.
Basically the emulator hangs. I do not yet have enough understanding of this cpu to figure out the appropriate fix to the emulator. Does the actual CPU recover from errors? It is easy for me to fix the Python. What is hard is to know what the CPU would do. Should I check for bounds somewhere? Should I put a try except in the dup method. Should I put it in the input method? I guess I am more interested in an accurate emulator than in a easy-to-use Forth. Maybe I am most interested in an accurate emulator of an easy-to-use Forth CPU.

Anyhow thank you for an interesting, rich and diverse project. I also took a look at the H2 cpu. It is writen in VHDL and supports interrupts. That project has a C language Emulator. A Python emulator is easier to work with.

Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner self.run() File "/usr/lib/python3.7/threading.py", line 865, in run self._target(*self._args, **self._kwargs) File "nuc.py", line 819, in __init__ self.CATCH() File "nuc.py", line 147, in CATCH self.EXECUTE() File "nuc.py", line 428, in EXECUTE self.xts[x - 1000]() File "nuc.py", line 774, in interpret ][i]() File "nuc.py", line 428, in EXECUTE self.xts[x - 1000]() File "nuc.py", line 449, in inner c() File "nuc.py", line 449, in inner c() File "nuc.py", line 250, in DUP self.d.append(self.d[-1]) IndexError: list index out of range

Hi Guys,
I have just purchased a PapilioDuo board and have managed to upload the .bit file, however it does not show up a /dev/ttyUSB device, any suggestions?

I must have the FTDI-2232 drivers on my system as the Lattice boards which seemingly have the same chip and work fine.

EDIT: The lattice board USB ID is 0403:6010 and the PaplioDuo 0403:7bc0
I have the latest kernel from Archlinux so don't know why it is not showing up a port ..

EDIT2: Doing a modinfo on ftdi_sio shows the 6010 device but not the 7bc0 one, so maybe my driver does not have support for this?

Hi
if j1a.bin is loaded to board compatible to icestick, should something come out of the serial port?

https://hackaday.io/project/6636-iced-an-arduino-style-board-with-ice-fpga

with j1a.bin loaded the LEDS are on, but I see nothing on uart, is that normal?

I cloned swapforth and have been looking at j1a. There is a subdirectory
called nandland-go which has a bin file that I loaded into the go board.
The 7seg displays show 88. I tried using python3 shell.py -h /dev/ttyUSB1
but the command always hangs output similar to previous reports.

I am able to connect to the go board with gtkterm at baud 115200
0 leds turns off the 7 seg displays and words gives a list

I ran the Makefile and compared its output with the supplied j1a.bin

the results are different as my file is smaller and after connecting with
gtkterm I see that words is much smaller maybe 145 instead of
around 200.

My system is fedora 27
yosys -V
Yosys 0.7 (git sha1 UNKNOWN, gcc 7.1.1 -fPIC -Os)

I presume I am missing something in my setup for yosys
as I am new owner of the go board and have been able to
get some small programs running.

1st issue: I had to comment out the following section in shell.py to even get it running:

def reset(self, fullreset = True):
........

    #waitcr()
    #ser.write(b'\r')
    #waitcr()

2nd issue: bye does not exit shell, doesn't exist ... just get:

bye
?+

3rd issue: #flash command does not work:

flash build/nuc.hex

please wait...
Traceback (most recent call last):
File "./shell.py", line 72, in
swapforth.main(TetheredJ1a)
File "../shell/swapforth.py", line 385, in main
r.shell()
File "../shell/swapforth.py", line 339, in shell
self.shellcmd(cmd)
File "../shell/swapforth.py", line 197, in shellcmd
d = self.serialize()
File "./shell.py", line 68, in serialize
s = array.array('B', s).tostring().ljust(8192, chr(0xff))
TypeError: ljust() argument 2 must be a byte string of length 1, not str

Seems shell.py is a bit broken
.. also the documentation says to connect on /dev/ttyUSB0, but on my system it is /dev/ttyUSB1, USB0 is the programmer SPI interface ..
"make connect" does the right thing ..

EDIT:
2. My bad .. needs '#bye', not 'bye'
3. Seems shell.py only works with python2, maybe that should be documented .. ;)
4. Documentation again ... in the "Building from scratch" section it is stated:

Now run make j1a again - this compiles an FPGA image with the complete code base built-in.

This does not work, as you have to run "make -C icestorm" again before "make j1a" to pick up the added words, otherwise you just get the minimum. I guess ram.v is not updated.

I'm learning to program for FPGA's, and read through the source of the j1 to learn. I wonder what EASE_IO_TIMING is for here. What function does it have/what problem does it solve?

Support the PLL; run faster than 12MHz

This uart.v fix works better here under mecrisp-ice, it allows to RX at 36MHz//115k (PLL based), UP5k.
As I've explained in my comment ("serial data corruption at 460800 ") I've changed the baudrate counters such they compare around 0, not at the limit. That could be faster than (coutner == limit).
I've added a 2FF synchronizer at uart_rx input (3FF could be even better).

uart_IM.txt

When I try to run the j1b emulated with Verilator in the j1b/verilator directory, I get the following error:

verilator --l2-name v -Wall -I../verilog/ --cc j1b.v ../verilog/j1.v ../verilog/stack.v --top-module j1b --exe sim_main.cpp
%Error-PROCASSWIRE: j1b.v:28: Procedural assignment to wire, perhaps intended var (IEEE 2017 6.5): insn
%Error: Exiting due to 1 error(s)
%Error: See the manual and http://www.veripool.org/verilator for more assistance.
%Error: Command Failed /usr/bin/verilator_bin --l2-name v -Wall -I../verilog/ --cc j1b.v  ../verilog/j1.v ../verilog/stack.v --top-module j1b --exe sim_main.cpp
make: *** [Makefile:8: obj_dir/Vj1b] Error 10

To cure it, I have to change the 21st line in j1b from:

  wire [15:0] insn;

to

  reg [15:0] insn;

After that change the simulation and compilation goes fine.

Hi,
I am using j1b on the Papilio Duo, but I cannot get my toplevel Forth word to execute on boot as there is no "init" vector word as there was for the j1a ..

There is nothing in the j1b documentation to show me how to do this ..

I see in j1a.v that the pin headers on the board are defined... with addresses defined under "IO PORTS" but I can't seem to set them:

255 $0020 io!
ok
$0020 io@ .
255 ok
255 $0010 io!
ok
$0010 io@ .
27 ok

...am I missing something?

There's a bug in the j4a reset mechanism which sees slots reset randomly when data is written to $4000 io!.

Ok, this is one's on me...

I get odd behaviour if another thread (say, $100 io! ) is running a DO ... LOOP and I run another bit of code, also with a do loop...

(this requires a ice40-HX8K Breakout Board be plugged in)

cd j1a
make j4a connect
make -C icestorm j4a
make[1]: Entering directory `/opt/swapforth/j1a/icestorm'
sudo iceprog j4a.bin
init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x12 0x42 0x18 0x11 0x00 0x88 0x00 0x44 0x03 0x11 0x11 0xA1 0x14
file size: 135356
erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
erase 64kB sector at 0x020000..
programming..
reading..
VERIFY OK
cdone: high
Bye.
make[1]: Leaving directory `/opt/swapforth/j1a/icestorm'
sudo python shell.py -h /dev/ttyUSB1 -p ../common/
Contacting... established
Loaded 207 words 
>:noname 1000 ms ; $100 io!
>: test 5 0 do i . loop ;
>test
 0 1 2 3 4    ok
>test
 0 5982 5983 5984 5985    ok
>test
0 1 2 998 5985    ok

It doesn't always do it - maybe 5% of the time or so - I exaggerated it a bit above.

I think this means the timing for the stack2pipe4 module isn't quite right... strange thing is, the system seems otherwise quite stable in actual applications.

I'll have a go at getting the verilator interactive build of the j4a going, and see if it does it too. (in which case it's just a logic bug.)

Otherwise this might be some form of odd timing or interference issue with the icestorm tools. Perhaps there are some constraints about routing nearby signals which might interfere under certain conditions we don't know about yet? I hope not... But, if so, then it might perhaps share a root cause with #25 .

I have confirmed the above behaviour on both of the boards I have.

Just noticed this now. This is critical (it blocks making application images) but there is a work around to get a compiled, bootstrapped image.

With swapforth@efb3813 , YosysHQ/icestorm@f2b2549 , YosysHQ/arachne-pnr@1a4fdf9 and YosysHQ/yosys@22c549a

~/build/swapforth/j1a$ make j1a
make -C icestorm j1a
make[1]: Entering directory `/home/likewise-open/NEXUS/dye025/build/swapforth/j1a/icestorm'
yosys  -q -p "synth_ice40 -top top -abc2 -blif j1a.blif" j1a.v uart.v ../verilog/j1.v ../verilog/stack2.v
Warning: Wire top._uart0._rx.hh has an unprocessed 'init' attribute.
arachne-pnr -p j1a.pcf j1a.blif -o j1a.txt
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif j1a.blif...
prune...
read_pcf j1a.pcf...
instantiate_io...
pack...

After packing:
IOs          40 / 96
GBs          0 / 8
  GB_IOs     0 / 8
LCs          1219 / 1280
  DFF        711
  CARRY      73
  CARRY, DFF 8
  DFF PASS   103
  CARRY PASS 15
BRAMs        16 / 16
WARMBOOTs    1 / 1
PLLs         1 / 1

place_constraints...
promote_globals...
  promoted _bn00.RCLK, 751 / 786
  promoted _j1.rstack.move, 305 / 305
  promoted _j1.dstack.move, 259 / 259
  promoted $abc$10779$n1230, 36 / 36
  promoted unlocked, 17 / 17
  promoted _j1.rstack.delta[1], 304 / 304
  promoted _j1.dstack.delta[1], 260 / 260
  promoted $abc$10779$n1158, 16 / 16
  promoted 8 nets
    3 sr/we
    4 cen/wclke
    1 clk
  8 globals
    3 sr/we
    4 cen/wclke
    1 clk
realize_constants...
  realized 1
place...
fatal error: failed to place: placed 1121 LCs of 1220 / 1280
make[1]: *** [j1a.bin] Error 1
make[1]: Leaving directory `/home/likewise-open/NEXUS/dye025/build/swapforth/j1a/icestorm'
make: *** [j1a] Error 2

The work around is to run make -C swapforth/j1a bootstrap first, after which make -C swapforth/j1a j1a works, but since this make a 'fresh bootstrapped ' 207-word swapforth nuc.hex, there isn't any way to use #flash build/nuc.hex to make an application image, since the same failure-to-place occurs there too.

:(

I get the following error running make -C icestorm as of Aug 29th
fatal error: failed to place: placed 1125 LCs of 1294 / 1280

I'm not sure if this is an Icestorm issue or a swap forth issue
full output below
make[1]: `build/ram.v' is up to date.
yosys -q -p "synth_ice40 -top top -blif j1a.blif" j1a.v uart.v ../verilog/j1.v ../verilog/stack2.v
Warning: Wire top._j1.reboot has an unprocessed 'init' attribute.
Warning: Wire top._uart0._rx.hh has an unprocessed 'init' attribute.
Warning: Wire top.unlocked has an unprocessed 'init' attribute.
arachne-pnr -p j1a.pcf j1a.blif -o j1a.txt
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
supported packages: tq144
read_blif j1a.blif...
prune...
read_pcf j1a.pcf...
instantiate_io...
pack...

After packing:
IOs 24 / 96
LCs 1293 / 1280
DFF 730
CARRY 103
CARRY, DFF 32
DFF PASS 97
CARRY PASS 15
BRAMs 16 / 16
WARMBOOTs 0 / 1
GBs 0 / 8

promote_globals...
promoted clk$2, 794 / 794
promoted _j1.rstack.move, 305 / 305
promoted _j1.dstack.move, 259 / 259
promoted $techmap$techmap9280$auto$simplemap.cc:449:simplemap_adff$793.$logic_not$/usr/local/bin/../share/yosys/ice40/cells_map.v:12$9274_Y, 36 / 36
promoted unlocked, 17 / 17
promoted _j1.rstack.delta[1], 304 / 304
promoted _j1.dstack.delta[1], 260 / 260
promoted $techmap_j1.dstack.$procmux$209_CMP, 16 / 16
promoted 8 nets
3 sr/we
4 cen/wclke
1 clk
8 globals
3 sr/we
4 cen/wclke
1 clk
realize_constants...
realized 1
place...
fatal error: failed to place: placed 1125 LCs of 1294 / 1280

Hi,

I execute the following commands:

papilio-prog -v -f xilinx/j1-papilioduo.bit
python shell.py -h /dev/ttyUSB0

That works, but ...

I thought the 1st command would store the *.bit file to the SPI Flash, but when I power-cycle the board, and shell in again, nothing ... I have to re-program, then shell in again, before I am back in the Forth.

Any idea's: What am I missing?

Also is there any guide to downloading/installing the xilinx tools? I have no idea which package to install ...

I have written a PWM module that I would like to add to the build, but having trouble interfacing to it when adding to the top level.

I have added the following to the "top" module:

// ########### PWM ###############################################

  wire pwm_wr = io_wr_ & io_addr_[8];

  // Instantiate PWM module 
  pwm #(.CTR_LEN(8)) pwm_1 (
    .rst(1'b1),
    .clk(clk),
    .wr(pwm_wr),
    .compare(8'd80),
    //.compare(dout_[7:0]), this doesn't route
    .pwm(PWM)
  );

I am trying to write to the "compare" input from Forth. The line ".compare(8'd80)" works fine, but
when I replace it with the commented line, it synthesises fine, but won't route ..
I am using the uart module as an example ... what have I done wrong?
... or have I just run out of room on the FPGA ... (on the 1k device)

EDIT: Seems it was a space issue, routed fine on the 8k device. Looks like I have to buy new hardware ;)

Hi there,

I've tried building from scratch as per the reference document here: https://github.com/jamesbowman/swapforth/raw/master/j1a/doc/j1a-reference.pdf

The Verilog seems to build and program OK, but when trying to connect using the python terminal I get nothing.

Note that using the j1a.bin as build in the repo works fine and gives me the correct response of:
Contacting... established
Loaded 208 words

I've tried checking out the last build that changed the j1a.bin file and building from scratch there, but it failed as well.

Colour me confused, any tips?

https://github.com/jamesbowman/swapforth/blob/master/j1b/cross.fs#L22

Should read 131072, not 31072, I believe.

Hey, first time using any sort of Forth so this might be a stupid question. I arrived here by trying to control the LEDs on my new ICE40 dev kit with the least effort possible. I managed to do that. Thanks so much for paving the way!

I am a bit stuck now though as I haven't been able to figure out how to program in the multi-line words mentioned in the reference manual and your video, I tried Shift-Enter an Alt-Enter and Ctrl-V and ; but none of those seem to work.

Forth allows certain base-setting prefixes in literals:
e.g.,:

• & – decimal
• # – decimal
• % – binary
• $ – hexadecimal

unfortunately, it seems that in swapforth the error in parsing of the literal after the prefix leaves the base modified according to the prefix. Below is an example of session demonstrating the issue:

>decimal
  ok
>%101 .
 5  ok
>$32 .
 50  ok
>%fggdg
 error: F3 +
  ok
>$32 .
 110010  ok
>

In gforth, an attempt to parse the incorrect literal doesn't lead to changed base:

Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
decimal  ok
%101 . 5  ok
$2 . 2  ok
$32 . 50  ok
%fggdg 
:5: Undefined word
>>>%fggdg<<<
Backtrace:
$7F0C14C6EA68 throw 
$7F0C14C84DB0 no.extensions 
$7F0C14C6ED28 interpreter-notfound1 
$32 . 50  ok

Similar problem in swapforth occurs also for other base-setting prefixes. Below is an example of unintended switching to hex mode due to entering the incorrect literal with "$" prefix:

>decimal
  ok
>$fgdds
 error: F3 +
  ok
>$32 .
 32  ok
>#51
  ok
>.
 33  ok

with Swapforth@9d45735 built on Ubuntu 14.04.3 LTS, with: YosysHQ/yosys@5e1dc78 and YosysHQ/arachne-pnr@eb7876b ,

make -C j1a clean
make -C j1a/icestorm

Results in a fatal error to place, apparently because 1297 of 1280 LCs are packed.

I think this an upstream issue with a recent change to yosys, but it's still our issue if we can no longer fit swapforth on a 1k :(

Verilator stops with an error about not finding Python.h

Is there a good place in the readme to mention that swapforth on Ubuntu needs python-dev, gforth and verilator installed in addition to the list of packages given at http://www.clifford.at/icestorm/ ?

I just hit this one whilst setting up a clean (actually a livebooted) Ubuntu 15.10 system. (It also needed "universe" and "multiverse" software sources enabled in "Software & Updates" to get Clifford's list to install).

Perhaps we need an INSTALL.md to hold this sort of system-dependant setup info

Hi James,

I don't know if you are still contactable or if this project is still active, but I have posted this just in case are still interested.

I have j1b running at 80Mhz on both Spartan-6 and Artix-7 boards - it will run at 100Mhz (just) on the Artix-7, but borderline as there is timing issues on the ram dstack .... Is there a way to improve this?

Also for your interest, I have implemented a number of Floating point hardware modules in verilog and interfaced them to Forth (F+,F-,F*,F/ and F-inverse-sqrt) They all happen in less than 3 clock cycles.

On Artix-7 Forth + FP takes up 3500 LUT's .......

Suggestion from mk:

Perhaps you could wire in the whole memory on the instruction bus,
and let the processor trigger the   $2000 + execute sequence internally
instead of the "classic" memory fetch ? This way data fetches would be
a cycle slower, but all memory could be used both for instructions and
data. As there is still quite a lot of data-only-memory left, it could
allow for larger projects.

Thinking about how this would work...

• remove the '@' instruction completely, replace it with the current 'code@' word. This would actually be the same speed (2 cycles)
• remove CP, replace it with DP throughout
• dictionary header no longer needs an xt pointer

There is another nice advantage of this scheme. Currently fetching a variable (e.g. "X @") assembles to a 3-instruction sequence. But in this scheme X can be fetched in one instruction:

CALL $2000+X

Hi Guys,

I am trying to interface a fifo, the instantiation is this:

fifo ff( .clk(clk), .rst(~reset), .buf_in(buf_in), .buf_out(buf_out), 
         .wr_en(wr_en), .rd_en(rd_en), .buf_empty(buf_empty), 
         .buf_full(buf_full), .fifo_counter(fifo_counter) );

I am trying to load buf_in on the Verilog side, and unload buf_out on the Forth side.

On the Verilog side at the top level I am doing:

always @(posedge clk) begin
    wr_en <= 1'b0;
    if (!buf_full & drum_output[1]) begin
      buf_in <= drum_output[1];
      wr_en <= 1'b1;
    end
  end

And to read the fifo on the Forth side added:

wire rd_en = io_rd_ & io_addr_[9];

and

assign io_din =
    """""""
    (io_addr_[ 9] ? {buf_out}                                      : 16'd0) |
   """""
    (io_addr_[12] ? {8'd0, uart0_data}                                  : 16'd0) |
    (io_addr_[13] ? {11'd0, random, 1'b0, PIOS_01, uart0_valid, !uart0_busy} : 16'd0);

So that fifo can be read on address $200, but I get no output on the Forth side, any clues?

Hello,

the last 4th led can not be turned on, neither by "-1 leds" nor by "$10 $0004 io!". Tried with latest master code. Works with the checked-in icestorm/j1a.bin, but not with the new freshly compiled one.

It starts working after reverting c2211de commit:
git show c2211def2ce50576e8df73edb6bdcc21e75e2009 | patch -p1 -R

Best regards
Kei

This is on swapforth@9157271 , YosysHQ/arachne-pnr@52e69ed , and YosysHQ/yosys@7a33b98

Symptoms: LED's on iceStick (and possibly other IO ports) don't set/clear properly.

Steps to reproduce (with iceStick plugged in):

cd swapforth/j1a
make clean
make 
sudo make bootstrap 
sudo make j1a connect
-1 leds

After this, one led is not lit, but -1 -1 leds drop will set all, likewise -1 0 leds drop will leave that one led on.

The affected .bin, .blif and .txt are here:
broken_j1a.zip

Hi James,

Just letting you know I have an initial port of j1b to the ESP5 fpga. I intend to target the tinyFPGA-EX board once it get's released ..

I have used the opensource Yosys/nextpnr/trellis workflow ..

Initial timing suggests the j1b should run at 70Mhz and use ~6000 LUT's
I will update once I have hardware ..

Hi, I've got an ice40UP5k board and want to try with J1a(b).
Is there any chance to get available a ready made "ram.v" with the basic words set?
My current understanding is the ram.v is the same source for all 1k/4k/8k/UP5k chips.
My intention is to get it working with IceCube2 under Win.
Thanks

I've also been meaning to think up a better organisation for where the j4a can live... maybe as a never-merged-to-master sub-branch so it can benefit from being in the same tree as the j1a, rather than being side-by-side as it is.

The reason being, as it is, when changes happen to j1.v, they currently need to be manually propagated into j4.v and so on (which happened with the subtractor recently added, and is kinda made worse by having separate tops for the different build targets), and the idea is to remain at least swapforth-level code compatibility with the j1a.

(Excepting in the io address space... but that's also a common issue for ports to different boards )

Since the idea is to 'stay attached' to the j1a's code base, so as to allow upgrade/downgrade paths, it might not be too bad to just keep the j4a as an unmerged git branch of the j1a.

Or, just keep it in my github fork - but I am loathe to unintentionally end up as a non-compatible fork, when I don't want nor need to do so.

Hmm.

After some thought, I realised this might also be a good way to handle the other j1 variants and hardware platforms too - just have a separate branch for each variant, and sub-branches for each build target (with possibly sub-sub-branch for each different physical board.)

That way it should be much easier to keep the variants from drifting apart, and the whole codebase will be much clearer as well (fewer subdirectories) and it establishes the code-of-conduct for introducing dependant variants like the j4a. ( I'm already thinking about doing a 24 bit datapath version of the j4a, with 1M addresses via 2 or 3 external SRAM's - expanding the PC to 20 bits, so it sits between a 16 bit and 32 bit j1 architecture - more space, but still no DRAM with it's cycle stealing refresh shenanigans. it would be a sub-sub-variant, so it stays in synch with the j4a. Call it the j4a24 perhaps.)

It could also be used to attach and share application swapforth code as well, which would be ideal, and also allow git to be exploited to handle sharing/merging/etc between derived-app codebases too.

So anyway, what are people's thoughts Re this keeping-unmerged-branches idea?