Introduction

[PythonLinks]

First thank you for creating this repository.

I plan on using this to generate many core Forth processors.
You can read more about my plans here.
https://forth.pythonlinks.info

Probably initially as an audio synthesizer. There are a bunch of us interested in audio synthesis on the pico-ice discord server.

You may have seen my SVFIG talk on "A review of Forth Soft Core Processors"

https://www.youtube.com/watch?v=qgmrZoJyHUw

More recently I did the same talk at the Stockholm FPGA conference. Here are the updated slides.
https://pythonlinks.info/presentations/StockholmConference.pdf

It turns out that the Mecrisp Forth interpreter is 200 times smaller than the Python interpreter. Wow.

I recently bought the Pico-Ice and the Upduino FPGA boards. I released an echo server for the Pico-Ice.
https://forth.pythonlinks.info/pico-ice-echo-server

Then I got Mecrisp Forth running on the Pico-Ice. But it took up
way too many resources.
ICESTORM_LC: 2604/ 5280 49%

Hard to buld a many core, when half the luts are already used.

But there is a more important reason to switch to this software stack. If you look at the Mecrisp source code, it support some 12 boards, and 28 different options in the verilog files. Really hard to mange that complexity in pure Verilog. Much better to do it in a high level language.

I took a look at MyHDL, did not like it. They generate the code, but throw out hierarchy information at simulation time, making debugging harder. Amaranth did not resonate with me either. I took one look at SpinalHDL, and everything looks very reasonable, even fantastic. I can refer to something in another branch of the hierarchy without having to manage wires up and down the stack. Awesome.

Not only I think so. The VexRiscV which won the first prize at the RISC-V Summit softCore contest, was also written in SpinalHDL

https://tomverbeure.github.io/rtl/2018/12/06/The-VexRiscV-CPU-A-New-Way-To-Design.html

Also I think it is much better to start with a tiny core, and only add in the stuff that I need.

As for issues, I wish that there were a newer release of this software, and I wish that more Electrical Engineers were aware of the advantages of high level languages, and were using this software, instead of sticking to Verilog and VHDL. Oh well.

Wish me luck.

[PythonLinks]

The code is beautifully commented. Really quite fantastic. I am new to Scala and SpinalHDL, so every line is cryptic, but almost every line has an English comment. Thank you so much. I have no idea if the code itself is good or not, but at first impression it looks fantastic, and even if there are problems, with all those comments, I should be able to figure it out.

It looks like you even have single stepping for debugging! WOW. Mecrisp does not have that I think!

And it has way more stuff here than just the raw J1. If you look in
J1Sc/src/main/scala
You will also find these very useful files.

GPIO.scala
J1Decoder.scala
LEDArray.scala
InterruptCtrl.scala
PWM.scala
J1Jtag.scala
SSD.scala
J1Bus.scala
J1JtagData.scala
SingleStepUnit.scala
J1BusSlaveFactory.scala
J1Nexys4X.scala
Timer.scala
Plus a few other files that I cannot figure out what they do from the name.

You have about as many options as the Mecrisp CPU, maybe more because each file probably supports more options.

Of course like Mecrisp, it is a bit hard to figure out the directory structure. Some docs would be useful. What do those other files do. Maybe they are commented internally, but an external list of file descriptions would be useful.

But at the high level your instructions for starting it up are also fantastic. So I should be able to figure it all out.

Thank you so much.

I am also mindful of how there are so many Verilog versions of the J1, and how almost no one is using this beautiful code. Maybe most people do not understand the power of abstraction. Indeed the necessity of abstraction.

When I first realized I had to learn both Scala and SpinalHDL, I thought of just starting simple with the original J1 Verilog code. But if I want to do multiple cores, then I will have wires running from these cores to those cores, and to do that all by passing stuff up to the top node and back down, would be a nightmare in complexity.

With your J1Sc it and SpinalHDL it should both be easy to do and more importantly easy to modify.

I see that your address is at a University. I wonder if there is a thesis documenting this code. Maybe it exists in German.

I am only sorry that you like everyone else has moved onto RISC-V.

[SteffenReith]

Dear PythonLinks,

thank you for your kind words and remarks about the code and the comments (personally I call this style "prosa programming")! J1Sc is an ongoing project (have a look at the devel-branch) to learn the features of SpinalHDL and
to serve as a starting point and non-trivial example for a Spinal-beginner. Moreover, it should serve as an example of the power of abstraction, which would help (my opinion) to improve hardware-design dramatically.

I plan to develop a mechanism to automatically include the IO modules in the address space. So you write a list of objects, the modules are automatically mapped into the address space and the necessary FORTH code is automatically generated. Only I have to find time for it.

Wonderful would be a port of Mecrisp FORTH. Unfortunately, I am not a FORTH expert. J1Sc was basically built around SwapForth and is completely compatible with the original J1 (only the stacks are deeper) except for a fix of an instruction (which has no effect on SwapForth, as this instruction is not used).

There were attempts of an application of J1Sc in a manycore-architecture following the ideas of old transputer architectures, but this was not pursued.

Yes, I work at a university and you could call J1Sc a university project. The better description is "project to distract you from administrative tasks that drive you crazy". In that sense, J1Sc is just a SpinalHDL learning project, with the ulterior motive of being able to use it to do exciting things in the field of senors and ASIC development.

[PythonLinks]

Great to hear from you. Also great to see that the develop branch is only 8 months old. Very encouraging. I was worried.

If you are interested in J1Sc, let me know if I can / should help.

What m-atthias at Mecrisp, did was answer a few questions the few times I got lost.
That was enormously helpful. He is also hugely interested in the many core stuff.

It is great to know that this is j1 compatible. That is where I want to start.

The default Mecrisp is too big. Here are some relevant numbers.

On the Ice40 boards, the J1 is reportedly 1162 luts. The default for the Mecrisp is 2604 Luts as built by me. So Mecrisp is too big. And I want to have at least 4 cores on my low-end board. I only get 5280 luts on the $28 ico-ice board.

More importantly Mecrisp is targeting looking like a microcontroler. Initially I just want to do audio I/O using I2S. Maybe even ditch the blinkys and have audio feedback. So most of the hardware that Mecrisp adds is not that interesting to me, but your single stepping looks most irresistible. Release one gateware with fewer cores, but debugging options.

So I worry that your cpu is also too large. How do I switch off all of your optional stuff?

Wonderful would be a port of Mecrisp FORTH.

The Mecrisp Forth has many words to support the Mecrisp hardware.
First off I think that all of the Mecrisp verilog should be ported over to J1Sc/SpinalHDL. The current code base is reaching complexity limits. And then one needs to split Mecrisp Forth into groups, with optional includes, so one can only load the needed parts. Do you have any specific words you wish to add from their vocabularies?

I am also not (yet) a Forth developer, but I am about to become one. My strategy will be like the Core-1, just synthesize the outer interpreter and let people load whichever code they want. I want people installing the gateware, not building it.

As for the transputer, that is exactly the direction I am heading. CSP Cooperating Sequential Processes is such a powerful concept, used by GoLang, and Python's Gevent. Of course the transputer had fixed links, we can do application specific connections. A music synthesizer has cores connected differently than a hearing aid. Do you have a URL for that J1Sc Transputer project? I wonder why it was dropped?

And yes, I am delighted to find others who understand the need for abstraction in hardware design.

[PythonLinks]

I love this source code. You have long variable names, clearly understandable. Sure electronics engineers have to minimize the circuits, but why do they minimize the letters in variable names? And the prose comments are off the charts fantastic. I can read it like prose.

Clearly you are a software developer, but you are also one of those rare breeds who are both a software developer and an electonics engineer.