The vision of this group is to create a Forth based AI Computer where you can communicate with the system using an English conversational approach. We will add many high level Words for string manipulation, arrays, and other structures as we develop this computer. We will extend Forth to include AI words too. All of this will be built into FPGAs which are really parallel computers written in Behavioral System Verilog (the Assembler).
I think the world really needs a Forth processor written in System Verilog. I believe the J1 is done in Verilog, the EP32/24/16 are in VHDL, and the MicroCore is in VHDL 83. System Verilog is probably the most productive language, so you are on the right side of history. And even if System Verilog does have some inefficiency, one can always drop down to Verilog for that part of the design. No point doing premature optimizations.
It is also quite amazing that you have 200 people in your Facebook group. I am impressed.
So I am busy reading your code. I love the one line comments, that say what it is that a particular section wire or register does. Most helpful.
It is a bit confusing that there are two versions of the cpu. One at ForthProc.sv and one at Altera/ForthProc.sv. A merge of the two or a comment in the README would be helpful. Could they be done with two separate smaller chunks of Systemverilog, which are conditionally imported?
Similarly there are six different branches. A merge would be awesome. Or at least documentation of what the branches do.
Accepting the existing pull request would also be good.
I believe that this cpu works on both a Lattice board and on an Altera board. It would be good to know which boards it already runs on. It would be even better to have also included all of the configuration files. Getting started with an existing FPGA project is very intimidating. Anything you can do to lower the entrance barrier would be great. Maybe suggest when to buy which board. Comments on which is better, the Lattice tools, or the intel tools, would also be helpful.
I am having a difficult time reading the code. My personal theory is that all Verilog, including my own, is hard to read for software developers, even those of us who have been trained in electrical engineering. Ting wrote gorgeous documentation on how his CPU’s worked. I am tempted to start by writing documentation or comments. Although historically none of my documentation ever gets approved. Maybe because documentation by beginners always includes mistakes.
Another way to understand your chip is to model it in Python. The J1 has an open source emulator written in Python. I am interested in porting it over here. Then I could prototype code on the emulator, instead of on the chip. I think it would also be most useful in cpu testing and verification. Run the test software in both Python and Verilog, compare the output, and make sure that they perform the same. More importantly one could stop the simulation the moment something between the two differed.
There was a recent suggestion to target mainstream languages. A great idea. Mainstream languages all have garbage collectors. My personal interest lies in building a real time garbage collector. But it is hard to do in real time. Maybe do reference counting, including references on the stack, using a flag to indicate if it is a reference or not. The Lisp CPU’s did this. Maybe even have two cooperating processors, one to run the application, the other to clean up the garbage.
There was a recent suggestion to add registers. I do not like that idea as much. The strength of Forth is in real time control. Real time control needs fast context switches, registers slow down that process. The microCore can do a context swap at 4 clock cycles at 25Mhz. My new faculty adviser loved that idea that there are no registers to switch out. Well there are two, the top and next of stack.
I am so impressed that you coded some of the forth directly in memory. I did not realize that was possible. Of course I am still trying to figure out what that code does. I like the idea of a Python script which takes the Forth and generates the memory verilog. Then the forth could also be imported to a Python emulator.
The MicroCore has 84 instructions coded in VHDL 83. Many are numerical operations needed for real time control. They synthesize on every platform. Meaning that the vendors all support VHDL83. The vendors also support designs with multiple languages. They 84 words mostly operate on the top of stack and next in stack . At an abstract level it may be possible to just reuse them in your design. Licensing is permissive.
And of course you code still needs an official license.
In other news, the school semester wraps up in a few weeks. I am so ready for a vacation. I do have a thesis advisor, whose expertise is real time control. He loves the idea of not having to swap out the registers. But I am not sure if I will be continuing. It was great to get a semester’s free education on these topics. Mostly the school is interested in different things than I am, so it may be time to part ways. Or more likely to limit my engagement with the academic program.
Thank you for your work and interest. It has been a long road for us, documentation always comes last in projects like this. We now have a working model to play with.
First thank you so much for doing this.
I think the world really needs a Forth processor written in System Verilog. I believe the J1 is done in Verilog, the EP32/24/16 are in VHDL, and the MicroCore is in VHDL 83. System Verilog is probably the most productive language, so you are on the right side of history. And even if System Verilog does have some inefficiency, one can always drop down to Verilog for that part of the design. No point doing premature optimizations.
It is also quite amazing that you have 200 people in your Facebook group. I am impressed.
So I am busy reading your code. I love the one line comments, that say what it is that a particular section wire or register does. Most helpful.
It is a bit confusing that there are two versions of the cpu. One at ForthProc.sv and one at Altera/ForthProc.sv. A merge of the two or a comment in the README would be helpful. Could they be done with two separate smaller chunks of Systemverilog, which are conditionally imported?
Similarly there are six different branches. A merge would be awesome. Or at least documentation of what the branches do.
Accepting the existing pull request would also be good.
I believe that this cpu works on both a Lattice board and on an Altera board. It would be good to know which boards it already runs on. It would be even better to have also included all of the configuration files. Getting started with an existing FPGA project is very intimidating. Anything you can do to lower the entrance barrier would be great. Maybe suggest when to buy which board. Comments on which is better, the Lattice tools, or the intel tools, would also be helpful.
I am having a difficult time reading the code. My personal theory is that all Verilog, including my own, is hard to read for software developers, even those of us who have been trained in electrical engineering. Ting wrote gorgeous documentation on how his CPU’s worked. I am tempted to start by writing documentation or comments. Although historically none of my documentation ever gets approved. Maybe because documentation by beginners always includes mistakes.
Another way to understand your chip is to model it in Python. The J1 has an open source emulator written in Python. I am interested in porting it over here. Then I could prototype code on the emulator, instead of on the chip. I think it would also be most useful in cpu testing and verification. Run the test software in both Python and Verilog, compare the output, and make sure that they perform the same. More importantly one could stop the simulation the moment something between the two differed.
There was a recent suggestion to target mainstream languages. A great idea. Mainstream languages all have garbage collectors. My personal interest lies in building a real time garbage collector. But it is hard to do in real time. Maybe do reference counting, including references on the stack, using a flag to indicate if it is a reference or not. The Lisp CPU’s did this. Maybe even have two cooperating processors, one to run the application, the other to clean up the garbage.
There was a recent suggestion to add registers. I do not like that idea as much. The strength of Forth is in real time control. Real time control needs fast context switches, registers slow down that process. The microCore can do a context swap at 4 clock cycles at 25Mhz. My new faculty adviser loved that idea that there are no registers to switch out. Well there are two, the top and next of stack.
I am so impressed that you coded some of the forth directly in memory. I did not realize that was possible. Of course I am still trying to figure out what that code does. I like the idea of a Python script which takes the Forth and generates the memory verilog. Then the forth could also be imported to a Python emulator.
The MicroCore has 84 instructions coded in VHDL 83. Many are numerical operations needed for real time control. They synthesize on every platform. Meaning that the vendors all support VHDL83. The vendors also support designs with multiple languages. They 84 words mostly operate on the top of stack and next in stack . At an abstract level it may be possible to just reuse them in your design. Licensing is permissive.
And of course you code still needs an official license.
In other news, the school semester wraps up in a few weeks. I am so ready for a vacation. I do have a thesis advisor, whose expertise is real time control. He loves the idea of not having to swap out the registers. But I am not sure if I will be continuing. It was great to get a semester’s free education on these topics. Mostly the school is interested in different things than I am, so it may be time to part ways. Or more likely to limit my engagement with the academic program.