FPGA’s are great for building parallel applications, there is a huge growth in the market for FPGA’s in the data centres, but they are a nightmare to develop for. A grid of Forth cores would be much more fun.study EE to understand how they convert a design into digital circuitry (synthesis), how to write good code, and how to recognize disastrous code. They take forever to create a large design. The simulators do not always work correctly, so the simulator
I had no idea how bad it was, until I recently started my masters degree in Electrical Engineering, Digital Design in Katowice Poland. I thought Verily and VHDL looked easy, but I completely failed to understand how they work under the hood. One has to
I think it would be a lot more fun to develop prototypes on a grid of Forth CPUs. Changes could be tested instantly. Once the application was developed, optimizations could be made.There are caches that can become inconsistent, and messaging between cores is limited. In contrast with a grid of Forth cores on an FPGA, each gets its own memory area, and can talk to its neighbors. Much conceptually simpler. KISS.
Why not just use a multicore processor running 8th????
Because then I cannot add in some custom logic blocks. Also Multicore processors are optimized for speed of each individual processor, and not for cooperation between processors. The guys who made linux run on multi-core had a very difficult time.
In an ideal world, each Forth CPU would have access to its own external memory, to maximize external memory bandwidth. But in the real world, an FPGA board has just one or two memory banks, so good to do something like vision processing, where oneimage frame gets loaded, and shared with all of the processors. Indeed the Lattice boards even have interfaces for digital cameras.
So let us talk about a particular vision application. Vision processing in a moving vehicle. Or even when the camera is being rotated. The vision processing develops a model of the system being observed. Here are the straight edges, here are the flatsurfaces, here are the curved edges. As the image moves, the model needs to be handed over to the adjacent processor to be updated. At least to calculate velocities. There is a lot of communication between adjacent nodes. So hard to do on a multicore cpu.
Next question: Which Forth core should I use?CPU. The one person who worked equally on both FPGA’s and C compilers was Dr. Ting. I am sorry that he is now gone. But I believe that he optimized the eForth language and CPU to both work best together. So I think that the EP 32/24/16 with eForth is
There are so many Forth FPGA cpus, and so many versions of Forth, it is hard to choose which one to use. Many Forth CPU’s are optimized to fit on an FPGA, many forth virtual machines are optimized to run on the C programming language, or on an Intel
Let me make a few more observations. It is very difficult for a single Forth CPU to compete against commercial mainstream register machines. On the other hand, lots of small Forth cores should be able to outperform a single RISC-V cpu on parallelizableapplications. In the Forth Days 2022 video, Dan Golding reports that their Forth CPU is 1/10 the size of a RISC-V cpu. I suspect that it is more than 1/10th as fast. So potentially 10 Forth cores or even 5 could outperform a single RISC core.
Clearly a dedicated FPGA application will outperform anything we can build on a grid of Forth CPU’s but I also believe that a lot of small developers will be able to release many innovative FPGA applications quickly, and then if the market is there,potentially migrate them to a more optimised implementation.
I was very discouraged that Dr. Ting passed away before I had a chance to work with him. I am very mindful that at the recent Forth2020 video conference there was a lot of grey hair. I hope that we can find a project that grows this community, beforeall of the expertise disengages.
And of course the dream is to build up a large enough community around such a platform, that it eventually gets built in silicon.
There is one project I saw that might fit in https://www.facebook.com/groups/1304548976637542/?multi_permalinks=1639420426483727¬if_id=1678535445817102¬if_t=group_activity&ref=notif
So how does this differ from what they are doing?
Officially they are more focused on building a tablet to make Forth accessible to
more people. I am more interested in something like the GA144, a large number of tiny stack machines working together to solve computationally intensive problems.
They are Forth advocates. I am less interested in Forth itself, and more interested in
advocating for lots of tiny stack processors versus fewer larger register machines.
Of course the stack processors will be running Forth, but they could conceivably run
something else.
They have a primary processor, maybe some more for an AI application. I am more
interested in very parallel applications divided among cores.
They are building a new processor, maybe a new Forth. I want to use existing cores,
with an existing eForth user base.
They are in Verilog, EP24 is in VHDL.
Marcel Hendrix wrote:
Epiphany multicore chips from Adapteva. . The Parallella dev. board can be had for 200$
or so. ( https://www.digikey.nl/en/products/filter/evaluation-boards-embedded-mcu-dsp/786?s=N4IgTCBcDaIA4EMBOCA2qCm6EgLoF8g )
Hugely interesting. A friend wrote Lisp for the device. I thought Adapteva closed down. And now they have been
bought, by a company in stealth mode, and the boards are once again available. HUGELY tempting.
I think "stack processor" is a red herring.The core 1 team reports that their stack processor is 1/10th the size of a Risc-v core. Meaning that i can fit a lot more
of them on a device. And a forth instruction executes in a single clock cycle. So why is it a red herring?
Let me tell you, eForth is not suitable.I would love to know why. I am still learning. The Core 1 guys said th ep16 did not have an I/O op code. They started
out porting the EP16 to ALtera, then ditched the design. I still have not figured out why. I wonder if Dr. Ting was an
electrical engineer who knew what he was doing or not. Not at all intuitive how device synthesis works.
Epiphany multicore chips from Adapteva. . The Parallella dev. board can be had for 200$
or so. ( https://www.digikey.nl/en/products/filter/evaluation-boards-embedded-mcu-dsp/786?s=N4IgTCBcDaIA4EMBOCA2qCm6EgLoF8g )
I think "stack processor" is a red herring.The core 1 team reports that their stack processor is 1/10th the size of a Risc-v core. Meaning that i can fit a lot more of them on a device. And a forth instruction executes in a single clock cycle. So why is it a red herring?
Let me tell you, eForth is not suitable.I would love to know why. I am still learning. The Core 1 guys said th ep16 did not have an I/O op code. They started out porting the EP16 to ALtera, then ditched the design. I still have not figured out why. I wonder if Dr. Ting was an
You misunderstood. eForth is not suitable -> the experts saying don't do it ->
that is the project you should embark in.
(Unless I misunderstood.)
On Sunday, March 12, 2023 at 1:45:27 PM UTC+1, none albert wrote:
[..]
You misunderstood. eForth is not suitable -> the experts saying don't do it ->
that is the project you should embark in.
(Unless I misunderstood.)
Also remember the way ants build a bridge, and how to become
a millionaire.
On 13/03/2023 12:27 am, Marcel Hendrix wrote:
On Sunday, March 12, 2023 at 1:45:27 PM UTC+1, none albert wrote:
[..]
You misunderstood. eForth is not suitable -> the experts saying don't do it ->
that is the project you should embark in.
(Unless I misunderstood.)
Also remember the way ants build a bridge, and how to become
a millionaire.
An expert is one who has learnt how to get others to take all the risk.
On Monday, 13 March 2023 at 09:42:07 UTC, dxforth wrote:
An expert is one who has learnt how to get others to take all the risk.
This might be your approach in your business.
I am in our business more used to the fact,
that the expert understands the issues,=20
puts them all on the table for the ones involved,
and helps with expert advice to move the project forward.
Jurgen Pitaske <jpitaske@gmail.com> writes:
On Monday, 13 March 2023 at 09:42:07 UTC, dxforth wrote:
An expert is one who has learnt how to get others to take all the risk.
This might be your approach in your business.
I am in our business more used to the fact,
that the expert understands the issues,=20
puts them all on the table for the ones involved,
and helps with expert advice to move the project forward.
The sentence from dxforth appeared to be a typical dxforthisms,
although this appeared particularly nonsensical even among
On Sunday, March 12, 2023 at 1:45:27 PM UTC+1, none albert wrote:
[..]
You misunderstood. eForth is not suitable -> the experts saying don't do it ->
that is the project you should embark in.
(Unless I misunderstood.)
Also remember the way ants build a bridge, and how to become
a millionaire.
You can try Mecrisp-Ice (custom stack processor)That is a great idea.
On Monday, March 13, 2023 at 2:36:59 PM UTC+1, Matthias Koch wrote:
You can try Mecrisp-Ice (custom stack processor)That is a great idea.
i am getting educated about these issues. The EP16/24/32 seem to have two issues.
The stack uses a very large shift register, instead of some memory.
It uses latches for registers, advised against in my class.
Both issues are red flags for me.
There must be a reason the J1 CPU is so popular. I need to read more about it.
I guess I am in the process of exploring these different stack machines.
The work on the CORE-1 is also very interesting. I particularly like how they do not use a cross compiler, they just put the Forth code in a memory region to start off with.
The EP16/24/32 seem to have two issues.
The stack uses a very large shift register, instead of some memory.
It uses latches for registers, advised against in my class.
I don't find any evidence of either of these being true. I can't find anything that indicates the stacks are shift registers. Looking at ep16.vhd, here is the code for the entire CPU register set.
"In this design, the CPU latches all data into appropriate registers and stacks on the rising edge of a single phase master clock. Such a synchronous design ensures that all instructions are executed quickly and reliably in a single clock cycle. Whenthe master clock is held steady, the microprocessor retains all data in registers, stacks and memory, consuming very little power. It is thus possible to further reduce its power consumption by reducing the clock rate, or stopping the clock completely.
You can try Mecrisp-Ice (custom stack processor)I did take a look at the Mecrisp-Ice. It runs on the J1a cpu.
On Thursday, March 16, 2023 at 11:55:26 PM UTC+1, Lorem Ipsum wrote:the master clock is held steady, the microprocessor retains all data in registers, stacks and memory, consuming very little power. It is thus possible to further reduce its power consumption by reducing the clock rate, or stopping the clock completely.
Thank you for correcting me. I got it not from the code, but from the documentation.The EP16/24/32 seem to have two issues.I don't find any evidence of either of these being true. I can't find anything that indicates the stacks are shift registers. Looking at ep16.vhd, here is the code for the entire CPU register set.
The stack uses a very large shift register, instead of some memory.
It uses latches for registers, advised against in my class.
"In this design, the CPU latches all data into appropriate registers and stacks on the rising edge of a single phase master clock. Such a synchronous design ensures that all instructions are executed quickly and reliably in a single clock cycle. When
."
I can't find the line where it said that the stacks are implemented as shift registers.
"Read the code" is good advice.
You can try Mecrisp-Ice (custom stack processor)
I did take a look at the Mecrisp-Ice. It runs on the J1a cpu.problem, is that it has no interrupts. The abstract problem is that it was designed to squeeze into a tiny space for a commercial app.
In the past I did look at the J1 CPU. I looked again. It now has 32 bit version, and Python simulators, and verilator to C++ compiler, and even a VHDL version. But it has two problems, one specific, one abstract. If I recall correctly, the specific
I am less interested in building an end user application, and more interested in building a wonderful development environment. A grid of Forth cpu's talking to each other, maybe even interrupting each other. So i think interrupts are critical.
In other news, I have been learning Verilog, and am most unhappy with it.
Here is a large list of Verilog Gotcha's. https://lcdm-eng.com/papers/snug06_Verilog%20Gotchas%20Part1.pdf
From the "Zen of Python"
Explicit is better than implicit.
I am not a full time EE, so an explicit language makes much more sense to me.
I think I much prefer VHDL. Of course the grass is always greener on the other side of the fence.
Thank you everyone for all of the great advice. I feel like you care about these issues. Out of caution, I do not even talk about it at school.
In other news, I have been learning Verilog, and am most unhappy with it.
Here is a large list of Verilog Gotcha's. https://lcdm-eng.com/papers/snug06_Verilog%20Gotchas%20Part1.pdf
Keep in mind that while Mecrisp-Ice (which comes in 16, 32 and 64 bits) is a direct descendant of Swapforth/J1 by James Bowman, I continued development, and it certainly has interrupts. There are also different variants of the processor, and you canuse either shift registers or BRAMs for the stacks. The shift register stacks help when one is short on RAM blocks, and also allow higher maximum frequency in some cases.
When you say "shift registers", what feature in the FPGA are you referring to?
But the iCE40 devices do *not* use the LUTs as memory or shift registers. I see their "General Purpose FPGAs" have "distributed" RAM, which is using the LUTs. But I see no mention of shift registers.
So, are you using the fabric FFs for the stack memory, if not the BRAMs?
Using the features of a given line of parts can save on resource utilization, but ties the design to that architecture. For some, that's not a problem.
configuration single port memories), and HX8K offers 16 kb BRAM.When you say "shift registers", what feature in the FPGA are you referring to?The normal flipflops available in fabric.
But the iCE40 devices do *not* use the LUTs as memory or shift registers. I see their "General Purpose FPGAs" have "distributed" RAM, which is using the LUTs. But I see no mention of shift registers.True.
So, are you using the fabric FFs for the stack memory, if not the BRAMs?Fabric FFs.
Using the features of a given line of parts can save on resource utilization, but ties the design to that architecture. For some, that's not a problem.Fabric FFs as shift register stacks are portable and run on Lattice iCE40, ECP5 and on Altera/Intel MAX10, the families I have used so far. The LUTs are not used, as Lattice iCE40 does not support the "lutram" design.
You correctly point out that using fabric FFs as memory is a waste of resources; but the smallest targets of Mecrisp-Ice come with very limited BRAM. HX1K offers 8 kb of dualport BRAM, UP5K offers 15 kb BRAM (plus 128 kb in total over four fixed-
In these configurations I decided to give Forth the full amount of dualport BRAM memory available, and use 16 elements * 16 bits * 2 stacks = 512 LUT+FF for stack elements in the smallest HX1K, and 32*16*2=1024 LUT+FF for UP5K and HX8K.
The ports to larger FPGAs came later in time, and for these, you decide if you like shift registers, or want to use BRAMs as stacks.
Still, when you say shift registers, you literally turn the FFs into shift registers? Yeah, I guess that's what a stack is when it comes down to it. It shifts in two directions, so each stack word needs a 2:1 mux on the input, and Bob's your uncle.Each FF has a LUT to make up the mux, so it fits well.
Have you looked at the Gowin parts?
But I might also be so burnt out that I swear off electronics forever!
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 399 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 39:29:06 |
| Calls: | 8,336 |
| Calls today: | 13 |
| Files: | 13,155 |
| Messages: | 5,891,234 |
| Posted today: | 1 |