This looks interesting

[PythonLinks]

A 16 bit stack machine running eforth on an altera FpgA. Sadly I cannot figure out what is what. could you please write some documentation?

Chris

[dicpeynado]

Sure, I have added a README with a short explanation and a link to the original project, which is well documented. This project is just moving the design from Lattice to Altera FPGA.

[PythonLinks]

Thank you. I am back. I just applied to graduate school in digital design, if accepted, I want to build on this project. I want to build a grid of Forth cpus. A Forth CPUs may be smaller than mainsream CPUs, but it is hard for one forth cpu to compete with commercial products. But an array of these cpus could outperform alternatives.

No point reinventing the cores, it should be enough work to make a grid of them.
So good to start with something like this.
I think that the ep16 and 32 are very solid foundations. Lots of engineering work went into them. They even/almost went to silicon. There is a mature language eForth running on top of them. What else could I ask for.

Ah yes, great documentation. You can find it here. http://forth.org/OffeteStore/OffeteStore.html

I have a lot to read!

I am only sorry to hear that Dr. Ting passed away recently.

[dicpeynado]

Welcome back.

Some things have changed since I first started this project. I am working on a new Forth CPU called Core I. https://youtu.be/KXjQdKBl7ag

[dicpeynado]

I would recommend joining the Forth2020 group to stay up to date with Forth CPU developments and network with other FPGA guys. https://www.forth2020.org/home

I think you have a good plan to use the eP16. You could also use the J1. The project I am currently working on is meant to get there too, but it is currently in the experimental phase.

All the best with your project. Dr Ting was working with us on this project too before starting his last project which was a Java/Forth FPGA CPU. He would be happy that you benefited from his project and continued it.

[PythonLinks]

I see, you must be the Demitri Peynado from the most recent Core 1 Forth video.

Well the Core 1 is also very interesting to me. They are actually talking about multicore, and they seem to be active. Good to have other people to work with. I did watch both of the videos, and read the code shortly after the 2022 SVFIG Forth day. Here is the link to that code repository. https://github.com/angelus9/AI-Robotics

Two obvious questions. Why did you ditch VHDL and EP16/32 and how is the project going? Which version of Forth are you targeting?

I will have to take a look at the updated code.

[PythonLinks]

Thank you for the advice. I will start paying more attention to the forth2020 monthly meetings.

[dicpeynado]

CORE I is active. We are working towards getting the word COLON to work, which is close, but I've yet to be able to focus on it as much as I would like.

I ditched VHDL because, as a verification engineer, I am much more familiar with SystemVerilog. Don likes SystemVerilog because it is easier to make modifications without causing unnecessary compiler errors, and it is more C which makes it look familiar to more programmers.

The main reason for changing from the EP16 is that the CORE I is designed for AI and robotics, so adding new functionality through words should be easy. We've designed it this way from the ground up. For example, IO operations can be individual opcodes for testing purposes rather than working with a memory-mapped GPIO system. The end goal is to add opcodes for logic programming, array programming and possibly even neural networks. This approach is facilitated by writing the design in a high-level behavioural code style rather than at the register transfer level.

We have no specific target for Forth and allow ourselves to try unconventional approaches. Ultimately, we don't want to write in Forth, but we want to benefit from it as an interactive assembly language and operating system on our FPGA. We plan to implement some base words which are common across implementations (F83 word set http://forth.sourceforge.net/standard/fst83/fst83-12.htm)

Although it is possible, multicore will not be the strength of CORE I. It will be like a tiny interactive FPGA computer controlling other hardware modules running in parallel. However, within the CORE I is a small yet readable CPU (we consider the CORE I itself a computer rather than a CPU), which we have considered the basis for multicore since we know we will have enough FPGA fabric to do this.

[PythonLinks]

Thank you for the excellent advice and description. I probably would have gone with the EP32. EP16 is a better idea. Eventually I may move to the EP24 for processing 24 bit images.

I agree that the ability to add opcodes is critical. A large existing code base is also critical. Both paths are good. Time will tell. It is always good to have two paths in life, not three, go down them as fast as possible. Eventually one closes down, and something else opens up.

[PythonLinks]

I am reading Ting's documentation on the EP32. Beautifully documented. "The T register connects data stack and return stack as a giant shift register." That sounds bad. Push or pop an item, and a whole bunch of stuff gets moved. I would think that some logic could be written to access the right memory or latches. And if accessing memory, another process could be preventing overflow.

What I am learning in school is that the right way to implement things on an FPGA may not be the easiest. I still do not have good judgement in this area. I wonder what the J1 did for stack management. I will have to read more.

I wonder if this shift register stack is another reason why you dropped his design? I know you said it was because of the I/O.